List Archive: gentoo-java
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Tue, 21 Feb 2006 16:42:51 +0100
Karl Trygve Kalleberg <email@example.com> 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 ...
... 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
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.
firstname.lastname@example.org mailing list