Re: The evils of /usr/share/java/repository

[Jeff Turner <jeff@socialchange.net.au>]

On Sat, Sep 15, 2001 at 08:54:19PM -0400, Andrew Pimlott wrote:
> On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> > But I'll spare you that ranting; let's just say I think it's a
> > horrifically bad idea to have a free-for-all in one's classpath.
> 
> I tend to agree, though I should point out that the opposite view
> has support.  For example, Per Bothner said in a previous thread,
> 
>     In Java we have a global namespace, so the user/developer should
>     not have to specify classpaths etc by default.
> 
>     (http://lists.debian.org/debian-java/2001/debian-java-200104/msg00014.html)

There isn't a global namespace. How could there be, given that Java has no
notion of class versioning? If app A requires a later, incompatible version of
a class than app B, then no matter what the classpath order, one is going to
break.

> I mention this because Per qualifies as something of an authority
> IMO but has not not appeared on this list lately.

Of course it's not as clear-cut as my ranting suggests ;) If there is a good
use-case for a global classpath, I'd be interested to hear it.

> > Developer communities gradually gain experience, and if the Java
> > community has learned anything, it's that **classpaths are evil**.
> 
> Do you think this is for some inherent reason (eg, the desire or need for
> multiple implementations of API's), or simply because the Java community has
> botched the idea of a global namespace (by making incompatible changes
> without moving in the namespace)?  Do you have any references for this
> viewpoint?

With no class-level versioning support, I don't see how a global namespace
could be feasible. Should programmers be changing package names for
incompatible versions? org.apache.xalan1, org.apache.xalan2 etc? If xalan2 is
backwards-compatible with xalan1, that's too bad; all your code is linked
against "org.apache.xalan1". I don't see how it could possibly work, and in the
projects I'm involved with, programmers make no attempt to do this. If a
project breaks backwards-compatibility, that's too bad; mention this fact in
the release notes and move on.

What would be nice if there was:
 - some way to version classes
 - some way to "symlink" a class, to indicate it's backwards-compatibility

That would allow a linking mechanism like /usr/lib. For example, one could
write a class as follows:

package org.apache.xalan;
version 1.1.2;
public class SomeClass {
	..
}

Then in the manifest (or somewhere), indicate that version 1.1.2 of SomeClass
is backwards-compatible with 1.0. Then the "import" command could be extended
to specify version:

import org.apache.xalan.SomeClass, 1.0;

So if 1.1.2 is present in the VM, and is marked as backwards-compatible, it
will be used. However, if someone specifically wants 1.1.2 functionality, that
can import that directly:

import org.apache.xalan.SomeClass, 1.1.2;

Anyway, just dreaming ;) Here's an interesting snippet of conversation from the
XML-DEV mailing list on the subject of versioning:

"[David Megginson, SAX author]
 > In Perl or Java, package names do not change with each new release:
 > Java2 still uses the java.util package name just like Java 1.0 and Java 1.1
 > did, even though the package's contents have changed considerably.

 [Dan Connolly, W3C]
 There are advantages and disadvantages to this... Java software is often
 labelled with out-of-band instructions on resolving Java package names ala
 "you need at least JDK 1.2 to compile this package" and such. They make it
 more convenient to install version 1.1 in place of version 1.0 on some machine
 and continue to use the code that was compiled on that machine against 1.0,
 but they make it less convenient to coordinate releases on a global scale.

 COM takes the other approach... they provide compile-time friendly aliases for
 UUIDs, but released code references the globally scoped UUIDs. And the COM
 design recognizes that code built against 1.1 libraries (using, e.g.  function
 OpenEx from interface Syslib) might in fact be installed on a machine with 1.0
 libraries (where inteface Syslib only has Open, not OpenEx). COM provides
 different global names for Syslib version 1.0 and syslib version 1.1 so that
 this code won't crash by trying to call a non-existent OpenEx function in the
 1.0 library.
 
 ..
 
 But that doesn't mean Java package name style versioning is right and COM
 interface style versioning is wrong.  It just means that each is more
 cost-effective than the other in some cases.
 "

  -- http://lists.xml.org/archives/xml-dev/200005/msg00573.html


So IMHO, Java has never had, and probably never will have, a global namespace,
due to lack of language-level versioning support. Therefore any attempt to
construct a global namespace (having a system-wide classpath) will inevitably
result in namespace clashes.

--Jeff

> Andrew