Re: java library installation issues
On 05 Apr 2001 00:26:11 -0700, Seth Arnold wrote:
> * Egon Willighagen <egonw@subdimension.com> [010405 00:14]:
> > This would certainly be a good option... If we good get it as flexible
> > as the proposed Perl launcher....
>
> I've got to throw in my two cents: I too hate the idea of using any sort
> of script to start execution of 'native-looking' Java programs. (e.g.,
> if someone implements 'ls' in Java the last thing I want is for 'ls' to
> be a perl script to muck around with environment variables or other
> nonsense before running either a compiled and executable 'ls' executable
> or the java interpreter with arguments to run 'ls.class'.)
>
> However, if you are suggesting that we should supply a script to handle
> 'java' and choose among various .jar files or other nonsense, sure. This
> makes more sense -- similar to the navigator script.
>
> I don't think any launcher system should be all that flexible -- it
> should accomodate the most common cases easily (though in my Java
> development time, I've never needed more than just calling the java
> executable directly with no mucking with anything :) -- but there is no
> need to make it very complex since people with specialized needs will
> probably find it much easier to just write their own launcher with the
> proper arguments.
Perl, bash, whatever. The important issues are, IMHO:
1) a facility that allows launching the a debian-installed java
application with only the required jars in it, and potentially with a
required version of the jvm (if the app is known to only work with a
certain one - of course, the package would have to require said jvm).
2) the facility be easy for maintainers and debian-using java developers
to configure and use.
We are talking about interfacing an OS-independent language with a
specific OS in the most efficient and user-friendly manner possible. To
my mind, under any kind of unix, that is a shell script with a simple,
easy-to-remember name, and of course an entry under the GUI menus for
gui apps.
servlets etc. have different needs, but some of the same issues apply. I
would imagine jars for jserv could be handled much like modules in
apache - you select the ones you want included in the classpath.
A generic wrapper for java is not sufficient; if any real number of jars
are distributed then you would have a single large, inefficient, and
potentially conflicting space of loadable classes for every java
application, which is highly unrealistic. It would be like having every
c app linked to every .so file. Yes, java does dynamic loading, but it
has to dig through jars to do it and that can slow things down. Also,
there may very well be conflicting implementations or
non-backwards-compatible versions of the same jar that are required for
some apps. E.g. App1 that requires Jar-v1.jar and App2 that requires the
incompatible Jar-v2.jar.
Making everyone write their own launcher is of course a way to go, but
that doesn't enforce any kind of policy, and policy is one of the things
that make debian better IMHO. Also, with a bunch of hand-coded launchers
there is no opportunity for the system to handle swapping out jvms or
setting global jvm switches or substituting jars or what-have-you. And
the right config file format could probably be used to generate both the
launcher scripts and package dependencies.
--
Paul Reavis preavis@partnersoft.com
Design Lead
Partner Software, Inc. http://www.partnersoft.com
Reply to: