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:[EMAIL PROTECTED] |
| 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:[EMAIL PROTECTED] |
| 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/ |
+--------------------------------------------------------------------+
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
