Announcement: micro-libgcj

[Mike Emmel]

On 1/6/06, Boehm, Hans <hans.boehm@hp.com> wrote:
> > From: Mike Emmel
> >
> > On 1/6/06, Joel Dice <dicej@mailsnare.net> wrote:
> ...
> > > It would be trivial to add a System.free(Object) function, allowing
> > > explicit memory management, if it was needed.
> > >
> >
> > What about stack allocation i.e a snew  or
> > System.stackAlloc(Foo.class) I'd think that would be useful
> > for these types of platforms.
> >
>
> I would have thought that a major reason for doing this would be to
> develop small stand-alone type-safe (at least for the Java piece)
> code.
>
> Neither stack allocation nor explicit deallocation preserves
> type-safety for the Java code, at least not in this simple form.
>
> My impression is that the RTSJ people thought about this fairly
> hard, and came up with a complex solution.  I don't know to what
> extent it has been accepted by the community.  It appeasr to me
> that a real-time collector is increasingly considered at least
> a viable alternative.
>
> 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.)
>
> Hans
>
Thats possible but there are issues first Sun aggressivly charges for
CLDC/CDC midp api's. I think a free version would be risky unless Sun
agrees.
They have pressured every current embedded vendor to accept paying for
midp regardless of it clean room status.

Now what is wrong with adding unsafe attributes things like stack
allocation can be checked via escape analysis etc to increase there
safety. Zone allocation is also of intrest. And a java like language
that embraces some C concepts is I think useful for embedded
programming and does not conflict with Sun's official java.