Re: Classpath future?

[John Keiser]

On 12 Jul 2001 11:01:30 -0400, Etienne M. Gagnon wrote:
> Aaron M. Renn wrote:
> 
> <snip>
> 
> > we have adopted a de facto policy that everything which can be written
> > in Java, will be written in Java, thus maximizing portability among other
> > things.  We have designed for a multiple VM environment by putting a
> > small number of adapter classes that form the interface between classpath
> > and the VM for those few classes which must be VM aware.
> 
> 
> OK, we can discuss the technical matters of how the VM interface and the 
> native could could (should?) be structured later.  But, at least we seem 
> to agree that most of the code should be written in Java.
> 
> <snip -- JNI/CNI discussion> 
> 
> > 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.
> 
> > 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.)
> 

I will weigh in on the technical part of the VM interface, at least.
The VM specific code *does* currently reside (at least logically) with
the VM itself.  Each VM is expected to create its own j.l.Thread, for
example.  Where the code actually resides (the fact that the Japhar and
Kaffe code happens to hang off our tree) is not as big a factor.  I
think it is advantageous to have at least one implementation of the VM
interface in the Classpath tree, for VM manufacturers to look at and
branch off of (there will be a good deal of copying).

The VM manufacturer also is able to determine his own packaging if he
does not like the method Classpath uses, but the ability to plug in your
classes into the tree and run configure/make to get yourself a zipfile
is a very useful thing because it is common to many VMs.  Anything which
can be reused, should be.

On the other hand, *as much as possible* is implemented in Classpath
proper so that VMs will share as much code as possible (except when the
VM can do something much more efficiently than Classpath could).  We
even go so far sometimes as to create analogue classes (like VMObject)
that require the VM to implement just a few methods, where the main
j.l.Object sits in Classpath proper, implementing all the common
methods.

> > 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).
> 

As far as I understand it, there are no problems whatsoever with any
sort of system that embeds LGPL'd products.  LGPL is not viral in the
linking sense.

As to whether this is good or not, this is a matter of opinion.  My
opinion is that it is good, but I'm not gung-ho GPL--I want more
eyeballs for software I write, and I want to help as many developers as
possible and make it so that as much as possible, code is shared.

> > 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.
> 

I believe that, if you want to make sure that anyone linking with your
VM is free software also, the best course would be to GPL your copy of
the VM interface and the VM as well.

--John