RE: Announcement: micro-libgcj

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

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

Hans