I'm a kaffe developer, working with Hakon to fix this issue. Thanks for your quick reply.
Brian Minchau wrote:
>
Hi Hakon, there is an existing bug under bugzilla (http://nagoya.apache.org/bugzilla ), number 20304 that already mentions this hard coded reference to a SUN class. Xerces recognizes that they should make a soft reference.
Maybe you want to add some comments to that bug.
I did ;)
I think it would make more sense for xerces to use the NIO interface, or ICU4J/ICU4JNI, both of which provide a documented way to access charset conversion information. Using sun's undocumented, internal, bound to go away soon (now that they've exposed a documented API to get that data) class in any way (hard coded, reflection) is quite pointless. If you can't do it on java < 1.4, I belive the opitions are to either don't do it then, require 1.4 for that specific bit of functionality, or use an external library like icu4j.
This may be an evil thought but one could always define this in your own code just to make the class loader happy:
package sun.io; Class CharToByteConverter { // ... don't know what to put here ... but something or it will be just as unhappy after it loads this class ... }
Just a thought. I don't know if it is a useful thought, but its a thought.
I was thinking about that, too, but it doesn't fix the problem, unfortunately. Noone knows what the class is supposed to do, so it's impossible to implement it. Tracking the bugs in undocumented internals of Sun's implementations is quite useless in the long run, as those bugs will get fixed, and the interesting internals exposed in APIs.
cheers, dalibor topic
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
