Announcement: micro-libgcj

[Mike Emmel]

On 1/6/06, Joel Dice <dicej@mailsnare.net> wrote:
> 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.
>
It does not. Your required to implement the complete specification and
it does introduce inter modular dependencies. As far as IO simple hash
database type stores are pretty popular in the embedded world and
generally make more sense then file io.


> 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.
>
YES !!! Its one of the biggest problems with java embedded paying the
price of supporting synchronization for every object. I think with it
removed your object header is down to a single pointer right ?

> 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.
>
Cool I really like what your doing I've no doubt in my mind its the
right answer for a lot of embedded programming problems. Btw I looked
at replacing String with a utf8 C pointer. One thing preventing it was
the syncronization issue. The other was the methods on object. I
noticed you kept most of the methods of Object even though many are
empty. Making all the methods of Object final would allow you to
introduce subclasses of object like my utf8 string pointers that have
at most a one byte/bit object header that says there really pointers.
I did not work completly through if the header could be collapsed but
it would certianly open up the chance to replace objects with
efficient internal structures if we could ensure that they extend from
object and object itself has no overridable methods.

Have you considered removing or finalizing the methods of Object ?

Mike



>    - Joel
>