Re: Classpath future?

[Etienne M. Gagnon]

Aaron M. Renn wrote:

> This is the right place.


Thanks for your reply.

> Classpath is and will be designed with a multi-VM environment in mind.


I'm glad to hear this.


> ···

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


> Solving the CNI/JNI issue is an outstanding point.  I do not see us ever
> abandoning JNI as it is the Java standard.  However, JNI has substantial
> performance penalties and creates bogus looking code.


This is not the case for "short methods".  Yes, it means programmers 
should read the JNI book (user guide and specification) ISBN 
0-201-32577-2 first, but this is like asking programmers to read the API 
specification before implementing them, i.e. a reasonible requirement.

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

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

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

Etienne
--
+--------------------------------------------------------------------+
| Étienne M. Gagnon                    mailto:address@hidden |
| Professeur adjoint            Téléphone: (514) 987-3000 poste 8215 |
| Bureau: PK-4930                        Télécopieur: (514) 987-8477 |
| Département d'informatique, UQÀM          http://www.info.uqam.ca/ |
| Auteur de SableVM                          http://www.sablevm.org/ |
| et de SableCC                              http://www.sablecc.org/ |
+--------------------------------------------------------------------+
| Etienne M. Gagnon                    mailto:address@hidden |
| Assistant Professor                Phone: (514) 987-3000 ext. 8215 |
| Office: PK-4930                                Fax: (514) 987-8477 |
| Department of Computer Science, UQAM      http://www.info.uqam.ca/ |
| Author of SableVM                          http://www.sablevm.org/ |
| and SableCC                                http://www.sablecc.org/ |
+--------------------------------------------------------------------+