As described in 208798 the JavaFX SDK will be cobundled with the JDK and the JavaFX Runtime will be cobundled with the JRE on Mac OS X starting with 7u4.
Once 208768 is fixed, NetBeans will be able to recognize the embedded JavaFX platform if you navigate to the JDK home directory and select that as your JavaFX SDK. You then need to do the same thing for the JavaFX Runtime, pointing the runtime to the JDKHOME/jre directory, since NetBeans won't otherwise find it. Both steps are combersome and error prone.
NetBeans should detect this case and automatically setup the JavaFX platform. As an optional "nice to have" part of this feature you might want to "gray out" the ability to change the JavaFX platform in this case.
Note that even though the Mac OS X release for 7u4 / FX 2.1 is the driver for this bug, the changes should be platform-independent.
just info for myself: not to forget to reflect all from
Same here today:
I have updated the JDK to 1.7u13. On starting Netbeans, it says that the old version cannot be found and asks to use the default version. Under Tools / Java Platforms, the correct JDK ist selected now, but the JavaFX Platform stays the old one, reference problems are complained.
After editing etc/netbeans.conf and correcting netbeans_jdkhome, everything works fine after restarting Netbeans.
Actually NB does recognize FX embedded in JDK and gives it precendence over other potential FX installations, but this is true only when initially creating the Default JavaFX Platform. The case you describe, i.e., updating the FX platform after JDK update, has not been implemented so far.
The Default JavaFX Platform is technically a non-default SE platform, so it does not change when the default JavaSE platform changes.
You do not need to edit etc/netbeans.conf in order to update the FX platform though. Alternatively you can: delete Default JavaFX Platform in Platform Manager and close/reopen your FX project (or restart NB). This recreates the Default JavaFX Platform based on the current JDK. However, JavaFX definition thus may remain as it was before. To make sure tha JavaFX SDK/RT is set depending on the current JDK, go to JavaFX tab, clear the SDK, RT and JavaDoc fiels, and disable then enable again. This invokes new FX SDK/RT location detection.
What I describe above is not very user-friendly support of the JDK-update use-case. What we can consider to implement would be the following: on project open we could not only auto-create Default JavaFX Platform in case it does not exist, we can also evaluate its state if it does exist. We can evaluate its inner state (if the JDK contains FX SDK/RT, does the platform use them or does it refer to different ones ?) and in case of need we can auto-update FX SDK/RT definitions. Or we can also compare Default JavaFX Platforms JDK settings to that of the default Java Platform - and recreate Default JavaFX Platform completely if there is a difference. We can not implement anything like that in NB7.3 though as the change in FX project infrastructure would be too big this close to 7.3 release. But we can consider this for 7.3.1. Note that in NB8 with the expected support to JDK8/FX8 will be simplified - in JDK8 all FX artifacts should be on classpath by deafult, thus the FX platform mechanism will become largely obsolete.
Personally I would prefer the "compare Default JavaFX Platforms JDK settings to
that of the default Java Platform" option, it sounds to be the most logical way to me. But as I do not have an overview on the project, that might not be the best way at all :)
Nevertheless thank you, Netbeans community is great even for a newbie like me!
This issue has been resolved as byproduct of another change implemented in NB 7.4, see Issue #229678. Now FX Projects use standard Java Platforms, no FX specific platforms need to be defined any more by user. This is based on the decision to support only JDKs that contain FX RT, i.e., JDKs from 7u6+. The current implementation does ensure that FX RT artifacts are added to classpath if they are not included by default (the case of all JDK7 distributions, in JDK8 jfxrt.jar is on classpath but other artifacts like javaws.jar etc are explicitly included as well). This implementation has at least three advantages: 1) simplification for users, no need to deal with the notion of FX-enabled platforms, 2) the current implementation now makes it easy to use FX in SE projects, 3) there is no need for JavaFX Class Library project as standard Java Class Library can now be used with FX (note that FX support in SE projects must be explicitly switched on in Project Properties).