Re: Announcement: micro-libgcj

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

On 1/6/06, Boehm, Hans <hans.boehm@hp.com> wrote:
> > -----Original Message-----
> > From: Joel Dice [mailto:dicej@mailsnare.net]
> > Sent: Friday, January 06, 2006 1:03 PM
> > To: Boehm, Hans
> > Cc: Mike Emmel; Martin Egholm Nielsen; java@gcc.gnu.org
> > Subject: RE: Announcement: micro-libgcj
> >
> >
> > ...
> > The other reason I created micro-libgcj is the opportunity to
> > correct what
> > I see as flaws in the design of Java.  For instance, I don't think
> > finalization makes sense; decisions to retain or release
> > resources like
> > file descriptors and database connections should not be based
> > on memory
> > pressure, but rather application-defined limits on those
> > resources.  So I
> > dumped Object.finalize().  Another example is synchronization;
> > micro-libgcj requires that only instances of the
> > Synchronizable interface
> > are used for this purpose, avoiding the complexity of hash
> > synchronization
> > or the overhead of an extra pointer in every single object.
>
> It seems to me that this will make the implementation far less useful as
> a vehicle for running existing Java code, or code you also want to run
> on other implementations.  There is lots of code out there that uses
> arbitrary Objects for synchronization, e.g. by explicitly allocating a
> lock with "new Object()".  And I think code that now synchronizes on
> something like strings would need significant changes.  If I got to
> redesign the language, I might agree with you, at least with respect to
> synchronization.  But the cost of such a redesign, in terms of broken
> client code, strikes me as huge.
>
CLDC the VM used in mobile phones removed finalization and added
arbitrary differing fixed maximum memory usage limits. So in a sense
changes like this have   been done already in standard java. The
classes used in cldc are subsetted from the standard java.
Not to mention the huge number of buggy and just plain broken
implementations that exist today in J2ME.  Considering all the crud
you have to deal with using todays "standard" implementations I don't
think that modifications to some synchronization code is a huge issue.
Plus and added benefit is that a lot of programmers don't actually
create new Objects for synchronization but instead use any handy
existing object for that purpose. I think that forcing them to
actually mark objects that are being used for locking is a good thing
and safer then java's current design. And you get smaller faster code.

> Hans
>
>