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
>> >>>>
>> >>
>>
>>
>
