This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH] [MinGW] for Review: Add UNICODE support to MinGW libgcj(UPDATED)
- From: João Garcia <jgarcia at uk2 dot net>
- To: gnustuff at thisiscool dot com
- Cc: Bryce McKinlay <bryce at mckinlay dot net dot nz>, tromey at redhat dot com, luciano at virgilio dot it, Ranjit Mathew <rmathew at hotmail dot com>, GCJ Patches <java-patches at gcc dot gnu dot org>, java at gcc dot gnu dot org, MinGW Developer <mingw-dvlpr at lists dot sourceforge dot net>, João Garcia <jgarcia at uk2 dot net>
- Date: Fri, 05 Dec 2003 13:13:41 +0000
- Subject: Re: [PATCH] [MinGW] for Review: Add UNICODE support to MinGW libgcj(UPDATED)
- References: <2XMK43GDOJVSSMTSUSJHSOXTOIE0IEZ.3fcfd4b2@p733>
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).
-java.io 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)...
João