JDK-8117191 : JavaFX applications with FXML fail while running on browser
  • Type: Bug
  • Component: javafx
  • Sub-Component: fxml
  • Affected Version: 7u6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-07-23
  • Updated: 2021-05-20
  • Resolved: 2013-10-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Blocks :  
JDK-8091203 - FXML should support usage of @FXML annotation even in unsigned contexts
Duplicate :  
JDK-8123640 - FXML doesn't work in applet mode
Relates :  
JDK-8117109 - FXMLLoader throws " java.lang.InternalError: CallerSensitive annotation expected at frame 1 "
Relates :  
JDK-8122052 - [Regression] As of b115 ListView of SceneBuilder Import dialog is broken
Description
When we try to run a JavaFX FXML  application embedded as applet, it fails because of a RuntimeException.

javafx.fxml.FXML loader's private HashMap<String, Field> getControllerFields() throws LoadException; 
method throws a SecurityAcception while calling getDeclaredFields method of the controller class.

Developers should be able to embed their JavaFX FXML applications  GUI's without signing their jars.

One possible solution is to call getFields method instead of calling getDeclaredFields. Developers can declare controller fields as public.
Comments
This issue is related to: https://javafx-jira.kenai.com/browse/RT-30131
10-01-2014
Starting in 7u51 (January 2014), all RIAs are going to need both a code signature and a Permissions attribute within the Manifest (https://blogs.oracle.com/java-platform-group/entry/new_security_requirements_for_rias). So in essence, the role of signed or unsigned is moot and the issue becomes how to use the FXML Loader in a sandboxed environment. The first comment on the blog entry was "I would like FXML to work in sandbox mode when the items are public. Currently it needs reflection and that violates the sandbox."
09-09-2013
Starting with Java SE 7 Update 21 in April 2013 all Java Applets and Web Start Applications are encouraged to be signed with a trusted certificate, for more info: http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html
12-04-2013
We are currently forced to hand-craft all our UI due to this issue. We have a requirement to run unsigned because unsigned applications are limited to sandbox access with no access to local resources so they are regarded as "safe" (i.e. they pose no threat to the local system). In these restricted environments it is a significant effort to get signed applications approved but unsigned applications are allowed without scrutiny. I'm not sure if there is a fatal flaw to this reasoning but this is what our clients require so for the moment signing is not an option for us. We are really looking forward to a solution for this issue (even if it means we have to declare all @FXML members/methods as public).
15-02-2013
I've verified that Class.getDeclaredFields() is indeed the problem. But I'm also wondering whether the ability to run from unsigned jar is still important now when default security level of Java in browser is set to High (and even recommendation is to set it to Very High), which means that such unsigned application won't be executed.
25-01-2013
Lombard is JavaFX 3.0.
24-07-2012
Exactly, signing is not the main issue... Another example is flash, it asks only allow or deny on the other hand java behaves like the application will damage the computer or steal all the private data on the computer it is about to run. These architectural constraints prevent java gui platforms to be more popular. JavaFX will be used as stand alone of course but the main advantage is that it is easy to distribute it on the web and it will be used mostly like that i assume. Thus not scaring users with unnecessary security messages would be nice. May I ask what is the Lombard version is this mean this issuue wont be fixed for a long time ?
24-07-2012
This is a known issue (see above). However, as you note, it is possible to work around this limitation by making controller fields and methods public.
24-07-2012
Duplicate of RT-14883.
24-07-2012
> after signing jar users are notified that the application is a security risk and that notification causes users tend to not permit the application to run Understood, though that may be more of an issue with how the JRE presents the notification than any inherent issues with signing code. All iOS apps need to be signed, for example, yet this doesn't seem to prevent users from downloading and installing them. :-)
24-07-2012
Thanks. Although there is nothing done in the application to be considered as a security risk (just loading fxml), after signing jar users are notified that the application is a security risk and that notification causes users tend to not permit the application to run. This is a major problem for applications that target the social media.
24-07-2012
Changing status to "Bug"/"Major" (I would not consider this "Blocker" or "Critical" since it is possible to work around the issue by signing the JAR).
24-07-2012
> I made the all controller fields and methods public but unsigned jar gives the same error from applet. > The exception is below : > SEVERE: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers") OK. That is not the expected behavior and sounds like a potential bug. I will re-open this issue.
24-07-2012
nope i cant make the application to run with Public fields method it is the same error still getting. For a possiblety of misundertanding this exception is only thrown for using as webstart or java applet. The same application is running as expected as a standalone java application.
24-07-2012
Hi Greg, I made the all controller fields and methods public but unsigned jar gives the same error from applet. The exception is below : SEVERE: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers")
24-07-2012
> First of all this not a feature this is an obvious bug. It is not a bug because it is a known issue, and has been since before 2.0 was released. > Secondly and most importatntly currently there is no workaround. > ...the method should be getFields not getDeclaredFields so public fields and methods would work. That is incorrect. Public fields are supported by the current implementation.
24-07-2012
First of all this not a feature this is an obvious bug. And its priority is not medium because it perevents JavaFX applet development with FXML. Secondly and most importatntly currently there is no workaround. As I explained in the description for workaround the method should be getFields not getDeclaredFields so public fields and methods would work. The exception is thrownvwhen calling getDeclaredFields....
24-07-2012