On Tue, 21 Feb 2006 16:42:51 +0100
Karl Trygve Kalleberg <karltk@g.o> wrote:

> Excellent! We need all the help we can get.

Whatever I can do.

> > ... Then use gcj to create native
> > executables or libraries out of that jar files. Creating a database
> > via gcj-dbtool for jar / native code resolution. If possible Java to
> > native.
> 
> The problem with this approach is your resulting programs will be
> potentially rather slow.

I got an example from OOo for jar to native compilation.
It may not be lightening-fast but ...

http://www.openoffice.org/issues/show_bug.cgi?id=54692

... there it still speeds up the process.

What is done there:

	* jars -> native libraries
	* .java -> native binaray

What used to do a JVM with jars now does a native binary with jars
compiled to native libs. Time went down from 3h40 to 2h45.

I hit a oom-killer feature of gij - run as JVM - there on my 512MB ram
testbox. If you compile that Java source to native that oom-kill
vanishes.

Still, just an example.

> While gcj can indeed compile .class files (inside .jars) to binary, I've
> been told it can produce the most efficient of results. The source code
> is much richer in structure than the bytecode, and opens up for many
> effective optimizations which could only be reached through
> "idiom-recognition" (which doesn't exist for gcj yet, afaik) of the
> .class files.

In a perfect world ... ;)

> I suspect that you shouldn't give up on using gcj as a source compiler
> quite yet. This story may evolve with the whole ecj/gcjx/GPLv3 debate.

I use gcj successfully on my testbox.
As far as it is possible. And with ecj as bytecompiler all my ugly hacks will
be a part of the past.

Only trouble I have actually is eclipse-sdk. Another oom-killer at runtime.
May be I find the time to get it to native code somehow.


Regards,
Hanno
-- 
gentoo-java@g.o mailing list