Hello Marko, This looks like a cool project and a nice addition to Debian. On 10/24/2015 05:56 AM, Emmanuel Bourg wrote: > Le 24/10/2015 07:50, Marko Dimjašević a écrit : > >> According to the Debian policy for Java [1], "[p]ackages must not ship >> gcj-code without the permission of the Java team >> (<debian-java@lists.debian.org>)." What would it take to get the >> permission from the team to have JPF packaged as a gcj-package? > > I can't speak for the team, but I feel that if GCJ doesn't improve the > speed by more than 15-20% on amd64/i386 it's probably not worth the trouble. I don't recall the specific reasoning behind requiring the permission of the Java Team in order to ship a gcj-package, but I suspect it's either because supporting the gij+Classpath runtimes was generally problematic (when using gcj to compile to bytecode .class files), or because using gcj to compile directly to native object code won't result in arch:all packages. I also agree with Emmanuel that it might be a lot of additional effort to create a gcj-package that may not provide a lot of performance benefit. In fact, I can't imagine that creating an arch:all package from gcj that are going to perform better than openjdk on the HotSpot architectures (but that's just a guess on my part). Compiling directly to native object code may provide an interesting performance comparison. >> I have no experience with packaging Java, but I do have experience with >> creating a package with Debhelper for a C++ tool. Any pointers to >> examples for gcj-packaging JPF would be greatly appreciated. > > Sorry I have never used GCJ for a new packages so I can't really help, > but I suggest looking at the few packages depending on gcj-native-helper > (ant, libitext-java and hsqldb1.8.0 for example). If there is a significant performance difference, you could ship both an arch:all binary package that contains bytecode for execution by the JRE and an arch:any binary package on architectures where the performance difference matters. Those binary packages would most likely conflict with each other because they'd provide the same commands. Still, users would have the option of using the native object code version. Cheers, tony
Attachment:
signature.asc
Description: OpenPGP digital signature