Re: A suggestion to list core classes
>>>>> "Ean" == Ean R Schuessler <ean@brainfood.com> writes:
Ean> Yeah, this is kind of good. I was thinking about a system
Ean> where each Java aware package puts a file in an /etc dir,
Ean> with init.d looking priorities.
Ean> So you might have:
Ean> /etc/java/classpaths/
Ean> 00_Kaffe.txt
Ean> 10_JServ.txt
Ean> .
Ean> .
Ean> .
Why do you need priorities? Order should not matter. If two
packages provide the same classes they should conflict or use
alternatives.
How about using a stripped down version of the extension mechanism
used in Java2 http://jsp2.java.sun.com/j2se/1.3/docs/guide/extensions/?
Instead of putting zip-, jar- and class-files in /usr/share/java,
every package should put jar files (and nothing else) into
/usr/share/java/ext and native libraries into
/usr/share/java/lib/$(uname -m).
Ean> All of these would get sourced to form a composite
Ean> CLASSPATH. I hadn't really considered the base class
Ean> problem. Maybe a combination of the two systems.
I don't see the need for /etc/java-core-classes. Every VM should be
able to find its core classes without it. This implies that there
should be no need to put core classes into CLASSPATH.
If VMs need to have their core classes in CLASSPATH then they should
add their core classes to CLASSPATH themselves internally. These
VMs may of course use a file like /etc/<vmname>.config but I don't see
why every VM should provide /etc/java-core-classes.
Ean> On Tue, Aug 29, 2000 at 10:05:25AM +0200, Stephane Bortzmeyer wrote:
>>
>> >From Edouard G. Parmelan <egp@free.fr>, one of the Kaffe
>> >upstream developers,
>> a proposal to the Java policy:
>>
>> Each java-virtual-machine comes with a /etc/java-core-classes (using
>> alternatives to manage it). This file contains the list of jars and
>> directories with core classes.
[...]
Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux.html
JVM'01: http://www.usenix.org/events/jvm01/
Reply to: