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
