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.com>wrote: > 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 >>> 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 felt about re-opening this >>> bug? I don't believe >>> >>>>> it has been fixed (see my comment). >>> >>>>> >>> >>>>> I'm also happy to work on it. But, let me know if you >>> think my time would >>> >>>>> be better spent elsewhere. I'm keen to take on a small >>> bug to just get the >>> >>>>> hang of the process and community (I'll be stumbling >>> with mercurial along >>> >>>>> the way too!). I think this bug is an ideal candidate >>> for someone just >>> >>>>> learning the ropes. >>> >>>>> >>> >>>>> https://javafx-jira.kenai.com/browse/RT-33954 >>> >>>>> >>> >>>>> Cheers, >>> >>>>> SR >>> >>>>> >>> >>>>> Sandipan Razzaque | www.sandipan.net >>> <http://www.sandipan.net> >>> >>>> >>> >> >>> >>> >>> >>
