Re: GCJ Thought Balloon
>>>>> "PB" == Per Bothner <per@bothner.com> writes:
>> If I am not mistaken, it's possible to use GCJ to compile
>> .class files as well as raw .java files. So a package could
>> ship with .class files and, if GCJ is available, compile them
>> into an .so.
PB> It is possible. Currently, you get better-optimized code and
PB> potentially better debuging information if you compile from
PB> Java source.
Ah, well, that's a good point.
PB> Another disadvantage is that what is installed depends on the
PB> order in which you installed package - unless installing gcj
PB> compiles previously-installed packages to native.
That's actually what happens when you install a new Emacs, now, in
Debian.
PB> Another thing to consider: Should gcjh-generated .h files be
PB> installed?
I dunno! Should they?
>> For Freenet the compiled .so is about 3Mb, so this would
>> actually be quite enough to worry about on my side.
PB> In that case the clean solution would seem to be make two
PB> packages: freenet and freenet-with-gcj (or whatever the naming
PB> convention would be).
Right. But that'd mean 2 Debian packages for every Java package that
-could- be compiled to native code with GCJ.
I'm just thinking that we've got a fairly elegant (and functional)
java-policy as it stands right now. It seems like a step backwards to
have a plethora of compiled-for-this and compiled-for-that Java
packages. If we could make sure that the problem of having M Java
platforms and N Java packages had an M + N rather than an M * N
solution, I'd be pretty happy.
Then again, M + 2*N (bytecode + native) might not be that bad,
expecially if there's a tradeoff in terms of performance and
installation speed.
Maybe we need to include some info about GCJ in the Java policy.
~ESP
P.S. While I'm on the policy note, it appears that libgcj2 doesn't
provide java-virtual-machine.
--
Evan Prodromou
evan@debian.org
Reply to: