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

Re: CLASSPATH and Jikes



On Wed, Apr 03, 2002 at 05:31:53PM -0800, Joe Emenaker wrote:
> 
> > I was just thinking of a simple way to set up my classpath so I made
> > this suggestion. But if it is not common to do somthing like that, then
> > I have to live with that. And maybe collecting all libs might not lead
> > to the expected result, because of combining libs in different versions
> > with the same classes in it. Then you need a script that checks the
> > consistency of the classpath and warns when there are classes more
> > then one time in the classpath
> 
> I'm beginning to think that we need a requires/provides database for java
> libs or something. One thing I've noticed about JDK 1.4 is that there's a
> lot of stuff now included in the basic package that used to be available as
> a separate package. Javasoft's XML libraries are one example. So, with
> previous versions of the JDK, you'd need to specifically include your XML
> parsing libs... but you don't with JDK 1.4.
> 
> So, I'm wondering if it would be worthwhile for a Debian system to have a
> database very similar to the dpkg database... describing which packages
> depend upon which other ones... and which JVM's provide which packages
> natively. That way, if I need the javax.xml libraries, my startup script
> could include something like:

I think it is worth it, yes. For issues that virtual packages can fix
it should be used. Like if someone packages a free implementation of
something that a jvm provides a virtual package should be used also
so the jvm can add it too.

>    JVM="JDK1.3"
>    CLASSPATH=${CLASSPATH}:`require-java-library "$JVM" javax.xml`
> 
> When JVM is "JDK1.3", then the require-java-library script would return the
> path to the jar that had the javax.xml tree in it. If JVM were "JDK1.4", the
> script would return nothing at all, since the javax.xml stuff is included in
> JDK1.4. This is kind of a crude example. I've got some other ideas that
> would make this a bit slicker... but you get the idea.

But as you have noticed a CLASSPATH database is needed too to tell where
it is stored.

> This can help reduce the problem of multiple jars in the classpath having
> the same packages. It should also reduce the number of unneeded jars in the
> classpath... which can't hurt execution times.

Agreed.

If people have suggestion on how to implement it I'll be more than happy.

Regards,

// Ola

> - Joe
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-java-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

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


-- 
To UNSUBSCRIBE, email to debian-java-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: