JPackage application image file system layout
andy.herrick at oracle.com
Wed Jul 3 12:22:35 UTC 2019
On 7/3/2019 2:08 AM, Robert Lichtenberger wrote:
> I just noticed that my last reply was addressed to Scott Palmer only, so
> I "repost" my latest thougths now:
> Am 01.07.19 um 16:50 schrieb Scott Palmer:
>>> On Jul 1, 2019, at 2:47 AM, Robert Lichtenberger <r.lichtenberger at gmail.com> wrote:
>>> While trying to update our application to the (ea-version of) jpackager I
>>> noticed that the executable files are now in a bin/ subdirectory, which
>>> will make the application update from javapackager a real pain.
>>> For Linux this can be argumented with the Filesystem Hierarchy Standard but
>>> under Windows it is not common or standard to do so. The .exe file for an
>>> application is expected to live in the base installation directory.
>> It can also be argued that on Windows it is more common to launch the application from a shortcut in the Start menu, on the Desktop, or in the launch bar.
>> I get that this is a change from the previous behaviour so some adjustments need to be made, but how bad is it really?
> For me, right now, it is a showstopper.
> I have to update my application silently, in-place. If jpackage isn't
> adapted I'll have to resort to crude hacks like a "trampoline"
> <name>.exe - File which will call bin/<name>.exe when it's called and/or
> adapting existing .lnk - Files on the Windows machine (which will
> probably look very suspicious to anti-malware solutions ...).
>> The JDK has always had a bin directory and many other applications follow this pattern on Windows as well.
> Usually these are applications ported from Linux/Unix. But I admit
> there's no real standard or de-facto-standard about it. It's just the
> fact that javapackager used to work this way and now jpackage works that
> way, which makes it difficult in some situations.
> I've digged into the jpackage source code yesterday and was able to
> adapt LinuxAppImageBuilder.java and LinuxPlatform.cpp so that they would
> no longer use the bin/ subdirectory and from a cursory look it seems
> this could be done for Windows as well. Of course this would have to be
> tested and checked much more.
> To me it looks like there are three possible solutions:
> a) Everything stays as it is now. Things will remain difficult for me
> (and possibly for other people)
> b) We change Windows so as to not use the bin/ subdirectory.
I have filed an enhancement JDK-8227172
<https://bugs.openjdk.java.net/browse/JDK-8227172> to consider this option .
> c) We add another config-option that will control whether or not to use
> the bin/ subdirectory
This option is basically a subset of JDK-8216564
<https://bugs.openjdk.java.net/browse/JDK-8216564> , except option would
allow any specified subdir path (or none) to be used.
These options will require further discussion.
> I would be willing to invest time in a patch for b) or c) but only if
> someone with authority (Andy Herrick?) tells me, this makes sense.
> Best regards,
> Robert Lichtenberger
More information about the core-libs-dev