Re: findjava is the question, is fixjava the answer?
In message: <[🔎] 3F85B326.5050606@kaffe.org>
Dalibor Topic <robilad@kaffe.org> writes:
>T. Alexander Popiel wrote:
>> In message: <[🔎] 3F858E30.5030000@kaffe.org>
>> Dalibor Topic <robilad@kaffe.org> writes:
>>
>>>Things like -bootclasspath are only used by broken by design
>>>applications, anyway. It's -X*bootclasspath nowadays with Sun's VM, and
>>>it's there for a single reason: debugging. Applications have no
>>>buisiness replacing classes from the core libraries.
>>
>>
>> In general, I agree... but I'll also say that Sun has no business
>> putting Xerces (of a decidedly old version) into the core libraries.
>> But they do anyway, and if you want to use a recent version of
>> Xerces, you have to go dorking with the bootclasspath.
>
>Well, yes. But no matter which version they put in, it's always going to
>have bugs, and be a decidedly old version in a year from now. I thought
>there was a documented way to replace the parser implementation using
>system properties? How about using your own class loader to load the
>parser classes in their own namespace and using those instead?
I have not found any documented way of replacing the parser version.
Mangling bootclasspath to do it isn't documented, either... but follows
from first principles.
Given that the code which is having trouble is being run inside both
jboss and weblogic, we don't have particularly good control of the
classloader (unless we do a whole bunch of platform-specific dinking
for each one).
The core libraries have no business depending on or including separately
distributable packages like xerces... but that's a rant for another day.
- Alex
Reply to: