[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Classpath and versioned libraries for Debian-Java



On Fri, Nov 09, 2001 at 12:54:00PM +0100, Max Kellermann wrote:
> 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 :-)

I'm not very good at them. What is the differentce?

> > > 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.

Maybe that is a solution yes.

> 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?

It makes things easier to handle, yes. One though though. Is there
just a problem when two jars that contain the same thing is installed
or is it also problems when you load the wrong one?

If the later is there is no use to have that, we should simply use
two different names.

Regards,

// Ola

> Regards,
> Max

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Björnkärrsgatan 5 A.11   \
|  opal@lysator.liu.se                 584 36 LINKÖPING         |
|  +46 (0)13-17 69 83                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Reply to: