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

Re: Bug#764630: RFS: javatools 0.48 [RC]

On Sun, 21. Dec 09:57 tony mancill <tmancill@debian.org> wrote:
> On 12/15/2014 12:06 AM, Mathieu Malaterre wrote:
> > On Sun, Dec 14, 2014 at 6:50 PM, Markus Koschany <apo@gambaru.de> wrote:
> > [...]
> >> Actually what was the reasoning behind the choice to use a custom shell
> >> script like jarwrapper instead of jexec to register executable jars with
> >> binfmt-misc? This question also came up in the bug report.
> >
> > Here is my guess:
> > `jexec` only works with openjdk installed. At one point debian had
> > multiple java implementation (sun, kaffe...). These days only two
> > really remains, so maybe an easier solution would be to have a
> > `gcj-exec` provided by `gcj-jdk` to mimic openjdk package. Which means
> > it would be much easier to handle the LD_LIBRARY_PATH issue within the
> > `gcj-exec` executable.
> >
> > jarwrapper is only really needed with a custom jre installation...
> That sounds reasonable to me, although it can be hard in practice to
> keep things functional for users running non-Debian JRE packages.  Which
> is not to say that we shouldn't generally discourage jarwrapper...

I think before we create another solution like gcj-exec, it is easier to
maintain the current implementation of jarwrapper. I agree that gcj's
handling of LD_LIBRARY_PATH and Multiarch could be improved but in my
opinion there are other aspects about gcj which deserve even more
attention. Most modern Java applications just don't work with it.

I suggest to upload the fix for #764630 now. I just saw tony's email
from the 21th. The current state on master is final. I haven't planned
any further changes to jarwrapper. Please go ahead.



Attachment: signature.asc
Description: Digital signature

Reply to: