Re: High memory usage with jdk1.4.x

[Dean Hiller]

I thought sun actually did some work so you could pop it in an 
extensions directory of the jre and it would override.  I can't 
remember, but I thought I read an article about that specifically 
concerning xerces, so the implementation changed.  Unless the xerces 
interface has changed, this would work.  I haven't noticed if it has 
changed at all, but that could be because I may not be using new 
functions that were added.
dean

Dalibor Topic wrote:
Hi Joseph,
Joseph Kesselman wrote:

Are you aware that JDK 1.3 and 1.4 come with relatively ancient 
versions of
Xerces, and have you remembered to override that with the current code
before running your tests? It isn't just a matter of setting the 
classpath,
unfortunately.

Well, yeah, congratulations to sun for using the same namespace when 
they imported xerces into their class library. That's bound to cause 
exactly this type of problems. They should have chucked it in into 
sun.external.* or something like that.

I wouldn't recommend fiddling with the bootclasspath, unless you're 
debugging a VM. It's an unsupported option, basically, and not 
guaranteed to function between VM releases, like all -X options. It 
probably doesn't work on gcj, and other free runtimes, as well.

Can't Xerces fix this type of problems by allowing the user to specify 
what class loader to use to load itself? An jaxp.classloader option 
would be great, so that jaxp.classloader="" uses the default class 
loader, and jaxp.classloader="myXercesLoader" instantiates my xerces 
loader as the Thread's contextLoader. Would taht work?

cheers,
dalibor topic
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]