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 http://docs.oracle.com/javafx/2/deployment/deploy_quick_start.htm mentions "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. Cheers, Scott
