Binary size of statically linked java application

Tue Nov 28 16:42:00 GMT 2006

Hi, Michael and Marco.
On 2006年11月28日, Lehner, Michael wrote:
>> Lehner, Michael wrote:
>>>>>> [Lehner, Michael]
>>> Thank you for all the interesting information you provided to me. In
> the
>>> moment I am trying to build a toolchain with ulibgcj, but I am not
> sure
>>> if this will work, because they write on the project page, that it
> is
>>> for i686/amd64/.. but I am using a mips64 in the moment and this
> type is
>>> not listed.

I don't have a mips machine available to test with, so I can't verify it 
myself, but it shouldn't be difficult to make micro-libgcj work on that 
platform, assuming it already works with the standard libgcj. Please let 
me know if you need help.
>> In my understanding, micro-libgcj changes the source and doesn't do
> any
>> platform dependent stuff. So I would guess that it will work for you.
>> The thing to remember is that a lot of useful stuff gets kicked out of
>> the java class library and java language features. So check carefully
> if
>> you don't need them before investing time for micro-libgcj.
>> I think you could always write an eMail to the maintainer of
>> micro-libgcj if you have questions. He seemed to be quite a nice
> guy...

:)

> [Lehner, Michael]
> The problem is, that I really don't know what features someone would
> perhaps need in the feature. I only make some research on how to include
> java in the current development process. That means there are no classes
> written for this project in java, but we perhaps want to use this
> language later. In the current situation we are not using gcc for this
> project, but there are other reasons why we also make some research if
> gcc could solve all our needs. In the view of java this would be
> perfect, because otherwise we would have to use 2 compilers for new
> releases written in java and C.

As Marco and I have discussed before, one of the biggest weaknesses of 
Java (especially for embedded developers) is that it is so monolithic. 
Almost everything is tied to everything else, directly or indirectly, so 
you can't pick an arbitrary subset of the libraries without pulling in the 
rest.
Unfortunately, you generally can't refactor the libraries in a more 
modular way without breaking compatibility with the official versions. 
Thus, you lose one of the most attractive aspects of Java - its stable, 
well known API.
On the other hand, if you have the luxury of starting from scratch and 
don't need perfect compatibility with the Java standard, you have a lot 
more options. That's the idea behind micro-libgcj - start with a minimal 
core and add to it, balancing the goals of modularity, compatibility, and 
usefulness. Of course, everybody has a different vision of those goals, 
and micro-libgcj only matches my vision right now.
Eventually, I hope to see a stable, modular version of the Java libraries 
that covers most or all of the J2SE functionality without the tight 
interdependencies that make it so unwieldy. Like I told Marco, I don't 
have time to pursue that myself, but if others believe micro-libgcj is a 
good foundation for it, I would happily accept patches and/or encourage 
forks of the project.
>>> so that I won't need
>>> to rebuild my libgcj every time use a new package or I don't need
> one
>>> any longer? Or can I only exclude whole archives?
>>>> You don't need to rebuild GCJ. Thats why I meant that my approach is
>> easier to maintain. What you have to do:
>> - extract all objects from the libgcj archive (ar x libgcj.a)
>> - remove the ones you don't need
>> - create the new archive (ar q libgcj.a *.o)
>> - compile your application again
>>>> Of course you will now get unresolved depencies because your objects
> are
>> referenced from other classes in the class library. For those you have
>> to write stubs (minimal classes) and add them to the compilation.
>> It needs quite some time, but it's worth the effort...

How many stubs did you need to write to cut out Swing, AWT, and 
javax.crypto?
>>> [Lehner, Michael]
> Perhaps I'll find a way to resolve these dependencies automatically or
> use a list where all are listed and get a new libgcj every build. But
> there is some time to solve this problem, first I will have to find out
> how libgcj will work, when I want my applications to run without a Linux
> system. Writing something simply out wont work, this is clear, but what
> about calculations and other operations, not using any system specific
> modules? We'll see.

How much POSIX functionality do you have available? Do you have libc, 
libm and pthreads, for example? If so, things should go pretty smoothly. 
If not, you may have to write your own implementations of certain native 
methods, depending on what features you need.
 - Joel