Re: Classpath future?

[Tom Tromey]

>>>>> "Etienne" == Etienne M Gagnon <address@hidden> writes:

Etienne> It is my impression that since the Classpath/libgcj merge,
Etienne> most efforts have been deployed on the libgcj side (most
Etienne> probably because most active developers are working mainly on
Etienne> the gcj project).

There have been 65 ChangeLog entries since Jan 1.  Of these, 32 were
from people who work primarily on gcj.  So I wouldn't say that
development has been gcj-centric.  gcj might be the single largest
user of (parts of) Classpath.  But it certainly isn't the only one.

Etienne> (1) It is unreasonible to require VMs to be CNI compatible:

I agree.  There isn't any CNI code in Classpath.  While we would like
to solve the CNI/JNI problem, the solution doesn't really seem likely,
given that nobody is working on it.  We aren't due to scheduling
pressure :-(.

Etienne> (2) It is pretty difficult (if not impossible) to make a good
Etienne> CNI->JNI code converter, and even if such a thing was built,
Etienne> I doubt it would make an optimal use of JNI (by caching
Etienne> MethodIDs and FieldIDs).

Does Classpath really benefit from MethodID and FieldID caching?  (I
have no idea.)

Etienne> I am not willing to go all the way to assign my code to the
Etienne> FSF (I and my university, will defend my rights under
Etienne> copyright law, here in Quebec/Canada).

That's too bad.  My understanding is that this is generally a
requirement of the FSF.  Both Classpath and gcj required this before
the merge started.

Etienne> I would also like to license my code under the LGPL, because
Etienne> it is not my objective to allow RedHat or other companies to
Etienne> use my code without the few additional restrictions of the
Etienne> LGPL over that of the GPL+Exception currently in use in
Etienne> Classpath.

That's unfortunate.  Why don't you want to do this?

I'm certainly not in a position to force Red Hat's goals on you.  Red
Hat's customers do embedded development.  So we write target libraries
that can be used on embedded systems.  That is what libgcj is.
Actually, at one point it was LGPL for the public and under a
different license for Red Hat (then Cygnus) customers, much like Kaffe
is handled by TVT now.  But we wanted libgcj to be part of the general
gcc distribution.  In our estimation this would make it more likely
that other people would use gcj.  At the same time, people recognized
that it was a bit silly that the FSF had two competing class library
projects.  So it was agreed to relicense most of Classpath and begin
merging the code that could be merged.

I think that a 100% merge will never be accomplished.  For instance,
we'll probably never get rid of our special String implementation.
However, I do think we can merge much more than we have done.  And I
do try to merge classes when I can.  For instance when I find serious
bugs in our code, I see if merging will help me clean things up.  That
is where the recent Calendar bug fixes came from.

Etienne> [In fact, this whole licensing issue is probably one of the
Etienne> reasons for the sorry state of the awt support, and the very
Etienne> slow progression of Classpath over that last couple of
Etienne> years.]

While I agree that licensing is partly responsible for the current sad
state of the Classpath AWT, I think that this doesn't actually support
your argument.  In my opinion the Classpath AWT would be better if it
were relicensed for inclusion in libgcj.  Then more people would be
exposed to it and work on it.  For all I know Red Hat might have
gotten a contract to fix it up.  However, this relicensing is
unlikely.  RMS was very clear about that during negotiations.

Tom