RFC: micro-libgcj merge proposal

Sat Jan 14 00:11:00 GMT 2006

On 1/13/06, Boehm, Hans <hans.boehm@hp.com> wrote:
> > From: Joel Dice
> > On 2006年1月13日, 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
>