This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 220529

Summary: Problems with Java platforms and JavaFX
Product: javafx Reporter: george.scott
Component: ProjectAssignee: Petr Somol <psomol>
Status: RESOLVED WONTFIX    
Severity: normal CC: tzezula
Priority: P2    
Version: 7.3   
Hardware: PC   
OS: Windows XP   
Issue Type: DEFECT Exception Reporter:
Bug Depends on:    
Bug Blocks: 202090, 220737    

Description george.scott 2012-10-22 03:19:28 UTC
[ BUILD # : 201210210002 ]
[ JDK VERSION : 1.7.9 ]

Having problems entering defects via this web site.  This is the shell of a
description which I'll modify once it has been accepted.  Once bitten...
Comment 1 george.scott 2012-10-22 03:33:59 UTC
Okay, seems to have got past first base...  I'm sorry that I don't have the time to refine this description.  I have already spent far too much time trying to help.

I had this problem with NB 7.3 beta.  To test further I did a fresh install of the latest dev (201210210002) and the problem is much the same.

There seem to be a few problems in the same area.  Don't know if they are related or not.

Part 1
------

In a brand new install of NB IDE there is a "JDK 1.7 (Default)" Java platform precreated automatically.  This platform does not have a "JavaFX" tab.  If I create a new Java Platform based on the exact same JDK there is a JavaFX tab.
Comment 2 george.scott 2012-10-22 03:55:46 UTC
Still working...

Part 2
------

In my fresh install, if I open an existing JavaFX project, and look at Project Properties->Libraries I have many broken references, with mention of ${javafx.runtime}, which makes sense.

I also notice that a new Java Platform has been silently created called "Default JavaFX Platform".

If I change my project to use this new platform (in Project Properties->Libraries all of the references are resolved.

If I now change my project back to use the original Java Platform the references are still resolved.  There seems to be some sort of contamination between the different Java Platforms.

If I now remove the "Default JavaFX Platform" the broken references are back again, as expected.
Comment 3 george.scott 2012-10-22 04:23:30 UTC
Sorry that working around web site bug is so painful...

Problems
--------

The problems as I see them are:

There should be no crosstalk between different Java Platforms.  Each platform should be independent of all others - settings in one should not affect another, for better or for worse.

You can split the various versions of the JDK into three groups.  The NB IDE should behave differently for each group, and in harmony with it.  The automatically created Java Platform (called "JDK 1.7 (Default)" in the one I am looking at) should be just like any manually created one.

The three groups are:

Recent JDK's with JavaFX built in.  These JDK's come with JavaFX - it is not optional.  NB should know this and not have the option to "Enable JavaFX" - it should always be enabled.

Middle age JDK's that do not have JavaFX built in, but will work with it.  NB should give the option to "Enable JavaFX".  The JavaFX parameters should be automatically detected where possible.  This seems to work as I would expect.

Old age JDK's that will not work with JavaFX.  NB should not give the option to "Enable JavaFX".  I do not have the resources to test whether this happens correctly or not.

This is the last part of this multi-part bug report.
Comment 4 Tomas Zezula 2012-10-22 08:31:02 UTC
>There should be no crosstalk between different Java Platforms.  Each platform
>should be independent of all others - settings in one should not affect
>another, for better or for worse.
There is no crosstalk among Java Platforms. Each platform is independent with
its own settings.

>You can split the various versions of the JDK into three groups.  The NB IDE
>should behave differently for each group, and in harmony with it.  The
>automatically created Java Platform (called "JDK 1.7 (Default)" in the one I am
>looking at) should be just like any manually created one.
The Default platform is not same as manually created one and it cannot. As it's
the platform the IDE runs on. So it's varying as you start NB on different JDK or you share a project.
Comment 5 Petr Somol 2012-10-24 11:36:53 UTC
ad Part 1:
----------
This is by design. The default platform is the one on which NB itself runs. As FX artifacts still are not integral part of JDK (although in newest JDKs the FX SDK is included, the FX RT artifacts still are not by default on classpath), we do not (allow) add them explicitly to default platform as there are many users who do not use FX and for whom it makes more sense to keep NB classpath uncluttered. 

ad Part 2:
----------
Yes there is the silent mechanism of creating Default FX Platform, which is invoked whenever no FX platform exists and either a FX project is created or an existing one opened. The seeming reference problems you see in Project Properties->Libraries->Compile have the following background: as mentioned, JavaFX RT artifacts need to be added explicitly to classpath - these are the four references, with jfxrt.jar being the most important one. Different Java Platforms may however use different FX SDKs, so the references added to classpath of the project are created relative with respect to current ${javafx.runtime} value, which is different for each FX enabled platform. This means no interference between platforms. 

There is however a problem in this dialog that I confirm, and that is the missing listener on platform change, that would update Compile tab contents so that the correct reference is shown for the currently selected platform.
I have filed a separate issue for that: Issue #220737.

ad Problems:
------------
As already mentioned here and in Comment #4 there is no crosstalk between Java Platforms, the confusion comes from the faulty refresh in Project Properties dialog. 

As for the three groups of JDKs, you are right that for the first group it is inconvenient that FX needs to be manually enabled after the platform creation, what may not even be discoverable. We have an issue filed that addresses that: Issue #202090.

As each of the parts of this issue that we find relevant has its own issue filed, I am closing this one now.