This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [MinGW] for Review: Add UNICODE support to MinGW libgcj(UPDATED)

Hi All,

at this stage, I am supporting Mohan's patch at 100%. The proposed patch
solves the problem at present time and seems to set an easy and complete
path to the future. The rationale can also be applied all across libgcj
whenever this kind of conversion is necessary for Win32:
-JvNewUTFString() (CNI).
-NewStringUTF() (JNI). native functions.
-and in many more functions...

But I would like to add something to the following topic.

Mohan Embar wrote:

>>I'm presuming its just not really possible to just determine at runtime
>>which (ansi or unicode) should be used, right?
>It is, but I deemed this way more trouble than it's worth.

It would also duplicate code in a larger scale, without any relevant benefit.
I think that everybody would like libgcj with the smallest possible footprint
at runtime. At least everybody that would like to use it statically linked...

Any special case with a "Major Need for Speed" (I cannot remember of any
exemple in current Java applications) can be solved (if we do not want to have
a "special" unicode build of libgcj at present time) by overriding the relevant
methods in derived classes and using CNI to implement native methods... But I
do not see a real need for this strategy when using gcj! If someone is
seriously optimizing for speed at present time (using FSF tools), I would
expect s/he to be using g++ for the process (even if the GUI and
non-speed-critical methods are written using SWT and Java)...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]