Re: A third party short summary of Classloader woes - aren't they allcaused by..

[ru...@us.ibm.com]

Costin Manolache wrote:
>
> Keep in mind that a next version of JDK will ( probably)
> include JAXP and a parser, so the DOM will be part of the "system"
> ( and I do hope no class loader will override the system classes ).

What will happen when DOM 3 comes out?

Distributing W3C classes with the JDK is a good idea.  Declaring them as
"system classes" is not.

- Sam Ruby

Re: A third party short summary of Classloader woes - aren't they allcaused by..

[Jim Rudnicki <jd...@pacbell.net>]

> >
> > Keep in mind that a next version of JDK will ( probably)
> > include JAXP and a parser, so the DOM will be part of the "system"
> > ( and I do hope no class loader will override the system classes ).
>
> What will happen when DOM 3 comes out?

Exactly!  It can be fixed _today_ by including DOM2, but there remains a
fundamental problem here.

Flux hurts,
Jim

Re: A third party short summary of Classloader woes - aren't theyallcaused by..

[Sergey Sushkov <se...@arcus.lv>]

>
>I agree with that !!
>
>I was just pointing that all APIs that are included with the JDK are
>"special".
>We may hack something to override DOM, but changing interfaces in the JDK is
>
>not easy. If DOM will be included in rt.jar ( or in ext/ ) than the class
>loader used will be the system loader. It's a problem - not that I want it
>this way.
>
>Lets check if DOM2/DOM1 are backward compatible, if so then we don't have to
>worry about this. They are smart people.
DOM2 and DOM1 ARE backward compatible.
__
serg

Re: A third party short summary of Classloader woes - aren't theyallcaused by..

[Costin Manolache <cm...@yahoo.com>]

rubys@us.ibm.com wrote:

> Costin Manolache wrote:
> >
> > Keep in mind that a next version of JDK will ( probably)
> > include JAXP and a parser, so the DOM will be part of the "system"
> > ( and I do hope no class loader will override the system classes ).
>
> What will happen when DOM 3 comes out?
>
> Distributing W3C classes with the JDK is a good idea.  Declaring them as
> "system classes" is not.

I agree with that !!

I was just pointing that all APIs that are included with the JDK are
"special".
We may hack something to override DOM, but changing interfaces in the JDK is

not easy. If DOM will be included in rt.jar ( or in ext/ ) than the class
loader used will be the system loader. It's a problem - not that I want it
this way.

Lets check if DOM2/DOM1 are backward compatible, if so then we don't have to
worry about this. They are smart people.


Costin