Re: Classpath future?

[Aaron M. Renn]

Etienne M. Gagnon (address@hidden) wrote:
> > Because CNI is
> > both faster and cleaner, the gcj people are not going to adopt that.
> 
> But, as I repeatedly said, CNI is ONLY good for gcj.  The question is, 
> should the VM specific code reside in Classpath, or in their respective 
> projects?  I would say "in their respective projects".  Classpath should 
> contain the common stuff.

There will always be some VM specific code distributed as part of 
Classpath.  This is the specific adapter code needed to implement 
certain parts of java.lang.Class, etc.  The real question is whether we
support certain non-JNI flavors of native libraries for non-VM specific
items such as java.io or java.net.  In pratice, there is very little
of this code.  In an ideal world, we would just use JNI and expect the
VM vendor to conform, rather than trying to include a FooBarVMNI 
version for every Tom, Dick and Harry that comes along.  However, in
the case of gcj, we do have a difference.  They are supplying a lot
of code and development effort to classpath itself.  Additionally,
they will surely agree to maintain this code themselves.  And at some
point we might figure out how to render the question moot with some sort
of unified version.  Finally, gcj (and ultimately classpath) is part
of the GNU project's GCC, which is the official compiler of the GNU
project.  As a GNU project, it is then appropriate for us to provide
a heightened level of support for that target environment, so long as
it doesn't preclude other people from using us.
 
> > My guess is that we will ultimately end up with two versions somehow
> > selected at compile time via a configure flag.
> 
> This could be the subject of a long discussion, but I personally think 
> that the whole configuration/building process should be left to the 
> various VMs to perform as they should provide their own classes for 
> things like j.l.Thread, and each VM has preferences as how and where 
> they'd like to install their classes (as is/in a .jar file/etc.)

At some point classpath has to be built.  It isn't realistic to expect
that each VM will have a custom method of compiling classpath.  Instead,
Classpath will come with its own automake/autoconf compilation system
with appropriate flags to set the necessary options for each VM.  This
will then probably be automatically invoked from the VM vendors top
level configure file, if indeed a full environment is being distributed.

As with Japhar, I expect that for each VM supported, we'll need to build
some custom compile support into Classpath to build with the correct
file names, etc.
 
> > In this context, it becomes painful for
> > companies to provide true linkable objects (and in many applications the
> > code can't be updated anyway), thus causing sales issues on the GNU
> > compiler suite.  As a practical matter, the difference between LGPL
> > and what we have now is not that great.
> 
> There are some difference, and these differences seem to be great enough 
> for RedHat putting a Veto on the license choice.
> 
> Could you please explain to me (us?) in clear terms the problems for 
> embedded systems with the LGPL?  I'd like to know what would prevent 
> somebody from using my VM in an embedded system (or what would be their 
> additional burden due to the LGPL license).

In summary, 

LGPL:
  -- Can be linked to proprietary code
  -- You must distribute the source code to the library (ie, classpath)
     if you modify it in any way
  -- You must supply linkable object code for your proprietary portions,
     so that if someone else wants to take advantage of their freedom to
     modify the library, they will be able to relink.

GPL + Exception (Classpath):
  -- Can be linked to proprietary code (this is the exception)
  -- You must distribute source code to the library (ie classpath)
     regardless of whether you modify it or not.

As you can see, the main difference is that in the LGPL case, a programmer
using the library must distribute linkable object modules.  In the 
current Classpath case, this is not required.  Normally in Java, you
are distributing "binaries" as either .class files or jar files, which
can be dynamically linked against.  So this fulfills the LGPL requirement.
It is built into the language.

However, in the Red Hat case, the gcj folks were building a compiler that
turned Java into native code.  In this case, there is a need to distribute
real re-linkable objects.  Usually not a terrible restriction.  However,
Red Hat (the former Cygnus part of it), targets embeddable computing
applications.  In this case, it can be a hardship to require re-linkable
object code.  In some cases it makes no sense because the embedded code
is on some chip that can't be updated.  Attempting to sell a compiler
with this restriction in the embedded market (with native compiled code)
is a marketing handicap.  Now one can argue that it is a mild one, but
Red Hat believed it was substantial.  Thus our changing of the license to
GPL + Exception to eliminate the need for distributing relinkable object
code.  In 99% of the cases (ie, when Java is used in an interpreted
VM environment rather than compiled to native code), there is no real
difference between the LGPL and what we have today.
 
> > For all intents and purposes, the licensing on Classpath is set in
> > concrete.  It is not my ideal either, but I can learn to live with it.
> 
> Maybe understanding clearly the implications of the differences above 
> would lessen my worries, but as of now, I can't live with a license that 
> seems as weak as the BSD (witout adv. clause) license.

The GPL + Exception is vastly different from the BSD license.  In the BSD
case, someone could take classpath code, modify it, and distribute the
modifications on a proprietary basis.  With our license, the classpath
code can never go proprietary.  Proprietary programmers can link against
it, but this is no real loss since there are equivalent proprietary 
libraries available at no charge (ie, the JDK).  In fact, it is doubtful
any vendor will even know or care whose libraries they ultimately run
against.

-- 
Aaron M. Renn (address@hidden) http://www.urbanophile.com/arenn/