[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging Java Pathfinder

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

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: