Re: Java libraries and proposal.
On Wed, Apr 11, 2001 at 12:32:12PM -0700, Per Bothner wrote:
> That is fine for nicely-packaged libraries and applications. However,
> I'm concerned about a random Java programmer who should not have to
> manually fiddle with their classpath. Such programmers should be able
> to write Java code without having to know which jar is where. Also,
> if each application has to specify jars, then you also complicate the
> life of people developing such applications. Hence, I feel the
> 'add everything" approach is a reasonable default.
The programmer would just specify the name of the jar, like with the C
compiler's -l flag.
Some think the hierarchical class/package namespace makes that sort of
thing obsolete, but I don't buy it. C++ has namespaces, but you wouldn't
default to linking your entire libdir to every C++ application unless it
said otherwise, even with a lazy dynamic linker. Java shouldn't be any
different in this sense.
(Yes, I'm aware that I'm ignoring certain issues in how a dynamic linker
would find a C++ class in an .so compared to how a JVM would find a .class
in a .jar, as well as some issues of namespace coordination. It's not that
I'm unaware of them or think they'd make no difference. I just don't think
they'd make ENOUGH of a difference, qualitatively, to make add-everything
the Right Thing for Java but not for C++.)
I wrote:
> > The 'add everything' approach only invites DLL hell.
Per Bothner continued:
> Well, first this is what Sun does, at least to some extent, with the
> "extensions" mechanism.
How very unfortunate.
> Secondly, DLL hell as I understand it is a completely different problem,
> due to lack of support for multiple versions of a library, and applications
> installing a version they need without consideration for other applications.
If an application were to install a new, incompatible version of a .jar
library, even with a version of add-everything that prioritised multiple
versions so that only one would be used, all the 'informal' applications
that were using the old version implicitly would break when the new version
was installed. Basically, for applications that didn't declare a
dependency on a particular library version it would be as if the support
for multiple versions didn't exist at all, thus dragging them into DLL hell.
I see no problem with an end-user script to run unpackaged applications in
a 'fat' library environment (although I'd never use it myself, too slow),
but if you encourage people to put sloppy stuff like that in '/usr/bin' what
you end up with perfectly satisfies the above definition of 'DLL hell'.
Packaged, or even plain released, libraries and applications should be
encouraged to specify what they really need, and to construct proper
(versioned!) dependencies for the release .jar when it is built, just
like the link step for any other compiled application or library.
--
James Deikun, Techie(tm), CSI Multimedia
The opinions expressed &c.
Reply to: