[Classpathx-discuss] Re: servlet code

[Per Bothner]

Tom Tromey <address@hidden> writes:

> What is the controversy again?

The question is should packages installed in appropriate magic locations
automatically be made part of the visible package space of gcj.

The issue appears to be control (and lack of surprises) vs convenience.
Some people dislike having the compiler or runtime system magically
search a ton of third-party extensions, and want control over which
version is picked for any given application.  (Note one might have
multiple versions of a Java library installed.)

Some are also concerned about performance.  For us that should not
be an issue except at compile-time.

In favor of convenience there is the argument developers should not
have to specify lots of paths.  Also, Java does use a global namespace,
and tha should be enough to resolve conflicts, at least in the common
default case.

> I think when searching for .class files we ought to follow whatever
> javac does.  javac compatibility is a longstanding goal, and I think
> it is a reasonable one.

Well, if a .jar installed in the appropriate extensions directory,
then JDK (both java and javac) will automatically make classes in that
.jar visible.  So javac compatibility also argues for automatic
visibility - at least to the extent that installed packages are viewed
as extensions.

My ideal would be that that for every .jar file installed in
/usr/share/gcj (say) there should be a matching .so file in /usr/lib.
The classpath used by gcj automatically includes all of
/usr/share/gcj/*.jar, except if there are multiple versions of the
same library, we prefer the least specific version (e.g FOO.jar over
FOO-2.0.jar over FOO-2.0.1.jar).  Also, if the compiler makes a
reference to a class found in FOO-XX.jar, it automatcally
causes -lFOO-XX to be added to the link command line, but only if
FOO-XX.jar is not explicitly listed in the CLASSPATH.
-- 
        --Per Bothner
address@hidden   http://www.bothner.com/per/