javafxpackager and launcher

Scott Palmer swpalmer at
Wed Jan 8 19:20:10 PST 2014

The Java 8 java.exe launcher is now JavaFX aware in that it will launch
JavaFX Applications that don't have a main(String []) method.
The javafxpackager uses it's own launcher when creating a native package.

Are there plans to unify those launchers?
I noticed a comment under "future work" in WinLauncher.cpp that says "Reuse
code between windows/linux launchers and borrow more code from java.exe
launcher implementation."
I'm wondering why not make java.exe the only launcher we need.  (Or the
javaw.exe variant)
I think would mainly be an issue of adding package.cfg parsing and picking
up the embedded runtime.  An "application bundle mode" could probably be
triggered via the contents of a resource that is injected much like the
custom icon is injected into the fx launcher (I'm not sure if something
needs to be done for preloader support too.  I think the embedded launcher
stub handles that on Java 7, but I believe it isn't used on JavaFX 8.)

I have been using a standard java.exe launcher from Java 7 for my apps and
hacked jfxrt.jar onto the classpath manually. I do this for a couple
reasons.  One because the same app could launch in a Swing or JavaFX mode
while we were transitioning our UI.  Two, because we install a private JRE
that is shared among multiple apps and services that make up our product
and javafxpackager only supports the default system-wide JRE or a JRE
embedded into the application bundle.  It's a bit too limited... though
after looking at the launcher source, I think I can fool it by making a
"runtime" directory symlink inside the app bundle folder that points to our
company-private JRE.

I just started experimenting with the javafxpackager and I noticed that the
.exe that is created could, and probably should, have more things
customized in the resources.  If you get properties on the file in Windows
and look at the Details tab, things like Product name and Version are not
filled in.  The project has a Title, a Vendor, Description and
Implementation Version, etc.  I believe those are used for JNLP deployment.
 It would be nice to have those details injected into the .exe just like
the icon is.  Should I create an issue for that?

I'm also curious about the installation location when making a .msi
package.  Instead of "Program Files/AppName" or "Program
Files/Vendor/AppName" it goes to the user-specific App-Data folder.  This
is almost never what a typical Windows user would want or expect. I
understand it is probably to avoid permission issues, but the installer
really should have had the option to do a per-machine install.
This page
"Deployment occurs with no need for admin permissions when using ZIP or
user-level installers." .. well how can you make a machine or system level
installer instead?
Is this out-of-scope for javafxpackager enhancements?

I'm also using only the javafxpackager command line.  No Ant tasks.  I'm
going for exclusively Gradle-based builds now and I don't want to mix
Gradle & Ant, so I've built a Gradle task that runs the javafxpackager.
Do we have as much power to customize the installer when using the
javafxpackager command line app instead of the Ant task? The javafxpackager
docs that I've found don't get too specific. Most of the docs are assuming
Ant-based builds. (When most people have moved to Maven long ago, long
enough for many of use to hate it now and switch to Gradle :-). )
E.g. Looking at the launcher code I see that it should be possible to
provide any JVM options in the package.cfg file... but I can't find
documentation for this.  I see the options in the Ant tasks for jvmargs,
but there doesn't appear to be a way to do it with the command line tool.



More information about the openjfx-dev mailing list