Re: Classpath and versioned libraries for Debian-Java
On 0, Ola Lundqvist <opal@debian.org> wrote:
> On Fri, Nov 09, 2001 at 11:46:53AM +0100, Max Kellermann wrote:
> I think so yes. I have not tested it though. Maybe it solves that
> issue, and maybe not. Anyway this is a java2 thing so we have to make
> a wrapper (or similar mechanism) for java1.
I just noticed I mixed library references in Manifest files and Java extensions, but they are similar, and as far as I know them, they're not good. If anyone feels they're sufficient for our problems, please explain :-)
> > But look at the TRAX API, the TRAX classes included in Xalan call concrete
> > Xalan classes in the TRAX factory classes (it has to, somehow). Another
> > XSLT processor will call their own concrete classes in the TRAX. So TRAX of
> > Xalan conflicts with TRAX of [fill in any other TRAX-implementing XSLT
> > processor here]. The same with javax.xml in XML parsers. That's what I meant
> > here.
>
> Then it actually does not provide it right? It provides something else just
> very similar.
Hm, interesting point.
Xalan does provide the TRAX API, the same as j2sdk1.3 provides java-virtual-machine - just an implementation, not the "one exact" copy of it. So it's ok for Xalan to tell it provides TRAX.
Maybe we should rename some things...
Xalan "provides" TRAX
Xerces "contains" DOM
More than one library which "contains" DOM interfaces may be in the same classpath. Two libraries who both "provide" TRAX, but their special implementation of it, so they must not be mixed.
DOM can never be "provided", it can only be "contained", because they're all identical.
TRAX can never be "contained" because it must contain Library-specific classes. Libraries can "provide" their implementations.
Does that sound better?
Regards,
Max
Reply to: