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

Reply via email to