Feedback JEP 343: Packaging Tool

[Alexey Semenyuk]

Hi Heiko,

Thank you for giving a try to jpackage and for your feedback!

Please find comments inlined.

On 9/10/2019 4:55 AM, Heiko Wagner wrote:
> I am sending this feedback as suggested by the jpackage project
> (https://jdk.java.net/jpackage/). I hope this is considered helpful
> information.
>
> I have tried the current build "14-jpackage+1-35" on Windows. It pretty
> much worked out of the box for me. Here are a few observations I make:
>
> - creating a image of the application is great for building protable
> applications. Sometime it is realy great to have the application on a
> thumb drive an just run it on any machine; currently i do this manually
> via jlink and use launch4j as a native launcher
>
> - MSI installation packages are great when deploying a application into
> a controlled it infrastructure, but in turn impose some restictions e.g.
> on application updates
Correct. That is why jpackage supports creation of an application image 
not bundled in MSI on Windows to give maximum flexibility.

> - my application is currently a portable app and does not use any native
> installer like MSI. Automatic updates are handled by the application by
> just in place updating the jar files. Deploying the application as a MSI
> would require to change the update behaviour. Even if automatic updates
> are out of the scope of the current JEP it would be helpful to have a
> common solution for this in the long run
>
> - Currently my app has a splash screen, since launch4j has support for a
> native splash screen. I have no tried it on jpackage, but the JEP states
> that there is no support for native splash screen.
That is correct, jpackage is not offering native splash screen support.
> Does this also mean that the functionality of "-splash: fileName" and
> its manifest file counter part will not work when using the launcher
> generated jpackage?
Right now it is not working as far as I can say from running the simple 
test. This looks like a bug in app launcher generated by jpackage. I've 
filed https://bugs.openjdk.java.net/browse/JDK-8230862 to track this.
>
> - Wher creating a image on Windows pretty much all .DLL from the bin
> folder in the runtime are duplicated into the application folder. Is
> this intended?
App launcher is linked dynamically with MS run-time libs so we have MS 
run-time dlls in the folder next to the launcher. There is no bold 
reason to keep it this way, we can link app launcher statically with MS 
run-time and get rid of all these dlls.
Created https://bugs.openjdk.java.net/browse/JDK-8230863 to track this.

- Alexey
> When using the generic java.exe launcher it is not
> required to this. It just works fine with all .DLL/.EXE files in the
> runtime bin folder
>
> Thanks for making such a great tool. Keep up the good work.
>
> Regards,
>
> Heiko