[RT-33954] static block...causes IllegalStateException - re-open?
Jonathan Giles
jonathan.giles at oracle.com
Wed Apr 9 04:01:41 UTC 2014
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