GCJ 4.0 and native Java packages
Hello! Some of you may have noticed the gcj-4.0 packages in
experimental!
I have altered my Eclipse packages which I've been working on to build
with gcj and run with gij by default. In the course of doing this, I
have noticed that it would be very helpful to get .so files provided
alongside .jar files By Default in our Java packages.
Has any policy been discused involving this? Where should we located
the .so's? Should the -java package be split? Does it matter? What about
gcj-dbtool generation. These any many more questions await answer!
Here's what I'm thinking about currently:
1. Jar files in /usr/share/java (same).
2. Native files matching Jar files in /usr/lib/java. File names the
exact same as the .jar, with a .so appended.
3. Provide a new 'update-gcj-database' or some such to generate
a /usr/lib/java/gcj.db file in the postinst of all of these packages.
Gcj is very interesting! It has a number of ways of resolving a request
for a class name to a .so file.
1. Try the packagename.so: org.apache.blah.so, org.apache.so, in
decreasing order until a match is found.
2. Loaded with LD_PRELOAD.
3. Resolution of class hash->.so using a gcj db file.
The third option looks like the most expandable.
gcj operates directly on the .jar file, creating a .so file. This means
the build for most packages doesn't have to be altered, a simple recurse
of all .jars in /usr/share/java should cover it during the build
process.
Questions, comments. We need to get on the ball on this, before I have
to do it all myself. =)
Reply to: