Announcement: micro-libgcj

Fri Jan 6 20:57:00 GMT 2006

I guess I hadn't appreciated the J2ME licensing issues. That's
unfortunate.
> From: Mike Emmel [mailto:mike.emmel@gmail.com] 
>> 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.
>For some applications, I agree. 
On the other hand, it seems to me that a potentially major attraction is
that you might be able to write small stand-alone applications for which
you are not likely to later discover things like buffer overrun errors
that complicate debugging and can potentially be turned into security
exploits. It seems to me that to really get there, you need to preserve
at least the type safety of the core language.
If you add unchecked explicit deallocation, that breaks. A premature
explicit deallocation may end up with the same piece of memory being
treated as both a char array and an object containing a reference field.
Aside from creating an interesting debugging problem, if an adversary
can control the contents of the char array, and then can arrange to
invoke a method on the referenced object, he can gain control of the
process. The fact that subscripts are still checked makes it safer than
C, but not safe.
Of course, anything you can do with complete checking is fine. Escape
analysis to automatically reduce heap allocation would be great. But as
far as I know, anything beyond automatic compiler optimization of
allocation either requires appreciable language changes (as in something
like Cyclone), longer pointers (e.g. tagged with a generation count),
and/or dynamic checks (e.g. for cross-region pointers, as in RTSJ, I
believe). I'm not sure that the latter two improve on general GC by
most metrics.
Hans