[no subject]
unsubscribe
Re: CLASSPATH and Jikes
[EMAIL PROTECTED] writes: > I also think the jikes-kaffe, etc proposals are silly: You should > be able to achieve the same with a simple "jikes -bootclasspath > /wherever/kaffe/puts/Klasses.jar". Oh, you don't seem to know the path from the top of your head! Me neither. That's the point of jikes-kaffe: relieving you from having to remember the obscure bootclasses path(s). Of course this could be combined sensibly with your idea: If everybody providing a JRE would provide /usr/share//.classpath we could enhance jikes (or a simple shell wrapper, not necessary named "jikes") so that "-jre foo" would take the base classes from package foo. Using *just* alternatives is IMHO not enough as the needs of some users may differ from the system default. -- Robbe signature.ng Description: PGP signature
Re: CLASSPATH and Jikes
On Tue, Apr 02, 2002 at 08:43:55PM +0200, Robert Bihlmeyer wrote: > [EMAIL PROTECTED] writes: > > > I also think the jikes-kaffe, etc proposals are silly: You should > > be able to achieve the same with a simple "jikes -bootclasspath > > /wherever/kaffe/puts/Klasses.jar". > > Oh, you don't seem to know the path from the top of your head! Well, I would put it once in my Makefile and forget about it. :-) > Me > neither. That's the point of jikes-kaffe: relieving you from having to > remember the obscure bootclasses path(s). > > Of course this could be combined sensibly with your idea: If everybody > providing a JRE would provide /usr/share//.classpath > we could enhance jikes (or a simple shell wrapper, not necessary named > "jikes") so that "-jre foo" would take the base classes from package > foo. Absolutely, this idea is nicer. It just requires a little more infrastructure, and I was trying to give the simplest version of the concept (which is that the ability to choose core classes should be decentralized). It can be seen as one step towards the full Java registry idea. BTW, I remembered that jikes knows how to read command-line arguments from a file, so "jikes -jre $foo" just becomes "jikes -bootclasspath @/usr/share/java/$foo/bootclasspath", or similar. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CLASSPATH and Jikes
On Sun, Mar 31, 2002 at 02:13:32PM -0800, Stephen Zander wrote: > > "Colin" == Colin Watson <[EMAIL PROTECTED]> writes: > Colin> That sounds like it would work better with autobuilders, > Colin> too - you could build-depend on jikes (>= foo), invoke > Colin> jikes-kaffe, and expect it to work everywhere. > > What he said This is a nice idea. At the risk of bloating Packages a bit more, I think I'll implement this instead of using debconf. Much easier for each user to select what classes they want to compile with. Nevertheless, there still remains the problem with alternatives and javac. Right now I have jikes set on a relatively low priority value as a javac replacement. Each of these scripts should, IMHO, be javac alternatives as well. But what should their priority be? Which classes are better? Any ideas? - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[no subject]
unsubscribe
Re: CLASSPATH and Jikes
[EMAIL PROTECTED] writes: > I also think the jikes-kaffe, etc proposals are silly: You should > be able to achieve the same with a simple "jikes -bootclasspath > /wherever/kaffe/puts/Klasses.jar". Oh, you don't seem to know the path from the top of your head! Me neither. That's the point of jikes-kaffe: relieving you from having to remember the obscure bootclasses path(s). Of course this could be combined sensibly with your idea: If everybody providing a JRE would provide /usr/share//.classpath we could enhance jikes (or a simple shell wrapper, not necessary named "jikes") so that "-jre foo" would take the base classes from package foo. Using *just* alternatives is IMHO not enough as the needs of some users may differ from the system default. -- Robbe signature.ng Description: PGP signature
Re: CLASSPATH and Jikes
On Tue, Apr 02, 2002 at 08:43:55PM +0200, Robert Bihlmeyer wrote: > [EMAIL PROTECTED] writes: > > > I also think the jikes-kaffe, etc proposals are silly: You should > > be able to achieve the same with a simple "jikes -bootclasspath > > /wherever/kaffe/puts/Klasses.jar". > > Oh, you don't seem to know the path from the top of your head! Well, I would put it once in my Makefile and forget about it. :-) > Me > neither. That's the point of jikes-kaffe: relieving you from having to > remember the obscure bootclasses path(s). > > Of course this could be combined sensibly with your idea: If everybody > providing a JRE would provide /usr/share//.classpath > we could enhance jikes (or a simple shell wrapper, not necessary named > "jikes") so that "-jre foo" would take the base classes from package > foo. Absolutely, this idea is nicer. It just requires a little more infrastructure, and I was trying to give the simplest version of the concept (which is that the ability to choose core classes should be decentralized). It can be seen as one step towards the full Java registry idea. BTW, I remembered that jikes knows how to read command-line arguments from a file, so "jikes -jre $foo" just becomes "jikes -bootclasspath @/usr/share/java/$foo/bootclasspath", or similar. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CLASSPATH and Jikes
On Sun, Mar 31, 2002 at 02:13:32PM -0800, Stephen Zander wrote: > > "Colin" == Colin Watson <[EMAIL PROTECTED]> writes: > Colin> That sounds like it would work better with autobuilders, > Colin> too - you could build-depend on jikes (>= foo), invoke > Colin> jikes-kaffe, and expect it to work everywhere. > > What he said This is a nice idea. At the risk of bloating Packages a bit more, I think I'll implement this instead of using debconf. Much easier for each user to select what classes they want to compile with. Nevertheless, there still remains the problem with alternatives and javac. Right now I have jikes set on a relatively low priority value as a javac replacement. Each of these scripts should, IMHO, be javac alternatives as well. But what should their priority be? Which classes are better? Any ideas? - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
