"javapackager" in no-mans-land?

[Lennart Börjeson]

Java Webstart is gone in Java 11.

This means there are no means left to build and distribute standalone Java applications across multiple platforms. 

Java Webstart was deprecated since the “old model” of having a separate system-wide JRE capable of running Java programs from different sources, was supposedly outmoded by the “new model”, i.e. stand-alone apps, complete with their own bundled JRE. ...but then all means to create a stand-alone application was also deprecated and removed. 

If you need webstart or application packaging, you must wait for the proposed jpackager, and remain at Java 10 until then. 


/Lennart Börjeson

Electrogramma ab iPhono meo missum est

> 20 sep. 2018 kl. 21:05 skrev Kamlesh Prajapati <kamlesh.prajapati at hops.healthcare>:
> 
> Hi,
> 
> Currently , I used javafx 8 with JNLP Application. 
> 
> Is JNLP application support in javafx11 + java11 ?
> 
> Any idea about auto update application in win(exe),mac,linux base application ?
> 
> 
> 
> 
> 
>> On Wed, Sep 19, 2018 at 11:54 AM Lennart Börjeson <lenborje at gmail.com> wrote:
>> It was migrated, but removed...
>> 
>> The recommended work-around is to use the javapackager in OracleJDK 10 when packing Java/OpenJfx 11 applications.
>> 
>> That may or may not be practical depending on your build setup. Also, if you’re currently using the UserJvmOptions services, these are also gone in Java/OpenJfx 11, and it would complicate the build process even further if you were required to separate the parts needing to compile with OracleJDK 10, too.
>> 
>> I’m using Gradle to build my project, and it is currently dependent on the javafx-Gradle-plugin to package. To upgrade to Java/OpenJfx 11, and still keep the javapackager, I would need to refactor:
>> 
>> 1) my code base, to separate the parts needed to compile with OracleJDK 10 to get the UserJvmOptions,
>> 2) my Gradle structure, to run in three steps (compile some parts with 10, compile most parts with 11, package all with 10 while still linking most from 11).
>> 
>> It’s too much for me. I’ve decided to remain at Java 10 and wait until there’s a javapackager replacement. The javafx-Gradle-plugin has also been deprecated due to the loss of the javapackager, so I’m stuck anyway with Java 10 unless I rework my entire build structure substantially. I’m hoping for a future Gradle plugin replacement.
>> 
>> Seriously, it would be much easier to build my own JDK with OpenJfx, the javapackager and UserJvmOptions Service still bundled with it, but then I’d step up to a completely different level of support commitment...
>> 
>> /Lennart Börjeson
>> Epistula electronica a meo computatro tabulari missa est
>> 
>> > 18 sep. 2018 kl. 22:37 skrev Tom Golden <tgolden at andplus.com>:
>> > 
>> > I understand that along with JavaFX being removed from the Oracle JDK
>> > distribution in Java 11, the Oracle team will no longer release the
>> > `javapackager` tool.
>> > 
>> > I also see there is a JEP discussing an eventual replacement, JEP-343 (
>> > http://openjdk.java.net/jeps/343).
>> > 
>> > Just to confirm, the tool was NOT migrated to OpenJFX with the rest of the
>> > JavaFX code, correct? So until JEP-343 is implemented in a future release
>> > (?) there is no "official" way to package native installers for JavaFX
>> > applications?
>> > 
>> > If so, is it in theory still possible to use the Oracle javapackager tool
>> > from earlier releases? Or should we remain on Java 10 for the time being?
>> > 
>> > -- 
>> > Thanks,
>> > Tom Golden
>> > Technical Architect
>> > AndPlus, LLC
>> > 257 Turnpike Road
>> > Southborough, MA 01772
>> > 
>> > Phone 508-425-7533
>> > http://www.andplus.com
> 
> 
> -- 
> Thanks With Regards,
> Kamlesh Prajapati