Re: RFC: micro-libgcj merge proposal

[Mike Emmel <mike dot emmel at gmail dot com>]

On 1/13/06, Boehm, Hans <hans.boehm@hp.com> wrote:
> > 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'd say pretty much all of java.utils could use a re evaluation for
embedded use for example.
But you would like partially compatible solutions. java.io is another area.
reflection. Security in standard java you  use a lot of inner classes
for security checks
this can get expensive on a small platform. In many cases you may want
the concepts of nio if your embedded platform does a lot of io  the
current nio package is overly complex.
I can't see one package not being subject to potentially significant
changes to rework it into a similar but embedded friendly package.  So
the real question is there any signifcant part of classpath that would
come over untouched ? I'd  say the answer would be no.
It makes no sense to me to ifdef probably 50% of the code if not more.


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

Yes but J2ME did not solve the resource management problem that is often solved
using finalization which is not good solution instead they hid it in
the implemention. I think at some point this will need to be
addressed.

>
> Hans
>