From hjohn at xs4all.nl Sat Sep 1 06:43:46 2018
From: hjohn at xs4all.nl (John Hendrikx)
Date: Sat, 1 Sep 2018 08:43:46 +0200
Subject: Review Request for JDK-8209968: Fix rounding error in image scale
calculation
Message-ID: <2d331c2f-167f-18bf-c7c0-bc48796c7438@xs4all.nl>
Hi,
This is a review request for:
https://bugs.openjdk.java.net/browse/JDK-8209968
The PR is on Github:
https://github.com/javafxports/openjdk-jfx/pull/170
--John
From pedro.duquevieira at gmail.com Sat Sep 1 12:00:48 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sat, 1 Sep 2018 13:00:48 +0100
Subject: Is JavaFX going to truly be a community project?
Message-ID:
?* 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.
?*
?* Another is the fact that I/O is not instantaneous and can appear to
standard output later than it actually was executed.
?*
?* 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.
?*
?* Proof: 1) debugCounter
starts at value 0
(zero). 2) debugCounter
is only incremented once,
by 1 (one), and that is after the first call to {@link
LabelEventHandler#showDebugInformation(String)} has returned. 3)
debugCounter
is only decremented once, by 1 (one) and that
is before the last call to {@link
LabelEventHandler#showDebugInformation(String)}. 4) however,
because
?* debugCounter
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)}
?*
?* End proof.
?*
?*
?*
?* So somehow the compiler is reordering the increment/decrement of
{@code? debugCounter} and the calls to {@code? ?showDebugInformation}.
But this would alter the correctness of the program, so this
cannot be the case, or the compiler is making an error.
?*
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.
But this can't account for the value of {@code?
?debugCounter}, so it can't
?* be the reason "debugCounter is 1" appears in output.
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. 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()}, and {@code?
?handle()} is being recursively invoked, then we may see a {@link
ConcurrentModificationException}.
?*
?* 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.
?*
?* I also have a screen grab (not included here) of the stack trace at
a specific moment 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
handle()
.
?*
?* 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.
?*
?*
?*
debugCounter
starts at value 0 (zero).
> 2) debugCounter
is only incremented once, by 1
> (one), and that is after the first call to {@link
> LabelEventHandler#showDebugInformation(String)} has returned. 3)
> debugCounter
is only decremented once, by 1 (one) and that
> is before the last call to {@link
> LabelEventHandler#showDebugInformation(String)}. 4) however, because
> * debugCounter
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)}
> *
> * End proof.
> *
> *
> * > * 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.
> * Some other possibilities other than the JavaFX Application Thread > recursing into {@code handle()} need to be addressed. 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. > *> *
> * Another is the fact that I/O is not instantaneous and can appear to
> standard output later than it actually was executed.
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.
But this can't account for the value of {@code
> debugCounter}, so it can't
> * be the reason "debugCounter is 1" appears in output.
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 handle()
.
> *
> * 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.
> *
> *
> *
> */
> public class LabelEventHandler implements EventHandler
> {
> /**
> * 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
> 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, javafx at 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 !
>
From javafx at use.startmail.com Sun Sep 9 21:38:53 2018
From: javafx at use.startmail.com (javafx at use.startmail.com)
Date: Sun, 9 Sep 2018 17:38:53 -0400
Subject: JavaFX Application Thread is recursively re-entrant into
Eventhandler handle() method under some circumstances
In-Reply-To: <11944a2d-d48d-4f0d-4587-47879921953d@xs4all.nl>
References: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com>
<55dd39dc-27e7-ce2b-62ae-247dc2808269@oracle.com>
<3105330a76395e24195b1b544a07f337.startmail@startmail.com>
<11944a2d-d48d-4f0d-4587-47879921953d@xs4all.nl>
Message-ID: <7409fb960d86a0b42db91804ccb32692.startmail@startmail.com>
I did not say it was another Thread. In fact, I said it was the Java
Application Thread itself- being recursively re-entrant.
Specifically, at the time the MOUSE_EXITED_TARGET event is generated,
the Java Application Thread has a choice- continue proocessing the
EventHandler#handle method which it is in, or respond to
the?MOUSE_EXITED_TARGET event which was just generated. Suprisingly, it
does the second , completes that call to handle, then the stack pops
and it nfinishes the previous invocation of handle. It's not about
another Thread.
I don't? ?refer to the stack trace as proof? ?that the thread is
reentrant. I do say the contrapositve of that, which is, if the thread
trace didn't show the bug? then the bug? wouldn't? exist. But I don't
assert the stack trace as a proof.
The proof is? the proof? I gave in the javadoc, and that is the value
of one the static int debugCounter acheives in the debug statements can
only be explained if? recursive re-entrancy has cocurred, which? is
true. You need to address this.?
Also, this is merely the most barebones implementation which reveals
this bug. This is why I didn't want to post it, because you have to
work out what cannot be the case before evaluating the argument. What
cannot be the case is? debugCounter cannot have value 1 in the debug
output method.?
The link provides a more consequential /? more easily understood bug /
less dismissable bug- a ConcurrentModificationException? against a Set
which the EventHandler is iterating through. That CME happens not
because two threads are operating on the Set but because one thread ,
the JAva Application Thread is modifying the Set while it is also
iterating through it.?
?
?
On Sunday, September 9, 2018 at 4:04 PM, John Hendrikx
wrote:
?
> I see nothing special in the stack trace.
>
> When you remove the component, a new MouseEvent *must* trigger
> (MouseEvent.EXITED) as it always needs to match with
> MouseEvent.ENTERED.
>
> So, the call to 'remove' triggers a new event, which gets handled by
> the
> same handler. ?It is indeed entered recursively, but in a normal
> fashion. ?This has nothing to do with another thread or compiler
> bugs.
>
> Don't be confused by the double "handle" lines in the stacktrace.
> ?This
> happens when methods are overriden (the line number is 1).
>
> There are two relevant lines in this trace:
>
> ? ?LabelEventHandler.handle(LabelEventHandler.java:95)
>
> ...where Remove is called, which triggers the recursive call later
> on:
>
> ? ?LabelEventHandler.handle(LabelEventHandler.java:88)
>
> ... for the MouseEvent.EXITED event.
>
> The full stack trace is this:
>
> at
> bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:88)
> at
> bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1)
> at
> javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218)
> at
> javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
> at
> javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
> at
> javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
> at
> javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
> at
> javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
> at
> javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at
> javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at
> javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at
> javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> at
> javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
> at javafx.base/javafx.event.Event.fireEvent(Event.java:198)
> at
> javafx.base/com.sun.javafx.event.EventQueue.fire(EventQueue.java:48)
> at
> javafx.graphics/javafx.scene.Scene$MouseHandler.handleNodeRemoval(Scene.java:3717)
> at
> javafx.graphics/javafx.scene.Scene$MouseHandler.access$7800(Scene.java:3604)
> at
> javafx.graphics/javafx.scene.Scene.generateMouseExited(Scene.java:3601)
> at
> javafx.graphics/javafx.scene.Parent$3.onProposedChange(Parent.java:613)
> at
> javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:329)
> at
> javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:221)
> at
> bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:95)
> at
> bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1)
> at
> javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218)
>
> (... rest cut off as it is not needed ... )
>
> --John
>
> On 09/09/2018 19:05, javafx at use.startmail.com wrote:
>> 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.
>> ?*
>> ?* 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.
>>
>> ?* 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.
>> 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}.
>> ?*
>> ?* discussion
>> ?*
>> ?* 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.
>> ?*
>> ?* Proof: 1) debugCounter
starts at value 0
>> (zero).
>> 2) debugCounter
is only incremented once, by 1
>> (one), and that is after the first call to {@link
>> LabelEventHandler#showDebugInformation(String)} has returned.
>> 3)
>> debugCounter
is only decremented once, by 1 (one) and
>> that
>> is before the last call to {@link
>> LabelEventHandler#showDebugInformation(String)}. 4) however,
>> because
>> ?* debugCounter
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)}
>> ?*
>> ?* End proof.
>> ?*
>> ?*
>> ?*
>> ?* 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.
>> ?* Some other possibilities other than the JavaFX Application Thread
>> recursing into {@code handle()} need to be addressed. 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.
>> ?*
>> ?* So somehow the compiler is reordering the increment/decrement of
>> {@code ?debugCounter} and the calls to {@code ?
>> showDebugInformation}.
>>
But this would alter the correctness of the program, so
>> this
>> cannot be the case, or the compiler is making an error.
>> ?*
>> ?*
>> ?* Another is the fact that I/O is not instantaneous and can appear
>> to
>> standard output later than it actually was executed.
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.
But this can't account for the value of {@code
>> ?debugCounter}, so it can't
>> ?* be the reason "debugCounter is 1" appears in output.
In
>> fact
>> we can make this recursive behaviour more obviously consequential to
>> the
>> correctness of the program. If {@code ? handle() } is being
>> recursively re-entered, then we can force a {@link
>> ConcurrentModificationException} on a {@link Collection}. ?
>> 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. 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()}, and {@code
>> ?handle()} is being recursively invoked, then we may see a {@link
>> ConcurrentModificationException}.
>> ?*
>> ?* 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.
>> ?*
>> ?* I also have a screen grab (not included here) of the stack trace
>> at a
>> specific moment 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 handle()
.
>> ?*
>> ?* 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.
>> ?*
>> ?*
>> ?*
>> ?*/
>> public class LabelEventHandler implements EventHandler
>> {
>> ? /**
>> ? ?* 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
>> 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, javafx at 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 !
From javafx at use.startmail.com Sun Sep 9 21:58:16 2018
From: javafx at use.startmail.com (javafx at use.startmail.com)
Date: Sun, 9 Sep 2018 17:58:16 -0400
Subject: JavaFX Application Thread is recursively re-entrant into
Eventhandler handle() method under some circumstances
In-Reply-To: <11944a2d-d48d-4f0d-4587-47879921953d@xs4all.nl>
References: <11143b3d4920860f005d4243e5b9a9c1.startmail@startmail.com>
<55dd39dc-27e7-ce2b-62ae-247dc2808269@oracle.com>
<3105330a76395e24195b1b544a07f337.startmail@startmail.com>
<11944a2d-d48d-4f0d-4587-47879921953d@xs4all.nl>
Message-ID:
I am reading your stack trace but I defintely never mentioned the
double invocation to handle that I see there are evidencing anything.
The issue is the value of debugCounter at a two certain moments in the
application - in the two calls to showDebugInformation.?
Although the proof that I am right is contained in the value
debugCounter in the method showDebugInformation in the current program,
if you go to the link in my previous post and download? and run the
Complex version of this, you can more easily see the departure of the
JavaApplicationThread from the instance of handle which is on the stack
- and at a method which is not handle (as it is in this one) followed
by? it's recursive re-entry to handle , completion of that
recursive-handle's execution and re-entry and then completion into the
previous invocation of handle. It's is completely obvious in the output
of that Applcation.?
That application also throws the ConcurrentModificationException which
is no way an artifact or misreading of a stacktrace.?
However, what is at issue in this program is the value of debugCounter
in?showDebugInformation.
Cheers.?
?
On Sunday, September 9, 2018 at 4:04 PM, John Hendrikx
wrote:
?
> I see nothing special in the stack trace.
>
> When you remove the component, a new MouseEvent *must* trigger
> (MouseEvent.EXITED) as it always needs to match with
> MouseEvent.ENTERED.
>
> So, the call to 'remove' triggers a new event, which gets handled by
> the
> same handler. ?It is indeed entered recursively, but in a normal
> fashion. ?This has nothing to do with another thread or compiler
> bugs.
>
> Don't be confused by the double "handle" lines in the stacktrace.
> ?This
> happens when methods are overriden (the line number is 1).
>
> There are two relevant lines in this trace:
>
> ? ?LabelEventHandler.handle(LabelEventHandler.java:95)
>
> ...where Remove is called, which triggers the recursive call later
> on:
>
> ? ?LabelEventHandler.handle(LabelEventHandler.java:88)
>
> ... for the MouseEvent.EXITED event.
>
> The full stack trace is this:
>
> at
> bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:88)
> at
> bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1)
> at
> javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218)
> at
> javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
> at
> javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
> at
> javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
> at
> javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
> at
> javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
> at
> javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at
> javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at
> javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at
> javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> at
> javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
> at javafx.base/javafx.event.Event.fireEvent(Event.java:198)
> at
> javafx.base/com.sun.javafx.event.EventQueue.fire(EventQueue.java:48)
> at
> javafx.graphics/javafx.scene.Scene$MouseHandler.handleNodeRemoval(Scene.java:3717)
> at
> javafx.graphics/javafx.scene.Scene$MouseHandler.access$7800(Scene.java:3604)
> at
> javafx.graphics/javafx.scene.Scene.generateMouseExited(Scene.java:3601)
> at
> javafx.graphics/javafx.scene.Parent$3.onProposedChange(Parent.java:613)
> at
> javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:329)
> at
> javafx.base/com.sun.javafx.collections.VetoableListDecorator.remove(VetoableListDecorator.java:221)
> at
> bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:95)
> at
> bareBonesJavaFXBugExample.LabelEventHandler.handle(LabelEventHandler.java:1)
> at
> javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218)
>
> (... rest cut off as it is not needed ... )
>
> --John
>
> On 09/09/2018 19:05, javafx at use.startmail.com wrote:
>> 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.
>> ?*
>> ?* 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.
>>
>> ?* 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.
>> 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}.
>> ?*
>> ?* discussion
>> ?*
>> ?* 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.
>> ?*
>> ?* Proof: 1) debugCounter
starts at value 0
>> (zero).
>> 2) debugCounter
is only incremented once, by 1
>> (one), and that is after the first call to {@link
>> LabelEventHandler#showDebugInformation(String)} has returned.
>> 3)
>> debugCounter
is only decremented once, by 1 (one) and
>> that
>> is before the last call to {@link
>> LabelEventHandler#showDebugInformation(String)}. 4) however,
>> because
>> ?* debugCounter
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)}
>> ?*
>> ?* End proof.
>> ?*
>> ?*
>> ?*
>> ?* 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.
>> ?* Some other possibilities other than the JavaFX Application Thread
>> recursing into {@code handle()} need to be addressed. 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.
>> ?*
>> ?* So somehow the compiler is reordering the increment/decrement of
>> {@code ?debugCounter} and the calls to {@code ?
>> showDebugInformation}.
>>
But this would alter the correctness of the program, so
>> this
>> cannot be the case, or the compiler is making an error.
>> ?*
>> ?*
>> ?* Another is the fact that I/O is not instantaneous and can appear
>> to
>> standard output later than it actually was executed.
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.
But this can't account for the value of {@code
>> ?debugCounter}, so it can't
>> ?* be the reason "debugCounter is 1" appears in output.
In
>> fact
>> we can make this recursive behaviour more obviously consequential to
>> the
>> correctness of the program. If {@code ? handle() } is being
>> recursively re-entered, then we can force a {@link
>> ConcurrentModificationException} on a {@link Collection}. ?
>> 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. 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()}, and {@code
>> ?handle()} is being recursively invoked, then we may see a {@link
>> ConcurrentModificationException}.
>> ?*
>> ?* 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.
>> ?*
>> ?* I also have a screen grab (not included here) of the stack trace
>> at a
>> specific moment 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 handle()
.
>> ?*
>> ?* 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.
>> ?*
>> ?*
>> ?*
>> ?*/
>> public class LabelEventHandler implements EventHandler
>> {
>> ? /**
>> ? ?* 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
>> 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, javafx at 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 !
From brian.r.hudson at gmail.com Mon Sep 10 15:22:23 2018
From: brian.r.hudson at gmail.com (Brian Hudson)
Date: Mon, 10 Sep 2018 11:22:23 -0400
Subject: Animation enhancements
Message-ID:
I would love to see "Animation needs more events" resolved [1].
Maybe following events: started, paused, resumed, cycleStarted, cycleEnded,
stopped/ended? These additional life cycle events would allow me to do some
things with animations/transitions that I've been struggling to do.
There may even be use cases events for starting, pausing, resuming,
cycleStarting, cycleEnding, stopping/ending.
[1]: https://bugs.openjdk.java.net/browse/JDK-8092408
From nlisker at gmail.com Tue Sep 11 08:42:23 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 11 Sep 2018 11:42:23 +0300
Subject: Animation enhancements
In-Reply-To:
References:
Message-ID:
Hi Brian,
Thanks for the input. How is "starting" different from "started" etc.?
On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson
wrote:
> I would love to see "Animation needs more events" resolved [1].
>
> Maybe following events: started, paused, resumed, cycleStarted, cycleEnded,
> stopped/ended? These additional life cycle events would allow me to do some
> things with animations/transitions that I've been struggling to do.
>
> There may even be use cases events for starting, pausing, resuming,
> cycleStarting, cycleEnding, stopping/ending.
>
> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>
From brian.r.hudson at gmail.com Tue Sep 11 13:09:18 2018
From: brian.r.hudson at gmail.com (Brian Hudson)
Date: Tue, 11 Sep 2018 09:09:18 -0400
Subject: Animation enhancements
In-Reply-To:
References:
Message-ID:
starting: Indicates that the animation is about to start. This is the last
opportunity to change an aspect of the animation that cannot be changed
once the animation has started. PathTransition duration for example.
started: The animation has started.
The "-ed" actions are really what I've had a need for, other than
"starting" I can't really think of use cases for the other "-ing" events
On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker wrote:
> Hi Brian,
>
> Thanks for the input. How is "starting" different from "started" etc.?
>
> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson
> wrote:
>
>> I would love to see "Animation needs more events" resolved [1].
>>
>> Maybe following events: started, paused, resumed, cycleStarted,
>> cycleEnded,
>> stopped/ended? These additional life cycle events would allow me to do
>> some
>> things with animations/transitions that I've been struggling to do.
>>
>> There may even be use cases events for starting, pausing, resuming,
>> cycleStarting, cycleEnding, stopping/ending.
>>
>> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>>
>
From nlisker at gmail.com Tue Sep 11 13:50:56 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 11 Sep 2018 16:50:56 +0300
Subject: Animation enhancements
In-Reply-To:
References:
Message-ID:
Hi Rick,
Seems to me like multiple onFinished event handlers [1]. The first comment
there lists a plan for multiple event handlers in general.
[1] https://bugs.openjdk.java.net/browse/JDK-8091406
On Tue, Sep 11, 2018 at 4:07 PM Rick Walker
wrote:
> Dear Nir,
>
> Please forgive me if I am not following protocol - I rarely contribute to
> this mailing list.
>
> I find myself constantly wrapping an animation within a ParallelTransition
> or SerialTransition so that setOnFinished can be called twice - once for
> the core animation and again by higher level code.
> Can you figure out a way to do this in a cleaner, simpler way?
>
> Like this:
>
> public Animation getFadeOut()
> {
> // create a transition to fade out this node
> FadeTransition fade = new FadeTransition(Duration.millis(300), this);
> fade.setFromValue(this.getOpacity());
> fade.setToValue(0);
>
> // when complete, do something
> fade.setOnFinished(e -> { /* do something here */ });
>
> // wrap the fade out transition so that the caller of this method can
> separately call setOnFinished()
> ParallelTransition pt = new ParallelTransition();
> pt.getChildren().setAll(fade);
> return pt;
> }
>
> Best regards,
> Rick Walker
>
>
> On Tue, 11 Sep 2018 at 04:54, Nir Lisker wrote:
>
>> Hi Brian,
>>
>> Thanks for the input. How is "starting" different from "started" etc.?
>>
>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson
>> wrote:
>>
>> > I would love to see "Animation needs more events" resolved [1].
>> >
>> > Maybe following events: started, paused, resumed, cycleStarted,
>> cycleEnded,
>> > stopped/ended? These additional life cycle events would allow me to do
>> some
>> > things with animations/transitions that I've been struggling to do.
>> >
>> > There may even be use cases events for starting, pausing, resuming,
>> > cycleStarting, cycleEnding, stopping/ending.
>> >
>> > [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>> >
>>
>
>
> --
> Richard P. Walker
> thoughtslinger at gmail.com
>
> This email is intended only for the use of the individual(s) to whom it is
> addressed and may be privileged and confidential. Unauthorised use or
> disclosure is prohibited. If you receive this e-mail in error, please
> advise immediately and delete the original message. This message may have
> been altered without your or our knowledge and the sender does not accept
> any liability for any errors or omissions in the message.
>
> Ce courriel est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux
> droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou
> copie de ce message ou des renseignements qu'il contient par une personne
> autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous
> recevez ce courriel par erreur, veuillez m'en aviser imm?diatement, par
> retour de courriel ou par un autre moyen.
>
From nlisker at gmail.com Tue Sep 11 14:11:21 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 11 Sep 2018 17:11:21 +0300
Subject: Animation enhancements
In-Reply-To:
References:
Message-ID:
So the "-ed" events are synchronous? That is, in case of "started", the
animation needs to wait until the event handling finished and then start.
In the case of "starting", the animation would start and call the event
handler asynchronously (like "finished" does now).
Synchronous events can be problematic because they interfere with the
running of the animation. A "cycleStarting" (for example) handler will need
to suspend the animation somehow before each cycle for an unknown duration
(because it can't know what you put in the handler code). This can be done
in practice via something like Future, but I'm skeptical about how much
this would fit with the current animation semantics.
There is a case for "starting" though, which is that it doesn't interfere
with a running animation, and that it can be used as a
"prepare-then-start", as you said. But what happens when the animation is
embedded in a sequential and parallel transitions?
I agree that other "-ed" events are not that useful. We can discuss a
"prepare-then-start" mechanism.
On Tue, Sep 11, 2018 at 4:09 PM Brian Hudson
wrote:
> starting: Indicates that the animation is about to start. This is the last
> opportunity to change an aspect of the animation that cannot be changed
> once the animation has started. PathTransition duration for example.
>
> started: The animation has started.
>
> The "-ed" actions are really what I've had a need for, other than
> "starting" I can't really think of use cases for the other "-ing" events
>
> On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker wrote:
>
>> Hi Brian,
>>
>> Thanks for the input. How is "starting" different from "started" etc.?
>>
>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson
>> wrote:
>>
>>> I would love to see "Animation needs more events" resolved [1].
>>>
>>> Maybe following events: started, paused, resumed, cycleStarted,
>>> cycleEnded,
>>> stopped/ended? These additional life cycle events would allow me to do
>>> some
>>> things with animations/transitions that I've been struggling to do.
>>>
>>> There may even be use cases events for starting, pausing, resuming,
>>> cycleStarting, cycleEnding, stopping/ending.
>>>
>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>>>
>>
From nlisker at gmail.com Tue Sep 11 14:20:21 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 11 Sep 2018 17:20:21 +0300
Subject: Animation enhancements
In-Reply-To:
References:
Message-ID:
Alright, Iv'e queued the multiple event handlers issue after the additional
event types issue.
On Tue, Sep 11, 2018 at 5:15 PM Rick Walker
wrote:
> Thank you, yes that looks like it, I had not seen that comment.
>
> On Tue, 11 Sep 2018 at 09:51, Nir Lisker wrote:
>
>> Hi Rick,
>>
>> Seems to me like multiple onFinished event handlers [1]. The first
>> comment there lists a plan for multiple event handlers in general.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8091406
>>
>> On Tue, Sep 11, 2018 at 4:07 PM Rick Walker
>> wrote:
>>
>>> Dear Nir,
>>>
>>> Please forgive me if I am not following protocol - I rarely contribute
>>> to this mailing list.
>>>
>>> I find myself constantly wrapping an animation within a
>>> ParallelTransition or SerialTransition so that setOnFinished can be called
>>> twice - once for the core animation and again by higher level code.
>>> Can you figure out a way to do this in a cleaner, simpler way?
>>>
>>> Like this:
>>>
>>> public Animation getFadeOut()
>>> {
>>> // create a transition to fade out this node
>>> FadeTransition fade = new FadeTransition(Duration.millis(300), this);
>>> fade.setFromValue(this.getOpacity());
>>> fade.setToValue(0);
>>>
>>> // when complete, do something
>>> fade.setOnFinished(e -> { /* do something here */ });
>>>
>>> // wrap the fade out transition so that the caller of this method
>>> can separately call setOnFinished()
>>> ParallelTransition pt = new ParallelTransition();
>>> pt.getChildren().setAll(fade);
>>> return pt;
>>> }
>>>
>>> Best regards,
>>> Rick Walker
>>>
>>>
>>> On Tue, 11 Sep 2018 at 04:54, Nir Lisker wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> Thanks for the input. How is "starting" different from "started" etc.?
>>>>
>>>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson
>>>> wrote:
>>>>
>>>> > I would love to see "Animation needs more events" resolved [1].
>>>> >
>>>> > Maybe following events: started, paused, resumed, cycleStarted,
>>>> cycleEnded,
>>>> > stopped/ended? These additional life cycle events would allow me to
>>>> do some
>>>> > things with animations/transitions that I've been struggling to do.
>>>> >
>>>> > There may even be use cases events for starting, pausing, resuming,
>>>> > cycleStarting, cycleEnding, stopping/ending.
>>>> >
>>>> > [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>>>> >
>>>>
>>>
>>>
>>> --
>>> Richard P. Walker
>>> thoughtslinger at gmail.com
>>>
>>> This email is intended only for the use of the individual(s) to whom it
>>> is addressed and may be privileged and confidential. Unauthorised use or
>>> disclosure is prohibited. If you receive this e-mail in error, please
>>> advise immediately and delete the original message. This message may have
>>> been altered without your or our knowledge and the sender does not accept
>>> any liability for any errors or omissions in the message.
>>>
>>> Ce courriel est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux
>>> droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou
>>> copie de ce message ou des renseignements qu'il contient par une personne
>>> autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous
>>> recevez ce courriel par erreur, veuillez m'en aviser imm?diatement, par
>>> retour de courriel ou par un autre moyen.
>>>
>>
>
> --
> Richard P. Walker
> thoughtslinger at gmail.com
>
> This email is intended only for the use of the individual(s) to whom it is
> addressed and may be privileged and confidential. Unauthorised use or
> disclosure is prohibited. If you receive this e-mail in error, please
> advise immediately and delete the original message. This message may have
> been altered without your or our knowledge and the sender does not accept
> any liability for any errors or omissions in the message.
>
> Ce courriel est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux
> droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou
> copie de ce message ou des renseignements qu'il contient par une personne
> autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous
> recevez ce courriel par erreur, veuillez m'en aviser imm?diatement, par
> retour de courriel ou par un autre moyen.
>
From brian.r.hudson at gmail.com Tue Sep 11 15:49:49 2018
From: brian.r.hudson at gmail.com (Brian Hudson)
Date: Tue, 11 Sep 2018 11:49:49 -0400
Subject: Animation enhancements
In-Reply-To:
References:
Message-ID:
Async: started, cycleStarted, cycleEnded, ended, paused, resumed
A "starting" event would have to be synchronous to work as I described. The
other "-ing" events probably aren't useful an cause the complications you
describe.
On Tue, Sep 11, 2018 at 10:11 AM Nir Lisker wrote:
> So the "-ed" events are synchronous? That is, in case of "started", the
> animation needs to wait until the event handling finished and then start.
> In the case of "starting", the animation would start and call the event
> handler asynchronously (like "finished" does now).
>
> Synchronous events can be problematic because they interfere with the
> running of the animation. A "cycleStarting" (for example) handler will need
> to suspend the animation somehow before each cycle for an unknown duration
> (because it can't know what you put in the handler code). This can be done
> in practice via something like Future, but I'm skeptical about how much
> this would fit with the current animation semantics.
>
> There is a case for "starting" though, which is that it doesn't interfere
> with a running animation, and that it can be used as a
> "prepare-then-start", as you said. But what happens when the animation is
> embedded in a sequential and parallel transitions?
>
> I agree that other "-ed" events are not that useful. We can discuss a
> "prepare-then-start" mechanism.
>
> On Tue, Sep 11, 2018 at 4:09 PM Brian Hudson
> wrote:
>
>> starting: Indicates that the animation is about to start. This is the
>> last opportunity to change an aspect of the animation that cannot be
>> changed once the animation has started. PathTransition duration for example.
>>
>> started: The animation has started.
>>
>> The "-ed" actions are really what I've had a need for, other than
>> "starting" I can't really think of use cases for the other "-ing" events
>>
>> On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker wrote:
>>
>>> Hi Brian,
>>>
>>> Thanks for the input. How is "starting" different from "started" etc.?
>>>
>>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson
>>> wrote:
>>>
>>>> I would love to see "Animation needs more events" resolved [1].
>>>>
>>>> Maybe following events: started, paused, resumed, cycleStarted,
>>>> cycleEnded,
>>>> stopped/ended? These additional life cycle events would allow me to do
>>>> some
>>>> things with animations/transitions that I've been struggling to do.
>>>>
>>>> There may even be use cases events for starting, pausing, resuming,
>>>> cycleStarting, cycleEnding, stopping/ending.
>>>>
>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>>>>
>>>
From nlisker at gmail.com Tue Sep 11 16:00:12 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 11 Sep 2018 19:00:12 +0300
Subject: Animation enhancements
In-Reply-To:
References:
Message-ID:
So the questions remain about embedded animations. If an animation has a
"starting" and it is embedded, should it pause a sequential animation? This
is the same problem with the the cycle synchronous events. For parallel,
does it delay only itself so that the animations are not parallel anymore?
Or, we could ignore this event when embedded. Do you have any other idea?
On Tue, Sep 11, 2018 at 6:50 PM Brian Hudson
wrote:
> Async: started, cycleStarted, cycleEnded, ended, paused, resumed
>
> A "starting" event would have to be synchronous to work as I described.
> The other "-ing" events probably aren't useful an cause the complications
> you describe.
>
>
>
> On Tue, Sep 11, 2018 at 10:11 AM Nir Lisker wrote:
>
>> So the "-ed" events are synchronous? That is, in case of "started", the
>> animation needs to wait until the event handling finished and then start.
>> In the case of "starting", the animation would start and call the event
>> handler asynchronously (like "finished" does now).
>>
>> Synchronous events can be problematic because they interfere with the
>> running of the animation. A "cycleStarting" (for example) handler will need
>> to suspend the animation somehow before each cycle for an unknown duration
>> (because it can't know what you put in the handler code). This can be done
>> in practice via something like Future, but I'm skeptical about how much
>> this would fit with the current animation semantics.
>>
>> There is a case for "starting" though, which is that it doesn't interfere
>> with a running animation, and that it can be used as a
>> "prepare-then-start", as you said. But what happens when the animation is
>> embedded in a sequential and parallel transitions?
>>
>> I agree that other "-ed" events are not that useful. We can discuss a
>> "prepare-then-start" mechanism.
>>
>> On Tue, Sep 11, 2018 at 4:09 PM Brian Hudson
>> wrote:
>>
>>> starting: Indicates that the animation is about to start. This is the
>>> last opportunity to change an aspect of the animation that cannot be
>>> changed once the animation has started. PathTransition duration for example.
>>>
>>> started: The animation has started.
>>>
>>> The "-ed" actions are really what I've had a need for, other than
>>> "starting" I can't really think of use cases for the other "-ing" events
>>>
>>> On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> Thanks for the input. How is "starting" different from "started" etc.?
>>>>
>>>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson
>>>> wrote:
>>>>
>>>>> I would love to see "Animation needs more events" resolved [1].
>>>>>
>>>>> Maybe following events: started, paused, resumed, cycleStarted,
>>>>> cycleEnded,
>>>>> stopped/ended? These additional life cycle events would allow me to do
>>>>> some
>>>>> things with animations/transitions that I've been struggling to do.
>>>>>
>>>>> There may even be use cases events for starting, pausing, resuming,
>>>>> cycleStarting, cycleEnding, stopping/ending.
>>>>>
>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>>>>>
>>>>
From nlisker at gmail.com Wed Sep 12 08:42:20 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 12 Sep 2018 11:42:20 +0300
Subject: JDK-8210361: Add images to docs for public API classes of controls
Message-ID:
Hi,
Iv'e started working on JDK-8210361 [1] and I'd like my comment there
addressed before continuing.
[1] https://bugs.openjdk.java.net/browse/JDK-8210361
Thanks,
Nir
From venatorxoa at gmail.com Wed Sep 12 08:52:39 2018
From: venatorxoa at gmail.com (Vincent MOLLIERE)
Date: Wed, 12 Sep 2018 10:52:39 +0200
Subject: Parallel Camera in Java 9+
Message-ID:
Hi,
I am new to this list so let me know if I?m wrong somewhere.
In my development, I?m using JavaFX 3d in an extensive manner.
I developed a JavaFX 3D framework, compensating flows and missing features.
One of this flaws in the ParallelCamera, the position and clippings are
calculated weirdly. And there is no zoom.
I have developed a new implementation of camera that calculate correctly
this parameters. This new class only work if I put in a jar, and copy it
the the ext folder in the jdk, if not, its implemented functions are not
called.
The problem is from JDK 9, the ext folder was deleted, and I cannot use
anymore this camera. I tried in JDK10 with JavaFX libraries from Maven and
it does not work too (the implemented functions are not called)
What could be a solution for this problem ?
Thank you for your help.
From kevin.rushforth at oracle.com Wed Sep 12 11:44:59 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 12 Sep 2018 04:44:59 -0700
Subject: JDK-8210361: Add images to docs for public API classes of controls
In-Reply-To:
References:
Message-ID:
They look fine to me. I think placing them next to the code sample, near
the bottom, seems best.
-- Kevin
On 9/12/2018 1:42 AM, Nir Lisker wrote:
> Hi,
>
> Iv'e started working on JDK-8210361 [1] and I'd like my comment there
> addressed before continuing.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8210361
>
> Thanks,
> Nir
From kevin.rushforth at oracle.com Wed Sep 12 12:16:18 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 12 Sep 2018 05:16:18 -0700
Subject: Parallel Camera in Java 9+
In-Reply-To:
References:
Message-ID: <151d4619-7718-f6d8-d803-d1376cc86acf@oracle.com>
Hi Vincent,
As of JDK 9 the Standard Extension mechanism, as implemented by the
"lib/ext" directory in the JDK, has been removed. If you need to locally
modify a class in one of the javafx.* modules you will either need to
build JavaFX from source or patch the module (presumably,
javafx.graphics) using the "--patch-module" option of "java".
-- Kevin
On 9/12/2018 1:52 AM, Vincent MOLLIERE wrote:
> Hi,
>
> I am new to this list so let me know if I?m wrong somewhere.
>
> In my development, I?m using JavaFX 3d in an extensive manner.
>
> I developed a JavaFX 3D framework, compensating flows and missing features.
>
> One of this flaws in the ParallelCamera, the position and clippings are
> calculated weirdly. And there is no zoom.
>
> I have developed a new implementation of camera that calculate correctly
> this parameters. This new class only work if I put in a jar, and copy it
> the the ext folder in the jdk, if not, its implemented functions are not
> called.
>
> The problem is from JDK 9, the ext folder was deleted, and I cannot use
> anymore this camera. I tried in JDK10 with JavaFX libraries from Maven and
> it does not work too (the implemented functions are not called)
>
> What could be a solution for this problem ?
>
> Thank you for your help.
From venatorxoa at gmail.com Wed Sep 12 12:24:40 2018
From: venatorxoa at gmail.com (Vincent MOLLIERE)
Date: Wed, 12 Sep 2018 14:24:40 +0200
Subject: Parallel Camera in Java 9+
In-Reply-To: <151d4619-7718-f6d8-d803-d1376cc86acf@oracle.com>
References:
<151d4619-7718-f6d8-d803-d1376cc86acf@oracle.com>
Message-ID:
I understand that, but for commercial products we try to avoid touching the
jdk. I did it to disable image view smoothing. My point beyond that (we can
stay in jdk 8 there is no rush to update to the latest jdk) is to improve
JavaFx 3D API and implementations. I have some feature request I think are
necessary, and one of them is a working parallel camera. We use it in our
analysis software.
Le mer. 12 sept. 2018 ? 14:16, Kevin Rushforth
a ?crit :
> Hi Vincent,
>
> As of JDK 9 the Standard Extension mechanism, as implemented by the
> "lib/ext" directory in the JDK, has been removed. If you need to locally
> modify a class in one of the javafx.* modules you will either need to
> build JavaFX from source or patch the module (presumably,
> javafx.graphics) using the "--patch-module" option of "java".
>
> -- Kevin
>
>
> On 9/12/2018 1:52 AM, Vincent MOLLIERE wrote:
> > Hi,
> >
> > I am new to this list so let me know if I?m wrong somewhere.
> >
> > In my development, I?m using JavaFX 3d in an extensive manner.
> >
> > I developed a JavaFX 3D framework, compensating flows and missing
> features.
> >
> > One of this flaws in the ParallelCamera, the position and clippings are
> > calculated weirdly. And there is no zoom.
> >
> > I have developed a new implementation of camera that calculate correctly
> > this parameters. This new class only work if I put in a jar, and copy it
> > the the ext folder in the jdk, if not, its implemented functions are not
> > called.
> >
> > The problem is from JDK 9, the ext folder was deleted, and I cannot use
> > anymore this camera. I tried in JDK10 with JavaFX libraries from Maven
> and
> > it does not work too (the implemented functions are not called)
> >
> > What could be a solution for this problem ?
> >
> > Thank you for your help.
>
>
From pedro.duquevieira at gmail.com Wed Sep 12 13:18:35 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Wed, 12 Sep 2018 14:18:35 +0100
Subject: JDK-8210361: Add images to docs for public API classes of controls
Message-ID:
I would remove the window decorations. That's platform dependent, windows,
linux, mac have different aesthetics for this. They also don't add any
value to the representation of the control.
That's what I usually do.
Cheers,
--
Pedro Duque Vieira - https://www.pixelduke.com
From kevin.rushforth at oracle.com Wed Sep 12 14:41:17 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 12 Sep 2018 07:41:17 -0700
Subject: Parallel Camera in Java 9+
In-Reply-To:
References:
<151d4619-7718-f6d8-d803-d1376cc86acf@oracle.com>
Message-ID:
I thought your question was about a replacement for copying a jar file
into $JAVA_HOME/lib/ext (which also touches the JDK).
If you are interested in fixing a bug or otherwise improving JavaFX,
then please see the OpenJDK page [1] about becoming a contributor. There
is a GitHub sandbox [2] that you can fork and use to prototype your fix
and eventually send a pull request when ready. See CONTRIBUTING.md [3]
if you are interesting in contributing using the GitHub sandbox.
There are a couple of known bugs in ParallelCamera when working with 3D
objects, so you might check the bug database [4] to see if it has
already been filed. Otherwise, you can file a new bug [5].
-- Kevin
[1] http://openjdk.java.net/contribute/
[2] https://github.com/javafxports/openjdk-jfx
[3]
https://github.com/javafxports/openjdk-jfx/blob/develop/.github/CONTRIBUTING.md
[4] https://bugs.openjdk.java.net/
[5] https://bugreport.java.com/bugreport/
On 9/12/2018 5:24 AM, Vincent MOLLIERE wrote:
>
> I understand that, but for commercial products we try to avoid
> touching the jdk. I did it to disable image view smoothing. My point
> beyond that (we can stay in jdk 8 there is no rush to update to the
> latest jdk) is to improve JavaFx 3D API and implementations. I have
> some feature request I think are necessary, and one of them is a
> working parallel camera. We use it in our analysis software.
>
>
> Le?mer. 12 sept. 2018 ??14:16, Kevin Rushforth
> > a ?crit?:
>
> Hi Vincent,
>
> As of JDK 9 the Standard Extension mechanism, as implemented by the
> "lib/ext" directory in the JDK, has been removed. If you need to
> locally
> modify a class in one of the javafx.* modules you will either need to
> build JavaFX from source or patch the module (presumably,
> javafx.graphics) using the "--patch-module" option of "java".
>
> -- Kevin
>
>
> On 9/12/2018 1:52 AM, Vincent MOLLIERE wrote:
> > Hi,
> >
> > I am new to this list so let me know if I?m wrong somewhere.
> >
> > In my development, I?m using JavaFX 3d in an extensive manner.
> >
> > I developed a JavaFX 3D framework, compensating flows and
> missing features.
> >
> > One of this flaws in the ParallelCamera, the position and
> clippings are
> > calculated weirdly. And there is no zoom.
> >
> > I have developed a new implementation of camera that calculate
> correctly
> > this parameters. This new class only work if I put in a jar, and
> copy it
> > the the ext folder in the jdk, if not, its implemented functions
> are not
> > called.
> >
> > The problem is from JDK 9, the ext folder was deleted, and I
> cannot use
> > anymore this camera. I tried in JDK10 with JavaFX libraries from
> Maven and
> > it does not work too (the implemented functions are not called)
> >
> > What could be a solution for this problem ?
> >
> > Thank you for your help.
>
From nlisker at gmail.com Wed Sep 12 14:50:59 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 12 Sep 2018 17:50:59 +0300
Subject: JDK-8210361: Add images to docs for public API classes of controls
In-Reply-To:
References:
Message-ID:
That's sensible, though for Alert and the like I think they should stay as
it's effectively part of the control.
On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira <
pedro.duquevieira at gmail.com> wrote:
> I would remove the window decorations. That's platform dependent, windows,
> linux, mac have different aesthetics for this. They also don't add any
> value to the representation of the control.
>
> That's what I usually do.
>
> Cheers,
>
>
>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>
From pedro.duquevieira at gmail.com Wed Sep 12 14:57:10 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Wed, 12 Sep 2018 15:57:10 +0100
Subject: JDK-8210361: Add images to docs for public API classes of controls
In-Reply-To:
References:
Message-ID:
Yes I agree with you. Controls on which their window decorations are a part
of them, should show up with them. If those decorations change depending on
the platform their running, I would put a note saying that.
The vast majority of controls don't belong to that category.
Cheers,
On Wed, Sep 12, 2018 at 3:51 PM Nir Lisker wrote:
> That's sensible, though for Alert and the like I think they should stay as
> it's effectively part of the control.
>
> On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira <
> pedro.duquevieira at gmail.com> wrote:
>
>> I would remove the window decorations. That's platform dependent, windows,
>> linux, mac have different aesthetics for this. They also don't add any
>> value to the representation of the control.
>>
>> That's what I usually do.
>>
>> Cheers,
>>
>>
>>
>>
>> --
>> Pedro Duque Vieira - https://www.pixelduke.com
>>
>
--
Pedro Duque Vieira - https://www.pixelduke.com
From kevin.rushforth at oracle.com Wed Sep 12 15:07:12 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 12 Sep 2018 08:07:12 -0700
Subject: JDK-8210361: Add images to docs for public API classes of controls
In-Reply-To:
References:
Message-ID: <1b7e836d-7fd1-03ba-c746-5ff9ba3eb3ac@oracle.com>
Agreed. For simple controls like checkbox, button, etc., it makes sense
to use an undecorated Stage. It's less busy and puts the emphasis on the
control being illustrated.
-- Kevin
On 9/12/2018 7:57 AM, Pedro Duque Vieira wrote:
> Yes I agree with you. Controls on which their window decorations are a part
> of them, should show up with them. If those decorations change depending on
> the platform their running, I would put a note saying that.
>
> The vast majority of controls don't belong to that category.
>
> Cheers,
>
> On Wed, Sep 12, 2018 at 3:51 PM Nir Lisker wrote:
>
>> That's sensible, though for Alert and the like I think they should stay as
>> it's effectively part of the control.
>>
>> On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira <
>> pedro.duquevieira at gmail.com> wrote:
>>
>>> I would remove the window decorations. That's platform dependent, windows,
>>> linux, mac have different aesthetics for this. They also don't add any
>>> value to the representation of the control.
>>>
>>> That's what I usually do.
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>> --
>>> Pedro Duque Vieira - https://www.pixelduke.com
>>>
From powers.anirvan at gmail.com Wed Sep 12 19:33:30 2018
From: powers.anirvan at gmail.com (Anirvan Sarkar)
Date: Thu, 13 Sep 2018 04:33:30 +0900
Subject: JDK-8210361: Add images to docs for public API classes of controls
In-Reply-To: <1b7e836d-7fd1-03ba-c746-5ff9ba3eb3ac@oracle.com>
References:
<1b7e836d-7fd1-03ba-c746-5ff9ba3eb3ac@oracle.com>
Message-ID:
Hi Nir,
Thanks for this RFE.
Now other UI toolkits like GTK and QT have a separate gallery of
controls[1][2].
I was considering to add something similar in JavaFX but I never got around
to start working on it, mostly due to all the screenshots which is needed
to be taken beforehand !
Since you will now take images of all the controls, you can consider to add
a gallery in this RFE itself.
But if you don't want then someone else (me) can volunteer to do this once
this RFE is merged.
Let me know what you decide :-)
[1] : https://developer.gnome.org/gtk4/stable/ch03.html
[2] : http://doc.qt.io/archives/qt-4.8/gallery.html
On Thu 13 Sep, 2018, 12:07 AM Kevin Rushforth,
wrote:
> Agreed. For simple controls like checkbox, button, etc., it makes sense
> to use an undecorated Stage. It's less busy and puts the emphasis on the
> control being illustrated.
>
> -- Kevin
>
>
> On 9/12/2018 7:57 AM, Pedro Duque Vieira wrote:
> > Yes I agree with you. Controls on which their window decorations are a
> part
> > of them, should show up with them. If those decorations change depending
> on
> > the platform their running, I would put a note saying that.
> >
> > The vast majority of controls don't belong to that category.
> >
> > Cheers,
> >
> > On Wed, Sep 12, 2018 at 3:51 PM Nir Lisker wrote:
> >
> >> That's sensible, though for Alert and the like I think they should stay
> as
> >> it's effectively part of the control.
> >>
> >> On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira <
> >> pedro.duquevieira at gmail.com> wrote:
> >>
> >>> I would remove the window decorations. That's platform dependent,
> windows,
> >>> linux, mac have different aesthetics for this. They also don't add any
> >>> value to the representation of the control.
> >>>
> >>> That's what I usually do.
> >>>
> >>> Cheers,
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Pedro Duque Vieira - https://www.pixelduke.com
> >>>
>
>
From nlisker at gmail.com Wed Sep 12 20:23:58 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 12 Sep 2018 23:23:58 +0300
Subject: JDK-8210361: Add images to docs for public API classes of controls
In-Reply-To:
References:
<1b7e836d-7fd1-03ba-c746-5ff9ba3eb3ac@oracle.com>
Message-ID:
Hi Anirvan,
A gallery will fit best in the tutorials. The page for UI controls [1] will
be ideal in my opinion (put the gallery as the first link).
About the screenshots: that page contains much more suitable screenshots in
each control's page when it comes to a gallery. They are stylistic,
show-off-ish, and present a wider range of possibilities and states for
each control. The examples in the JavaDocs are minimalistic, with the point
of showing how easy it is to create the control. They don't make for much
of a gallery, but they do show the developer very quickly what that control
they are looking at is for a WYSIWYG code example.
I suggest you submit an RFE which relates to the general "update the
tutorials" issue [2] (instead of the one I'm working on) and take the
screenshots from those pages.
[1]
https://docs.oracle.com/javase/8/javafx/user-interface-tutorial/ui_controls.htm#JFXUI336
[2] https://bugs.openjdk.java.net/browse/JDK-8210360
- Nir
On Wed, Sep 12, 2018 at 10:33 PM Anirvan Sarkar
wrote:
> Hi Nir,
>
> Thanks for this RFE.
>
> Now other UI toolkits like GTK and QT have a separate gallery of
> controls[1][2].
>
> I was considering to add something similar in JavaFX but I never got
> around to start working on it, mostly due to all the screenshots which is
> needed to be taken beforehand !
>
> Since you will now take images of all the controls, you can consider to
> add a gallery in this RFE itself.
>
> But if you don't want then someone else (me) can volunteer to do this once
> this RFE is merged.
>
> Let me know what you decide :-)
>
> [1] : https://developer.gnome.org/gtk4/stable/ch03.html
> [2] : http://doc.qt.io/archives/qt-4.8/gallery.html
>
>
> On Thu 13 Sep, 2018, 12:07 AM Kevin Rushforth,
> wrote:
>
>> Agreed. For simple controls like checkbox, button, etc., it makes sense
>> to use an undecorated Stage. It's less busy and puts the emphasis on the
>> control being illustrated.
>>
>> -- Kevin
>>
>>
>> On 9/12/2018 7:57 AM, Pedro Duque Vieira wrote:
>> > Yes I agree with you. Controls on which their window decorations are a
>> part
>> > of them, should show up with them. If those decorations change
>> depending on
>> > the platform their running, I would put a note saying that.
>> >
>> > The vast majority of controls don't belong to that category.
>> >
>> > Cheers,
>> >
>> > On Wed, Sep 12, 2018 at 3:51 PM Nir Lisker wrote:
>> >
>> >> That's sensible, though for Alert and the like I think they should
>> stay as
>> >> it's effectively part of the control.
>> >>
>> >> On Wed, Sep 12, 2018 at 4:19 PM Pedro Duque Vieira <
>> >> pedro.duquevieira at gmail.com> wrote:
>> >>
>> >>> I would remove the window decorations. That's platform dependent,
>> windows,
>> >>> linux, mac have different aesthetics for this. They also don't add any
>> >>> value to the representation of the control.
>> >>>
>> >>> That's what I usually do.
>> >>>
>> >>> Cheers,
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Pedro Duque Vieira - https://www.pixelduke.com
>> >>>
>>
>>
From kevin.rushforth at oracle.com Thu Sep 13 12:42:04 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 13 Sep 2018 05:42:04 -0700
Subject: [11] RFR: JDK-8210691: Deliver release notes for JavaFX 11
Message-ID: <54c53052-9178-68bb-c67a-71a7e6dc2e7c@oracle.com>
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8210691
https://github.com/javafxports/openjdk-jfx/pull/201
Here is the file is a human readable form:
https://github.com/kevinrushforth/openjdk-jfx/blob/release-notes/doc-files/release-notes-11.md
The review is happening on GitHub.
-- Kevin
From johan at lodgon.com Thu Sep 13 12:57:09 2018
From: johan at lodgon.com (Johan Vos)
Date: Thu, 13 Sep 2018 14:57:09 +0200
Subject: [11] RFR: JDK-8210691: Deliver release notes for JavaFX 11
In-Reply-To: <54c53052-9178-68bb-c67a-71a7e6dc2e7c@oracle.com>
References: <54c53052-9178-68bb-c67a-71a7e6dc2e7c@oracle.com>
Message-ID:
+1 (reviewed on GitHub)
Op do 13 sep. 2018 om 14:55 schreef Kevin Rushforth <
kevin.rushforth at oracle.com>:
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8210691
> https://github.com/javafxports/openjdk-jfx/pull/201
>
> Here is the file is a human readable form:
>
> https://github.com/kevinrushforth/openjdk-jfx/blob/release-notes/doc-files/release-notes-11.md
>
> The review is happening on GitHub.
>
> -- Kevin
>
>
From amnojeeuw at gmail.com Thu Sep 13 18:47:32 2018
From: amnojeeuw at gmail.com (Amno Jeeuw)
Date: Thu, 13 Sep 2018 14:47:32 -0400
Subject: Tutorial
Message-ID:
I'm looking for a installation tutorial for OpenJavaFX. Is there one that's
up-to-date? Thanks in advance.
From nlisker at gmail.com Fri Sep 14 12:22:38 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 14 Sep 2018 15:22:38 +0300
Subject: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL,
not a stringified URL
In-Reply-To:
References:
Message-ID:
Hi Michael,
The issue in the JBS is JDK-8209921 [1].
getStylesheets() returns an ObservableList, it cannot be changed to
ObservableList. What solution do you propose?
[1] https://bugs.openjdk.java.net/browse/JDK-8209921
- Nir
On Wed, Aug 22, 2018 at 9:47 PM Michael Binz wrote:
> Hi all,
>
> I opened a proposal for an extension of the javafx.scene.Scene API to allow
> to add a stylesheet using a typed java.net.URL.
>
> Currently the Scene class offers a list of stylesheet URLs in their
> stringified representation accessible by Scene.getStylesheets().
>
> The problem is that in some cases an URL instance encapsulates internal
> state that gets lost in the conversion into its external form and back into
> an URL instance, namely information on an URL handler. This ultimately
> results in a failure (IOException file not found) when the Screen class
> tries to load a stylesheet though code that loads the file contents using
> URL#openStream() on the original URL instance can read the file contents
> successfully.
>
> In my case the problem showed up when creating an executable jar file
> containing my JavaFX application (using OneJar). The application startup
> in this case installs a customized Classloader that implements special
> logic for accessing the jars contained classes, This works transparently
> for classes and resources, but the URLs returned by Class#getResource( name
> ) do not survive the conversion to string and back because of the described
> reason.
>
> There is a workaround that caches the resource in a temporary file and
> passes this file's URL to the Scene's list of stylesheets, but this poses
> other problems.
> As a remark, other APIs in JavaFX use the same pattern of expecting
> stringified URLs like the Image() constructor and have the same problem,
> but offer alternative constructors accepting a stream which allows to solve
> the problem nicely.
>
> Please discuss and decide if the proposal can be added as a change request
> for JavaFX.
>
> Best wishes,
> Michael.
>
From kevin.rushforth at oracle.com Fri Sep 14 12:51:25 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 14 Sep 2018 05:51:25 -0700
Subject: Tutorial
In-Reply-To:
References:
Message-ID: <8c314b9f-9369-d09a-2400-6d416f7d3fe4@oracle.com>
A basic set of instructions is here:
http://docs.gluonhq.com/javafx11/
Read the Introduction and then click on the other links for information
on downloading the SDK or using JavaFX via maven modules.
-- Kevin
On 9/13/2018 11:47 AM, Amno Jeeuw wrote:
> I'm looking for a installation tutorial for OpenJavaFX. Is there one that's
> up-to-date? Thanks in advance.
From kevin.rushforth at oracle.com Fri Sep 14 13:15:57 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 14 Sep 2018 06:15:57 -0700
Subject: Tutorial
In-Reply-To: <8c314b9f-9369-d09a-2400-6d416f7d3fe4@oracle.com>
References:
<8c314b9f-9369-d09a-2400-6d416f7d3fe4@oracle.com>
Message-ID: <57d126b4-c4a6-8cf7-69a8-8e2246005b5e@oracle.com>
I should note that this is an early-access build. The final release is
planned for next week [1] at which time we will send out an announcement
with more information.
-- Kevin
[1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/022004.html
On 9/14/2018 5:51 AM, Kevin Rushforth wrote:
> A basic set of instructions is here:
>
> http://docs.gluonhq.com/javafx11/
>
> Read the Introduction and then click on the other links for
> information on downloading the SDK or using JavaFX via maven modules.
>
> -- Kevin
>
>
> On 9/13/2018 11:47 AM, Amno Jeeuw wrote:
>> I'm looking for a installation tutorial for OpenJavaFX. Is there one
>> that's
>> up-to-date? Thanks in advance.
>
From kevin.rushforth at oracle.com Sat Sep 15 15:59:58 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 15 Sep 2018 08:59:58 -0700
Subject: [11] RFR: JDK-8210791: Update release notes for JavaFX 11
Message-ID:
Please review the following updates for the JavaFX 11 release notes:
https://bugs.openjdk.java.net/browse/JDK-8210791
https://github.com/javafxports/openjdk-jfx/pull/202
-- Kevin
From tom.schindl at bestsolution.at Sat Sep 15 18:39:36 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sat, 15 Sep 2018 20:39:36 +0200
Subject: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL,
not a stringified URL
In-Reply-To:
References:
Message-ID: <17a71624-61eb-60d7-46ab-f37e6977d6e8@bestsolution.at>
Hi,
I don't understand why something should be lost but anyways I don't
think JavaFX API is not the right place to fix a short coming of OneJar.
As Nir pointed out it is next to impossible to retrofit the JavaFX API
to URL with breaking it.
Tom
On 22.08.18 20:47, Michael Binz wrote:
> Hi all,
>
> I opened a proposal for an extension of the javafx.scene.Scene API to allow
> to add a stylesheet using a typed java.net.URL.
>
> Currently the Scene class offers a list of stylesheet URLs in their
> stringified representation accessible by Scene.getStylesheets().
>
> The problem is that in some cases an URL instance encapsulates internal
> state that gets lost in the conversion into its external form and back into
> an URL instance, namely information on an URL handler. This ultimately
> results in a failure (IOException file not found) when the Screen class
> tries to load a stylesheet though code that loads the file contents using
> URL#openStream() on the original URL instance can read the file contents
> successfully.
>
> In my case the problem showed up when creating an executable jar file
> containing my JavaFX application (using OneJar). The application startup
> in this case installs a customized Classloader that implements special
> logic for accessing the jars contained classes, This works transparently
> for classes and resources, but the URLs returned by Class#getResource( name
> ) do not survive the conversion to string and back because of the described
> reason.
>
> There is a workaround that caches the resource in a temporary file and
> passes this file's URL to the Scene's list of stylesheets, but this poses
> other problems.
> As a remark, other APIs in JavaFX use the same pattern of expecting
> stringified URLs like the Image() constructor and have the same problem,
> but offer alternative constructors accepting a stream which allows to solve
> the problem nicely.
>
> Please discuss and decide if the proposal can be added as a change request
> for JavaFX.
>
> Best wishes,
> Michael.
>
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
From nlisker at gmail.com Sun Sep 16 13:01:33 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 16 Sep 2018 16:01:33 +0300
Subject: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL,
not a stringified URL
In-Reply-To:
References:
Message-ID:
I think this needs to be discussed with a project lead - Kevin or Johan.
On Sun, Sep 16, 2018 at 6:07 AM Michael Binz wrote:
> Hi Nir,
>
> I understand that switching the API to use net.URL is not trivial.
>
> The only idea that comes to mind is to offer two list properties, the one
> existing as today, holding stringified URLs for backwards compatibility,
> and a second one that holds typed .net.URLs. The existing version can be
> deprecated in favour of the typed version.
>
> Before starting such an effort it would be interesting if it is common
> understanding that an URL instance is preferrable over a string URL.
> Was there a special reason that JavaFX uses in its interfaces in many
> places stringified URLs instead of the existing java.net.URL?
>
> Best wishes,
> Michael.
>
>
> Am Fr., 14. Sep. 2018 um 14:23 Uhr schrieb Nir Lisker :
>
>> Hi Michael,
>>
>> The issue in the JBS is JDK-8209921 [1].
>>
>> getStylesheets() returns an ObservableList, it cannot be changed
>> to ObservableList. What solution do you propose?
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8209921
>>
>> - Nir
>>
>> On Wed, Aug 22, 2018 at 9:47 PM Michael Binz wrote:
>>
>>> Hi all,
>>>
>>> I opened a proposal for an extension of the javafx.scene.Scene API to
>>> allow
>>> to add a stylesheet using a typed java.net.URL.
>>>
>>> Currently the Scene class offers a list of stylesheet URLs in their
>>> stringified representation accessible by Scene.getStylesheets().
>>>
>>> The problem is that in some cases an URL instance encapsulates internal
>>> state that gets lost in the conversion into its external form and back
>>> into
>>> an URL instance, namely information on an URL handler. This ultimately
>>> results in a failure (IOException file not found) when the Screen class
>>> tries to load a stylesheet though code that loads the file contents using
>>> URL#openStream() on the original URL instance can read the file contents
>>> successfully.
>>>
>>> In my case the problem showed up when creating an executable jar file
>>> containing my JavaFX application (using OneJar). The application startup
>>> in this case installs a customized Classloader that implements special
>>> logic for accessing the jars contained classes, This works transparently
>>> for classes and resources, but the URLs returned by Class#getResource(
>>> name
>>> ) do not survive the conversion to string and back because of the
>>> described
>>> reason.
>>>
>>> There is a workaround that caches the resource in a temporary file and
>>> passes this file's URL to the Scene's list of stylesheets, but this poses
>>> other problems.
>>> As a remark, other APIs in JavaFX use the same pattern of expecting
>>> stringified URLs like the Image() constructor and have the same problem,
>>> but offer alternative constructors accepting a stream which allows to
>>> solve
>>> the problem nicely.
>>>
>>> Please discuss and decide if the proposal can be added as a change
>>> request
>>> for JavaFX.
>>>
>>> Best wishes,
>>> Michael.
>>>
>>
From tom.schindl at bestsolution.at Mon Sep 17 05:27:42 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Mon, 17 Sep 2018 07:27:42 +0200
Subject: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL,
not a stringified URL
In-Reply-To:
References:
<17a71624-61eb-60d7-46ab-f37e6977d6e8@bestsolution.at>
Message-ID: <9500dfac-3bd3-887a-a84c-e06cc193b908@bestsolution.at>
[you replied offlist but I guess that was an oversight so I bring it back]
Reading through the document I don't see what concept is not working,
but indeed the URL-constructor says that the protocol handler is
resolved when constructing the URL. Does OneJar rely on that fact?
The Stackoverflow problem who talks about Felix is strange as Felix
returns in the toExternalForm() approach a custom protocol (bundle:) and
Felix like eg Equinox installs an URLHandler for that protocol.
URL-Handlers work prefectly fine - I know that because I maintain
e(fx)clipse who is based on Equinox and we there make extensive usage of
that and never had any trouble.
I also found: http://one-jar.sourceforge.net/index.php?page=frameworks
who talks about a custom protocol supported by OneJar but as I've never
used OneJar (we use maven-shade for stuff like this) I don't know if
this applies to this problem.
Tom
On 16.09.18 05:24, Michael Binz wrote:
> Hi,
>
> actually this is not a problem with a particular tool we use.? The
> problem is that some of the concepts described in [1] that are used for
> resource loading do not longer work. This impacts all tools that base
> their functionality on this,? See [2] for other situations where
> classloader-based resource-loading fails.
>
> Michael.
>
> [1]
> https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html
> [2]
> https://stackoverflow.com/questions/20000897/javafx-stylesheets-inside-osgi-bundle
>
>
> Am Sa., 15. Sep. 2018 um 20:40?Uhr schrieb Tom Schindl
> >:
>
> Hi,
>
> I don't understand why something should be lost but anyways I don't
> think JavaFX API is not the right place to fix a short coming of OneJar.
> As Nir pointed out it is next to impossible to retrofit the JavaFX API
> to URL with breaking it.
>
> Tom
>
> On 22.08.18 20:47, Michael Binz wrote:
> > Hi all,
> >
> > I opened a proposal for an extension of the javafx.scene.Scene API
> to allow
> > to add a stylesheet using a typed java.net.URL.
> >
> > Currently the Scene class offers a list of stylesheet URLs in their
> > stringified representation accessible by Scene.getStylesheets().
> >
> > The problem is that in some cases an URL instance encapsulates
> internal
> > state that gets lost in the conversion into its external form and
> back into
> > an URL instance, namely information on an URL handler. This ultimately
> > results in a failure (IOException file not found) when the Screen
> class
> > tries to load a stylesheet though code that loads the file
> contents using
> > URL#openStream() on the original URL instance can read the file
> contents
> > successfully.
> >
> > In my case the problem showed up when creating an executable jar file
> > containing my JavaFX application (using OneJar).? The application
> startup
> > in this case installs a customized Classloader that implements special
> > logic for accessing the jars contained classes,? This works
> transparently
> > for classes and resources, but the URLs returned by
> Class#getResource( name
> > ) do not survive the conversion to string and back because of the
> described
> > reason.
> >
> > There is a workaround that caches the resource in a temporary file and
> > passes this file's URL to the Scene's list of stylesheets, but
> this poses
> > other problems.
> > As a remark, other APIs in JavaFX use the same pattern of expecting
> > stringified URLs like the Image() constructor and have the same
> problem,
> > but offer alternative constructors accepting a stream which allows
> to solve
> > the problem nicely.
> >
> > Please discuss and decide if the proposal can be added as a change
> request
> > for JavaFX.
> >
> > Best wishes,
> > Michael.
> >
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
From kevin.rushforth at oracle.com Tue Sep 18 13:02:24 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 18 Sep 2018 06:02:24 -0700
Subject: JavaFX 11 is released
Message-ID:
I am pleased to announce the final release of JavaFX 11 as well as the
launch of a new OpenJFX community site at:
http://openjfx.io/
The GA version of JavaFX 11 is now live and can be downloaded by going
to the openjfx.io site or by accessing javafx modules from maven central
at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
graphics, controls, and so forth).
This is the first standalone release of JavaFX 11. It runs with JDK 11,
which is available as a release candidate now and will be shipped as a
GA version next week, or on JDK 10 (OpenJDK build only).
A big thank you to all who have contributed to OpenJFX make this release
possible! I especially thank Johan Vos, both for taking on the role as
Co-Lead of the OpenJFX Project and for the work that Gluon as done to
build and host the JavaFX 11 release.
I look forward to working with you all on JavaFX 12 and beyond.
-- Kevin
From johan.vos at gluonhq.com Tue Sep 18 13:08:48 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 18 Sep 2018 15:08:48 +0200
Subject: JavaFX 11 is released
In-Reply-To:
References:
Message-ID:
Adding to what Kevin already said (huge thanks to Kevin and Oracle for all
they did), I want to thank everyone on this list for being part of this
release. The JavaFX 11 release is a huge milestone, and there are many
people who contributed, some of them who have been working with JavaFX from
day 1, some who just started working.
As for the site http://openjfx.io: this is something we created with Gluon,
but we really want it to be a community-organised site. Therefore, it is
all available via github, and open for PR's:
https://github.com/openjfx/hugo-site.
Thanks again,
- Johan
On Tue, Sep 18, 2018 at 3:02 PM Kevin Rushforth
wrote:
> I am pleased to announce the final release of JavaFX 11 as well as the
> launch of a new OpenJFX community site at:
>
> http://openjfx.io/
>
> The GA version of JavaFX 11 is now live and can be downloaded by going
> to the openjfx.io site or by accessing javafx modules from maven central
> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
> graphics, controls, and so forth).
>
> This is the first standalone release of JavaFX 11. It runs with JDK 11,
> which is available as a release candidate now and will be shipped as a
> GA version next week, or on JDK 10 (OpenJDK build only).
>
> A big thank you to all who have contributed to OpenJFX make this release
> possible! I especially thank Johan Vos, both for taking on the role as
> Co-Lead of the OpenJFX Project and for the work that Gluon as done to
> build and host the JavaFX 11 release.
>
> I look forward to working with you all on JavaFX 12 and beyond.
>
> -- Kevin
>
>
From dlemmermann at gmail.com Tue Sep 18 13:30:16 2018
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Tue, 18 Sep 2018 15:30:16 +0200
Subject: JavaFX 11 is released
In-Reply-To:
References:
Message-ID: <9639538F-569B-4ABF-9A6D-4E40B936F699@gmail.com>
Johan, Kevin,
a big "thank you!" from someone who has based his company and career on JavaFX. This release will put an end to all of the ?JavaFX is dead? speculations / rumors out there and it will hopefully also mark the beginning of ongoing and accelerated development of this fantastic piece of technology.
Dirk
http://www.dlsc.com
http://javafx-days.com
> Am 18.09.2018 um 15:08 schrieb Johan Vos :
>
> Adding to what Kevin already said (huge thanks to Kevin and Oracle for all
> they did), I want to thank everyone on this list for being part of this
> release. The JavaFX 11 release is a huge milestone, and there are many
> people who contributed, some of them who have been working with JavaFX from
> day 1, some who just started working.
>
> As for the site http://openjfx.io: this is something we created with Gluon,
> but we really want it to be a community-organised site. Therefore, it is
> all available via github, and open for PR's:
> https://github.com/openjfx/hugo-site.
>
> Thanks again,
>
> - Johan
>
> On Tue, Sep 18, 2018 at 3:02 PM Kevin Rushforth
> wrote:
>
>> I am pleased to announce the final release of JavaFX 11 as well as the
>> launch of a new OpenJFX community site at:
>>
>> http://openjfx.io/
>>
>> The GA version of JavaFX 11 is now live and can be downloaded by going
>> to the openjfx.io site or by accessing javafx modules from maven central
>> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
>> graphics, controls, and so forth).
>>
>> This is the first standalone release of JavaFX 11. It runs with JDK 11,
>> which is available as a release candidate now and will be shipped as a
>> GA version next week, or on JDK 10 (OpenJDK build only).
>>
>> A big thank you to all who have contributed to OpenJFX make this release
>> possible! I especially thank Johan Vos, both for taking on the role as
>> Co-Lead of the OpenJFX Project and for the work that Gluon as done to
>> build and host the JavaFX 11 release.
>>
>> I look forward to working with you all on JavaFX 12 and beyond.
>>
>> -- Kevin
>>
>>
From r.lichtenberger at gmail.com Tue Sep 18 13:51:58 2018
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 18 Sep 2018 15:51:58 +0200
Subject: Compiling OpenJFX
Message-ID:
I am trying (again) to get my toes wet with building OpenJFX myself.
Here are some things I am wondering about:
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle
says:
Gradle is the primary build tool for building OpenJFX. We currently use
Gradle 4.8 for jfx-dev
but a few lines down it says:
add gradle-4.3/bin to your PATH
I assume it should say gradle-4.8/bin here too.
Other than that, I was able to build OpenJFX on Windows 64-bit without
web and media. So after that I tried to build with web and media, where
I got this error:
> Task :web:compileNativeWin FAILED
Can't locate English.pm in @INC (you may need to install the English
module) (@INC contains:
/cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts
/usr/local/lib/perl5/site_perl/5.26/x86_64-cygwin-threads
/usr/local/share/perl5/site_perl/5.26
/usr/lib/perl5/vendor_perl/5.26/x86_64-cygwin-threads
/usr/share/perl5/vendor_perl/5.26
/usr/lib/perl5/5.26/x86_64-cygwin-threads /usr/share/perl5/5.26) at
/cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm
line 37.
BEGIN failed--compilation aborted at
/cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm
line 37.
Compilation failed in require at
/cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm
line 48.
BEGIN failed--compilation aborted at
/cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm
line 48.
Compilation failed in require at
C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration
line 33.
BEGIN failed--compilation aborted at
C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration
line 33.
FAILURE: Build failed with an exception.
I then upgraded perl from the cygwin setup to revision 5 version 26
subversion 2, then the build was able to continue. Maybe the build
instructions could mention the exact minimum perl version required?
The build then took about an hour but otherwise completed successfully,
which is a pretty smooth experience considering the complexity of JavaFX
and WebKit ;-).
What about Windows 32-bit though? There will be no Oracle JDK from
JDK-11 onwards, however https://adoptopenjdk.net/ have said they are
willing to produce a JDK for Windows-32 bit. But will OpenJFX be
buildable for that platform? If yes, how?
Robert Lichtenberger
From mike at plan99.net Tue Sep 18 14:07:17 2018
From: mike at plan99.net (Mike Hearn)
Date: Tue, 18 Sep 2018 07:07:17 -0700
Subject: JavaFX 11 is released
In-Reply-To:
References:
Message-ID:
Excellent work, congratulations to everyone involved and the new site is
wonderful.
From namannigam12 at gmail.com Tue Sep 18 14:36:25 2018
From: namannigam12 at gmail.com (Naman Nigam)
Date: Tue, 18 Sep 2018 20:06:25 +0530
Subject: Improve the pom.xml referenced in Maven example
Message-ID:
Hi! I am not sure if there is a format to reporting such minor possible
improvements. Pardon me if this is not the correct mailing list to share
such minor enhancements and please help redirect this to the correct person
in that case. (Since I couldn't find the source on GitHub as well)
The Run HelloWorld using Maven makes
reference to a pom.xml which can
be further improved with the use of
org.apache.maven.plugins
maven-compiler-plugin
3.8.0
11 or
as mentioned in another StackOverflow answer
as
well.
PS: I made that answer some time back and coincidently saw the usage of the
formerly suggested answer in the production links via this mailing list as
well. Thought
Regards
Naman Nigam
+91-9761212401 | LinkedIn
From abhinay_agarwal at live.com Tue Sep 18 14:44:11 2018
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Tue, 18 Sep 2018 14:44:11 +0000
Subject: Improve the pom.xml referenced in Maven example
In-Reply-To:
References:
Message-ID:
Hi Nigam,
Please raise a PR in https://github.com/openjfx/openjfx-docs
Regards,
Abhinay
________________________________
From: openjfx-dev on behalf of Naman Nigam
Sent: Tuesday, September 18, 2018 8:06 PM
To: openjfx-dev at openjdk.java.net
Subject: Improve the pom.xml referenced in Maven example
Hi! I am not sure if there is a format to reporting such minor possible
improvements. Pardon me if this is not the correct mailing list to share
such minor enhancements and please help redirect this to the correct person
in that case. (Since I couldn't find the source on GitHub as well)
The Run HelloWorld using Maven makes
reference to a pom.xml which can
be further improved with the use of
org.apache.maven.plugins
maven-compiler-plugin
3.8.0
11 or
as mentioned in another StackOverflow answer
as
well.
PS: I made that answer some time back and coincidently saw the usage of the
formerly suggested answer in the production links via this mailing list as
well. Thought
Regards
Naman Nigam
+91-9761212401 | LinkedIn
From kevin.rushforth at oracle.com Tue Sep 18 14:51:27 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 18 Sep 2018 07:51:27 -0700
Subject: Compiling OpenJFX
In-Reply-To:
References:
Message-ID: <3c202106-cab5-3866-3d60-cba663c6d414@oracle.com>
Good catch. I fixed it to reference to gradle-4.8/ bin.
-- Kevin
On 9/18/2018 6:51 AM, Robert Lichtenberger wrote:
> I am trying (again) to get my toes wet with building OpenJFX myself.
>
> Here are some things I am wondering about:
>
>
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle
> says:
>
> Gradle is the primary build tool for building OpenJFX. We currently use
> Gradle 4.8 for jfx-dev
>
> but a few lines down it says:
>
> add gradle-4.3/bin to your PATH
>
> I assume it should say gradle-4.8/bin here too.
>
>
> Other than that, I was able to build OpenJFX on Windows 64-bit without
> web and media. So after that I tried to build with web and media, where
> I got this error:
>
>> Task :web:compileNativeWin FAILED
> Can't locate English.pm in @INC (you may need to install the English
> module) (@INC contains:
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts
> /usr/local/lib/perl5/site_perl/5.26/x86_64-cygwin-threads
> /usr/local/share/perl5/site_perl/5.26
> /usr/lib/perl5/vendor_perl/5.26/x86_64-cygwin-threads
> /usr/share/perl5/vendor_perl/5.26
> /usr/lib/perl5/5.26/x86_64-cygwin-threads /usr/share/perl5/5.26) at
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm
> line 37.
> BEGIN failed--compilation aborted at
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm
> line 37.
> Compilation failed in require at
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm
> line 48.
> BEGIN failed--compilation aborted at
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/webkitdirs.pm
> line 48.
> Compilation failed in require at
> C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration
> line 33.
> BEGIN failed--compilation aborted at
> C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration
> line 33.
>
> FAILURE: Build failed with an exception.
>
> I then upgraded perl from the cygwin setup to revision 5 version 26
> subversion 2, then the build was able to continue. Maybe the build
> instructions could mention the exact minimum perl version required?
>
> The build then took about an hour but otherwise completed successfully,
> which is a pretty smooth experience considering the complexity of JavaFX
> and WebKit ;-).
>
>
> What about Windows 32-bit though? There will be no Oracle JDK from
> JDK-11 onwards, however https://adoptopenjdk.net/ have said they are
> willing to produce a JDK for Windows-32 bit. But will OpenJFX be
> buildable for that platform? If yes, how?
>
>
> Robert Lichtenberger
>
>
>
>
From namannigam12 at gmail.com Tue Sep 18 15:13:59 2018
From: namannigam12 at gmail.com (Naman Nigam)
Date: Tue, 18 Sep 2018 20:43:59 +0530
Subject: Improve the pom.xml referenced in Maven example
In-Reply-To:
References:
Message-ID:
Sure, thanks for pointing out the docs repository. Did that =>
https://github.com/openjfx/openjfx-docs/pull/2
Regards
Naman Nigam
+91-9761212401 | LinkedIn
On Tue, Sep 18, 2018 at 8:14 PM Abhinay Agarwal
wrote:
> Hi Nigam,
>
> Please raise a PR in https://github.com/openjfx/openjfx-docs
>
> Regards,
> Abhinay
>
> ------------------------------
> *From:* openjfx-dev on behalf of
> Naman Nigam
> *Sent:* Tuesday, September 18, 2018 8:06 PM
> *To:* openjfx-dev at openjdk.java.net
> *Subject:* Improve the pom.xml referenced in Maven example
>
> Hi! I am not sure if there is a format to reporting such minor possible
> improvements. Pardon me if this is not the correct mailing list to share
> such minor enhancements and please help redirect this to the correct person
> in that case. (Since I couldn't find the source on GitHub as well)
> The Run HelloWorld using Maven
> makes
> reference to a pom.xml which can
> be further improved with the use of
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.8.0
>
> 11 or
>
>
>
> as mentioned in another StackOverflow answer
> <
> https://stackoverflow.com/questions/49398894/unable-to-compile-simple-java-10-project-with-maven/51586202#51586202
> >
> as
> well.
>
> PS: I made that answer some time back and coincidently saw the usage of the
> formerly suggested answer in the production links via this mailing list as
> well. Thought
>
>
> Regards
> Naman Nigam
> +91-9761212401 | LinkedIn
>
From javafx at use.startmail.com Tue Sep 18 16:31:33 2018
From: javafx at use.startmail.com (javafx at use.startmail.com)
Date: Tue, 18 Sep 2018 12:31:33 -0400
Subject: JavaFX 11 is released
In-Reply-To:
References:
Message-ID: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
I don't see a way to attach java classes at the bug report form located
here:
https://bugreport.java.com/bugreport/start_form.do
Is there some way to do this??
Thank you.?
?
On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth
wrote:
?
> I am pleased to announce the final release of JavaFX 11 as well as
> the
> launch of a new OpenJFX community site at:
>
> http://openjfx.io/
>
> The GA version of JavaFX 11 is now live and can be downloaded by
> going
> to the openjfx.io site or by accessing javafx modules from maven
> central
> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
> graphics, controls, and so forth).
>
> This is the first standalone release of JavaFX 11. It runs with JDK
> 11,
> which is available as a release candidate now and will be shipped as
> a
> GA version next week, or on JDK 10 (OpenJDK build only).
>
> A big thank you to all who have contributed to OpenJFX make this
> release
> possible! I especially thank Johan Vos, both for taking on the role
> as
> Co-Lead of the OpenJFX Project and for the work that Gluon as done to
> build and host the JavaFX 11 release.
>
> I look forward to working with you all on JavaFX 12 and beyond.
>
> -- Kevin
> ?
From kevin.rushforth at oracle.com Tue Sep 18 16:35:48 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 18 Sep 2018 09:35:48 -0700
Subject: JavaFX 11 is released
In-Reply-To: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
Message-ID:
You can either paste the code in line, upload it to Google Drive or
similar, or else email the bundle to one of us and we will attach it.
-- Kevin
On 9/18/2018 9:31 AM, javafx at use.startmail.com wrote:
> I don't see a way to attach java classes at the bug report form
> located here:
>
> https://bugreport.java.com/bugreport/start_form.do
>
> Is there some way to do this?
>
> Thank you.
>
>
> On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth
> wrote:
>
>> I am pleased to announce the final release of JavaFX 11 as well as the
>> launch of a new OpenJFX community site at:
>>
>> http://openjfx.io/
>>
>> The GA version of JavaFX 11 is now live and can be downloaded by going
>> to the openjfx.io site or by accessing javafx modules from maven central
>> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
>> graphics, controls, and so forth).
>>
>> This is the first standalone release of JavaFX 11. It runs with JDK 11,
>> which is available as a release candidate now and will be shipped as a
>> GA version next week, or on JDK 10 (OpenJDK build only).
>>
>> A big thank you to all who have contributed to OpenJFX make this release
>> possible! I especially thank Johan Vos, both for taking on the role as
>> Co-Lead of the OpenJFX Project and for the work that Gluon as done to
>> build and host the JavaFX 11 release.
>>
>> I look forward to working with you all on JavaFX 12 and beyond.
>>
>> -- Kevin
>>
From philip.race at oracle.com Tue Sep 18 16:37:13 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 18 Sep 2018 09:37:13 -0700
Subject: JavaFX 11 is released
In-Reply-To: <9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
Message-ID: <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
No. If you have a test case, include it in the body.
if its too big for that .. then maybe it needs to be trimmed down anyway.
-phil.
On 09/18/2018 09:31 AM, javafx at use.startmail.com wrote:
> I don't see a way to attach java classes at the bug report form
> located here:
>
> https://bugreport.java.com/bugreport/start_form.do
>
> Is there some way to do this?
>
> Thank you.
>
>
> On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth
> wrote:
>
>> I am pleased to announce the final release of JavaFX 11 as well as the
>> launch of a new OpenJFX community site at:
>>
>> http://openjfx.io/
>>
>> The GA version of JavaFX 11 is now live and can be downloaded by going
>> to the openjfx.io site or by accessing javafx modules from maven central
>> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
>> graphics, controls, and so forth).
>>
>> This is the first standalone release of JavaFX 11. It runs with JDK 11,
>> which is available as a release candidate now and will be shipped as a
>> GA version next week, or on JDK 10 (OpenJDK build only).
>>
>> A big thank you to all who have contributed to OpenJFX make this release
>> possible! I especially thank Johan Vos, both for taking on the role as
>> Co-Lead of the OpenJFX Project and for the work that Gluon as done to
>> build and host the JavaFX 11 release.
>>
>> I look forward to working with you all on JavaFX 12 and beyond.
>>
>> -- Kevin
>>
From kevin.rushforth at oracle.com Tue Sep 18 16:49:19 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 18 Sep 2018 09:49:19 -0700
Subject: JavaFX 11 is released
In-Reply-To: <4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
<4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
Message-ID: <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
In general, smaller test cases are better, so this the preferred choice.
-- Kevin
On 9/18/2018 9:37 AM, Phil Race wrote:
> No. If you have a test case, include it in the body.
> if its too big for that .. then maybe it needs to be trimmed down anyway.
>
> -phil.
>
> On 09/18/2018 09:31 AM, javafx at use.startmail.com wrote:
>> I don't see a way to attach java classes at the bug report form
>> located here:
>>
>> https://bugreport.java.com/bugreport/start_form.do
>>
>> Is there some way to do this?
>>
>> Thank you.
>>
>>
>> On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth
>> wrote:
>>
>>> I am pleased to announce the final release of JavaFX 11 as well as the
>>> launch of a new OpenJFX community site at:
>>>
>>> http://openjfx.io/
>>>
>>> The GA version of JavaFX 11 is now live and can be downloaded by going
>>> to the openjfx.io site or by accessing javafx modules from maven
>>> central
>>> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
>>> graphics, controls, and so forth).
>>>
>>> This is the first standalone release of JavaFX 11. It runs with JDK 11,
>>> which is available as a release candidate now and will be shipped as a
>>> GA version next week, or on JDK 10 (OpenJDK build only).
>>>
>>> A big thank you to all who have contributed to OpenJFX make this
>>> release
>>> possible! I especially thank Johan Vos, both for taking on the role as
>>> Co-Lead of the OpenJFX Project and for the work that Gluon as done to
>>> build and host the JavaFX 11 release.
>>>
>>> I look forward to working with you all on JavaFX 12 and beyond.
>>>
>>> -- Kevin
>>>
>
From javafx at use.startmail.com Tue Sep 18 18:26:04 2018
From: javafx at use.startmail.com (javafx at use.startmail.com)
Date: Tue, 18 Sep 2018 14:26:04 -0400
Subject: JavaFX 11 is released
In-Reply-To: <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
<4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
<54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
Message-ID:
Thanks Kevin.
I will paste it all in this email. I have essentially three versions.
Two are so compressed it's hard for people to get what the issue is.
Since in those programs the proof only takes the form of the value of a
class variable, and that proof is demonstrated only by?
System.out.printlns of that variable's value, it's understandable that
the significance of what's being output could easily be missed or
misinterpreted/ dismissed etc.?
?The other one is a proper demo application which throws a
ConcurrentModificationException which can't be so easily misunderstood
or dismissed, but it has multiple *very small , very well documented*
classes. You can't? read the documentation and not get at what's being
shown (and still call yourself a developer LOL...), but you have to
read the javadoc.?
Note: don't shoot from the hip based on a cursory examination of the
output or stack trace (like I did LOL). I have probably already
considered your alternate explanation,? things from overridden methods
to the confusion about how and why? ConcurrentModificationExceptions
are thrown? to the (non) presence of multiple class loaders etc etc. It
took me real time to even entertain the idea that this was not a subtle
programming mistake but instead a bug in JavaFX. I can't avoid writing
these so that you have to read the javadoc? - you just have to read the
javadoc.?
My experience tells me the brief? versions were not easy to understand
so I'll post the bigger version here. All but one or two of these
classes should be? easy, one-glance classes for most everyone here and
the others are also very easy, with brief methods? and anyway
thoroughly javadoced.:
OK:
1)? A Receiver receives a mouse event.?
***********************************************************************
package javaApplicationThreadCuriosityComplex;
import javafx.scene.input.MouseEvent;
public interface Receiver
{
? void receiveEvent(MouseEvent event);
}
**************************************************************************
A do-nothing receiver receives? the mouse event and does nothing
**************************************************************************
package javaApplicationThreadCuriosityComplex;
import javafx.scene.input.MouseEvent;
/**
?* A {@link Receiver} implementation which literally does nothing
except receive the {@link MouseEvent} in {@link
#receiveEvent(MouseEvent)}, as defined in {@link Receiver}.
?* Exists in order that we can create many instances of a {@link
Receiver} implementation, where the mere existence and not the
functionality of the implementation is of any consequence to the
program.
?* See {@link PaneEventHandlerExceptionThrower}? for details.
?*
?* To satisfy yourself that these objects are being invoked,
uncomment-out the line in {@link #receiveEvent(MouseEvent)}, which will
print "Hello" to standard output.
?*/
public class DoNothingReceiver implements Receiver
{
? @Override
? public void receiveEvent(MouseEvent event)
? {
? ? //System.out.println("Hello");
? }
}
****************************************************************************************************
?
A rectangle drawing Receiver implementation. Very simple class; long
only because it's? written to be? transparent in its behavior.?
If the received mouse event is a certain type (arbitrarily selected for
ease of use in the application - mouse pressed on the primary button)
then it just removes the sole? Rectangle from the application's sole
Pane, if? such a Rectangle is there.
In any case, it next? immediately creates a new Rectangle,? sizes it,
changes its color,? positions it and adds it? to? the same Pane.
The effect is the Rectangle either? appears for the first time, or
appears to change color.?
That's it.?
****************************************************************************************************
package javaApplicationThreadCuriosityComplex;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import javafx.scene.paint.Color;
import javafx.scene.shape.Rectangle;
import java.util.List;
/**
?*?
?* This object receives {@link MouseEvent}s from the {@link
javafx.event.EventHandler}.
?* If the event is the primary button of the mouse being pressed, this
object removes the member {@link RectangleDrawingReceiver#rectangle}
from the list of the {@link Pane}'s children if that {@link Rectangle}
is present in that list.
?* It then assigns a new instance of a {@link Rectangle} to the member
{@link RectangleDrawingReceiver#rectangle}.
?* Finally it adds that member to the list of the {@link Pane}'s
children.
?* */
public class RectangleDrawingReceiver implements Receiver
{
? /**
? ?* The {@link Rectangle} which will appear after the Mouse is pressed
for the first time and be replaced on subsequent MOUSE_PRESSED events.
? ?*/
? private Rectangle rectangle;
? /**
? ?* boolean value which is reversed each time the primamry button of
the mouse is pressed and a new {@link Rectangle } appears.
? ?*/
? private boolean doDrawRectangleRed =true;
? /**
? ?* No-arg constrcutor added for clarity.
? ?*/
? public RectangleDrawingReceiver()
? {
? }
? /**
? ?* If the signal to add and remove the {@link Rectangle} is received,
then this method invokes {@link
RectangleDrawingReceiver#addAndRemoveRectangle(Pane)}. Otherwise
returns without doing anything.
? ?* @param mouseEvent the {@link MouseEvent} received from the {@link
PaneEventHandlerExceptionThrower}
? ?*/
? @Override
? public void receiveEvent(MouseEvent mouseEvent)
? {
? ? if (isAddAndRemoveRectangleSignal(mouseEvent))
? ? {
? ? ? Pane pane = (Pane) mouseEvent.getSource();
? ? ? addAndRemoveRectangle(pane);
? ? }
? }
? /**
? ?* Define the specific Mouse gesture, MOUSE_PRESSED and primary
button down, which will cause this object to possibly remove, then
defintely add a {@link Rectangle} to its list of children.
? ?* @param mouseEvent the {@link MouseEvent} which may or may not be
the trigger to remove and add a {@link Rectangle}
? ?* @return true iff the primary button of the mouse is pressed.
? ?*/
? private boolean isAddAndRemoveRectangleSignal(MouseEvent mouseEvent)
? {
? ? return mouseEvent.getEventType().equals(MouseEvent.MOUSE_PRESSED)
&& mouseEvent.isPrimaryButtonDown();
? }
? /**
? ?* Remove the {@link Rectangle} from the {@link Pane}, if it is
there. In either case, add a new {@link Rectangle} of pre-determined
size to the {@link Pane} at a pre-determined location.
? ?* @param pane the {@link Pane} which may or may not currently have a
{@link Rectangle} as a child.
? ?*/
? private void addAndRemoveRectangle(Pane pane)
? {
? ? pane.getChildren().remove(rectangle);
? ? reassignRectangle();
? ? pane.getChildren().add(rectangle);
? }
? /**
? ?* Create a completely new instance of the {@link Rectangle} with the
same size and location but with the opposite {@link Color} either
{@link Color#RED} or {@link Color#BLUE}.
? ?*/
? private void reassignRectangle()
? {
? ? rectangle = new Rectangle();
? ? sizeAndPositionRectangle();
? ? setRectangleColor();
? }
? /**
? ?* Establish the size and position of the {@link Rectangle}
? ?*/
? private void sizeAndPositionRectangle()
? {
? ? rectangle.setX(200);
? ? rectangle.setY(200);
? ? rectangle.setWidth(200);
? ? rectangle.setHeight(200);
? }
? /**
? ?* To make it apparent that the rectangle is being changed, we change
its color every other time
? ?*/
? private void setRectangleColor()
? {
? ? if (doDrawRectangleRed)
? ? {
? ? ? rectangle.setFill(Color.RED);
? ? ? doDrawRectangleRed= false;
? ? }
? ? else
? ? {
? ? ? rectangle.setFill(Color.BLUE);
? ? ? doDrawRectangleRed= true;
? ? }
? }
}
**********************************************************************************************************************
The meat of the processing loop. This generates and displays the bug.
This is an EventHandler which gets attached to a the Application's sole
Pane . It handles all MouseEvents which occur on the Pane.
In its constructor, creates a List of 100 do nothing receivers and? one
rectangle drawing receiver.?
For each received mouse event, it iterates through a List of Receivers
reserveReceiver and transfers them into a Set of Receivers,
activeReceivers.
Then goes through that Set and invokes each one's receive method.
This ensures? this method? first? adds to activeReceivers and then when
that is completely done,? iterates over? activeReceivers. If there
aren't two threads? *then given the way this is written*,? ?there will
be? no problem. A ConcurrentModicationException can be created on one
Thread, I am aware.?
That's it.?
Because this method is entered into recursively, as it goes through its
member activeReceivers in the method sendEvent it throws a
ConcurrentModificationException.?
As a secondary proof, this class keeps a static int , recursiveDepth,
whose value can only be 1 *in the debug output methods*. (elsewhere it
does assume? a value of 1) in the event the JavaFX Application Thread
has recursed into this class's handle().
****You should absolutely satisfy yourself that under no circumstances
should the output of the debug methods, as this program is written,?
show recursiveDepth to be other than 0 (zero) . You should convince
yourself of this before running this program****
In fact, if you search the resultant (copious LOL)? output for the
words stackTraceElement to find the point at which the exception is
thrown, you will see just above it the output produced from the debug
methods which are invoked just upon? entering and just before? exiting
of handle itself ,? reporting the impossible event that the value of
recursiveDepth? is 1. This is also when the
ConcurrentModificationException is thrown.?
Those two independent? ?output events are always paired because they
are not, in fact independent. The Application Thread is recursively
re-entrant? at that point.?
********************************************************************************************************************
package javaApplicationThreadCuriosityComplex;
import com.sun.javafx.tk.quantum.QuantumToolkit;
import
javaApplicationThreadCuriositySimple.JavaFXAnomalySimpleVersionApplication;
import javaApplicationThreadCuriositySimple.PaneEventHandler;
import javafx.event.EventHandler;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import java.util.*;
import java.util.function.Supplier;
/**
?*?
?* This has two {@link List}s of {@link Receiver}s and transfers the
contents of one {@link List} to the other for the sole purpose of
invoking {@link Collection#add(Object)} within the scope of this
method's {@link #handle(MouseEvent)}
?* This invocation demonstrates the bug by throwing a {@link
ConcurrentModificationException}.
?*
?*
?*? With enough elements in {@link #activeReceivers}, a {@link
ConcurrentModificationException} is reliably generated, proving that
the recursive re-entry? of the JavaFX Application Thread and that this
re-entry is deterimentally consequential to program correctness.
?*? ?We catch any such {@link Exception} and display its
details.
?*
?*
?*/
public class PaneEventExceptionGeneratingHandler implements
EventHandler
{
? /**
? ?* Class level variable which will only ever be 0 (zero) in the
methods {@link #showEnterDebugInformation(int, String, boolean)} and
{@link #showExitDebugInformation(int, String, boolean)} if the JavaFX
Application Thread does not invoke {@link #handle(MouseEvent)}
recursively and will be 1 (one) otherwise.
? ? */
? private static int recursiveDepth;
? /**
? ?* a {@link List} of {@link Receiver}s which will have its contents
transferred into {@link #activeReceivers} in order to provoke a {@link
ConcurrentModificationException}.
? ?*/
? private Set reserveReceivers = new HashSet<>();
? /**
? ?* a {@link Set} of {@link Receiver}s which will have the contents of
{@link #reserveReceivers} transferred into it order to provoke a {@link
ConcurrentModificationException}.
? ? ? */
? private List activeReceivers = new ArrayList<>();
? /**
? ?* No-arg constructor which populates a {@link List } of {@link
Receiver}s 101 elements long. The first 100 elements are {@link
DoNothingReceiver}s. The final element is an instance of {@link
RectangleDrawingReceiver}.
? ?*/
? public PaneEventExceptionGeneratingHandler()
? {
? ? DoNothingReceiver doNothingReceiver = null;
? ? int numberOfDonthingReceivers=100;// increasing this to a large
value such as here? where it is 100,? makes the
ConcurrentModificationException more likely or even certain. Lowering
the value to 1 prevents the Exception. In between values may or may not
cause the Exception to be thrown. Any specific in-between value? ***
RESULTS IN NON_DETERMINISITIC BEHAVIOR WRT TO EXCEPTION GENERATION FROM
RUN TO RUN OF THE PROGRAM***
? ? for (int i=0; i < numberOfDonthingReceivers; i++)
? ? {
? ? ? doNothingReceiver = new DoNothingReceiver();
? ? ? reserveReceivers.add(new DoNothingReceiver());
? ? }
? ? RectangleDrawingReceiver rectangleDrawingReceiver = new
RectangleDrawingReceiver();
? ? reserveReceivers.add(new RectangleDrawingReceiver());
? }
? /**
? ?* First invokes {@link #showEnterDebugInformation(int, String,
boolean)} to show the depth of recursion. Then clears the elements in
{@link #activeReceivers}. Then transfers the elements in {@link
#reserveReceivers} into {@link #activeReceivers}. Sends the {@link
MouseEvent} to each element in {@link #activeReceivers}. Finally,
invokes {@link #showExitDebugInformation(int, String, boolean)} to show
the depth of recursion.
? ?* If an {@link Exception} is raised, catches that {@link Exception}
and prints its relevant information to standard I?O.
? ?*
? ?* @param mouseEvent the {@link MouseEvent} which was generated on
the {@link Pane} and passed to this object by the JavaFX Application
Thread.
? ?*/
? @Override
? public void handle(MouseEvent mouseEvent)
? {
? ? showEnterDebugInformation(0, "handle", true);
? ? recursiveDepth++;
? ? activeReceivers.clear();
? ? transferReserveReceiversToActiveReceivers();
? ? try
? ? {
? ? ? sendEvent(mouseEvent);
? ? }
? ? catch (Exception ex)
? ? {
? ? ? showExceptionTrace(ex);
? ? }
? ? recursiveDepth--;
? ? showExitDebugInformation(0, "handle", true);
? }
? /**
? ?* Sends the {@link MouseEvent} received from the {@link Pane} to all
the {@link Receiver}s in {@link #activeReceivers}.
? ?*
? ?* @param mouseEvent
? ?*? ? ? ? ?the {@link MouseEvent} which was delivered from the {@link
Pane} by the JavaFX Application Thread.
? ?*/
? public void sendEvent(MouseEvent mouseEvent)
? {
? ? showEnterDebugInformation(2, "sendEvent", false);
? ? try
? ? {
? ? ? for (Receiver activeReceiver : activeReceivers)
? ? ? {
? ? ? ? activeReceiver.receiveEvent(mouseEvent);
? ? ? }
? ? }
? ? catch (Exception ex)
? ? {
? ? ? showExceptionTrace(ex);
? ? }
? ? showExitDebugInformation(2, "sendEvent", false);
? }
? /**
? ?* Prints spacesLength number of spaces to standard I/O. Used by
debug statements to indent output statements from the same method the
same amount.
? ?*
? ?* @param spacesLength
? ?*? ? ? ? ?the number of spaces to append to standard I/O
? ?*/
? private void printSpaces(int spacesLength)
? {
? ? for (int i = 0; i <= spacesLength; i++)
? ? ? System.out.print("? ");
? }
? /**
? ?* Prints "ENTERING"? then the method name and optionally the value
of {@link #recursiveDepth} at the time this method is invoked.
? ?*
? ?* @param prettyPrintOffset
? ?*? ? ? ? ?the amount of pretty printing indenting to be written to
standard I/O for this method
? ?* @param method
? ?*? ? ? ? ?the name of the method which invoked this method
? ?* @param showCounter
? ?*? ? ? ? ?true iff {@link #recursiveDepth} should also be appended
to standard I/O.
? ?*/
? private void showEnterDebugInformation(int prettyPrintOffset, String
method, boolean showCounter)
? {
? ? System.out.println();
? ? printSpaces(prettyPrintOffset);
? ? System.out.print("ENTERING? " + method);
? ? if (showCounter)
? ? {
? ? ? System.out.print(" and recursiveDepth is " + recursiveDepth);
? ? }
? ? System.out.println();
? }
? /**
? ?* Print to standard I/O some relevant information of the exception
passed to this method, including the {@link StackTraceElement}
elements.
? ?*
? ?* @param ex
? ?*? ? ? ? ?the {@link Exception} passed to this method whose
information should be printedc to standard I/O.
? ?*/
? private void showExceptionTrace(Exception ex)
? {
? ? System.out.println("ex = " + ex);
? ? StackTraceElement[] stackTrace = ex.getStackTrace();
? ? for (int i = 0; i < stackTrace.length; i++)
? ? {
? ? ? StackTraceElement stackTraceElement = stackTrace[i];
? ? ? System.out.println("stackTraceElement = " + stackTraceElement);
? ? }
? }
? /**
? ?* Prints "EXITING"? then the method name and optionally the value of
{@link #recursiveDepth} at the time this method is invoked.
? ?*
? ?* @param prettyPrintOffset
? ?*? ? ? ? ?the amount of pretty printing indenting to be written to
standard I/O for this method
? ?* @param method
? ?*? ? ? ? ?the name of the method which invoked this method
? ?* @param showCounter
? ?*? ? ? ? ?true iff {@link #recursiveDepth} should also be appended
to standard I/O.
? ?*/
? private void showExitDebugInformation(int prettyPrintOffset, String
method, boolean showCounter)
? {
? ? System.out.println();
? ? printSpaces(prettyPrintOffset);
? ? System.out.print("EXITING? " + method);
? ? if (showCounter)
? ? {
? ? ? System.out.print(" and recursiveDepth is " + recursiveDepth);
? ? }
? ? System.out.println();
? }
? /**
? ?* Transfer the contents of {@link #reserveReceivers} into {@link
#activeReceivers} as a means of invoking {@link Collection#add(Object)}
and thereby provoking a {@link ConcurrentModificationException} in the
event the JavaFX Application Thread recurses into {@link
#handle(MouseEvent)} .
? ?*/
? private void transferReserveReceiversToActiveReceivers()
? {
? ? for (Receiver reserveReceiver : reserveReceivers)
? ? {
? ? ? activeReceivers.add(reserveReceiver);
? ? }
? }
}?// class
package javaApplicationThreadCuriosityComplex;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.Pane;
import javafx.scene.shape.Rectangle;
import javafx.stage.Stage;
import java.util.ConcurrentModificationException;
/**
?* An {@link Application} with one {@link Pane}. The {@link Pane} has a
single {@link javafx.event.EventHandler}, {@link
PaneEventExceptionGeneratingHandler} which processes all {@link
MouseEvent}s the {@link Pane} receives.
?*
?* To use this program, launch it and move the mouse. A stream of
messages will appear in standard IO which you can ignore for now.?
Click once anywhere in the {@link Pane}. A {@link Rectangle} will
appear. Move the mouse over the {@link Rectangle} and click again. The
Rectangle will change color and? a {@link
ConcurrentModificationException} (unrelated to the change in color)
will be thrown, caught and its stack trace will be printed to the
screen.
?*
?* The messages to IO are are sent as the application enters into and
later exits each method. They can help you understand the bug. When the
exception is thrown, its stack trace elements are printed also.
?*
?* It's not enough to look at the stack trace to understand the bug.
You have to read the? the javadoc in {@link
PaneEventExceptionGeneratingHandler} for an explanation of how this
program demonstrates the bug.
?*/
public class JavaFXAnomalyComplexVersionApplication extends Application
{
? ? public void start(Stage primaryStage)
? ? {
? ? ? Pane mainPane = new Pane();
? ? ? mainPane.setMinHeight(800);
? ? ? mainPane.setMinWidth(800);
? ? ? PaneEventExceptionGeneratingHandler paneEventSender = new
PaneEventExceptionGeneratingHandler();
? ? ? mainPane.addEventHandler(MouseEvent.ANY, paneEventSender);
? ? ? 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);
? ? }
}
***************************END
******************************************
?
On Tuesday, September 18, 2018 at 12:49 PM, Kevin Rushforth
wrote:
?
> In general, smaller test cases are better, so this the preferred
> choice.
>
> -- Kevin
>
>
> On 9/18/2018 9:37 AM, Phil Race wrote:
>> No. If you have a test case, include it in the body.
>> if its too big for that .. then maybe it needs to be trimmed down
>> anyway.
>>
>> -phil.
>>
>> On 09/18/2018 09:31 AM, javafx at use.startmail.com wrote:
>>> I don't see a way to attach java classes at the bug report form
>>> located here:
>>>
>>> https://bugreport.java.com/bugreport/start_form.do
>>>
>>> Is there some way to do this?
>>>
>>> Thank you.
>>>
>>>
>>> On Tuesday, September 18, 2018 at 9:02 AM, Kevin Rushforth
>>> wrote:
>>> ?
>>>> I am pleased to announce the final release of JavaFX 11 as well as
>>>> the
>>>> launch of a new OpenJFX community site at:
>>>>
>>>> http://openjfx.io/
>>>>
>>>> The GA version of JavaFX 11 is now live and can be downloaded by
>>>> going
>>>> to the openjfx.io site or by accessing javafx modules from maven
>>>> central
>>>> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
>>>> graphics, controls, and so forth).
>>>>
>>>> This is the first standalone release of JavaFX 11. It runs with
>>>> JDK 11,
>>>> which is available as a release candidate now and will be shipped
>>>> as a
>>>> GA version next week, or on JDK 10 (OpenJDK build only).
>>>>
>>>> A big thank you to all who have contributed to OpenJFX make this
>>>> release
>>>> possible! I especially thank Johan Vos, both for taking on the
>>>> role as
>>>> Co-Lead of the OpenJFX Project and for the work that Gluon as done
>>>> to
>>>> build and host the JavaFX 11 release.
>>>>
>>>> I look forward to working with you all on JavaFX 12 and beyond.
>>>>
>>>> -- Kevin
>>>> ?
From kevin.rushforth at oracle.com Tue Sep 18 19:24:42 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 18 Sep 2018 12:24:42 -0700
Subject: JavaFX 11 is released
In-Reply-To:
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
<4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
<54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
Message-ID:
I really meant that when you file a bug at https://bugreport.java.com/
you can paste it inline there, along with your description of the bug.
If you have already filed a bug, send me the ID and I can copy the info
into that bug.
Thanks.
-- Kevin
On 9/18/2018 11:26 AM, javafx at use.startmail.com wrote:
> Thanks Kevin.
>
> I will paste it all in this email.
From javafx at use.startmail.com Tue Sep 18 19:30:33 2018
From: javafx at use.startmail.com (javafx at use.startmail.com)
Date: Tue, 18 Sep 2018 15:30:33 -0400
Subject: JavaFX 11 is released
In-Reply-To:
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
<4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
<54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
Message-ID: <8b93794cc1182b0c4605a9d6e04a9ac5.startmail@startmail.com>
We will review your report and have assigned it an internal review ID :
9057296.
hth...
?
On Tuesday, September 18, 2018 at 3:24 PM, Kevin Rushforth
wrote:
?
> I really meant that when you file a bug at
> https://bugreport.java.com/
> you can paste it inline there, along with your description of the
> bug.
> If you have already filed a bug, send me the ID and I can copy the
> info
> into that bug.
>
> Thanks.
>
> -- Kevin
>
>
> On 9/18/2018 11:26 AM, javafx at use.startmail.com wrote:
>> Thanks Kevin.
>>
>> I will paste it all in this email.
From bourges.laurent at gmail.com Tue Sep 18 17:52:04 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 18 Sep 2018 19:52:04 +0200
Subject: [12] RFR: JDK-8210386: Clipping problems with complex affine
transforms
Message-ID:
Please review the following bug fix in the MarlinFX renderer for JavaFX 12:
https://bugs.openjdk.java.net/browse/JDK-8210386
https://github.com/javafxports/openjdk-jfx/pull/206
PS: What is the process to backport this bug fix to OpenJFX 11 updates ?
This patch is small and can be applied directly to OpenJFX 11.
Thanks,
Laurent
From kevin.rushforth at oracle.com Tue Sep 18 20:06:41 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 18 Sep 2018 13:06:41 -0700
Subject: JavaFX 11 is released
In-Reply-To: <8b93794cc1182b0c4605a9d6e04a9ac5.startmail@startmail.com>
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
<4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
<54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
<8b93794cc1182b0c4605a9d6e04a9ac5.startmail@startmail.com>
Message-ID: <74cfe381-902d-3dac-bb7a-508b8d1a6049@oracle.com>
Yes, thank you for filing it. It should be transferred to the JDK
project tomorrow.
-- Kevin
On 9/18/2018 12:30 PM, javafx at use.startmail.com wrote:
> We will review your report and have assigned it an internal review ID
> : 9057296.
>
> hth...
>
> On Tuesday, September 18, 2018 at 3:24 PM, Kevin Rushforth
> wrote:
>> I really meant that when you file a bug at https://bugreport.java.com/
>> you can paste it inline there, along with your description of the bug.
>> If you have already filed a bug, send me the ID and I can copy the info
>> into that bug.
>>
>> Thanks.
>>
>> -- Kevin
>>
>>
>> On 9/18/2018 11:26 AM, javafx at use.startmail.com wrote:
>>> Thanks Kevin.
>>>
>>> I will paste it all in this email.
From tgolden at andplus.com Tue Sep 18 20:37:56 2018
From: tgolden at andplus.com (Tom Golden)
Date: Tue, 18 Sep 2018 16:37:56 -0400
Subject: "javapackager" in no-mans-land?
Message-ID:
I understand that along with JavaFX being removed from the Oracle JDK
distribution in Java 11, the Oracle team will no longer release the
`javapackager` tool.
I also see there is a JEP discussing an eventual replacement, JEP-343 (
http://openjdk.java.net/jeps/343).
Just to confirm, the tool was NOT migrated to OpenJFX with the rest of the
JavaFX code, correct? So until JEP-343 is implemented in a future release
(?) there is no "official" way to package native installers for JavaFX
applications?
If so, is it in theory still possible to use the Oracle javapackager tool
from earlier releases? Or should we remain on Java 10 for the time being?
--
Thanks,
Tom Golden
Technical Architect
AndPlus, LLC
257 Turnpike Road
Southborough, MA 01772
Phone 508-425-7533
http://www.andplus.com
From cnewland at chrisnewland.com Tue Sep 18 21:32:19 2018
From: cnewland at chrisnewland.com (Chris Newland)
Date: Tue, 18 Sep 2018 22:32:19 +0100
Subject: JavaFX 11 is released
In-Reply-To:
References:
Message-ID: <68839d620ecf44e92ea1482b677f68de.squirrel@excalibur.xssl.net>
Congratulations to all involved in this!
Looking forward to seeing JavaFX grow now it's outside of the JDK.
-Chris
On Tue, September 18, 2018 14:08, Johan Vos wrote:
> Adding to what Kevin already said (huge thanks to Kevin and Oracle for
> all they did), I want to thank everyone on this list for being part of
> this release. The JavaFX 11 release is a huge milestone, and there are
> many people who contributed, some of them who have been working with
> JavaFX from
> day 1, some who just started working.
>
> As for the site http://openjfx.io: this is something we created with
> Gluon,
> but we really want it to be a community-organised site. Therefore, it is
> all available via github, and open for PR's:
> https://github.com/openjfx/hugo-site.
>
>
> Thanks again,
>
>
> - Johan
>
>
> On Tue, Sep 18, 2018 at 3:02 PM Kevin Rushforth
>
> wrote:
>
>
>> I am pleased to announce the final release of JavaFX 11 as well as the
>> launch of a new OpenJFX community site at:
>>
>> http://openjfx.io/
>>
>>
>> The GA version of JavaFX 11 is now live and can be downloaded by going
>> to the openjfx.io site or by accessing javafx modules from maven central
>> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
>> graphics, controls, and so forth).
>>
>> This is the first standalone release of JavaFX 11. It runs with JDK 11,
>> which is available as a release candidate now and will be shipped as a
>> GA version next week, or on JDK 10 (OpenJDK build only).
>>
>>
>> A big thank you to all who have contributed to OpenJFX make this
>> release possible! I especially thank Johan Vos, both for taking on the
>> role as Co-Lead of the OpenJFX Project and for the work that Gluon as
>> done to build and host the JavaFX 11 release.
>>
>> I look forward to working with you all on JavaFX 12 and beyond.
>>
>>
>> -- Kevin
>>
>>
>>
>
From nlisker at gmail.com Wed Sep 19 01:58:59 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 19 Sep 2018 04:58:59 +0300
Subject: Compiling OpenJFX
In-Reply-To:
References:
Message-ID:
Yeah, I missed that one during the recent update of the instructions.
Thanks.
If you have any other improvements you'd like to suggest that are not
related to WebKit please send them my way. I never built Webkit so I can't
help with that.
On Tue, Sep 18, 2018 at 4:52 PM Robert Lichtenberger <
r.lichtenberger at gmail.com> wrote:
> I am trying (again) to get my toes wet with building OpenJFX myself.
>
> Here are some things I am wondering about:
>
>
>
> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Gradle
> says:
>
> Gradle is the primary build tool for building OpenJFX. We currently use
> Gradle 4.8 for jfx-dev
>
> but a few lines down it says:
>
> add gradle-4.3/bin to your PATH
>
> I assume it should say gradle-4.8/bin here too.
>
>
> Other than that, I was able to build OpenJFX on Windows 64-bit without
> web and media. So after that I tried to build with web and media, where
> I got this error:
>
> > Task :web:compileNativeWin FAILED
> Can't locate English.pm in @INC (you may need to install the English
> module) (@INC contains:
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts
> /usr/local/lib/perl5/site_perl/5.26/x86_64-cygwin-threads
> /usr/local/share/perl5/site_perl/5.26
> /usr/lib/perl5/vendor_perl/5.26/x86_64-cygwin-threads
> /usr/share/perl5/vendor_perl/5.26
> /usr/lib/perl5/5.26/x86_64-cygwin-threads /usr/share/perl5/5.26) at
>
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm
> line 37.
> BEGIN failed--compilation aborted at
>
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/VCSUtils.pm
> line 37.
> Compilation failed in require at
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/
> webkitdirs.pm
> line 48.
> BEGIN failed--compilation aborted at
> /cygdrive/c/openjfx/rt/modules/javafx.web/src/main/native/Tools/Scripts/
> webkitdirs.pm
> line 48.
> Compilation failed in require at
>
> C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration
> line 33.
> BEGIN failed--compilation aborted at
>
> C:\openjfx\rt\modules\javafx.web/src/main/native/Tools/Scripts/set-webkit-configuration
> line 33.
>
> FAILURE: Build failed with an exception.
>
> I then upgraded perl from the cygwin setup to revision 5 version 26
> subversion 2, then the build was able to continue. Maybe the build
> instructions could mention the exact minimum perl version required?
>
> The build then took about an hour but otherwise completed successfully,
> which is a pretty smooth experience considering the complexity of JavaFX
> and WebKit ;-).
>
>
> What about Windows 32-bit though? There will be no Oracle JDK from
> JDK-11 onwards, however https://adoptopenjdk.net/ have said they are
> willing to produce a JDK for Windows-32 bit. But will OpenJFX be
> buildable for that platform? If yes, how?
>
>
> Robert Lichtenberger
>
>
>
>
>
From youngty1997 at gmail.com Wed Sep 19 02:11:55 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Tue, 18 Sep 2018 21:11:55 -0500
Subject: BUG: TableView's setMouseTransparent method does not make mouse
transparent
Message-ID:
Bug review ID: 9057302.
TavleView's setMouseTransparent no longer makes mouse events(like
clicking) transparent for that TableView when set to true in JavaFX 11.
In Oracle 9 and 10 it did, however. I vaguely remember compiling OpenJDK
10 with JavaFX integrated and had the same issue even though Oracle 10
did not have the bug.
I personally use this to create an On Screen Display for displaying some
GPU information while playing games in Linux(Yes, I know it's incredibly
bad to do that since the desktop is still being rendered). Because of
this bug, in-game menus cannot be clicked if they are in the top left
corner(where the window is) as the mouse transparent method is no longer
working.
(While i'm at it, does JavaFX *always* render the desktop even if a
JavaFX application is fullscreen?)
From youngty1997 at gmail.com Wed Sep 19 02:30:22 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Tue, 18 Sep 2018 21:30:22 -0500
Subject: BUG: zip file in sdk lib folder causes bugged JDK build
Message-ID: <527442d0-2554-61a1-93e9-1a27a1eea338@gmail.com>
The zip file "src.zip" located in rt/build/sdk/lib/ after building
JavaFX from source causes a bugged build of OpenJDK with JavaFX
integrated into it. The build itself completes just fine, it's just that
resulting build has issues.
Because a zip file isn't a supported module format, Netbeans spits out
an error saying as such when attempting to compile a JavaFX
application(unsure if the project being modular matters here or not, but
it is.). It also seems to cause any attempt to build a new build of
OpenJDK to segmentation fault using that same bugged JDK as the boot jdk.
Is there somekind of special exception for unsupported module formats
for the standalone SDK or is it just manually removed after it's done
being compiled?
Not sure if it's worth creating a bug report for this since this seems
to be some minor mishap. Including a zipped file of the source code in a
lib file doesn't make a whole lot of sense to me... I would think it
should be in the parent directory(rt/buid/sdk), next to the legal and
lib folders.
From lenborje at gmail.com Wed Sep 19 06:12:42 2018
From: lenborje at gmail.com (=?utf-8?Q?Lennart_B=C3=B6rjeson?=)
Date: Wed, 19 Sep 2018 08:12:42 +0200
Subject: "javapackager" in no-mans-land?
In-Reply-To:
References:
Message-ID: <3F07CAF6-1614-46FE-850B-99A7D5409AE0@gmail.com>
It was migrated, but removed...
The recommended work-around is to use the javapackager in OracleJDK 10 when packing Java/OpenJfx 11 applications.
That may or may not be practical depending on your build setup. Also, if you?re currently using the UserJvmOptions services, these are also gone in Java/OpenJfx 11, and it would complicate the build process even further if you were required to separate the parts needing to compile with OracleJDK 10, too.
I?m using Gradle to build my project, and it is currently dependent on the javafx-Gradle-plugin to package. To upgrade to Java/OpenJfx 11, and still keep the javapackager, I would need to refactor:
1) my code base, to separate the parts needed to compile with OracleJDK 10 to get the UserJvmOptions,
2) my Gradle structure, to run in three steps (compile some parts with 10, compile most parts with 11, package all with 10 while still linking most from 11).
It?s too much for me. I?ve decided to remain at Java 10 and wait until there?s a javapackager replacement. The javafx-Gradle-plugin has also been deprecated due to the loss of the javapackager, so I?m stuck anyway with Java 10 unless I rework my entire build structure substantially. I?m hoping for a future Gradle plugin replacement.
Seriously, it would be much easier to build my own JDK with OpenJfx, the javapackager and UserJvmOptions Service still bundled with it, but then I?d step up to a completely different level of support commitment...
/Lennart B?rjeson
Epistula electronica a meo computatro tabulari missa est
> 18 sep. 2018 kl. 22:37 skrev Tom Golden :
>
> I understand that along with JavaFX being removed from the Oracle JDK
> distribution in Java 11, the Oracle team will no longer release the
> `javapackager` tool.
>
> I also see there is a JEP discussing an eventual replacement, JEP-343 (
> http://openjdk.java.net/jeps/343).
>
> Just to confirm, the tool was NOT migrated to OpenJFX with the rest of the
> JavaFX code, correct? So until JEP-343 is implemented in a future release
> (?) there is no "official" way to package native installers for JavaFX
> applications?
>
> If so, is it in theory still possible to use the Oracle javapackager tool
> from earlier releases? Or should we remain on Java 10 for the time being?
>
> --
> Thanks,
> Tom Golden
> Technical Architect
> AndPlus, LLC
> 257 Turnpike Road
> Southborough, MA 01772
>
> Phone 508-425-7533
> http://www.andplus.com
From sverre.moe at gmail.com Wed Sep 19 07:22:14 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Wed, 19 Sep 2018 09:22:14 +0200
Subject: JavaFX 11 is released
In-Reply-To: <54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
<4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
<54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
Message-ID:
Great work with JavaFX 11. Looking forward to trying it out.
About license for OpenJDK and OpenJFX:
Given that OpenJDK has a GPLv2-CE license, is it possible to use it with a
commercial application, when bundling with a native runtime, or do we need
a commercial license from Oracle? We will not be providing the source code
for our application which is required when using software with GPL.
We deliver both software and hardware to our customers. The server hardware
running SUSE Linux Enterprise Server, which provides the OpenJDK builds,
comes preinstalled with our applications. SLES 15.0 has the OpenJDK 10
build, but I reckon later SP will probably provide OpenJDK 11. We pay for
SLES and are getting LTSS updates from SUSE which includes the OpenJDK.
Given that Oracle JDK which we have used up to now to build our application
cannot any longer be used in production without license from Oracle, we
then would either need a license or use the OpenJDK to build and deliver
with out application. Using the OpenJDK I am not sure we can because of the
GPLv2 license it is under.
I guess it would not be an issue if we did not bundle the JRE runtime, but
required the client computer to have it installed, like we do today when
using Java Web Start. However with the removal of Java Web Start we are
looking into creating native packages for Linux, Windows and Mac.
When it comes to third party Java libraries we have been carefully to only
use those which is possible in a commercial application, like Apache, BSD
and LGPL, such as JFXtras (BSD License 2.0), Medusa (Apache License v2.0)
and JFreechart-FX (LGPL 2.1).
Now that we will provide JavaFX in the same way as a OpenJFX dependency I
have the same concern with it as I do with OpenJDK if it also is under
GPLv2.
/Sverre
From johan.vos at gluonhq.com Wed Sep 19 08:55:57 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 19 Sep 2018 10:55:57 +0200
Subject: Filling the Packager gap
Message-ID:
Hi,
As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
We backported the required changes to an OpenJDK 11 mirror:
https://github.com/johanvos/openjdk-mobile11/tree/packager
With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at
http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.
Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
- Johan
From blackdrag at gmx.org Wed Sep 19 09:05:24 2018
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Wed, 19 Sep 2018 11:05:24 +0200
Subject: ASF and Licensing
Message-ID:
Hi all,
Because moving to an organization was recently mentioned here, or
founding one for OpenJFX, I would like to mention a very few points.
Corner stones for the Apache Foundation:
*) clear and open project governance
*) be open about decisions and develop the community the Apache way
*) be Apache licensed and branded
And while I think OpenJFX will manage the first two points I am really
wondering about the licensing issue. GPL2 with or without CE is
considered category-x, which means it cannot be included in an Apache
product: https://www.apache.org/legal/resolved.html#category-x
That means incubation involves (among other things) clearing up and
transferring the "IP" to the Apache Software Foundation, and then
licensing the project under Apache License.
Right now the project is kind of unusable for the ASF
bye Jochen
From dlemmermann at gmail.com Wed Sep 19 12:07:44 2018
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Wed, 19 Sep 2018 14:07:44 +0200
Subject: JavaFX Days Zurich
Message-ID: <3DC949DC-A9F1-401A-A58B-C74E9A35C781@gmail.com>
With all this activity going on in the JavaFX space right now, I thought it is a good idea to inform people on this list that we are currently organizing a ?JavaFX-Only? conference in Zurich on Dec. 3rd until Dec. 5. More info on: javafx-days.com
The first day will have a beginners and an expert training class (Anton Epple, Hendrik Ebbers).
The second day will be filled with presentations from various JavaFX experts: Johan Vos, Hendrik Ebbers, Gerrit Grunwald, ?. me ( ** blushing **)
The third day will be a ?JavaFX on Mobile? day with a Gluon Workshop.
Hope to see you there ?
Dirk
From kevin.rushforth at oracle.com Wed Sep 19 12:47:07 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 19 Sep 2018 05:47:07 -0700
Subject: ASF and Licensing
In-Reply-To:
References:
Message-ID: <3656a7cd-f696-da3f-184c-d29b3ab3e4b1@oracle.com>
> Because moving to an organization was recently mentioned here, or
> founding one for OpenJFX, I would like to mention a very few points.
It has been mentioned, but there are no plans to do this.
-- Kevin
On 9/19/2018 2:05 AM, Jochen Theodorou wrote:
> Hi all,
>
> Because moving to an organization was recently mentioned here, or
> founding one for OpenJFX, I would like to mention a very few points.
>
> Corner stones for the Apache Foundation:
> *) clear and open project governance
> *) be open about decisions and develop the community the Apache way
> *) be Apache licensed and branded
>
> And while I think OpenJFX will manage the first two points I am really
> wondering about the licensing issue. GPL2 with or without CE is
> considered category-x, which means it cannot be included in an Apache
> product: https://www.apache.org/legal/resolved.html#category-x
>
> That means incubation involves (among other things) clearing up and
> transferring the "IP" to the Apache Software Foundation, and then
> licensing the project under Apache License.
>
> Right now the project is kind of unusable for the ASF
>
> bye Jochen
From kevin.rushforth at oracle.com Wed Sep 19 12:51:11 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 19 Sep 2018 05:51:11 -0700
Subject: JavaFX 11 is released
In-Reply-To:
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
<4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
<54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
Message-ID: <113e2a22-3ad3-fb08-6e03-37872c219d83@oracle.com>
While this is not meant to be legal advice... The purpose of the
Classpath exception to GPL v2 [1], both for the JDK itself and for
JavaFX, is to allow applications to use it without requiring that the
application itself be licensed under GPL nor requiring that the source
for the application be provided. This applies whether you use OpenJDK 11
+ OpenJFX 11 or Oracle JDK 11 + OpenJFX 11.
-- Kevin
[1] http://openjdk.java.net/legal/gplv2+ce.html
On 9/19/2018 12:22 AM, Sverre Moe wrote:
> Great work with JavaFX 11. Looking forward to trying it out.
>
> About license for OpenJDK and OpenJFX:
>
> Given that OpenJDK has a GPLv2-CE license, is it possible to use it
> with a commercial application, when bundling with a native runtime, or
> do we need a commercial license from Oracle? We will not be providing
> the source code for our application which is required when using
> software with GPL.
>
> We deliver both software and hardware to our customers. The server
> hardware running SUSE Linux Enterprise Server, which provides the
> OpenJDK builds, comes preinstalled with our applications. SLES 15.0
> has the OpenJDK 10 build, but I reckon later SP will probably provide
> OpenJDK 11. We pay for SLES and are getting LTSS updates from SUSE
> which includes the OpenJDK.
>
> Given that Oracle JDK which we have used up to now to build our
> application cannot any longer be used in production without license
> from Oracle, we then would either need a license or use the OpenJDK to
> build and deliver with out application. Using the OpenJDK I am not
> sure we can because of the GPLv2 license it is under.
>
> I guess it would not be an issue if we did not bundle the JRE runtime,
> but required the client computer to have it installed, like we do
> today when using Java Web Start. However with the removal of Java Web
> Start we are looking into creating native packages for Linux, Windows
> and Mac.
>
> When it comes to third party Java libraries we have been carefully to
> only use those which is possible in a commercial application, like
> Apache, BSD and LGPL, such as JFXtras (BSD License 2.0), Medusa
> (Apache License v2.0) and JFreechart-FX (LGPL 2.1).
> Now that we will provide JavaFX in the same way as a OpenJFX
> dependency I have the same concern with it as I do with OpenJDK if it
> also is under GPLv2.
>
> /Sverre
From kevin.rushforth at oracle.com Wed Sep 19 13:01:35 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 19 Sep 2018 06:01:35 -0700
Subject: BUG: TableView's setMouseTransparent method does not make mouse
transparent
In-Reply-To:
References:
Message-ID:
Thanks for reporting the issue. I see it in the bug system, and it
should be transferred to the JDK project in JBS in a day or so.
I'm not sure I understand your question:
> (While i'm at it, does JavaFX *always* render the desktop even if a
JavaFX application is fullscreen?)
What do you mean by "render the desktop" ?
-- Kevin
On 9/18/2018 7:11 PM, Ty Young wrote:
> Bug review ID: 9057302.
>
>
> TavleView's setMouseTransparent no longer makes mouse events(like
> clicking) transparent for that TableView when set to true in JavaFX
> 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling
> OpenJDK 10 with JavaFX integrated and had the same issue even though
> Oracle 10 did not have the bug.
>
>
> I personally use this to create an On Screen Display for displaying
> some GPU information while playing games in Linux(Yes, I know it's
> incredibly bad to do that since the desktop is still being rendered).
> Because of this bug, in-game menus cannot be clicked if they are in
> the top left corner(where the window is) as the mouse transparent
> method is no longer working.
>
>
> (While i'm at it, does JavaFX *always* render the desktop even if a
> JavaFX application is fullscreen?)
>
From youngty1997 at gmail.com Wed Sep 19 14:52:48 2018
From: youngty1997 at gmail.com (Ty Young)
Date: Wed, 19 Sep 2018 09:52:48 -0500
Subject: BUG: TableView's setMouseTransparent method does not make mouse
transparent
In-Reply-To:
References:
Message-ID: <651f2ccf-bf8a-eea5-2603-eb9114b9c3c2@gmail.com>
On 9/19/18 8:01 AM, Kevin Rushforth wrote:
> Thanks for reporting the issue. I see it in the bug system, and it
> should be transferred to the JDK project in JBS in a day or so.
>
> I'm not sure I understand your question:
>
> > (While i'm at it, does JavaFX *always* render the desktop even if a
> JavaFX application is fullscreen?)
>
> What do you mean by "render the desktop" ?
>
> -- Kevin
>
Typically when a game(or potentially any 3d application) is fullscreen,
that game(or 3d application) has exclusive control and desktop
elements(the desktop environment and the windows within) are no longer
rendered. As a result, frame rate is increased, latency is reduced, and
stuttering/jittering are reduced or non existent.
However, it's possible to "fake" fullscreen by using borderless windowed
mode which does not provide the performance benefits of fullscreen while
being 'fullscreen".
Basically what I'm asking is: Does JavaFX just disable window
decorations(title bar/resize borders) and overlays the application over
the OS's desktop or is it *truly* fullscreen?
> On 9/18/2018 7:11 PM, Ty Young wrote:
>> Bug review ID: 9057302.
>>
>>
>> TavleView's setMouseTransparent no longer makes mouse events(like
>> clicking) transparent for that TableView when set to true in JavaFX
>> 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling
>> OpenJDK 10 with JavaFX integrated and had the same issue even though
>> Oracle 10 did not have the bug.
>>
>>
>> I personally use this to create an On Screen Display for displaying
>> some GPU information while playing games in Linux(Yes, I know it's
>> incredibly bad to do that since the desktop is still being rendered).
>> Because of this bug, in-game menus cannot be clicked if they are in
>> the top left corner(where the window is) as the mouse transparent
>> method is no longer working.
>>
>>
>> (While i'm at it, does JavaFX *always* render the desktop even if a
>> JavaFX application is fullscreen?)
>>
>
From kevin.rushforth at oracle.com Wed Sep 19 15:27:01 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 19 Sep 2018 08:27:01 -0700
Subject: BUG: TableView's setMouseTransparent method does not make mouse
transparent
In-Reply-To: <651f2ccf-bf8a-eea5-2603-eb9114b9c3c2@gmail.com>
References:
<651f2ccf-bf8a-eea5-2603-eb9114b9c3c2@gmail.com>
Message-ID: <8a7da427-eade-16e3-e468-8ebc898f0f82@oracle.com>
JavaFX does not use exclusive full-screen mode. It simulates full screen
by using an undecorated window that is exactly the size of the screen.
This means that pop-ups, such as those used by ComboBox and content
menus, will continue to work (they use separate windows).
-- Kevin
On 9/19/2018 7:52 AM, Ty Young wrote:
>
> On 9/19/18 8:01 AM, Kevin Rushforth wrote:
>> Thanks for reporting the issue. I see it in the bug system, and it
>> should be transferred to the JDK project in JBS in a day or so.
>>
>> I'm not sure I understand your question:
>>
>> > (While i'm at it, does JavaFX *always* render the desktop even if a
>> JavaFX application is fullscreen?)
>>
>> What do you mean by "render the desktop" ?
>>
>> -- Kevin
>>
>
> Typically when a game(or potentially any 3d application) is
> fullscreen, that game(or 3d application) has exclusive control and
> desktop elements(the desktop environment and the windows within) are
> no longer rendered. As a result, frame rate is increased, latency is
> reduced, and stuttering/jittering are reduced or non existent.
>
> However, it's possible to "fake" fullscreen by using borderless
> windowed mode which does not provide the performance benefits of
> fullscreen while being 'fullscreen".
>
> Basically what I'm asking is: Does JavaFX just disable window
> decorations(title bar/resize borders) and overlays the application
> over the OS's desktop or is it *truly* fullscreen?
>
>
>> On 9/18/2018 7:11 PM, Ty Young wrote:
>>> Bug review ID: 9057302.
>>>
>>>
>>> TavleView's setMouseTransparent no longer makes mouse events(like
>>> clicking) transparent for that TableView when set to true in JavaFX
>>> 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling
>>> OpenJDK 10 with JavaFX integrated and had the same issue even though
>>> Oracle 10 did not have the bug.
>>>
>>>
>>> I personally use this to create an On Screen Display for displaying
>>> some GPU information while playing games in Linux(Yes, I know it's
>>> incredibly bad to do that since the desktop is still being
>>> rendered). Because of this bug, in-game menus cannot be clicked if
>>> they are in the top left corner(where the window is) as the mouse
>>> transparent method is no longer working.
>>>
>>>
>>> (While i'm at it, does JavaFX *always* render the desktop even if a
>>> JavaFX application is fullscreen?)
>>>
>>
From sverre.moe at gmail.com Wed Sep 19 17:17:08 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Wed, 19 Sep 2018 19:17:08 +0200
Subject: JavaFX 11 is released
In-Reply-To: <113e2a22-3ad3-fb08-6e03-37872c219d83@oracle.com>
References:
<9b4b9061c38a3f68b3f769dbbb5bcbed.startmail@startmail.com>
<4630f7c9-d23e-696b-2a0a-9bbed1a7939a@oracle.com>
<54aae6ee-5f85-f8ed-63b8-cc27f1f4872f@oracle.com>
<113e2a22-3ad3-fb08-6e03-37872c219d83@oracle.com>
Message-ID:
Thanks for the clarification. I tried to read the GPLv2-CE license, but it
gave me a headache.
/Sverre
Den ons. 19. sep. 2018 kl. 14:51 skrev Kevin Rushforth <
kevin.rushforth at oracle.com>:
> While this is not meant to be legal advice... The purpose of the
> Classpath exception to GPL v2 [1], both for the JDK itself and for
> JavaFX, is to allow applications to use it without requiring that the
> application itself be licensed under GPL nor requiring that the source
> for the application be provided. This applies whether you use OpenJDK 11
> + OpenJFX 11 or Oracle JDK 11 + OpenJFX 11.
>
> -- Kevin
>
> [1] http://openjdk.java.net/legal/gplv2+ce.html
>
>
> On 9/19/2018 12:22 AM, Sverre Moe wrote:
> > Great work with JavaFX 11. Looking forward to trying it out.
> >
> > About license for OpenJDK and OpenJFX:
> >
> > Given that OpenJDK has a GPLv2-CE license, is it possible to use it
> > with a commercial application, when bundling with a native runtime, or
> > do we need a commercial license from Oracle? We will not be providing
> > the source code for our application which is required when using
> > software with GPL.
> >
> > We deliver both software and hardware to our customers. The server
> > hardware running SUSE Linux Enterprise Server, which provides the
> > OpenJDK builds, comes preinstalled with our applications. SLES 15.0
> > has the OpenJDK 10 build, but I reckon later SP will probably provide
> > OpenJDK 11. We pay for SLES and are getting LTSS updates from SUSE
> > which includes the OpenJDK.
> >
> > Given that Oracle JDK which we have used up to now to build our
> > application cannot any longer be used in production without license
> > from Oracle, we then would either need a license or use the OpenJDK to
> > build and deliver with out application. Using the OpenJDK I am not
> > sure we can because of the GPLv2 license it is under.
> >
> > I guess it would not be an issue if we did not bundle the JRE runtime,
> > but required the client computer to have it installed, like we do
> > today when using Java Web Start. However with the removal of Java Web
> > Start we are looking into creating native packages for Linux, Windows
> > and Mac.
> >
> > When it comes to third party Java libraries we have been carefully to
> > only use those which is possible in a commercial application, like
> > Apache, BSD and LGPL, such as JFXtras (BSD License 2.0), Medusa
> > (Apache License v2.0) and JFreechart-FX (LGPL 2.1).
> > Now that we will provide JavaFX in the same way as a OpenJFX
> > dependency I have the same concern with it as I do with OpenJDK if it
> > also is under GPLv2.
> >
> > /Sverre
>
>
From guy.abossolo.foh at scientificware.com Wed Sep 19 21:03:05 2018
From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy)
Date: Wed, 19 Sep 2018 23:03:05 +0200
Subject: JBS report status.
In-Reply-To:
References:
Message-ID: