This is the mail archive of the java-patches@gcc.gnu.org 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 for Review: JvGetStringUTFChars


On Thursday, Aug 14, 2003, at 03:11 Pacific/Auckland, Mohan Embar wrote:

My only concern is that, in most of the cases where these UTF8
conversions are being done in libgcj, we really want to be able to
convert into any native character set, not just UTF - especially for
windows which afaik does not even use UTF8? So we'll really need
another API entirely.

This other API could also open up a can of worms. The MinGW port has the issues you mentioned, as indicated here:

http://gcc.gnu.org/ml/java-patches/2003-q2/msg00328.html

...but I don't think that unconditionally going against libiconv is
the answer. MinGW doesn't use libiconv, and we probably
wouldn't need to for WinNT-based MinGW because we could
invoke the Unicode OS API directly.

What I have in mind is a wrapper around the standard java character-conversion stuff (ideally java.nio.charset but possibly gnu.gcj.convert since the former isn't really complete/tested yet), but with a fast path to use the JvGetStringUTF etc in the UTF8 case. In turn, gnu.gcj.convert or java.nio.charset API may have providers that wrap iconv or the windows APIs on systems where they exist.


In conclusion, shall I just cash in my chips, not touch cni.h and
simply submit a patch for jvm.h which uses the existing CNI
functions?

Sounds good. Meanwhile I'll see if I can come up with a prototype StringConverter implementation, for discussion.


Regards

Bryce.


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