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 202455 - JavaFX platform must not be hard-coded in files
Summary: JavaFX platform must not be hard-coded in files
Alias: None
Product: javafx
Classification: Unclassified
Component: Platform (show other bugs)
Version: 7.1
Hardware: PC Other
: P2 normal (vote)
Assignee: Tomas Zezula
: 202113 202677 203042 (view as bug list)
Depends on:
Blocks: 202113 202677
  Show dependency tree
Reported: 2011-09-21 20:34 UTC by kcr
Modified: 2013-01-18 10:20 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

project libraries (6.98 KB, image/png)
2013-01-18 10:12 UTC, arataj

Note You need to log in before you can comment on or make changes to this bug.
Description kcr 2011-09-21 20:34:04 UTC
Jasper noticed this issue, and I have verified it. It appears that the actual location to the JavaFX platform is stored in the file of each project. There are two fundamental problems with this:

1) The project is not portable to another machine with the default JavaFX SDK in a different location

2) You can't change the location of a particular JavaFX platform and have all projects that use that platform automatically pick it up (which may be the root cause of 202113)

I would expect this to work like Java platforms, where only the name of the platform is stored in the file. The mapping of platform name to specific location on the machine should be in the user's .netbeans directory somewhere, right?

Here is the e-mail from Jasper describing the bug.


I see a big issue with how the JavaFX SDK and Runtime locations are stored. It seem like you pick a platform with JavaFX support, at that point it stores the location of the JFX SDK and JFX Runtime inside the project properties file. The problem is that is a platform specific location. The result is a project created on Windows 64bit with 32bit Java can not be run on Mac, or Windows 32bit or Windows 64bit with 64bit Java without hand editing of project properties file.

In for a project created on Windows 64bit with 32bit it contains:

javafx.runtime=C:\\Program Files (x86)\\Oracle\\JavaFX Runtime 2.0
javafx.sdk=C:\\Program Files (x86)\\Oracle\\JavaFX 2.0 SDK

In for a project created on Windows 64bit with 64bit it contains:

javafx.runtime=C:\\Program Files\\Oracle\\JavaFX Runtime 2.0
javafx.sdk=C:\\Program Files\\Oracle\\JavaFX 2.0 SDK

In for a project created on Mac it contains:    
( which is specific to my machine as no standard location yet)


So a project created on one computer is not portable to another. As far as I understand NB handles this for JDK locations by storing them in not

This seems like a critical issue to me.
Comment 1 kcr 2011-09-21 20:38:56 UTC
This bug is present in 201109202329
Comment 2 John Jullion-ceccarelli 2011-09-21 20:56:31 UTC
Will be fixed for FCS, not a Beta blocker so downgrading to P2.
Comment 3 David Strupl 2011-10-07 13:51:45 UTC
*** Bug 203042 has been marked as a duplicate of this bug. ***
Comment 4 Anton Chechel 2011-11-07 09:37:47 UTC
*** Bug 202677 has been marked as a duplicate of this bug. ***
Comment 5 Anton Chechel 2011-11-10 13:53:51 UTC
*** Bug 202113 has been marked as a duplicate of this bug. ***
Comment 6 Tomas Zezula 2011-11-15 10:15:51 UTC
Fixed jet-main 47453b267ad2
Comment 7 Tomas Zezula 2011-11-15 10:19:11 UTC
Fixed in jet-main but the javafx properties are strange, the javafx project adds a non reference on endorsed cp, these cp entries depend on JFX layout which is forbidden.
Comment 8 Petr Somol 2011-11-15 13:32:38 UTC
fix extension to SDK paths:
Comment 9 Petr Somol 2011-11-15 15:24:16 UTC
added path reference validity check + warning if not
Comment 10 Quality Engineering 2011-11-16 15:48:46 UTC
Integrated into 'main-golden'
User: Tomas Zezula <>
Log: #202455:JavaFX platform must not be hard-coded in files
Comment 11 Petr Somol 2011-11-16 18:23:10 UTC
propagated the fix to all FX samples
Comment 12 Quality Engineering 2011-11-17 07:28:35 UTC
Integrated into 'main-golden'
User: Petr Somol <>
Log: #202455 (follow-up): propagate the fix to all FX samples
Comment 13 Stepan Zebra 2011-12-06 16:00:48 UTC
verified in 7.1 FCS
Comment 14 arataj 2013-01-18 10:12:06 UTC
Created attachment 130353 [details]
project libraries
Comment 15 arataj 2013-01-18 10:15:44 UTC
Is the bug really fixed? I attach a screenshot of "compile-time libraries" from a freshly created project in NB 7.2. Perhaps it works anyway, the "broken references" do. But it may look suspicious to the users.
Comment 16 arataj 2013-01-18 10:20:42 UTC
even that IDE shows an absolute path anyway, looks fine: