JDK11/JavaFX: How do I make a fat jar without build/depdency management?
Asked Answered
P

1

12

I think it goes without saying that I should be able to use Oracle's own JDK with JavaFX (from gluonhq) to build a distributable jar file that users can just USE.

After an exhaustive search, much reading (24 hours or more over the last few months)and finally this Google search query:

how to make a fat jar -maven -gradle -scala -eclipse -ant -docker -hadoop -netbeans -jerkar -phy -mozni -yogurt -pizza - throwing -python -bacon

I'm absolutely at the end of the road. Why on earth is this so much work? How can I build a JavaFX application and give it to people that want to actually use it without knowing anything else except how to use the application itself?

Polyphagia answered 22/3, 2019 at 13:29 Comment(4)
I think for JDK-11 you're supposed to use javapackager for thisLusatia
But why you don't want to use a standard build tool?Jobless
@Abeltramo because using oracle's Java , I don't think I should have to go for open source build tools to deliver my product. Feel free to school me on what's going on with Java and JavaFXPolyphagia
@Lusatia That would be nice but javapackager doesn't exist for JDK-11. The last version of the tool was for JDK 9 and it looks set for reintroduction only in JDK 14!Orthorhombic
D
12

This has been answered a few times already for Maven and Gradle. Build tools make things way easier than doing it on command line, and not only because of the dependency management.

Since you ask specifically about command line, there is already a full set of instructions documented for it here: https://openjfx.io/openjfx-docs/#modular.

Non modular App

The section Non-Modular from CLI covers JavaFX non-modular projects from command line, and gives you the whole set of instructions to create an old classic fat jar, where all the dependencies, including the JavaFX ones, are bundled all together.

There is a note that warns you not to use this procedure:

Warning: This is a discouraged tedious error-prone manual process that should be avoided by using the Maven's shade plugin or the Gradle's jar task, in case jlink is not applicable.

After you get the fat jar (it can be cross-platform), you can distribute it, and your user will need to have Java installed and run:

java -jar myFat.jar 

Modular App

The section Modular from CLI covers JavaFX modular projects from command line, and refers to the use of the jlink command, in terms of distribution, as it creates a custom image that you can send to your users. It is not a fat jar, but it will allow you sending a zip to your user that needs only to be unzipped and run like:

hellofx/bin/java -m hellofx/hellofx.HelloFX

In this case your user won't even need to have Java installed.

And with a little bit of extra work you can also create a batch, so you can run:

hellofx

However, if you still want to do a fat jar with a modular app, you can still apply the exact same instructions from the non-modular apps. In this case, you will probably have to remove the module-info.java file, as it doesn't really makes sense at this point.

Other options

You still have a few more options to distribute your application.

Custom Java+JavaFX image

Another option, covered in the same document, section Custom JDK+JavaFX image, explains how to create your own "JDK" that includes JavaFX. Then you will produce your jar as usual in Java 8 and you will be able to run it with:

/path/to/custom/java -jar myFat.jar

Note that there are already some JDK distributions that bundle JavaFX, like this one.

jpackage

jpackage tool is not there yet, but there is an early access: http://jdk.java.net/jpackage/, that is using Java 13-internal. The exiting documentation explains what are the command line options you need to produce a custom image or an installer.

Note that you can still use JavaFX 11 or 12 with this.

Build tools

And finally, you can still decide to use build tools (Maven or Gradle), that will really help you in many ways. See any of the linked questions above.

Diagnostic answered 22/3, 2019 at 15:52 Comment(3)
Thank you for this huge response! I have to admit that the #modular link from openjfx didn't do it for me. They posted a mods/ directory which was left undefined in their instructions as well as a non-functioning SET command (at least in WIndows10) for env vars. I will follow your advice and get back to this question asapPolyphagia
I've replied to your other question related to that. I don't see an issue with naming your output folder mods if it is going to have modules. But that's up to you to use it or name it as you want. As for the "non"-functioning set, that shouldn't be, I have tested it and works fine for me, but if it doesn't please report an issue.Burkhard
As an FYI, see: JEP 392: Packaging Tool (delivered in JDK 16), "The jpackage tool was introduced as an incubating tool in JDK 14 by JEP 343. It remained an incubating tool in JDK 15, to allow time for additional feedback. It is now ready to be promoted from incubation to a production-ready feature (in JDK 16)". Note, the native packaging output by jpackage is in an installable application, and so is different from an executable jar.Sadoc

© 2022 - 2024 — McMap. All rights reserved.