GCJ for eCos

Fri Jun 6 10:07:00 GMT 2003

I think it would be a good idea to split java (the language) from libraries.
That would make gcj suitable for embedded systems. C compiles HelloWorld
application to 5K, while java still produces static executables of over 1M size
(tested for mingw).
It's a bit more complicated task than it may seem. Object, the base for all java
objects references Class, which references ClassLoader, InputStream, etc. Soon
you find out that Object alone (indirectly) produces 72 dependancies, if you
insist of being signature compatible with Sun's JDK. The good news is, that
those 72 classes are mostly simple, many of them being exception classes.
The second problem is that gcj's implementation of java the language itself
requires some of the library classes. For example, if you remove StringBuffer,
you can't do 'String a = b + "something"' anymore, because '+' operator uses
StringBuffer.
Boris
Ã˜yvind Harboe wrote:
> Currently I'm working on a project for eCos where
> we have a 66MHz ARM CPU w/2MB flash and 256kb RAM.
>> Although I've seen a couple of messages about GCJ being
> supported for eCos and I'd love to use Java for the project
> (reuse + easier), it seems a bit of a stretch. Java would
> give me resources tracking and garabage collection. I'm not
> after the JRE library. 
>> GCJ should not use more than 1MB + 128kb RAM.
>> Is this something I should just leave be, or is it worh
> investigating?
>> Ã˜yvind
>>>