Classpath future?

[Etienne M. Gagnon]

Hi.

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.

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?

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?

I think it is OK if the Classpath project decides to mostly be "libgcj". 
 In that case, maybe it should say so on its web pages, and then simply 
drop completely any C/JNI native support in favor of CNI.  If this is 
the case, I am ready to get involved in starting a parrallel project, 
based on the Classpath code base, that would dedicate itself to be a 
library provider for as many Free VMs out there.

If the Classpath project decides, instead, that supporting as many Free 
VMs is the goal, they should then question whether writing native code 
targetting a single environment (CNI) is really appropriate.  I'm not 
saying CNI should be completely dropped, I'm just saying it should 
probably be done under the gcj project, instead of Classpath, so that 
the Classpath code base remains consistent for as many VMs as possible.

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

Again, please direct me in the right direction if this is the wrong 
forum (or person) to ask.

Regards,

Etienne

PS:It would have been nice to get a reply to my message(s) on the 
JNI/CNI issue.  Please feel free to do so.  I won't bite;-)
--
+--------------------------------------------------------------------+
| É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/ |
+--------------------------------------------------------------------+