Re: Classpath future?

[Aaron M. Renn]

Etienne M. Gagnon (address@hidden) wrote:
> Hi.

Thank you for writing.
 
> I have some questions about the future of Classpath.  Maybe this is not 
> the right place to ask such questions (and get answers); please point me 
> in the right direction if so.

This is the right place.

> It is my impression that since the Classpath/libgcj merge, most efforts 
> have been deployed on the libgcj side (most probably because most active 
> developers are working mainly on the gcj project).  But, more 
> importantly, it seems that a shift happened in the objectives of the 
> Classpath project (please correct me if I'm wrong).  Originally, 
> Classpath was meant as a Free replacement for the proprietary Java class 
> libraries, targetting as many Free VMs as possible (but initially, for 
> technical reasons, Japhar).  This seems to have shifted to make 
> Classpath mainly a library provider for the gcj project, while 
> accomodating other VMs only if this requires a minimal effort on top of 
> the gcj work.  Is this so?  Or, is supporting as many Free VMs still a 
> fundamental objective of Classpath?

Classpath is and will be designed with a multi-VM environment in mind.
At this point, the gcj environment is probably the prime target (along with
the original Japhar JVM, where development seems to have dramatically
slowed).  However, nothing will be done to preclude or make it seriously
difficult to interface to other VM's.  

The vast majority of the classes in the standard library don't know or
care what VM they run on.  They are effectively user level code.  Additionally,
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.
 
> On the technical side:  Classpath cannot be both gcj specific (e.g. CNI) 
> and compatible with other Free VMs without duplicating efforts to 
> support JNI:
> (1) It is unreasonible to require VMs to be CNI compatible: e.g. CNI, 
> because it gives direct access to fields, is incompatible with precise 
> garbage collection schemes, or bidirectional object layout, etc.
> (2) It is pretty difficult (if not impossible) to make a good CNI->JNI 
> code converter, and even if such a thing was built, I doubt it would 
> make an optimal use of JNI (by caching MethodIDs and FieldIDs).  And, as 
> I pointed in an earlier message, it seems overkill to encode a few short 
> methods in C++.
> 
> So, the question is: what future direction is the Classpath project taking?

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.  Because CNI is
both faster and cleaner, the gcj people are not going to adopt that.
My guess is that we will ultimately end up with two versions somehow
selected at compile time via a configure flag.

Unless some work has taken place I'm unaware of.
 
> And finally, there are some lingering issues...  I am ready to 
> contribute code, patches and bug fixes to the Classpath project, but, 
> like many others (I'm sure), I am not willing to go all the way to 
> assign my code to the FSF (I and my university, will defend my rights 
> under copyright law, here in Quebec/Canada).  I would also like to 
> license my code under the LGPL, because it is not my objective to allow 
> RedHat or other companies to use my code without the few additional 
> restrictions of the LGPL over that of the GPL+Exception currently in use 
> in Classpath.  [In fact, this whole licensing issue is probably one of 
> the reasons for the sorry state of the awt support, and the very slow 
> progression of Classpath over that last couple of years.]  Do you have 
> any plans to relax your licensing rules?  (In a parrallel project, I 
> would relax them, while keeping the "clean-room" status).

In effect, the Java language itself supplies the "object code" modules
suitable for linking by its very nature.  Red Hat had a very specific
objection to this in the case of compiling Java (which gcj does) targetted
at embedded computing.  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.

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.

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