Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #8511

Re: Packaging Java Pathfinder

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

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

Back to linux.debian.maint.java | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Packaging Java Pathfinder Marko Dimjašević <marko@dimjasevic.net> - 2015-10-23 06:10 +0200
  Re: Packaging Java Pathfinder Emmanuel Bourg <ebourg@apache.org> - 2015-10-23 10:10 +0200
    Re: Packaging Java Pathfinder Marko Dimjašević <marko@dimjasevic.net> - 2015-10-24 08:00 +0200
      Re: Packaging Java Pathfinder Emmanuel Bourg <ebourg@apache.org> - 2015-10-24 15:00 +0200
        Re: Packaging Java Pathfinder tony mancill <tmancill@debian.org> - 2015-10-25 19:00 +0100
  Re: Packaging Java Pathfinder Marko Dimjašević <marko@dimjasevic.net> - 2015-11-15 07:40 +0100
    Re: Packaging Java Pathfinder Emmanuel Bourg <ebourg@apache.org> - 2015-11-15 09:20 +0100
      Re: Packaging Java Pathfinder tony mancill <tmancill@debian.org> - 2015-11-15 17:50 +0100
        Re: Packaging Java Pathfinder Marko Dimjašević <marko@dimjasevic.net> - 2015-11-15 19:40 +0100
          Re: Packaging Java Pathfinder tony mancill <tmancill@debian.org> - 2015-11-16 02:10 +0100
            Re: Packaging Java Pathfinder Marko Dimjašević <marko@dimjasevic.net> - 2015-11-16 05:00 +0100

csiph-web