[External] : Re: jpackage usage problems

[Hiran Chaudhuri]

On Wed, 2022-04-20 at 12:38 -0400, Alexey Semenyuk wrote:
>
> On 4/18/2022 7:06 PM, Hiran Chaudhuri wrote:
> > On Mon, 2022-04-18 at 18:41 -0400, Alexey Semenyuk wrote:
> > > I've filed [1] and [2] CRs to track the issues.
> > >
> > > [1] https://bugs.openjdk.java.net/browse/JDK-8284973
> > > [2] https://bugs.openjdk.java.net/browse/JDK-8284974
> > >
> > > - Alexey
> > Sounds great. Thank you.
> >
> > While we are at improving JPackage, there are a few more items I
> > stumbled over:
> >
> > a) When running jpackage on Linux, a freedesktop.org style starter
> > file
> > is created - but one more line in there would make it a lot more
> > usable:
> > https://urldefense.com/v3/__https://stackoverflow.com/questions/70420618/jpackage-linux-creates-insufficient-desktop-file__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzhG0W4A9$
> >
> > b) The solution is to override resource files. Meanwhile I found
> > out
> > the resource files are templates, and jpackage replaces specific
> > strings in these files. This however is nowhere mentioned in the
> > documentation.
> Must the value of "StartupWMClass" property in .desktop file be
> synchronized with the value used in the app or it can be any unique
> value?
> If the latter, jpackage can create unique value for every launcher
> based
> on package and launcher names.
> Otherwise, if the value must be synchronized with the value used in
> the
> app it must be supplied to jpackage. In this case, overriding
> .desktop
> template is the way to go.

The WMClass of a swing application cannot be configured by the
developer. Yet as much as I saw it is related to the fully qualified
class name that resembles the swing window. So if you use something
like

package org.myproject.mypackage;

public class MyWindow extends JFrame {
    ...
}

and display an instance of that, it will carry the WMClass parameter as

org-myproject-mypackage-MyWindow

In many cases this class the is the main class at the same time, which
is either specified on the JPackage command line or via the executable
jar's manifest.

I think a reasonable default could be to derive the name from the main
class, with a way to override allowing coverage of exceptional cases.
Most IDEs generate the JFrame classes with a main method. If not
handled you'd force every developer to override resources. If that
becomes the mainstream use case I guess the documentation should be
improved.

>
> > c) Running jpackage in two phases as I do (1: create app-image, 2:
> > create final package) I learned that --name has to be specified in
> > both
> > runs. When running jpackage on MacOS however the second run needs
> > the
> > application name postfixed with .app otherwise jpackage won't find
> > the
> > directory it created in the first run. See the logs
> > https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055932278?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8DzplJmV2G$
> > and
> > https://urldefense.com/v3/__https://github.com/HiranChaudhuri/settlers-installer/runs/6055948346?check_suite_focus=true__;!!ACWV5N9M2RV99hQ!bccLoHcm78kdEbI7iOTUvaVrkbLhw5V7ZjrWS68OXiTaKqbHw-dMGrH3tv8Dzmh3le2h$
> --name is optional parameter in both runs. Check out
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/test/jdk/tools/jpackage/share/MultiNameTwoPhaseTest.java
> testing this feature.
> I guess you mean "--app-image" parameter, not "--name" parameter.
> ".app"
> suffix in app image name on macOS is a legacy jpackage inherited
> from
> JavaFX's javapackager.
>
> I've filed [1] to track this issue. It may be discarded for the sake
> of
> backward compatibility though.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8285265
>

Oh you are right. I am talking about app-image.

Somehow I'd like to have a more homogenous behaviour across the
platforms. It would allow to keep the build files simple.
This may be difficult to achieve as they impose different requirements.
After all I also stumbled across version numbers on MacOS which are
more restrictive than even on Linux.

Breaking backwards compatibility is a huge pain. Someone will have to
take a decision here.

Thank you for considering. :-)

Hiran