I have a Swing app that uses a JFXPanel. Running under Java 7u6 (dev preview b16) I expected the JavaFX classes to be on the classpath, but I found they were not.
I added them with -XX:bootclasspath/a and all seemed to work, but I wondered if this was expected?

This should be very close to the workflow you would use today with JavaFX 2.1. Starting with 7u6 you can count on JavaFX being there on Windows, Linux, and Mac, but you still need to use the ant tasks in jdk7u6/lib/ant-javafx.jar or the pacakger in jdk7u6/bin/javafxpackager. Netbeans 7.2 is configured to use the ant tasks for JavaFX projects. You can set up Eclipse and other IDEs to do this as well.

Note that:
- if you use fx:jar to package your application then it will embed launcher into your application jar.
It will know how to find JavaFX runtime on the system, set class path and then launch main() of your main application class
(unless you main class extends JavaFX Application class)
- with JavaFX 2.2 you can also pass 'toolkkit="swing'" to fx:application and then fx:deploy will
generate JNLP and html files for web deployment (see http://javafx-jira.kenai.com/browse/RT-19492)

I have an existing Swing-based application, built with Maven (this may change to Gradle, but isn't likely to see Ant again). A primary UI component of this app is implemented in JavaFX using a JFXPanel.
It is configured to build for Windows, Linux, and OS X.

Up to now I have taken the jars and Native libraries from the JavaFX zips and made my own Maven artifacts for them, for each platform. I installed the JavaFX jars and native libraries in the applications folder and added the native library folder to the java.library.path.
When I run this configuration (using the JavaFX 2.1 jars that I package with the app) it will fail with 7u6 because even though my JavaFX 2.1 jars are used, the native libraries are picked up from the 7u6 install and there is a mismatch between the Java and native code!

I was hoping that with 7u6 I can avoid packaging JavaFX separately. (I can require 7u6 minimum on Linux and Mac and can bundle a private JRE on Windows.)

All of the options you have listed involves significant changes to the launching infrastructure of the application. The application will be installed via installer or simple unzipping depending on the platform. Web Start may be used for some other cases, but this is generally not an application that will use Web Start. Many of the systems the app will run on will not be connected to the Internet.
It's unclear to me what the toolkit="swing" really means. I was hoping for something simple like "-XX:+EnableJavaFX to have the included JavaFX put on the bootclasspath automatically.

Regards,

Scott

P.S. I should stress that if the reason for not including the JavaFx classes by default was to avoid breaking stuff, it's clearly already broken because the native libraries embedded in the JRE are loaded ahead of what is in folders specified via java.library.path, leading to the mismatch mentioned above for apps that were working prior to 7u6.

swpalmer wrote:
I was hoping for something simple like "-XX:+EnableJavaFX to have the included JavaFX put on the bootclasspath automatically.

I'll second that if it's something that's possible.

I'm not actually using JavaFX for anything yet, but, the last time I tested it, the build / packaging strategy I came up with was basically the same as swpalmer. At the time I decided I'd wait until JavaFX got co-bundled (properly) before trying again. Having jfxrt.jar bundled, but not on the classpath makes it even more difficult to use JavaFX with existing build and deployment tools than it used to be. I don't think that's a good thing.

IMHO it's not wise to assume everyone wants to use the included ANT tooling. For me, a simple switch like "-XX:+EnableJavaFX" would be much better since my current build tool (Gradle) and deployment tools (ex: Install4J) would 'just work' with trivial modification. I could start using JavaFX with almost no effort. If using the included ANT tooling is a requirement, things get much more difficult.

I'm also curious how most IDEs are going to handle jfxrt.jar now. IntelliJ IDEA appears to add 'lib/*.jar' to the classpath when I register a new JDK. For me, that means my IDE (IDEA) thinks all the JavaFX libraries are available while my build tool (Gradle) thinks the opposite.

I had an existing NB JavaFX application project that was already built. I decided to use it to test running javafxpackager manually. From my projects folder I ran this:

$ /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/bin/javafxpackager -createjar -appclass mypackage.MyClass.class -srcdir build/classes/ -outfile MyApp.jar -v
Exception in thread "main" com.sun.javafx.tools.packager.PackagerException: Error: jfxrt.jar needs to be on classpath for -createbss and for -createJar without -nocss2bin
at com.sun.javafx.tools.packager.PackagerLib.loadClassFromRuntime(PackagerLib.java:1408)
at com.sun.javafx.tools.packager.PackagerLib.createBinaryCss(PackagerLib.java:1433)
at com.sun.javafx.tools.packager.PackagerLib.jar(PackagerLib.java:1340)
at com.sun.javafx.tools.packager.PackagerLib.jar(PackagerLib.java:1319)
at com.sun.javafx.tools.packager.PackagerLib.jar(PackagerLib.java:1319)
at com.sun.javafx.tools.packager.PackagerLib.jar(PackagerLib.java:1319)
at com.sun.javafx.tools.packager.PackagerLib.jar(PackagerLib.java:1319)
at com.sun.javafx.tools.packager.PackagerLib.jar(PackagerLib.java:1287)
at com.sun.javafx.tools.packager.PackagerLib.packageAsJar(PackagerLib.java:235)
at com.sun.javafx.tools.packager.Main.main(Main.java:410)
Caused by: java.lang.ClassNotFoundException: com.sun.javafx.css.parser.Css2Bin
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:789)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at com.sun.javafx.tools.packager.PackagerLib.loadClassFromRuntime(PackagerLib.java:1406)
... 9 more

The use of "package.class" suggests that a .class file is being specified. But what is expected is a fully qualified class name, i.e.: package.name.ClassName Since the standard convention is for packages to be lowercase and class names to be CamelCase the lowercase .class in the sample through me off.

<< IMHO it's not wise to assume everyone wants to use the included ANT tooling. >>

Absolutely spot on! Ant is simply not an option for many people. In fact, as a build dependency, it's a show stopper. I can't use JavaFx nor sell it to anyone until the whole build/packaging/deployment ball of craziness has been sorted out properly. Sorry - I just wanted to state ( once again ) how serious this issue is to JavaFx adoption.

@javawerks Ant is not a build dependency for JavaFX, as I pointed out in an answer to a previous question you posted:Ant dependency... "Thread: Ant dependency..."

That's not to say that there are not JavaFX build/packaging/deployment issues and improvements which can be made around such things as:
- integration with various installers and updaters
- integration with various build systems such as Maven and Gradle
- improvements to existing tool chains supplied with JavaFX
- etc.
Some of these things will come via modifications to the core JavaFX (now really JavaSE), toolchain and others through provision of third party libraries and add-ons. The e(fx)clipse and netbeans projects have also provided a mountain of work and infrastructure to try to address these issues - it would be great to see more work done by third parties on solving build/packaging/deployment pain points.

There are certain things with only the JavaFX team can do and 3rd parties cannot, for example:
- the JavaFX/JavaSE integration in the JDK/JRE.
- the resolution of any java platform licensing and distribution issues.
- work in closed source repositories.
If any of these items effect your deployments, I would strongly urge you to raise jira issues (or jdk bug reports) to get the specific blocking or paint points addressed.

I am sure that the JavaFX team would welcome:
- any specific feedback or suggestions you have (creating quality jira cases are a good way to track these).
- any offers of implementation assistance or code contribution
- detailed deployment requirements and JavaFX specific shortcomings for a substantial application.

I do think the JavaFX team is taking these issues seriously. For example, two of the three issues which igor filed based on this thread are classed critical and all three are targeted for the next release of JavaFX, even though that release is far along the development track.

When I try to show JavaFX UI, I get an unsatisfied link error from JavaFX classes:

java.lang.UnsatisfiedLinkError: com.sun.glass.ui.win.WinWindow._setBounds(JIIZZIIII)V
at com.sun.glass.ui.win.WinWindow._setBounds(Native Method)
at com.sun.glass.ui.Window.setBounds(Window.java:364)
at com.sun.javafx.tk.quantum.WindowStage.setBounds(WindowStage.java:185)
at javafx.stage.Window$TKBoundsConfigurator.apply(Window.java:1076)
at javafx.stage.Window$10.invalidated(Window.java:717)
at javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:129)
at javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:163)
at javafx.stage.Window.setShowing(Window.java:768)
at javafx.stage.Window.show(Window.java:783)
at javafx.stage.Stage.show(Stage.java:207)
at my.company.gui.javafx.SplashScreen.fx_showSplashScreen(SplashScreen.java:84)
at my.company.kayak.gui.javafx.SplashScreen.access$100(SplashScreen.java:37)
at my.company.kayak.gui.javafx.SplashScreen$2.run(SplashScreen.java:49)
at com.sun.javafx.application.PlatformImpl$3.run(PlatformImpl.java:141)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.access$100(WinApplication.java:29)
at com.sun.glass.ui.win.WinApplication$2$1.run(WinApplication.java:62)
at java.lang.Thread.run(Thread.java:722)

Is there already a JIRA issue for the mistmatched native library loading (unsatisfied link error) if you try to bundle jfxrt.jar from Java 2.1 with your application and run it on 7u6?

I don't recall seeing one.
It would seem to me from looking at the steps you describe in your sample, that it should work.
I'd advise filing a jira: http://javafx-jira.kenai.com

As a workaround you could try invoking System.loadLibrary in your app's main method - not sure if it would fix the problem or not.
http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#loadLibrary%28java.lang.String%29

Is there already a JIRA issue for the mistmatched native library loading (unsatisfied link error) if you try to bundle jfxrt.jar from Java 2.1 with your application and run it on 7u6?

I don't recall seeing one.
It would seem to me from looking at the steps you describe in your sample, that it should work.

And it does work for Java 6 up to 7u5. A workaround on 7u6 is to make sure the JRE-bundled JavaFX 2.2 jfxrt.jar is on the bootclasspath so it hijacks the 2.1 version bundled with the app.

I had thought while getting the bundling working on earlier JREs that the jfxrt.jar was sneaky and attempted to load the native libraries by trying a path relative to where the jar lived. I.e. the absolute version of ../bin/xxxx.dll using System.load and only if that failed did it fall back to a more general System.loadLibrary - maybe I have it backwards?
I any case, the bundled .dlls found in the JRE seem to get precedence leading to the above issue, which I suspect isn't caused by not being able to loading the requested native library, but rather the wrong version (2.2) of the native library where the native method asked for doesn't have the same method signature or simply doesn't exist anymore.