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 API<https://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.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> >>> 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 >>> >>>> >>> >> >>> >>> >> >