Re: RFC: micro-libgcj merge proposal

["S. Meslin-Weber" <steph at tangency dot co dot uk>]

Hi Everyone,

On Fri, Jan 13, 2006 at 10:50:43AM -0700, Joel Dice wrote:
> Hi all.
> 
> The following is a brief proposal for merging micro-libgcj into the GCC
> source tree.  Comments and suggestions are welcome.

Sorry to join this discussion so late in the day.

First, I'd like to say that micro-libgcj is a great idea. It addresses a
good set of issues and is most definately *not* a solution looking for a
problem.

As an embedded developer having used PJava, Personal Profile (Sun's
Early Access JVM for ARM) and a commercial ~1.4 JVM for embedded devices
(whose name I can alas not post) over the course of the past few years,
I feel that I have lived through some of their worst abuses of the Java
language and APIs. I have also done a little JavaCard (to complete the
set).

Now, although I believe micro-libgcj is a great idea, I also believe it
would exist better as a fork (on a branch if needed, that's where
experimentations start best) pushing appropriate changes upstream.

I do not think that micro-libgcj (or other Java-like reduced-API such as
J2ME) should be merged with either libgcj OR upstream with GNU Classpath
*unless* the following concerns can be addressed. I'll cast my comments
with respect to J2ME as that is a good case in point of sufficiently
similar APIs for Java and is an example of the extreme degenerate case.

1. Pre-processing

a) As Tom as said, adding pre-processing directives to code pushes at
least some of the maintenance to active developers, but also, such
pre-processing does not seem to address certain changes between API sets
such as class hierarchy changes (yes you can ifdef out a whole class
definition - but then you're maintaining *two* functionally similar
classes). This adds complexity to the already interesting landscape that
ifdeffing adds to any code.

b) Java language specifications. J2ME is currently almost 3 major
language revisions behind (for shipped devices) with JVM compatibility
being at Java 1.3.1.

Yes, PBP 1.1 raises this to 1.4 (released August 2005), but with Java
1.6 around the corner, it will _still_ be 2 major revisions behind. Sun
is reportedly moving to converge J2ME and J2SE, but that's not yet a
reality.

* Note that as far as can be inferred by bug incompatibilities between
J2ME and J2SE JVMs of matching versions, Sun appears to have at least
partially separate source trees for both J2ME and J2SE.

** This issue also raises its ugly head in GNU Classpath to a lesser
degree - JAPI analysis is done against 1.1, 1.2, 1.3, 1.4 and 1.5 of
Sun's public Java API... different parts of GNU Classpath are at
different points in this version chain. The maintainers chose not to
ifdef things even to allow choosing different versions to 'slice' out
(although interestingly, the Mauve tests do essentially have this
functionality).

2. Post-processing

This is already a reality with tools such as Retroweaver[0] being
available that uses bytecode engineering to allow some 1.5-compiled
bytecode to effectively run on 1.4-compliant JVMs. It should be noted
that Retroweaver is less than happy with some of the 1.5 constructs and
will fail to engineer them; some engineered classes sometimes will also
fail to function, most often due to bug incompatibilities between JVM
implementations.

3. Emulation

Emulating J2ME on top of J2SE is possible right now using the ME4SE[1]
tool (GPL'd). Of course, this tool has essentially a separate source
tree for the J2ME-specific classes.


In summary, the least effort solution would seem to be to give
micro-libgcj a branch to develop on as a fork, merging in compatible
fixes as necessary. Once micro-libgcj is a little more mature as a fork,
and, in true Kaffe fashion, its merge into its parent can be revisited
with a better understanding of the impact there.

Best regards,

Steph

[0] Retroweaver, http://retroweaver.sourceforge.net/
[1] Me4SE, http://kobjects.sourceforge.net/me4se/

-- 
================================================================
Stephane Meslin-Weber         Email: steph@tangency.co.uk
Senior Software Engineer      Web: http://odonata.tangency.co.uk
================================================================

Attachment: signature.asc
Description: Digital signature