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. =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
