Re: [RT-33954] static block...causes IllegalStateException - re-open?
The two ways of launching are equivalent however, at one point, we did
not run main() even when main() was available and this caused problems
on the desktop. Lots of code was written that expected main() to run
and this code was broken. We will be supporting both ways of launching
an FX application for the foreseeable future, however, the IDE's still
need to understand that FX applications that only contain start() are
launchable.
Steve
On 2014-04-08 8:34 AM, ngalarn...@abinitio.com wrote:
Hi Richard,
You raised this IntelliJ issue here:
http://youtrack.jetbrains.com/issue/IDEA-101939
It is marked as a feature request.
Are you guys saying that the 2 ways of launching are not equivalent?
What is the difference?
Maybe that issue should be upgraded to a BUG if the old launching method
is now wrong, not merely old fashioned.
Neil
From: Richard Bair richard.b...@oracle.com
To: Kevin Rushforth kevin.rushfo...@oracle.com
Cc: openjfx-dev@openjdk.java.net, Sandipan Razzaque m...@sandipan.net
Date: 04/07/2014 09:43 PM
Subject:Re: [RT-33954] static block...causes IllegalStateException
- re-open?
Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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.b...@oracle.com
mailto: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 mailto: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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
Stephen F Northover wrote:
Right, I jumped in mid-thread. The link points to an IntelliJ issue
that talks about launching only.
IntelliJ inserts its own launcher and this isn't great, but do we have
concrete problems or JIRA that are caused by this?
Yes we have concrete problems (but no JIRA yet) caused by this. This
feature of IntelliJ prevents the initializing of the specified app
class from being done on the FX application thread. I will file an FX
JIRA and follow up.
-- Kevin
Steve
On 2014-04-08 9:21 AM, Kevin Rushforth wrote:
Note that this feature request is only somewhat related to the issue
at hand. Yes we would like IntelliJ (and Eclipse) to recognize and
launch JavaFX application subclasses with no main method, but the
issue here is that IntelliJ (unlike the other IDEs) inserts its own
launcher class in front of the program you are running, which causes
the Java launcher to not recognize that it is being asked to launch a
JavaFX program. So we could either file a new JIRA or maybe add the
additional information to the existing one that Richard filed.
Either way, we need to document this on our Wiki to warn IntelliJ
users of this.
-- Kevin
Stephen F Northover wrote:
The two ways of launching are equivalent however, at one point, we
did not run main() even when main() was available and this caused
problems on the desktop. Lots of code was written that expected
main() to run and this code was broken. We will be supporting both
ways of launching an FX application for the foreseeable future,
however, the IDE's still need to understand that FX applications
that only contain start() are launchable.
Steve
On 2014-04-08 8:34 AM, ngalarn...@abinitio.com wrote:
Hi Richard,
You raised this IntelliJ issue here:
http://youtrack.jetbrains.com/issue/IDEA-101939
It is marked as a feature request.
Are you guys saying that the 2 ways of launching are not equivalent?
What is the difference?
Maybe that issue should be upgraded to a BUG if the old launching
method
is now wrong, not merely old fashioned.
Neil
From: Richard Bair richard.b...@oracle.com
To: Kevin Rushforth kevin.rushfo...@oracle.com
Cc: openjfx-dev@openjdk.java.net, Sandipan Razzaque
m...@sandipan.net
Date: 04/07/2014 09:43 PM
Subject:Re: [RT-33954] static block...causes
IllegalStateException
- re-open?
Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
https://javafx-jira.kenai.com/browse/RT-36581
-- Kevin
Kevin Rushforth wrote:
Stephen F Northover wrote:
Right, I jumped in mid-thread. The link points to an IntelliJ issue
that talks about launching only.
IntelliJ inserts its own launcher and this isn't great, but do we
have concrete problems or JIRA that are caused by this?
Yes we have concrete problems (but no JIRA yet) caused by this. This
feature of IntelliJ prevents the initializing of the specified app
class from being done on the FX application thread. I will file an FX
JIRA and follow up.
-- Kevin
Steve
On 2014-04-08 9:21 AM, Kevin Rushforth wrote:
Note that this feature request is only somewhat related to the issue
at hand. Yes we would like IntelliJ (and Eclipse) to recognize and
launch JavaFX application subclasses with no main method, but the
issue here is that IntelliJ (unlike the other IDEs) inserts its own
launcher class in front of the program you are running, which causes
the Java launcher to not recognize that it is being asked to launch
a JavaFX program. So we could either file a new JIRA or maybe add
the additional information to the existing one that Richard filed.
Either way, we need to document this on our Wiki to warn IntelliJ
users of this.
-- Kevin
Stephen F Northover wrote:
The two ways of launching are equivalent however, at one point, we
did not run main() even when main() was available and this caused
problems on the desktop. Lots of code was written that expected
main() to run and this code was broken. We will be supporting both
ways of launching an FX application for the foreseeable future,
however, the IDE's still need to understand that FX applications
that only contain start() are launchable.
Steve
On 2014-04-08 8:34 AM, ngalarn...@abinitio.com wrote:
Hi Richard,
You raised this IntelliJ issue here:
http://youtrack.jetbrains.com/issue/IDEA-101939
It is marked as a feature request.
Are you guys saying that the 2 ways of launching are not equivalent?
What is the difference?
Maybe that issue should be upgraded to a BUG if the old launching
method
is now wrong, not merely old fashioned.
Neil
From: Richard Bair richard.b...@oracle.com
To: Kevin Rushforth kevin.rushfo...@oracle.com
Cc: openjfx-dev@openjdk.java.net, Sandipan Razzaque
m...@sandipan.net
Date: 04/07/2014 09:43 PM
Subject:Re: [RT-33954] static block...causes
IllegalStateException
- re-open?
Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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.comwrote:
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.comwrote:
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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.rushfo...@oracle.com mailto: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 http://www.sandipan.net
On Mon, Apr 7, 2014 at 9:42 PM, Richard Bair
richard.b...@oracle.com mailto: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
mailto: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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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
APIhttps://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.comwrote:
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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.gi...@oracle.comwrote:
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.rushfo...@oracle.com mailto: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 http://www.sandipan.net
On Mon, Apr 7, 2014 at 9:42 PM, Richard Bair
richard.b...@oracle.com mailto: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
mailto: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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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.comwrote:
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
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
Re: [RT-33954] static block...causes IllegalStateException - re-open?
Hi Jonathan, Thanks for the fast response and the warm welcome :-) I've moved my comment into RT-28754, so let's await Kevin's input. Will work on a test class as the next thing as you've recommended. I received confirmation of the OCA being processed just yesterday, so should be OK from that front. Cheers, SR Sandipan Razzaque | www.sandipan.net On Sat, Apr 5, 2014 at 9:20 PM, Jonathan Giles jonathan.gi...@oracle.comwrote: 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-28754https://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-28754https://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-28754did 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
