Re: Classpath future?

[Jeff Sturm]

"Etienne M. Gagnon" wrote:
> 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.

I can see why it would seem that way.  The gcj project has made a great deal of
headway since the merge.  More, it seems, than the free VM projects (or perhaps
I just don't hear as much about those).

Though I don't speak for the project, I'm not aware of any conscious decision to
change the project's goals.  I'd say it's a matter of head count: if more
volunteers are on the gcj side, the project will veer that way inevitably.

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

Ideally, the native parts will be minimal, as those are the least portable in
any event...

> (1) It is unreasonible to require VMs to be CNI compatible: e.g. CNI,
> because it gives direct access to fields,

True.

> is incompatible with precise garbage collection schemes,

False.

> or bidirectional object layout, etc.

??? (unfamiliar with this term)

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

I think you can find a subset of CNI and JNI however that is very similar.

Caching method/fieldIDs is painstaking work, as is exception handling in JNI.  I
once used C++ wrapper classes for JNI work that made it quite a bit more
palatable (and more CNI-like).   These classes could cache field/method lookups
whenever appropriate.  If I still wrote any JNI code, that's what I would do.

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

Why not just contribute to classpath?  I don't imagine they would refuse JNI
contributions.  (Is there even any CNI code in classpath?  I haven't looked
lately.)  Forking seems like overkill for what you want to accomplish.

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

Umm, yes, that can be a stumbling point in contributing.  Having examined this
issue ourselves, we concluded there are no risks in copyright assignment.  But
circumstances may vary.  I suggest you contact the FSF directly on this point.

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

I don't understand... what additional restrictions are imposed by the LGPL?

Jeff