Hi All,
I spent some time refactoring the program which displays this bug.
It's
now small enough to share the source in an email, but it is very
very
dense and the proof of bug, one specific line to standard I/O,
requires
the source code to be read and understood in order to see the bug.
As I
said previously, more comprehensible and user-friendly versions of
this
program are available at . The javadoc is more copious, the bug is
manifested as an exception and the side effect of the bug are more
consequential.
This brief version cnosists of just two classes. Here is the JavaFX
Application class:
***************************************************************************
package bareBonesJavaFXBugExample;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import javafx.stage.Stage;
/**
* An {@link Application} with one {@link Pane} containing one
{@link
Label}. The {@link Label} has a single {@link
javafx.event.EventHandler}, {@link LabelEventHandler} which
processes
all {@link MouseEvent}s the {@link Label} receives.
* <p></p>
* To trigger the bug, run the application, then spend a second
mouse
over the little label in the upper left hand corner of the scrren.
You
will see output to standard I/O. Then, click the label, which will
then
disppear. Check the I/O for Strings ending in debugCounter is 1.
<p></p>
* What that String means and how it proves that the JavaFX
Application
Thread has become reentrant is explained in the javadoc of {@link
LabelEventHandler}.
*/
public class JavaFXAnomalyBareBonesApplication extends Application
{
public void start(Stage primaryStage)
{
Pane mainPane = new Pane();
mainPane.setMinHeight(800);
mainPane.setMinWidth(800);
Label label = new Label(" this is quite a bug !!!!");
LabelEventHandler labelEventHandler = new
LabelEventHandler(mainPane, label);
label.addEventHandler(MouseEvent.ANY, labelEventHandler);
mainPane.getChildren().add(label);
Scene scene = new Scene(mainPane);
primaryStage.setScene(scene);
primaryStage.show();
}
/**
* The entry point of application.
*
* @param args
* the input arguments
*/
public static void main(String[] args)
{
launch(args);
}
}
***************************************************************************
and here is its only dependency, the EventListener class. I included
enough javadoc to have the program makes sense. :
***************************************************************************
package bareBonesJavaFXBugExample;
import javafx.event.Event;
import javafx.event.EventHandler;
import javafx.scene.control.Label;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import java.util.Collection;
import java.util.ConcurrentModificationException;
/**
* An {@link EventHandler} implementation for {@link MouseEvent}s.
<p></p> This implementation's {@link EventHandler#handle(Event)}
shows
the relevant debug information to standard output before and after
removing the member {@link #label} from the {@link #pane}.
* <p></p>
* <b>discussion</b><br></br>
* <P></P>
* Users should first satisfy themselves that the value of {@link
LabelEventHandler#debugCounter} can only be non-zero, in fact 1
(one) in
the method {@link LabelEventHandler#showDebugInformation(String)} if
the
method {@link LabelEventHandler#handle(MouseEvent)} has been
re-entered
recursively, that is, before a previous invocation of {@link
LabelEventHandler#handle(MouseEvent)} has returned.
* <p></p>
* Proof: <p></p> 1) <code>debugCounter</code> starts at value 0
(zero).
<p></p> 2) <code>debugCounter</code> is only incremented once, by 1
(one), and that is after the first call to {@link
LabelEventHandler#showDebugInformation(String)} has returned.<p></p>
3)
<code>debugCounter</code> is only decremented once, by 1 (one) and
that
is before the last call to {@link
LabelEventHandler#showDebugInformation(String)}.<p></p> 4) however,
because
* <code>debugCounter</code> is a class variable ( it's static), if
handle() is recurvsively re-entered then it's value can be 1 (one)
when
the re-entrant Thread executes {@link
LabelEventHandler#showDebugInformation(String)}
* <p></p>
* End proof.
* <p></p>
* <p></p>
* <p>
* The output of this method to standard I/O is volumnious but
searching
the output for the exact String "debugCounter is 1" will immediately
show the {@link LabelEventHandler#handle(MouseEvent)} method to have
been recursively entered. <p></p>
* Some other possibilities other than the JavaFX Application Thread
recursing into {@code handle()} need to be addressed. <p></p> One is
the
fact that the compiler is free to reorder statements if it can
* prove that such a reordering would have no effect on the
program's
correctness.
* <br></br>
* So somehow the compiler is reordering the increment/decrement of
{@code debugCounter} and the calls to {@code
showDebugInformation}.
<br></br> But this would alter the correctness of the program, so
this
cannot be the case, or the compiler is making an error.<P></P>
* <p>
* <p>
* Another is the fact that I/O is not instantaneous and can appear
to
standard output later than it actually was executed. <br></br> This
is
something often seen in debug stack traces, where the output is
broken
up or interleaved by the output of the stack trace even though the
two
sets of statments, i/o and stack trace i/o, were strictly ordered in
execution. <br></br> But this can't account for the value of {@code
debugCounter}, so it can't
* be the reason "debugCounter is 1" appears in output.<p></p> In
fact
we can make this recursive behaviour more obviously consequential to
the
correctness of the program. <p></p> If {@code handle() } is being
recursively re-entered, then we can force a {@link
ConcurrentModificationException} on a {@link Collection}. <br></br>
If
we try to invoke {@link Collection#add(Object)} to a {@link
Collection}
while it is being iterated through, then a
* {@link ConcurrentModificationException} will be thrown.<p></p> If
we
re-write this program slightly to first add or remove to or from a
{@link Collection} then iterate through that {@link Collection}
within
the scope of execution of {@code handle()}, <em>and</em> {@code
handle()} is being recursively invoked, then we may see a {@link
ConcurrentModificationException}.
* <p></p>
* Two other instances of this same basic program exist at the link
provided. They are named {@link
JavaFXAnomalySimpleVersionApplication}
and {@link JavaFXAnomalyComplexVersionApplication} which is written
to
throw a {@link ConcurrentModificationException} when the JavaFX
Application Thread becomes reentrant.
* <p></p>
* I also have a screen grab (not included here) of the stack trace
at a
specific moment <code>handle()/code> is being invoked, and it can
clearly be seen that the previous executing line was within the
scope of
execution of the previous invocation of <code>handle()</code>.
* <p></p>
* In the .zip file at the link there is a readme.txt. In that file.
I
present the two lines of code which need to be added, and where they
need to be added, so as to generate the same stack trace showing
the
same thing.
*
*
* </p>
*/
public class LabelEventHandler implements EventHandler<MouseEvent>
{
/**
* a counter which acts as a recursion detector. If {@link
#handle(MouseEvent)} is never recursively invoked by the JavaFX
Application Thread, then it's value will never be other than 0
(zero) in
{@link #showDebugInformation(String)}.
*/
private static int debugCounter;
/**
* The {@link Label} which will disappear when clicked. This
causes a
MOUSE_EXITED_TARGET event top be fired and that in turn causes the
JavaFX Event Dispatch Thread to recurse into this class's {@link
#handle(MouseEvent)}
*/
private Label label;
/**
* The {@link Pane} which contains the {@link Label}. The {@link
Label} is removed from this {@link Pane}.
*/
private final Pane pane;
/**
* Assign the values to the members {@link Pane} and {@link Label}
*/
public LabelEventHandler(Pane pane, Label label)
{
this.pane = pane;
this.label = label;
}
/**
* Causes the member {@link #label} to be removed as a child of
the
member {@link #pane}.
*
*
* @param mouseEvent
* the {@link MouseEvent} received from the JavaFX
Application
Thread from the {@link Label} which this {@link EventHandler} is
listening to.
*/
@Override
public void handle(MouseEvent mouseEvent)
{
showDebugInformation("ENTERING");// debug can only every be 0
(zero)
at this point
debugCounter++;
if (mouseEvent.getEventType().equals(MouseEvent.MOUSE_PRESSED)
&&
mouseEvent.isPrimaryButtonDown())
{
pane.getChildren().remove(label);
}
debugCounter--;
showDebugInformation("EXITING");// debug can only every be 0
(zero)
at this point
}
/**
* Displays two values to standard output. The first is a {@link
String} indicating whether the {@link
LabelEventHandler#handle(MouseEvent)} method is being entered or
exited
and the second is the value of {@link
LabelEventHandler#debugCounter} at
the time this method is executed.
*
* @param enterOrExit
* the string ENTERING or EXITING reflecting the point at
which this method was invoked by {@link
LabelEventHandler#handle(MouseEvent)}.
*/
private void showDebugInformation(String enterOrExit)
{
System.out.println();
System.out.print(enterOrExit + " method handle");
System.out.print(" and debugCounter is " + debugCounter);
System.out.println();
}
}
*******************************************************************
Just cut and pasting these two into files named by their
respective
Java class names, then placing those files into a folder
named bareBonesJavaFXBugExample is all it should take to make this
work.
Unless I get contrary feedback, I will file this as a bug after I
run
it against the most recent releases of the JavaFX.
Either way I am interested in feedback from the community.
Cheers !
On Saturday, September 8, 2018 at 8:02 AM, Kevin Rushforth
<kevin.rushfo...@oracle.com> wrote:
I am not aware of such a bug. If you have a test program, then you
can
file a bug here:
https://bugreport.java.com/
-- Kevin
On 9/7/2018 5:37 PM, jav...@use.startmail.com wrote:
Hi,
I have a couple of very small apps (3 small classes in one case
and 5
in another) which demonstrate that, under some circumstances, the
JavaFX Application Thread will recursively re-enter
EventHandler#handle().
So this means that it is already in handle (and calls therefrom)
and
will, in some situations not complete that processing (thus
exiting
handle) before it reappears in the same instance of EventHandler's
handle method again. So this is true recursion.
I actually don't know if this is expected behavior or not. No one
I've
talked to expected it; the general understanding is the JavaFX
Application Thread (processing) is specifically single-threaded
and
also that it will defintily complete one invocation of handle()
before
beginning another one.
I have to say that there is NO other Thread in play here, at
least no
other Thread my applications create (what's going on
QuantumToolKit
may be a different story.)
The material upshot of this is it can lead to apparent program
incorrectness if the dev believes that it's not the case, and 100%
of
devs I've talked to think it's not possible.
I am happy to post or attach the classes or modules as requested
but
first I wanted to check to see if in fact this is already known to
be
true and is in fact expected behavior, in which case it's a
non-issue
and just a subtlety people are not aware of.
Thank you so much !
