RE: RFC: micro-libgcj merge proposal

["Boehm, Hans" <hans dot boehm at hp dot com>]

> From: Joel Dice
> On Fri, 13 Jan 2006, Andrew Haley wrote:
> > I don't think we should do put anything really incompatible 
> into the 
> > libgcj source tree.  I understand the technical reasons for it, but 
> > divergence is IMO a Bad Thing.
> 
> This is a valid concern.  Unfortunately, compatibility and 
> compactness 
> seem to be mutually exclusive when it comes to Java.  If the 
> consensus 
> turns out to be that divergence from Java is a bad thing, 
> even as a build 
> option, then micro-libgcj will best remain a separate project.
> 
Do we have some other examples of where this is the case, i.e. even the
J2ME way of doing things is not acceptably compact, and things could be
fixed without drastically altering the language, i.e. moving to
something that's clearly type-unsafe?

I remain unconvinced about the synchronization issue.  I strongly
suspect there are engineering solutions that preserve the current
interface.  Certainly we don't have a good argument that there are no
such solutions.  (We do have a convincing argument that an
implementation like the current hash synchronization scheme, which was
really designed for servers, and certainly not optimized for
uniprocessors, is too big and complex.  But I'm not sure that's
interesting.)

And finalization is apparently already missing in some J2ME profiles, so
that's arguably not a strong incompatibility.

Hans