[RT-33954] static block...causes IllegalStateException - re-open?
Sandipan Razzaque
me at sandipan.net
Wed Apr 9 04:06:57 UTC 2014
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.giles at 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.rushforth at oracle.com <mailto:kevin.rushforth at 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.bair at oracle.com <mailto:richard.bair at 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.rushforth at oracle.com
>>> <mailto:kevin.rushforth at 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>
>>> >>>>
>>> >>
>>>
>>>
>>>
>>
More information about the openjfx-dev
mailing list