You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by bu...@apache.org on 2003/09/27 17:29:58 UTC

DO NOT REPLY [Bug 20304] - Dependency on sun.io.CharToByteConverter

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20304>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20304

Dependency on sun.io.CharToByteConverter





------- Additional Comments From robilad@yahoo.com  2003-09-27 15:29 -------
This bug also breaks xerces, and applications using it on kaffe, beside breaking
it on gcj. It breaks xerces on *any* virtual machine, that hasn't been derived
from Sun's source code. Please fix 

I'd propose to use reflection to pick the CharsetEncoder from NIO if its
available. Please don't use internal classes from some particular implementation
of Sun's JVM, unless you're willing to accept patches for kaffe.io.Char*,
gnu.java.io.Char* etc. But then xerces-j wouldn't compile anywhere ;)

If you want to use a clean, nice solution, it would be better to employ IBM's
ICU4J to do the conversion job. You can find ICU4J here:
http://oss.software.ibm.com/icu4j/. In fact, if character set conversion is so
much trouble, there is also ICU4JNI which uses the ICU library written in C++.

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org