hg: openjfx/8u-dev/rt: RT-36505 [Chart] xAxis and yAxis side properties no longer work in Ensemble8
Changeset: f9e4bf8e344e Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-04-08 09:47 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f9e4bf8e344e RT-36505 [Chart] xAxis and yAxis side properties no longer work in Ensemble8 ! modules/controls/src/main/java/javafx/scene/chart/XYChart.java
hg: openjfx/8u-dev/rt: [JAVADOC] ListChangeListener documentation updated wrt modifications done inside the listener. Related to RT-36426
Changeset: 0fde14fc10cd Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-04-08 10:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0fde14fc10cd [JAVADOC] ListChangeListener documentation updated wrt modifications done inside the listener. Related to RT-36426 ! modules/base/src/main/java/javafx/collections/ListChangeListener.java
Re: JavaFX 2 + with LWJGL ( OpenGL )
Hey guys, I followed the discussion with interest. I just checked the lwjdlfx-approach. It looked promising in the first place but it has still major performance issues. It is based on the snapshot functionality in the Node base class. This is actually a similar approach we've seen in the JFXPanel which indeed has horrible performance. From my point of view it is not the way to go. What I really like to see is a way to get a textureID directly into the JavaFX opengl context wraped with an Image object. I know it's pretty hard to do this cross-platform and cross-implementation (DirectX, OpenGl) but otherwise JFX can't be mixed with Third-Party applications. Okay, using JFX on top of a OpenGL game just as a replacement of the UI-framework like Ogre-UI etc. might still be a good point since there is no high performance need. In our case we need both high performance UI and high performance additional OpenGL drawings. As of today I could only use JavaFX with a SwingPanel that encapsulates a JOGL context... just my 2 cents Matthias Am 07.04.2014 um 18:47 schrieb Stephen F Northover steve.x.northo...@oracle.com: The lwjglfx solution. Steve On 2014-04-07 12:45 PM, Exo Verse wrote: @ Steve Which approach are you referring too ? The lwjglfx solution or this transparency background solution ? The lwjglfx I am assuming here since its drawing out to an image and back in again. But if your speaking about my transparency issue I solved, I didn't realize it was sending out to an image and back again. Could you please elaborate as to which solution your speaking about ? Torak On Mon, Apr 7, 2014 at 12:33 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: This solution is cool, but it draws to an image, sucks out the bits and then converts that to an FX image. This is a good approach because it uses API and does not rely on any internals of FX. Hopefully it is fast enough for you. Steve On 2014-04-06 12:41 PM, Exo Verse wrote: Yea the OpenGL comes with your graphics drivers for your video card. So your correct that it doesn't ship with JavaFX. What I have been going on about is trying to find a way to use JavaFX with LWJGL. In case you are unaware, LWJGL just means Light Weight Java OpenGL and its a wrapper for the OpenGL API. It's an alternative to JOGL. On another note, as I did a search, Thanks to Tom showing me that link I examined that code and I found something of interest in the JOGL code interface.. well it lead me to a google search, and viola.. LWJGL with JavaFX. :) LINK : https://github.com/Spasi/LWJGL-FX So just wanted to post the link here and say thanks for all of your help. :) Cheers, Torak On Sun, Apr 6, 2014 at 12:35 PM, Tom Schindl tom.schi...@bestsolution.at wrote: JavaFX does not ship OpenGL binaries on windows you have to build it your own. Please note: a) if there are people who manage to write a prism pipeline on jogl why should you not be able to do the same with lwjgl? b) the talk i mentionned from felipe and steve show how to get access to the native OpenGL context and there from you can use any API you like can't remember which one they used Tom Von meinem iPhone gesendet Am 06.04.2014 um 18:18 schrieb Exo Verse tora...@gmail.com: Thanks, but as I mentioned in my original post, I don't like JOGL. It doesn't work with my setup. I use LWJGL because its only about the OpenGL and not other libraries, and its an easy API wrapper to use. There are many many reason I hate JOGL.. but this thread is not about hating on JOGL, its about finding a way to use LWJGL with JavaFX2+. Also, Win32 API calls can use both DirectX and OpenGL APIs. And it doesn't matter what Windows OS you're using. I have tested this out from Windows XP all the way to Windows 7 - 32/64 Bit with no problem. Cheers Torak On Sun, Apr 6, 2014 at 11:52 AM, Tom Schindl tom.schi...@bestsolution.atwrote: There is a talk from Felipe and Steve at J1 last year how to embed OpenGL into FX using *internal* API! Search for it on parleys - this does not help you on Win32 which uses directx instead of javafx. BTW there are people doing a JOGL pipeline https://bitbucket.org/dejayberlin/joglfxpipeline/src! Tom Von meinem iPhone gesendet Am 06.04.2014 um 17:25 schrieb Exo Verse tora...@gmail.com: Yea its a shame that using JavaFX as an option along with OpenGL wasn't even thought of to begin with. I don't understand why they limit you like they do. Them trying to recreate the wheel and make their own version of a 3D interface is just plain stupid if it can't run low level. I can see 2D games and applications with a LOT of usage for JavaFX and its 2D graphics API. But True 3D needs low level other wise its a waste of time. Well, thanks for the replies. Guess I'll have to stick with using other sources for my GUI. It's just that I like JavaFX
hg: openjfx/8u-dev/rt: RT-36293: [TouchEvent, PopupControl] Using a ListView in PopupControl generates a lot of TouchEvent NPE
Changeset: 1094ee8bcf66 Author:pchelko Date: 2014-04-08 15:31 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1094ee8bcf66 RT-36293: [TouchEvent, PopupControl] Using a ListView in PopupControl generates a lot of TouchEvent NPE Reviewed-by: anthony, martin ! modules/graphics/src/main/java/com/sun/glass/ui/TouchInputSupport.java
Re: [RT-33954] static block...causes IllegalStateException - re-open?
The two ways of launching are equivalent however, at one point, we did not run main() even when main() was available and this caused problems on the desktop. Lots of code was written that expected main() to run and this code was broken. We will be supporting both ways of launching an FX application for the foreseeable future, however, the IDE's still need to understand that FX applications that only contain start() are launchable. Steve On 2014-04-08 8:34 AM, ngalarn...@abinitio.com wrote: Hi Richard, You raised this IntelliJ issue here: http://youtrack.jetbrains.com/issue/IDEA-101939 It is marked as a feature request. Are you guys saying that the 2 ways of launching are not equivalent? What is the difference? Maybe that issue should be upgraded to a BUG if the old launching method is now wrong, not merely old fashioned. Neil From: Richard Bair richard.b...@oracle.com To: Kevin Rushforth kevin.rushfo...@oracle.com Cc: openjfx-dev@openjdk.java.net, Sandipan Razzaque m...@sandipan.net Date: 04/07/2014 09:43 PM Subject:Re: [RT-33954] static block...causes IllegalStateException - re-open? Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net Yes, this is one of the few things that I just hate about IDEA. On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: I can't speak to other IntelliJ issues, but the root cause of this particular one is the same thing that Debbie ran into last week -- IntelliJ doesn't launch programs using the standard Java launcher. For whatever reason, it uses its own launcher. This might be worth raising with JetBrains. -- Kevin Jonathan Giles wrote: Kevin, Yes, that is the program I used, and yes, I get the 'Toolkit not initialized' exception. I am running IntelliJ, so that is the reason. I switched over to Eclipse and the code run as expected. I am slightly bothered by the occasional failures that seem to be IntelliJ-specific. I have a gut feeling that it doesn't always run all tests (or that it runs them slightly differently to get different results than when run on the command line). Does anyone know why this is? I'm actually most at home in Eclipse, so perhaps I should switch to that as my primary IDE for OpenJFX development. -- Jonathan On 8/04/2014 11:29 a.m., Kevin Rushforth wrote: Just to make sure we are running the same program, the one I ran to verify that RT-33954 is fixed was the simple test program in the comments of that bug. Here it is (with the imports omitted for brevity). public class Example extends Application { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } @Override public void start(final Stage primaryStage) throws Exception { } } The above program runs fine for me with no exception. Jonathan: are you seeing something different? Or perhaps running a different example? NOTE: if you run this from IntelliJ it will not work. I verified that with Debbie last week (on a different issue), which may be why you are seeing a problem. Running it from command line, from NB, or from Eclipse works. -- Kevin Jonathan Giles wrote: Firstly, I agree - this does seem to still be reproducible despite Kevin's comment that it should have been resolved in JavaFX 8.0 due to RT-28754 https://javafx-jira.kenai.com/browse/RT-28754, so that is troubling. I'll leave Kevin to comment on that. Secondly, RT-33954 was closed as a duplicate of RT-28754 https://javafx-jira.kenai.com/browse/RT-28754, so it would be better to leave RT-33954 closed and move discussion (including what you recently posted) into RT-28754 https://javafx-jira.kenai.com/browse/RT-28754. The discussion can start in there and most probably a new bug will need to be opened (as RT-28754 https://javafx-jira.kenai.com/browse/RT-28754 did result in a code change that at one point appears to have fixed the problem, so we're possibly dealing with a regression). Thirdly, whether this is a suitable bug for someone learning the ropes is debatable. I'll leave Kevin to offer his thoughts, but perhaps you can propose a patch that resolves this issue for you in your test scenarios. Also, a good starting point is to develop a simple test application that helps to demonstrate this issue (preferably the test case is a single class with no dependencies), and which you can then share in the jira issue via copy/paste into a comment. Fourthly, to be a contributor in the OpenJDK requires you to follow a process to get the paperwork in order. It is wise to get that started as soon as possible, as it can sometimes take a while. Here's a link to the process: http://openjdk.java.net/contribute/ The main thing is the OCA. Finally, welcome! :-) -- Jonathan On 6/04/2014 1:06 p.m., Sandipan Razzaque wrote: Hi JavaFX devs! I was wondering how people
Re: [RT-33954] static block...causes IllegalStateException - re-open?
Hi, What you've discovered is exactly how the Java launcher is intended to work (we have unit tests that verify this fact). The launcher recognizes a JavaFX application by checking whether the class to be launched extends javafx.application.Application. So this isn't a side effect, but an intentional behavior. The advice given in the JIRA is what you will need to do before accessing JavaFX: 1) Call Application.launch(MyAppClass.class) 2) Call new JFXPanel() -- Kevin Sandipan Razzaque wrote: Kevin/Jonathan - Steve's example in the Jira captures perfectly what I was encountering in Java, and I've been trying to boil it down into a minimal failing example - reconciling it with what I've experienced in dynamic languages. Turns out it's about whether or not you extend Application. This leads me to believe that it's something in Application's classloading that enables your example to work cleanly. Try your class out again - with the minor edits I've made below: public class Example /* extends Application */ { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } /*@Override*/ public void start(final Stage primaryStage) throws Exception { } } Cheers, SR Sandipan Razzaque | www.sandipan.net http://www.sandipan.net On Mon, Apr 7, 2014 at 9:42 PM, Richard Bair richard.b...@oracle.com mailto:richard.b...@oracle.com wrote: Yes, this is one of the few things that I just hate about IDEA. On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com mailto:kevin.rushfo...@oracle.com wrote: I can't speak to other IntelliJ issues, but the root cause of this particular one is the same thing that Debbie ran into last week -- IntelliJ doesn't launch programs using the standard Java launcher. For whatever reason, it uses its own launcher. This might be worth raising with JetBrains. -- Kevin Jonathan Giles wrote: Kevin, Yes, that is the program I used, and yes, I get the 'Toolkit not initialized' exception. I am running IntelliJ, so that is the reason. I switched over to Eclipse and the code run as expected. I am slightly bothered by the occasional failures that seem to be IntelliJ-specific. I have a gut feeling that it doesn't always run all tests (or that it runs them slightly differently to get different results than when run on the command line). Does anyone know why this is? I'm actually most at home in Eclipse, so perhaps I should switch to that as my primary IDE for OpenJFX development. -- Jonathan On 8/04/2014 11:29 a.m., Kevin Rushforth wrote: Just to make sure we are running the same program, the one I ran to verify that RT-33954 is fixed was the simple test program in the comments of that bug. Here it is (with the imports omitted for brevity). public class Example extends Application { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } @Override public void start(final Stage primaryStage) throws Exception { } } The above program runs fine for me with no exception. Jonathan: are you seeing something different? Or perhaps running a different example? NOTE: if you run this from IntelliJ it will not work. I verified that with Debbie last week (on a different issue), which may be why you are seeing a problem. Running it from command line, from NB, or from Eclipse works. -- Kevin Jonathan Giles wrote: Firstly, I agree - this does seem to still be reproducible despite Kevin's comment that it should have been resolved in JavaFX 8.0 due to RT-28754 https://javafx-jira.kenai.com/browse/RT-28754, so that is troubling. I'll leave Kevin to comment on that. Secondly, RT-33954 was closed as a duplicate of RT-28754 https://javafx-jira.kenai.com/browse/RT-28754, so it would be better to leave RT-33954 closed and move discussion (including what you recently posted) into RT-28754 https://javafx-jira.kenai.com/browse/RT-28754. The discussion can start in there and most probably a new bug will need to be opened (as RT-28754 https://javafx-jira.kenai.com/browse/RT-28754 did result in a code change that at one point appears to have fixed the problem, so we're possibly dealing with a regression). Thirdly, whether this is a suitable bug for someone learning the ropes is debatable. I'll leave Kevin to offer his thoughts, but perhaps you can propose a patch that resolves this
Re: [RT-33954] static block...causes IllegalStateException - re-open?
Stephen F Northover wrote: Right, I jumped in mid-thread. The link points to an IntelliJ issue that talks about launching only. IntelliJ inserts its own launcher and this isn't great, but do we have concrete problems or JIRA that are caused by this? Yes we have concrete problems (but no JIRA yet) caused by this. This feature of IntelliJ prevents the initializing of the specified app class from being done on the FX application thread. I will file an FX JIRA and follow up. -- Kevin Steve On 2014-04-08 9:21 AM, Kevin Rushforth wrote: Note that this feature request is only somewhat related to the issue at hand. Yes we would like IntelliJ (and Eclipse) to recognize and launch JavaFX application subclasses with no main method, but the issue here is that IntelliJ (unlike the other IDEs) inserts its own launcher class in front of the program you are running, which causes the Java launcher to not recognize that it is being asked to launch a JavaFX program. So we could either file a new JIRA or maybe add the additional information to the existing one that Richard filed. Either way, we need to document this on our Wiki to warn IntelliJ users of this. -- Kevin Stephen F Northover wrote: The two ways of launching are equivalent however, at one point, we did not run main() even when main() was available and this caused problems on the desktop. Lots of code was written that expected main() to run and this code was broken. We will be supporting both ways of launching an FX application for the foreseeable future, however, the IDE's still need to understand that FX applications that only contain start() are launchable. Steve On 2014-04-08 8:34 AM, ngalarn...@abinitio.com wrote: Hi Richard, You raised this IntelliJ issue here: http://youtrack.jetbrains.com/issue/IDEA-101939 It is marked as a feature request. Are you guys saying that the 2 ways of launching are not equivalent? What is the difference? Maybe that issue should be upgraded to a BUG if the old launching method is now wrong, not merely old fashioned. Neil From: Richard Bair richard.b...@oracle.com To: Kevin Rushforth kevin.rushfo...@oracle.com Cc: openjfx-dev@openjdk.java.net, Sandipan Razzaque m...@sandipan.net Date: 04/07/2014 09:43 PM Subject:Re: [RT-33954] static block...causes IllegalStateException - re-open? Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net Yes, this is one of the few things that I just hate about IDEA. On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: I can't speak to other IntelliJ issues, but the root cause of this particular one is the same thing that Debbie ran into last week -- IntelliJ doesn't launch programs using the standard Java launcher. For whatever reason, it uses its own launcher. This might be worth raising with JetBrains. -- Kevin Jonathan Giles wrote: Kevin, Yes, that is the program I used, and yes, I get the 'Toolkit not initialized' exception. I am running IntelliJ, so that is the reason. I switched over to Eclipse and the code run as expected. I am slightly bothered by the occasional failures that seem to be IntelliJ-specific. I have a gut feeling that it doesn't always run all tests (or that it runs them slightly differently to get different results than when run on the command line). Does anyone know why this is? I'm actually most at home in Eclipse, so perhaps I should switch to that as my primary IDE for OpenJFX development. -- Jonathan On 8/04/2014 11:29 a.m., Kevin Rushforth wrote: Just to make sure we are running the same program, the one I ran to verify that RT-33954 is fixed was the simple test program in the comments of that bug. Here it is (with the imports omitted for brevity). public class Example extends Application { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } @Override public void start(final Stage primaryStage) throws Exception { } } The above program runs fine for me with no exception. Jonathan: are you seeing something different? Or perhaps running a different example? NOTE: if you run this from IntelliJ it will not work. I verified that with Debbie last week (on a different issue), which may be why you are seeing a problem. Running it from command line, from NB, or from Eclipse works. -- Kevin Jonathan Giles wrote: Firstly, I agree - this does seem to still be reproducible despite Kevin's comment that it should have been resolved in JavaFX 8.0 due to RT-28754 https://javafx-jira.kenai.com/browse/RT-28754, so that is troubling. I'll leave Kevin to comment on that. Secondly, RT-33954 was closed as a duplicate of RT-28754 https://javafx-jira.kenai.com/browse/RT-28754, so it would be better to leave RT-33954 closed and move discussion (including what you
hg: openjfx/8u-dev/rt: RT-35197: Use Lambda in FX runtime and samples [graphics]
Changeset: 50c055ca2ce1 Author:snorthov Date: 2014-04-08 10:40 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/50c055ca2ce1 RT-35197: Use Lambda in FX runtime and samples [graphics] Summary: This component was lambdified (unlambdified file names recorded in the JIRA) ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java ! modules/graphics/src/main/java/com/sun/glass/ui/EventLoop.java ! modules/graphics/src/main/java/com/sun/glass/ui/GestureSupport.java ! modules/graphics/src/main/java/com/sun/glass/ui/Platform.java ! modules/graphics/src/main/java/com/sun/glass/ui/Screen.java ! modules/graphics/src/main/java/com/sun/glass/ui/View.java ! modules/graphics/src/main/java/com/sun/glass/ui/Window.java ! modules/graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/ios/IosApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensLogger.java ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensTouchInputSupport.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacCommonDialogs.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleRobot.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleSettings.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/RunnableProcessor.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/KeyInput.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/TouchInput.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/TouchState.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/GetEvent.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxInputDeviceRegistry.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxPlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxTouchProcessor.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/linux/LinuxTouchTransform.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/vnc/VNCScreen.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/x11/X11InputDeviceRegistry.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/x11/X11Screen.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTClipboard.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTCursor.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTMenuDelegate.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTTimer.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTView.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTWindow.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/swtPlatformFactory.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinApplication.java ! modules/graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java ! modules/graphics/src/main/java/com/sun/javafx/application/HostServicesDelegate.java ! modules/graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java ! modules/graphics/src/main/java/com/sun/javafx/css/SelectorPartitioning.java ! modules/graphics/src/main/java/com/sun/javafx/css/StyleManager.java ! modules/graphics/src/main/java/com/sun/javafx/css/StyleMap.java ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSLexer.java ! modules/graphics/src/main/java/com/sun/javafx/font/AndroidFontFinder.java ! modules/graphics/src/main/java/com/sun/javafx/font/DFontDecoder.java ! modules/graphics/src/main/java/com/sun/javafx/font/FontConfigManager.java ! modules/graphics/src/main/java/com/sun/javafx/font/FontFileReader.java ! modules/graphics/src/main/java/com/sun/javafx/font/FontFileWriter.java ! modules/graphics/src/main/java/com/sun/javafx/font/MacFontFinder.java ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/font/WoffDecoder.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/OS.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/OS.java ! modules/graphics/src/main/java/com/sun/javafx/font/freetype/OSFreetype.java ! modules/graphics/src/main/java/com/sun/javafx/font/freetype/OSPango.java ! modules/graphics/src/main/java/com/sun/javafx/geom/AreaOp.java !
Re: [RT-33954] static block...causes IllegalStateException - re-open?
https://javafx-jira.kenai.com/browse/RT-36581 -- Kevin Kevin Rushforth wrote: Stephen F Northover wrote: Right, I jumped in mid-thread. The link points to an IntelliJ issue that talks about launching only. IntelliJ inserts its own launcher and this isn't great, but do we have concrete problems or JIRA that are caused by this? Yes we have concrete problems (but no JIRA yet) caused by this. This feature of IntelliJ prevents the initializing of the specified app class from being done on the FX application thread. I will file an FX JIRA and follow up. -- Kevin Steve On 2014-04-08 9:21 AM, Kevin Rushforth wrote: Note that this feature request is only somewhat related to the issue at hand. Yes we would like IntelliJ (and Eclipse) to recognize and launch JavaFX application subclasses with no main method, but the issue here is that IntelliJ (unlike the other IDEs) inserts its own launcher class in front of the program you are running, which causes the Java launcher to not recognize that it is being asked to launch a JavaFX program. So we could either file a new JIRA or maybe add the additional information to the existing one that Richard filed. Either way, we need to document this on our Wiki to warn IntelliJ users of this. -- Kevin Stephen F Northover wrote: The two ways of launching are equivalent however, at one point, we did not run main() even when main() was available and this caused problems on the desktop. Lots of code was written that expected main() to run and this code was broken. We will be supporting both ways of launching an FX application for the foreseeable future, however, the IDE's still need to understand that FX applications that only contain start() are launchable. Steve On 2014-04-08 8:34 AM, ngalarn...@abinitio.com wrote: Hi Richard, You raised this IntelliJ issue here: http://youtrack.jetbrains.com/issue/IDEA-101939 It is marked as a feature request. Are you guys saying that the 2 ways of launching are not equivalent? What is the difference? Maybe that issue should be upgraded to a BUG if the old launching method is now wrong, not merely old fashioned. Neil From: Richard Bair richard.b...@oracle.com To: Kevin Rushforth kevin.rushfo...@oracle.com Cc: openjfx-dev@openjdk.java.net, Sandipan Razzaque m...@sandipan.net Date: 04/07/2014 09:43 PM Subject:Re: [RT-33954] static block...causes IllegalStateException - re-open? Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net Yes, this is one of the few things that I just hate about IDEA. On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: I can't speak to other IntelliJ issues, but the root cause of this particular one is the same thing that Debbie ran into last week -- IntelliJ doesn't launch programs using the standard Java launcher. For whatever reason, it uses its own launcher. This might be worth raising with JetBrains. -- Kevin Jonathan Giles wrote: Kevin, Yes, that is the program I used, and yes, I get the 'Toolkit not initialized' exception. I am running IntelliJ, so that is the reason. I switched over to Eclipse and the code run as expected. I am slightly bothered by the occasional failures that seem to be IntelliJ-specific. I have a gut feeling that it doesn't always run all tests (or that it runs them slightly differently to get different results than when run on the command line). Does anyone know why this is? I'm actually most at home in Eclipse, so perhaps I should switch to that as my primary IDE for OpenJFX development. -- Jonathan On 8/04/2014 11:29 a.m., Kevin Rushforth wrote: Just to make sure we are running the same program, the one I ran to verify that RT-33954 is fixed was the simple test program in the comments of that bug. Here it is (with the imports omitted for brevity). public class Example extends Application { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } @Override public void start(final Stage primaryStage) throws Exception { } } The above program runs fine for me with no exception. Jonathan: are you seeing something different? Or perhaps running a different example? NOTE: if you run this from IntelliJ it will not work. I verified that with Debbie last week (on a different issue), which may be why you are seeing a problem. Running it from command line, from NB, or from Eclipse works. -- Kevin Jonathan Giles wrote: Firstly, I agree - this does seem to still be reproducible despite Kevin's comment that it should have been resolved in JavaFX 8.0 due to RT-28754 https://javafx-jira.kenai.com/browse/RT-28754, so that is troubling. I'll leave Kevin to comment on that. Secondly, RT-33954 was closed as a duplicate of RT-28754 https://javafx-jira.kenai.com/browse/RT-28754, so it
Re: Dynamic position/size change and built-in layouts
Hi again, I've created the issue in Jira: https://javafx-jira.kenai.com/browse/RT-36582 Will send the small test app to the person that will be assigned this issue. Thanks, On Thu, Apr 3, 2014 at 10:57 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: In the situation I described nothing happens after c1 changes height. But strangely if some other child changes, for instance c3 changing its height, than the children c3 and c2 will re-position correctly, taking into account the height of c1. So the change is being delayed, even if I call requestLayout().. It's being delayed for an undefined amount of time so it should have nothing to due with the pulse. On Thu, Apr 3, 2014 at 10:07 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Setting VBox preferred height to: USE_COMPUTED_SIZE, doesn't work. Regards, On Thu, Apr 3, 2014 at 6:14 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: What I'm saying isn't exactly that. What I'm saying is, for instance, if I change the height of the first child of the VBox than the other children below would re-position themselves. -VBox- - --- - - c1 - - - - - - - - --- - - --- - - c2 - - --- - - --- - - c3 - - - - - --- First child (c1) gets smaller. Result - c2 and c3 move up automatically (and the height of the VBox would also get smaller automatically): -VBox- - --- - - c1 - - --- - - --- - - c2 - - --- - - --- - - c3 - - - - - --- Thanks, On Thu, Apr 3, 2014 at 5:29 PM, Jasper Potts jasper.po...@oracle.comwrote: VBox preferred size will grow if one of its children's preferred sizes grows. It will be down the the parent node of the VBox to react to that and make the VBox bigger if there is space available. The change is not immediate it will happen one pulse later. Jasper On Apr 3, 2014, at 7:01 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi, Are built-in layouts prepared for dynamic changes of their children position and/or size? That is, for instance, if in a VBox I change the first child height the other subsequent children would re-adjust their position. My experiments with VBox tell me that this will result in bugs, i.e. it won't work. I think this is important for RIAs. Thanks, best regards, -- Pedro Duque Vieira -- Pedro Duque Vieira -- Pedro Duque Vieira -- Pedro Duque Vieira -- Pedro Duque Vieira
hg: openjfx/8u-dev/rt: RT-36576: The fxpackager tests that pop up a window or steal focus must run only when FULL_TEST=true
Changeset: fbece058a2af Author:shemnon Date: 2014-04-08 09:54 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/fbece058a2af RT-36576: The fxpackager tests that pop up a window or steal focus must run only when FULL_TEST=true Summary: This affects the two DMG tests, test will be ignored otherwise ! build.gradle ! modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacDMGBundlerTest.java
hg: openjfx/8u-dev/rt: RT-36568: [Accessibility] Implement SplitMenuButton - Win implementation + common code
Changeset: cbd08125939c Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-04-07 16:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cbd08125939c RT-36568: [Accessibility] Implement SplitMenuButton - Win implementation + common code ! modules/controls/src/main/java/javafx/scene/control/SplitMenuButton.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Role.java
hg: openjfx/8u-dev/rt: [Accessiblity] Improve TitledPane support on mac (based on AXDisclosureTriangle).
Changeset: 7968162d59cd Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-04-08 15:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7968162d59cd [Accessiblity] Improve TitledPane support on mac (based on AXDisclosureTriangle). ! modules/controls/src/main/java/javafx/scene/control/TitledPane.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java
hg: openjfx/8u-dev/rt: [Accessibility] Removing ACCORDION role, it created an (unignored) AXUnknown the a11y hierarchy on Mac, that prevented VO to read the TITLED_PANE elements inside the Accordion.
Changeset: 742752b2de3d Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-04-08 16:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/742752b2de3d [Accessibility] Removing ACCORDION role, it created an (unignored) AXUnknown the a11y hierarchy on Mac, that prevented VO to read the TITLED_PANE elements inside the Accordion. Note that ACCORDION never really add any a11y functionality, it is just an PARENT. Tested using HelloAccordion.java. ! modules/controls/src/main/java/javafx/scene/control/Accordion.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java ! modules/graphics/src/main/java/javafx/scene/accessibility/Role.java
hg: openjfx/8u-dev/rt: RT-36583: [Accelerators] KeystrokeUtils should just be a function in KeyCombination
Changeset: ae223b23abf5 Author:jgiles Date: 2014-04-09 10:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ae223b23abf5 RT-36583: [Accelerators] KeystrokeUtils should just be a function in KeyCombination ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java - modules/controls/src/main/java/com/sun/javafx/scene/control/skin/KeyCodeUtils.java - modules/controls/src/main/java/com/sun/javafx/scene/control/skin/KeystrokeUtils.java - modules/controls/src/test/java/com/sun/javafx/scene/control/skin/KeystrokeUtilsTest.java ! modules/graphics/src/main/java/javafx/scene/input/KeyCharacterCombination.java ! modules/graphics/src/main/java/javafx/scene/input/KeyCodeCombination.java ! modules/graphics/src/main/java/javafx/scene/input/KeyCombination.java ! modules/graphics/src/test/java/javafx/scene/input/KeyCombinationTest.java
Re: [RT-33954] static block...causes IllegalStateException - re-open?
Hi Kevin - Thanks for the clarification that this is indeed by design - and also for the workarounds. For Clojure, the solution looks a little inelegant and isn't idiomatic clojure - any import statement will effectively cause a class initialization to happen - so if you have any source files with an :import anything extending Control at the top you're kind of screwed, because clojure will do a Class.forName at eval time. It's nice that in nashorn we have the -fx option. Just want to gauge people's thoughts here: just as an experiment, I tried moving the contents of the Control.java static init block into LauncherImpl#launchApplication and there seem to be no visible effects at least at a superficial level. My judgement of not at a superficial level is based upon: running 'gradle test' and seeing the same result as without making the change, running the sample 'hello world' app and running the Ensemble and clicking around. A nice side effect of this is of course we can import controls in dynamic language source files in the correct way without blowing up... Cheers, SR Sandipan Razzaque | www.sandipan.net On Tue, Apr 8, 2014 at 9:09 AM, Kevin Rushforth kevin.rushfo...@oracle.comwrote: Hi, What you've discovered is exactly how the Java launcher is intended to work (we have unit tests that verify this fact). The launcher recognizes a JavaFX application by checking whether the class to be launched extends javafx.application.Application. So this isn't a side effect, but an intentional behavior. The advice given in the JIRA is what you will need to do before accessing JavaFX: 1) Call Application.launch(MyAppClass.class) 2) Call new JFXPanel() -- Kevin Sandipan Razzaque wrote: Kevin/Jonathan - Steve's example in the Jira captures perfectly what I was encountering in Java, and I've been trying to boil it down into a minimal failing example - reconciling it with what I've experienced in dynamic languages. Turns out it's about whether or not you extend Application. This leads me to believe that it's something in Application's classloading that enables your example to work cleanly. Try your class out again - with the minor edits I've made below: public class Example /* extends Application */ { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } /*@Override*/ public void start(final Stage primaryStage) throws Exception { } } Cheers, SR Sandipan Razzaque | www.sandipan.net On Mon, Apr 7, 2014 at 9:42 PM, Richard Bair richard.b...@oracle.comwrote: Yes, this is one of the few things that I just hate about IDEA. On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: I can't speak to other IntelliJ issues, but the root cause of this particular one is the same thing that Debbie ran into last week -- IntelliJ doesn't launch programs using the standard Java launcher. For whatever reason, it uses its own launcher. This might be worth raising with JetBrains. -- Kevin Jonathan Giles wrote: Kevin, Yes, that is the program I used, and yes, I get the 'Toolkit not initialized' exception. I am running IntelliJ, so that is the reason. I switched over to Eclipse and the code run as expected. I am slightly bothered by the occasional failures that seem to be IntelliJ-specific. I have a gut feeling that it doesn't always run all tests (or that it runs them slightly differently to get different results than when run on the command line). Does anyone know why this is? I'm actually most at home in Eclipse, so perhaps I should switch to that as my primary IDE for OpenJFX development. -- Jonathan On 8/04/2014 11:29 a.m., Kevin Rushforth wrote: Just to make sure we are running the same program, the one I ran to verify that RT-33954 is fixed was the simple test program in the comments of that bug. Here it is (with the imports omitted for brevity). public class Example extends Application { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } @Override public void start(final Stage primaryStage) throws Exception { } } The above program runs fine for me with no exception. Jonathan: are you seeing something different? Or perhaps running a different example? NOTE: if you run this from IntelliJ it will not work. I verified that with Debbie last week (on a different issue), which may be why you are seeing a problem. Running it from command line, from NB, or from Eclipse works. -- Kevin Jonathan Giles wrote: Firstly, I agree - this does seem to still be reproducible despite Kevin's comment that it should have been
Re: [RT-33954] static block...causes IllegalStateException - re-open?
I'll leave Kevin to speak to the specifics of the JavaFX startup process, but the argument against what you are doing in your final paragraph is that this causes everyone to pay the controls tax even when they don't make use of UI controls in their application. In particular, this loads the controls css files (or their compiled bss form), and this is by no means a free (or cheap) operation. -- Jonathan On Wednesday, 9 April 2014 3:52:58 p.m., Sandipan Razzaque wrote: Hi Kevin - Thanks for the clarification that this is indeed by design - and also for the workarounds. For Clojure, the solution looks a little inelegant and isn't idiomatic clojure - any import statement will effectively cause a class initialization to happen - so if you have any source files with an :import anything extending Control at the top you're kind of screwed, because clojure will do a Class.forName at eval time. It's nice that in nashorn we have the -fx option. Just want to gauge people's thoughts here: just as an experiment, I tried moving the contents of the Control.java static init block into LauncherImpl#launchApplication and there seem to be no visible effects at least at a superficial level. My judgement of not at a superficial level is based upon: running 'gradle test' and seeing the same result as without making the change, running the sample 'hello world' app and running the Ensemble and clicking around. A nice side effect of this is of course we can import controls in dynamic language source files in the correct way without blowing up... Cheers, SR Sandipan Razzaque | www.sandipan.net http://www.sandipan.net On Tue, Apr 8, 2014 at 9:09 AM, Kevin Rushforth kevin.rushfo...@oracle.com mailto:kevin.rushfo...@oracle.com wrote: __ Hi, What you've discovered is exactly how the Java launcher is intended to work (we have unit tests that verify this fact). The launcher recognizes a JavaFX application by checking whether the class to be launched extends javafx.application.Application. So this isn't a side effect, but an intentional behavior. The advice given in the JIRA is what you will need to do before accessing JavaFX: 1) Call Application.launch(MyAppClass.class) 2) Call new JFXPanel() -- Kevin Sandipan Razzaque wrote: Kevin/Jonathan - Steve's example in the Jira captures perfectly what I was encountering in Java, and I've been trying to boil it down into a minimal failing example - reconciling it with what I've experienced in dynamic languages. Turns out it's about whether or not you extend Application. This leads me to believe that it's something in Application's classloading that enables your example to work cleanly. Try your class out again - with the minor edits I've made below: public class Example /* extends Application */ { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } /*@Override*/ public void start(final Stage primaryStage) throws Exception { } } Cheers, SR Sandipan Razzaque | www.sandipan.net http://www.sandipan.net On Mon, Apr 7, 2014 at 9:42 PM, Richard Bair richard.b...@oracle.com mailto:richard.b...@oracle.com wrote: Yes, this is one of the few things that I just hate about IDEA. On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com mailto:kevin.rushfo...@oracle.com wrote: I can't speak to other IntelliJ issues, but the root cause of this particular one is the same thing that Debbie ran into last week -- IntelliJ doesn't launch programs using the standard Java launcher. For whatever reason, it uses its own launcher. This might be worth raising with JetBrains. -- Kevin Jonathan Giles wrote: Kevin, Yes, that is the program I used, and yes, I get the 'Toolkit not initialized' exception. I am running IntelliJ, so that is the reason. I switched over to Eclipse and the code run as expected. I am slightly bothered by the occasional failures that seem to be IntelliJ-specific. I have a gut feeling that it doesn't always run all tests (or that it runs them slightly differently to get different results than when run on the command line). Does anyone know why this is? I'm actually most at home in Eclipse, so perhaps I should switch to that as my primary IDE for OpenJFX development. -- Jonathan On 8/04/2014 11:29 a.m., Kevin Rushforth wrote: Just to make sure we are running the same program, the one I ran to verify that RT-33954 is fixed was the simple
Re: [RT-33954] static block...causes IllegalStateException - re-open?
Oh and for the record, the workaround for Clojure is to simply use workaround provided (new up a JFXPanel) within Java, and then invoke your Clojure entry point via the Java-Clojure APIhttps://github.com/clojure/clojure/blob/master/changes.md#21-java-api. This is what I meant by little inelegant and isn't idiomatic clojure - it's not all that bad :-) Cheers, SR Sandipan Razzaque | www.sandipan.net On Tue, Apr 8, 2014 at 11:52 PM, Sandipan Razzaque m...@sandipan.net wrote: Hi Kevin - Thanks for the clarification that this is indeed by design - and also for the workarounds. For Clojure, the solution looks a little inelegant and isn't idiomatic clojure - any import statement will effectively cause a class initialization to happen - so if you have any source files with an :import anything extending Control at the top you're kind of screwed, because clojure will do a Class.forName at eval time. It's nice that in nashorn we have the -fx option. Just want to gauge people's thoughts here: just as an experiment, I tried moving the contents of the Control.java static init block into LauncherImpl#launchApplication and there seem to be no visible effects at least at a superficial level. My judgement of not at a superficial level is based upon: running 'gradle test' and seeing the same result as without making the change, running the sample 'hello world' app and running the Ensemble and clicking around. A nice side effect of this is of course we can import controls in dynamic language source files in the correct way without blowing up... Cheers, SR Sandipan Razzaque | www.sandipan.net On Tue, Apr 8, 2014 at 9:09 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Hi, What you've discovered is exactly how the Java launcher is intended to work (we have unit tests that verify this fact). The launcher recognizes a JavaFX application by checking whether the class to be launched extends javafx.application.Application. So this isn't a side effect, but an intentional behavior. The advice given in the JIRA is what you will need to do before accessing JavaFX: 1) Call Application.launch(MyAppClass.class) 2) Call new JFXPanel() -- Kevin Sandipan Razzaque wrote: Kevin/Jonathan - Steve's example in the Jira captures perfectly what I was encountering in Java, and I've been trying to boil it down into a minimal failing example - reconciling it with what I've experienced in dynamic languages. Turns out it's about whether or not you extend Application. This leads me to believe that it's something in Application's classloading that enables your example to work cleanly. Try your class out again - with the minor edits I've made below: public class Example /* extends Application */ { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } /*@Override*/ public void start(final Stage primaryStage) throws Exception { } } Cheers, SR Sandipan Razzaque | www.sandipan.net On Mon, Apr 7, 2014 at 9:42 PM, Richard Bair richard.b...@oracle.comwrote: Yes, this is one of the few things that I just hate about IDEA. On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: I can't speak to other IntelliJ issues, but the root cause of this particular one is the same thing that Debbie ran into last week -- IntelliJ doesn't launch programs using the standard Java launcher. For whatever reason, it uses its own launcher. This might be worth raising with JetBrains. -- Kevin Jonathan Giles wrote: Kevin, Yes, that is the program I used, and yes, I get the 'Toolkit not initialized' exception. I am running IntelliJ, so that is the reason. I switched over to Eclipse and the code run as expected. I am slightly bothered by the occasional failures that seem to be IntelliJ-specific. I have a gut feeling that it doesn't always run all tests (or that it runs them slightly differently to get different results than when run on the command line). Does anyone know why this is? I'm actually most at home in Eclipse, so perhaps I should switch to that as my primary IDE for OpenJFX development. -- Jonathan On 8/04/2014 11:29 a.m., Kevin Rushforth wrote: Just to make sure we are running the same program, the one I ran to verify that RT-33954 is fixed was the simple test program in the comments of that bug. Here it is (with the imports omitted for brevity). public class Example extends Application { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } @Override public void start(final Stage primaryStage) throws Exception { } } The above program
Re: [RT-33954] static block...causes IllegalStateException - re-open?
This makes perfect sense. I was scratching my head about this, but now it's clear as to why that code existed in the Control class in the first place. Thanks! - SR Sandipan Razzaque | www.sandipan.net On Wed, Apr 9, 2014 at 12:01 AM, Jonathan Giles jonathan.gi...@oracle.comwrote: I'll leave Kevin to speak to the specifics of the JavaFX startup process, but the argument against what you are doing in your final paragraph is that this causes everyone to pay the controls tax even when they don't make use of UI controls in their application. In particular, this loads the controls css files (or their compiled bss form), and this is by no means a free (or cheap) operation. -- Jonathan On Wednesday, 9 April 2014 3:52:58 p.m., Sandipan Razzaque wrote: Hi Kevin - Thanks for the clarification that this is indeed by design - and also for the workarounds. For Clojure, the solution looks a little inelegant and isn't idiomatic clojure - any import statement will effectively cause a class initialization to happen - so if you have any source files with an :import anything extending Control at the top you're kind of screwed, because clojure will do a Class.forName at eval time. It's nice that in nashorn we have the -fx option. Just want to gauge people's thoughts here: just as an experiment, I tried moving the contents of the Control.java static init block into LauncherImpl#launchApplication and there seem to be no visible effects at least at a superficial level. My judgement of not at a superficial level is based upon: running 'gradle test' and seeing the same result as without making the change, running the sample 'hello world' app and running the Ensemble and clicking around. A nice side effect of this is of course we can import controls in dynamic language source files in the correct way without blowing up... Cheers, SR Sandipan Razzaque | www.sandipan.net http://www.sandipan.net On Tue, Apr 8, 2014 at 9:09 AM, Kevin Rushforth kevin.rushfo...@oracle.com mailto:kevin.rushfo...@oracle.com wrote: __ Hi, What you've discovered is exactly how the Java launcher is intended to work (we have unit tests that verify this fact). The launcher recognizes a JavaFX application by checking whether the class to be launched extends javafx.application.Application. So this isn't a side effect, but an intentional behavior. The advice given in the JIRA is what you will need to do before accessing JavaFX: 1) Call Application.launch(MyAppClass.class) 2) Call new JFXPanel() -- Kevin Sandipan Razzaque wrote: Kevin/Jonathan - Steve's example in the Jira captures perfectly what I was encountering in Java, and I've been trying to boil it down into a minimal failing example - reconciling it with what I've experienced in dynamic languages. Turns out it's about whether or not you extend Application. This leads me to believe that it's something in Application's classloading that enables your example to work cleanly. Try your class out again - with the minor edits I've made below: public class Example /* extends Application */ { public static void main(String[] args) { //this is called from a static block in javafx.scene.control.Control PlatformImpl.setDefaultPlatformUserAgentStylesheet(); Application.launch(args); } /*@Override*/ public void start(final Stage primaryStage) throws Exception { } } Cheers, SR Sandipan Razzaque | www.sandipan.net http://www.sandipan.net On Mon, Apr 7, 2014 at 9:42 PM, Richard Bair richard.b...@oracle.com mailto:richard.b...@oracle.com wrote: Yes, this is one of the few things that I just hate about IDEA. On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com mailto:kevin.rushfo...@oracle.com wrote: I can't speak to other IntelliJ issues, but the root cause of this particular one is the same thing that Debbie ran into last week -- IntelliJ doesn't launch programs using the standard Java launcher. For whatever reason, it uses its own launcher. This might be worth raising with JetBrains. -- Kevin Jonathan Giles wrote: Kevin, Yes, that is the program I used, and yes, I get the 'Toolkit not initialized' exception. I am running IntelliJ, so that is the reason. I switched over to Eclipse and the code run as expected. I am slightly bothered by the occasional failures that seem to be IntelliJ-specific. I have a gut feeling that it doesn't always run all tests (or that it runs them slightly differently to get different results than when run on the command line). Does anyone know why