JDK-8117109 : FXMLLoader throws " java.lang.InternalError: CallerSensitive annotation expected at frame 1 "
  • Type: Bug
  • Component: deploy
  • Sub-Component: packager
  • Affected Version: 8
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-11-12
  • Updated: 2015-06-17
  • Resolved: 2013-11-18
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
Duplicate :  
JDK-8124647 - JRE 8 launcher doesn't load classes from the JavaFX-Class-Path attribute added to the manifest
Duplicate :  
JDK-8118218 - fx:jar + fx:resources produces a jar with JavaFX-Class-Path attribute in the manifest
Duplicate :  
JDK-8116735 - Launcher has AWT dependencies
Duplicate :  
JDK-8119288 - Cannot start using the launcher: java.lang.InternalError: CallerSensitive annotation expected at frame 1
Relates :  
JDK-8116629 - Program compiled with Java 8 b113 on Windows will not run on same java version on Raspberry PI
Relates :  
JDK-8118218 - fx:jar + fx:resources produces a jar with JavaFX-Class-Path attribute in the manifest
Relates :  
JDK-8117191 - JavaFX applications with FXML fail while running on browser
Relates :  
JDK-8124647 - JRE 8 launcher doesn't load classes from the JavaFX-Class-Path attribute added to the manifest
Description
Since we moved to FX8 b115, SB bundle is broken because FXMLLoader throws
the exception below.


java.lang.reflect.InvocationTargetException 
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
        at java.lang.reflect.Method.invoke(Method.java:483) 
        at com.javafx.main.Main.launchApp(Main.java:731) 
        at com.javafx.main.Main.main(Main.java:882) 
Caused by: java.lang.RuntimeException: Exception in Application start method 
        at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:894) 
        at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) 
        at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) 
        at java.lang.Thread.run(Thread.java:744) 
Caused by: java.lang.InternalError: CallerSensitive annotation expected at frame 1 
        at sun.reflect.Reflection.getCallerClass(Native Method) 
        at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2398) 
        at com.oracle.javafx.scenebuilder.kit.fxom.FXOMLoader.load(FXOMLoader.java:81) 
        at com.oracle.javafx.scenebuilder.kit.fxom.FXOMDocument.<init>(FXOMDocument.java:71) 
        at com.oracle.javafx.scenebuilder.kit.editor.EditorController.updateFxomDocument(EditorController.java:1341) 
        at com.oracle.javafx.scenebuilder.kit.editor.EditorController.setFxmlTextAndLocation(EditorController.java:440) 
        at com.oracle.javafx.scenebuilder.app.DocumentWindowController.loadWithDefaultContent(DocumentWindowController.java:210) 
        at com.oracle.javafx.scenebuilder.app.SceneBuilderApp.handleLaunch(SceneBuilderApp.java:221) 
        at com.oracle.javafx.scenebuilder.app.AppPlatform.requestStartGeneric(AppPlatform.java:132) 
        at com.oracle.javafx.scenebuilder.app.AppPlatform.requestStart(AppPlatform.java:100) 
        at com.oracle.javafx.scenebuilder.app.SceneBuilderApp.start(SceneBuilderApp.java:179) 
        at com.sun.javafx.application.LauncherImpl$8.run(LauncherImpl.java:837) 
        at com.sun.javafx.application.PlatformImpl$7.run(PlatformImpl.java:331) 
        at com.sun.javafx.application.PlatformImpl$6$1.run(PlatformImpl.java:297) 
        at com.sun.javafx.application.PlatformImpl$6$1.run(PlatformImpl.java:294) 
        at java.security.AccessController.doPrivileged(Native Method) 
        at com.sun.javafx.application.PlatformImpl$6.run(PlatformImpl.java:294) 
        at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) 
        at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) 
        at com.sun.glass.ui.win.WinApplication.access$300(WinApplication.java:39) 
        at com.sun.glass.ui.win.WinApplication$4$1.run(WinApplication.java:112) 
        ... 1 more
Comments
This issue is fixed. The fix is available in Scene Builder b07.
30-12-2013
[~elp] Could you verify, that issue is fixed?
30-12-2013
http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6b44a535f706
18-11-2013
Changes look fine. Approved.
18-11-2013
Looks good to me. Approved.
18-11-2013
This is a slightly dialed back version. Basically the same thing as the first webrev except left the API for setEmbeddedLauncher, because that is used by some app's Kevin and David please review http://cr.openjdk.java.net/~kcr/RT-34236.1/
18-11-2013
Can we get a more targeted fix in for b117?
16-11-2013
I get several build failures in the closed build, but I think they are just symptoms of the larger problem that there are still other places relying on com.javafx.main package. For example, if you use the NetBeans JavaFX project types it produces the following: # This is a JavaFX project javafx.enabled=true javafx.fallback.class=com.javafx.main.NoJavaFXFallback # Main class for JavaFX javafx.main.class=javafxapplication1.JavaFXApplication1 ... # Main class for Java launcher main.class=com.javafx.main.Main I think this is the primary reason for the failures in our internal build, but I see other references as well. So as much as I very much like the idea of getting rid of all of the com.javafx.main launcher, it looks like it will be more difficult (and perhaps more risky) than we initially thought.
15-11-2013
David and Kevin please review
15-11-2013
Review: http://cr.openjdk.java.net/~kcr/RT-34236/
15-11-2013
https://javafx-jira.kenai.com/browse/RT-28372
14-11-2013
https://javafx-jira.kenai.com/browse/RT-33765
14-11-2013
Should update this blog or add comment at least https://blogs.oracle.com/thejavatutorials/entry/javafx_2_0_beta_packager as well
14-11-2013
Doc-impact, -noembedlauncher will be removed from JDK8 options - http://docs.oracle.com/javafx/2/deployment/javafxpackager.htm
14-11-2013
We have several issues currently open that are related to adding JavaFX-Class-Path and using com.javafx.main.Main launcher in FX8. They were only originally required for 2.2x and are now causing problems in FX8. By not using com.javafx.main.Main and JavaFX-Class-Path fixes blocker RT-34236 and addresses the other two (plus I also recently fixed another problem in Main for scene builder - https://javafx-jira.kenai.com/browse/RT-33765 and https://javafx-jira.kenai.com/browse/RT-28372). After discussion with David and Kevin, I think it's best to completely remove com.javafx.main.Main, JavaFX-Class-Path and JavaFX-Application-Class, from fx8, the consequence is that you wouldn't be able to package an application using FX2.2u with JDK8. It won't work at this point anyway since JDK8 in now binary incompatible with JDK7. This means you can only package an application in the tool chain family that you are building with i.e. Use JDK7 packager to build app that uses any JDK7 ire Use JDK8 packager to build app that uses any JDK8 ire The only change an app may require is making sure their Application class has a main that calls launcher(String[] args). I'm going ahead with this change unless we run into some significant problem.
14-11-2013
With Mark's patch for ant-javafx.jar, the problem seems to be fixed. To recap, as suspected, root cause of RT-34236 appears to be the addition of: 1) RT-33765 (fx:jar + fx:resources produces a jar with JavaFX-Class-Path attribute in the manifest) 2) SB's workaround for RT-33765 3) a side effect from RT-34146 (FXMLLoader no longer inject variables when controller is a private static class) Since we removed #1 and #2, then RT-34236 no longer happens and Scene Builder now starts fine.
14-11-2013
@Yves: that may be another side effect of RT-34146. Our policy file probably needs some updates.
14-11-2013
I built an SB bundle on Mac with ant-javafx.jar from Mark: good news, I'm able to see SB starting up and it seems to work fine. I assume I can safely skip doing the same test on Windows and Linux, but don't hesitate to let me know if you think testing should be done on all platforms. There's a stack at startup to investigate, root cause could be on SB side: Exception in thread "LibraryFolderWatcher(/Users/yjoan/Library/Application Support/Scene Builder/Library)" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.javafx.scene.control.behavior") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1571) at java.lang.ClassLoader$1.run(ClassLoader.java:502) at java.lang.ClassLoader$1.run(ClassLoader.java:500) at java.security.AccessController.doPrivileged(Native Method) at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:500) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:455) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:367) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at com.oracle.javafx.scenebuilder.kit.library.util.JarExplorer.exploreEntry(JarExplorer.java:146) at com.oracle.javafx.scenebuilder.kit.library.util.JarExplorer.explore(JarExplorer.java:70) at com.oracle.javafx.scenebuilder.kit.library.user.LibraryFolderWatcher.exploreAndUpdateLibrary(LibraryFolderWatcher.java:236) at com.oracle.javafx.scenebuilder.kit.library.user.LibraryFolderWatcher.runDiscovery(LibraryFolderWatcher.java:111) at com.oracle.javafx.scenebuilder.kit.library.user.LibraryFolderWatcher.run(LibraryFolderWatcher.java:80) at java.lang.Thread.run(Thread.java:744)
14-11-2013
Sent ant-javafx.jar with fix to Yves and Eric to verify. Will create webrev tomorrow
14-11-2013
Sounds great.
14-11-2013
Sounds great.
14-11-2013
I have tested a fix with eliminating com.javafx.main.Main, JavaFX-Class-Path and JavaFX-Application-Class. Should have fix tonight with a jar that SceneBuilder can confirm with later tonight.
14-11-2013
Could this be as simple as adding @CallerSensitive to javafx.fxml.FXMLLoader.load?
13-11-2013
Thanks. I am likely one of a billion people that will be harassing you about this. Sorry.
13-11-2013
I spent yesterday looking at it, other than the test with Class-Path I don't have anything else to report, will continue working on it today
13-11-2013
I also tested with Class-Path rather than JavaFX-Class-Path and didn't make any difference.
13-11-2013
Mark, this is critical and killing SceneBuilder preview. It's bad. Can you get to it ASAP?
13-11-2013
SB performs its startup sequence in Application.start(Stage). For everything else, it relies on jfx-packager launcher.
13-11-2013
With Java 8 we should no longer be using com.javafx.main.Main(). It was only left in for compatibility with FX 2 (and I'm not sure how well it serves that purpose). Having said that, I think that the attached patch might be a reasonable solution to the problem, but it will need to be tested. Question for the SB team: is there a reason you need to still use com.javafx.main.Main to launch your application?
13-11-2013
I produced manually a SceneBuilder jar where the manifest contains Class-Path in place of JavaFX-Class-Path, as recommended by David (see RT-33765): dhcp-grenoble-10-166-105-112:Java yjoan$ manifest /Applications/JavaFX\ Scene\ Builder\ 2.0.app/Contents/Java/SceneBuilderApp.jar Manifest-Version: 1.0 Class-Path: SceneBuilderKit.jar Created-By: JavaFX Packager JavaFX-Application-Class: com.oracle.javafx.scenebuilder.app.SceneBuil derApp Main-Class: com/javafx/main/Main JavaFX-Version: 8.0+ Implementation-Title: JavaFX Scene Builder 2.0 Implementation-Version: 2.0 (Developer Preview) Implementation-Vendor: Oracle I copied it into my SB app and get a similar stack at startup; you'll notice however the line number in FXMLLoader.java differs a little (2382 against 2398) as in both cases we use strictly FX 8 b115, but this is most probably a false alarm because the stack below comes from a run on Mac as the one in the Description comes from a run on Linux. java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.javafx.main.Main.launchApp(Main.java:731) at com.javafx.main.Main.main(Main.java:882) Caused by: java.lang.RuntimeException: Exception in Application start method at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:894) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.InternalError: CallerSensitive annotation expected at frame 1 at sun.reflect.Reflection.getCallerClass(Native Method) at javafx.fxml.FXMLLoader.load(FXMLLoader.java:2382) at com.oracle.javafx.scenebuilder.app.menubar.MenuBarController.getMenuBar(MenuBarController.java:215) at com.oracle.javafx.scenebuilder.app.SceneBuilderApp.handleLaunch(SceneBuilderApp.java:211) at com.oracle.javafx.scenebuilder.app.AppPlatform.requestStartMac(AppPlatform.java:210) at com.oracle.javafx.scenebuilder.app.AppPlatform.requestStart(AppPlatform.java:98) at com.oracle.javafx.scenebuilder.app.SceneBuilderApp.start(SceneBuilderApp.java:179) at com.sun.javafx.application.LauncherImpl$8.run(LauncherImpl.java:837) at com.sun.javafx.application.PlatformImpl$7.run(PlatformImpl.java:331) at com.sun.javafx.application.PlatformImpl$6$1.run(PlatformImpl.java:297) at com.sun.javafx.application.PlatformImpl$6$1.run(PlatformImpl.java:294) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl$6.run(PlatformImpl.java:294) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
13-11-2013
It might also be related to RT-33765 : to workaround this issue, we added some code to setup the Thread Context Class Loader. May be this code conflicts with the new FXMLLoader behavior (see RT-34146).
12-11-2013
This might be a side effect of RT-34146.
12-11-2013
This is a blocking issue : it prevents us to publish SB preview and going back to b113 is no longer an option now.
12-11-2013