John Summerfield wrote:
> On Sun, 15 Nov 1998, Kenny Freeman wrote:
>
> > Hi, you have to add the path to the jar files like (for example):
> >
> > export
> > CLASSPATH=$CLASSPATH:/usr/local/swing/swing.jar:/home/freeman/jars/net.jar:etc
> >
> > that should work a little better for you (once you've added the path to
> > each jar you want to use).
>
> I do hope someone comes up with a better idea than classpath RSN: mine runs
> to well over 2K.
Mmmmm.... I've allways wondered why there isn't a JARPATH environment variable (or
something of the sort), where each .JAR or .ZIP within is treated as being on the
CLASSPATH. This way it wouldn't be neccessary to add new .jar's to your CLASSPATH
every time you want to install a new class library or application - just dump it in
your JARPATH.
On a related note, wouldn't it be nice if compiled runnable/executable classes
(those with a main() method) had a different extension to other classes's (lets say
.eclass or something). This would be completely transparent as far as the language
is concerned and both executable/non-executable classes classes would be treated
the same by the VM/classloader. The .eclass extension would allow legacy file
managers, etc, to identify runnable classes and associate them with the VM,
allowing users to launch them by double-clicking.
Perhaps it would also be cool to be able to specify a default runnable class for a
.jar file, allowing users to invoke an application (which comes distributed as a
.jar) by typing java <jarfilename>
IMO, the cross-platform capabilities of java are seriously hurt by all the hoops
that end-users have to jump through (setting up classpaths, .sh/.bat files, etc)
just to get someone elses application to run. Admittedly, java installshield and
the like do do a good job of setting this stuff up, but a more general (and built
in) solution is required.
[ bryce ]
