Announcement: micro-libgcj

Fri Jan 6 21:02:00 GMT 2006

On Fri, 6 Jan 2006, Boehm, Hans wrote:
> In general, I agree that something like micro-libgcj is really needed.
> Any chance of making the implemented subset match any of the
> previously defined ones, e.g. some J2ME version? (I ask this
> without having seriously looked at J2ME. But it seems to me that
> there is a big advantage to well-defined subsets of the API,
> since proliferation of subsets leads to nonportable
> client code.)

My hope for micro-libgcj is that it forms the basis of a modular system 
with clean, well defined dependencies. For example, a TCP module might 
depend on a I/O module which depends on the core runtime, which itself 
depends on nothing else. Even something like a runtime classloader would 
be a seperate module. You only pay for what you use. Unless J2ME offers 
this degree of modularity, it won't fit my requirements. J2SE certainly 
doesn't.
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.
Thus, micro-libgcj is not even intended to be a strict subset of any 
existing Java standard. If there is demand for such a subset, or a 
complete J2ME implementation, micro-libgcj may be a good starting-point. 
That's not a goal I'm interested in, though.
 - Joel