RFR: 8245634: [TestBug] Enable and fix tests ignored with message "impl_cssSet API removed"

[Ajit Ghaisas]

This is a simple test fix.

Issue : https://bugs.openjdk.java.net/browse/JDK-8245634

After fixing [JDK-8245457,](https://bugs.openjdk.java.net/browse/JDK-8245457) I 
found that there are more ignored tests
of similar nature that can be enabled and fixed. A search for ignored tests 
with message "impl_cssSet API removed" -
revealed a total 6 occurrences in 4 files - 1) CellTest
2) CheckBoxTest
3) ChoiceBoxTest
4) DateCellTest

This PR enables and fixes these tests.

-

Commit messages:
 - enable ignored unit tests

Changes: https://git.openjdk.java.net/jfx/pull/239/files
 Webrev: https://webrevs.openjdk.java.net/jfx/239/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245634
  Stats: 65 lines in 4 files changed: 48 ins; 7 del; 10 mod
  Patch: https://git.openjdk.java.net/jfx/pull/239.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/239/head:pull/239

PR: https://git.openjdk.java.net/jfx/pull/239

Re: [Integrated] RFR: 8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

[Arun Joseph]

On Tue, 26 May 2020 09:27:52 GMT, Arun Joseph  wrote:

> Cause: The test assumes that WebView/WebPage will be GCed right after 
> `System.gc()`
> 
> Fix: Use `runFinalization()` and `sleep()` to wait for objects to get GCed

This pull request has now been integrated.

Changeset: 8914bd2a
Author:Arun Joseph 
URL:   https://git.openjdk.java.net/jfx/commit/8914bd2a
Stats: 33 lines in 1 file changed: 15 ins; 7 del; 11 mod

8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

Reviewed-by: kcr

-

PR: https://git.openjdk.java.net/jfx/pull/236

Re: [Rev 01] RFR: 8245499: Text input controls should show handles on iOS

[Ajit Ghaisas]

On Tue, 26 May 2020 17:33:20 GMT, Jose Pereda  wrote:

>> After JDK-8242167, a JavaFX control is used for text input on iOS instead of 
>> the native control, on a touch enabled
>> device. However, selection handles are not enabled and currently text 
>> selection is not possible at all.
>> This PR enables handles on iOS as in the rest of the platforms with touch 
>> support.
>> 
>> It also tries to accommodate its style to the native style for handles, 
>> where selection handles have a circle shape and
>> are a little bit bigger, and there is no caret handle.
>> I've tested it on iPhone, running a small
>> [HelloFX](https://github.com/gluonhq/client-samples/tree/master/Maven/HelloFX)
>>  sample, with a TextField control.
>
> Jose Pereda has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add new line at the end of the file

Marked as reviewed by aghaisas (Reviewer).

-

PR: https://git.openjdk.java.net/jfx/pull/231

Re: [Integrated] RFR: 8234876: Unit test classes should not extend Application

[Ambarish Rapte]

On Tue, 26 May 2020 11:12:25 GMT, Ambarish Rapte  wrote:

> Copied from JBS:
> As a best practice, unit test classes that are run by Junit should not extend 
> javafx.application.Application.
> JUnit constructs an instance of a test class for each test method that it 
> runs. This will be different from the
> instance of the object that is constructed when Application.launch method is 
> called, and this can lead to unexpected
> behavior. Most of our tests use helper classes or nested (static) sub classes 
> of Application, but the following two
> test classes do not:  
> tests/system/src/test/java/test/com/sun/javafx/image/impl/ImageRaceTest.java
> tests/system/src/test/java/test/javafx/scene/control/AccordionTitlePaneLeakTest.java
> 
> 
> Changes in the tests are:
> ImageRaceTest.java->  Does not require a sub class of Application.
> AccordionTitlePaneLeakTest.java->  Required minor changes to create a static 
> sub class.

This pull request has now been integrated.

Changeset: 16f446a0
Author:Ambarish Rapte 
URL:   https://git.openjdk.java.net/jfx/commit/16f446a0
Stats: 51 lines in 2 files changed: 25 ins; 4 del; 22 mod

8234876: Unit test classes should not extend Application

Reviewed-by: kcr

-

PR: https://git.openjdk.java.net/jfx/pull/237

Re: RFR: 8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

[Kevin Rushforth]

On Tue, 26 May 2020 09:27:52 GMT, Arun Joseph  wrote:

> Cause: The test assumes that WebView/WebPage will be GCed right after 
> `System.gc()`
> 
> Fix: Use `runFinalization()` and `sleep()` to wait for objects to get GCed

Marked as reviewed by kcr (Lead).

-

PR: https://git.openjdk.java.net/jfx/pull/236

Re: RFR: 8234876: Unit test classes should not extend Application

[Kevin Rushforth]

On Tue, 26 May 2020 11:12:25 GMT, Ambarish Rapte  wrote:

> Copied from JBS:
> As a best practice, unit test classes that are run by Junit should not extend 
> javafx.application.Application.
> JUnit constructs an instance of a test class for each test method that it 
> runs. This will be different from the
> instance of the object that is constructed when Application.launch method is 
> called, and this can lead to unexpected
> behavior. Most of our tests use helper classes or nested (static) sub classes 
> of Application, but the following two
> test classes do not:  
> tests/system/src/test/java/test/com/sun/javafx/image/impl/ImageRaceTest.java
> tests/system/src/test/java/test/javafx/scene/control/AccordionTitlePaneLeakTest.java
> 
> 
> Changes in the tests are:
> ImageRaceTest.java->  Does not require a sub class of Application.
> AccordionTitlePaneLeakTest.java->  Required minor changes to create a static 
> sub class.

Marked as reviewed by kcr (Lead).

-

PR: https://git.openjdk.java.net/jfx/pull/237

Re: [Rev 01] RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts

[Kevin Rushforth]

On Wed, 13 May 2020 08:46:11 GMT, Rony G. Flatscher 
 wrote:

>> This WIP adds the ability for a fallback in case compilation of scripts 
>> fails, in which case a warning gets issued
>> about this fact and evaluation of the script will be done without 
>> compilation. Because of the fallback scripts get
>> compiled with this version by default. It extends PR 187 
>> .  To further ease
>> spotting scripts that cause a ScriptException a message in the form of 
>> "filename: caused ScriptException" gets added to
>> the exception handling in either of the three locations: an error message, a 
>> stack trace or a wrap-up into a
>> RuntimeException (having three different kinds of reporting ScriptExceptions 
>> may be questioned, however none of these
>> tear down the FXML GUI).
>
> Rony G. Flatscher has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Reword the compile processing instructions (replace 'Hint' with 'Note:', 
> adjust text to context), remove spurious empty
>   line in script example code.

Here are a couple overall comments.

1. Please update the Description of this PR now that this is no longer WIP. 
Also, can you copy any relevant information
from PR #187 so that this PR is standalone (reviewers shouldn't have to go to 
the earlier PRs for any information)?

2. The text you provided for the CSR is a good start, so I created a Draft CSR,
[JDK-8245873](https://bugs.openjdk.java.net/browse/JDK-8245873), based on what 
you have. I'll have additional comments
later, but one thing I noticed that needs to be added is that the 
"Specification" section needs to list the diffs for
the public API docs in FXMLLoader and for the FXML intro.

I also left some inline comments below. I haven't done a code review yet 
because I want to get the API documentation
and CSR in shape first.

modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html
 line 723:

> 722: ObservableList,  class="code">ObservableMap or  class="code">ObservableSet 723:  uses a special  class="code">onChange attribute that points to a
> handler method with a ListChangeListener.Change, 
>  class="code">MapChangeListener.Change or  class="code">SetChangeListener.Change parameter
> respectively. 724: 

Please revert this change since it is unrelated. Especially in this case where 
it is public API docs that will be noted
in the CSR, this will seem out of place. I filed JDK-n to track and 
accumulate these sort of typos.

modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1924:

> 1923:  */
> 1924: public static final String COMPILE_PROCESSING_INSTRUCTION = 
> "compile";
> 1925:

You need to add an `@since 15` javadoc tag for this new public field.

modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html
 line 775:

> 774:
> 775: Note: to turn off automatic compilation of script code place the 
> processing instruction  class="code"> before the script element. To 
> turn on compilation of script code again use
> the processing instruction  
> (or short:  class="code">). The compile processing instruction 
> can be used repeatedly to turn compilation
> of script code off and on. 776:

I would start by saying that scripts are compiled by default if the script 
engine implements `javax.script.Compilable`.
Maybe add a sentence something like this:

Scripts are compiled by default, when they are first loaded, if the 
`ScriptEngine` implements the
`javax.script.Compilable` interface. If compilation fails, the `FXMLLoader` 
will fall back to interpreted mode.

-

PR: https://git.openjdk.java.net/jfx/pull/192

Re: RFR: 8242523: Update the animation and clip envelope classes

[Kevin Rushforth]

On Fri, 24 Apr 2020 00:58:30 GMT, Nir Lisker  wrote:

> Mostly refactoring in preparation of the upcoming fixes. The changes might 
> look like a lot, but it's mostly rearranging
> of methods. Summery of changes:
> ### Animation
> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` 
> checks.
> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
> * Added `runHandler` method to deal with running the handler.
> * Moved methods to be grouped closer to where they are used rather than by 
> visibility.
> * Removed the static import for `TickCalculation`.
> * Various small subjective readability changes.
> * Behavioral changes: switching `autoReverse` and `onFinished` properties 
> from "Simple" to "Base" properties; and lazily
>   initializing the `cuePoints` map.
> 
> ### Clip Envelopes
> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and 
> finite clip envelopes.
> * Rearranged methods order to be consistent.
> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
> * Renamed `pos` to `cyclePos`.
> * Extracted common methods: `changedDirection` and `ticksRateChange`
> * Added internal documentation.
> 
> Also corrected a typo in `TicksCalculation` and added an explanation for an 
> animation test.

The code changes look fine except for one thing I noticed (see below), which 
might lead to an unintended side effect.
Also, I had one suggestion for a javadoc comment block.

modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 332:

> 331: }
> 332: if (isNearZero(newRate)) {
> 333: if (isRunning()) {

The code from here to the end of the method used to be in an `else` block of 
the `if (isRunningEmbedded())` test. It
will now be run even if that test is true. Was this intended, and if so, why?

modules/javafx.graphics/src/main/java/javafx/animation/Animation.java line 402:

> 401:  */
> 402: private void doSetCurrentRate(double value) {
> 403: if (currentRate != null || !areNearEqual(value, 
> DEFAULT_CURRENT_RATE)) {

The above javadoc comment block appears after the javadoc comments for the 
private `currentRate` property variable and
before the public get/property methods for `currentRate`. This seems fragile 
(although the API docs pick up the right
one), so I recommend making this an ordinary block comment (i.e., `/*` rather 
than `/**`). Either that or move it below
the get/property methods (and add `@param value`).

-

PR: https://git.openjdk.java.net/jfx/pull/196

Re: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLL

[Kevin Rushforth]

This is waiting on me. I need to review the updated API docs and CSR 
test, and then create a draft CSR issue.


-- Kevin


On 5/23/2020 11:30 AM, Rony G Flatscher wrote:

Hi Kevin,

is there anything I need to do? What are the next steps I should look for?

—-rony

Rony G. Flatscher (mobil/e)


Am 12.05.2020 um 19:23 schrieb Rony G. Flatscher :

Hi Kevin,

in the meantime I have tried to come up with a formulation for the "Introduction to 
FXML"
specification about the new compile processing instruction which is brief and 
complete. While being
there I fixed a typo in the document and added a missing language processing 
instruction to an
existing script example, hope that was o.k. as I have not filed an explicit bug 
for it.

Also closed the PR 129 and 187, removed the WIP from PR 192, and supplied the 
CSR draft as a comment.

If there is anything else I should do, please let me know.

Cheers,

---rony



On 11.05.2020 14:12, Rony G. Flatscher wrote:
Hi Kevin,


On 09.05.2020 17:16, Kevin Rushforth wrote:
I'm finally getting back to this. I took a look at 
https://github.com/openjdk/jfx/pull/192 and I
like that as the direction for this enhancement.

The initial CSR you have is a good start.

Thank you!


Next steps are:

1. Update the "Introduction to FXML" specification (see my comment in the PR)
2. Update PR 192 with the draft CSR as a comment, modifying it to include the 
above additions to
"Introduction to FXML"
3. Remove WIP from the title

You can then close the other two PRs (129 and 187).

will do (may take a little bit).

Cheers

---rony



On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:

Hi Kevin,

what should be the next steps?

Should I remove "WIP" from the title in 
 and add the CSR
draft text of my last e-mail as a "CSR" comment with PR # 192, thereby 
requesting it to be added
to ?

Please advise.

TIA,

---rony

P.S.: This is the RFE:

  * RFE (2020-01-24): 


These are the three versions (all with appropriate unit tests) that I came up 
with
chronologically to implement the RFE, would prefer the latest version (PR # 
192):

  * Compile if Compilable implemented (2020-02-28): 

  * Compile if compile PI and Compilable is implemented (2020-04-11):

  * Compile with fallback, if Compilable is implemented, compile PI for 
fine-grained control
(2020-04-14): 


On 22.04.2020 20:01, Rony G. Flatscher wrote:

Hi Kevin,

as I am not able to file a CSR with the issue you suggested to come up with a 
draft, so here it goes:

Summary
===
Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, if 
the script engine
implements the javax.script.Compilable interface to speed up execution. In 
case compilation
throws a javax.script.ScriptException fall back to evaluating the 
uncompiled script. Allow
control of script compilation with a "compile" PI for FXML files.

Problem
===
javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
(javax.script.ScriptEngine implementations) referred to or embedded in a 
FXML file.

If a script engine implements the javax.script.Compilable interface, then 
such scripts could be
compiled and the resulting javax.script.CompiledScript could be executed 
instead using its
eval() methods.

Evaluating the javax.script.CompiledScript objects may help speed up the 
execution of script
invocations, especially for scripts defined for event attributes in FXML 
elements (e.g. like
onMouseMove) which may be repetitively invoked and evaluated.

Solution

Before evaluating the script code test whether the 
javax.script.ScriptEngine implements
javax.script.Compilable. If so, compile the script to a 
javax.script.CompiledScript object first
and then use its eval() method to evaluate the script, otherwise continue 
to use the
javax.script.ScriptEngine's eval() method instead. Should compilation of a 
script yield
(unexpectedly) a javax.script.ScriptException then fall back to using the
javax.script.ScriptEngine's eval() method. A new process instruction 
"compile" allows control of
the compilation of scripts ("true" sets compilation on, "false" to set 
compilation off) in FXML
files.

Specification
=
If a javax.script.ScriptEngine implements the javax.script.Compilable 
interface, then use its
compile() method to compile the script to a javax.script.CompiledScript 
object and use its
eval() method to run the script. In the case that the compilation throws 
(unexpectedly) a
javax.script.ScriptException log a warning and fall back to using the
javax.script.ScriptEngine's eval() method instead.
  

Re: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes

[Kevin Rushforth]

On Mon, 13 Apr 2020 18:56:36 GMT, Johan Vos  wrote:

>> The root cause for this issue is not the unnecessary logging, but the fact 
>> that the Quantum Renderer keeps running when
>> the app is not in the foreground (causing a long list of debug lines). I'll 
>> create a separate issue for that.
>
> It would be nice to show this debug info when javafx.pulseLogger is true, and 
> hide it when that property is false. It
> shows interesting information about the rendering phase, so when that info is 
> requested (by enabling pulseLogger), it
> is useful.

@jperedadnr I think this is pending an answer to @johanvos comment. Also, he 
should review it, so I set the number of
reviewers to 2.

-

PR: https://git.openjdk.java.net/jfx/pull/165

Re: [Rev 01] RFR: 8245499: Text input controls should show handles on iOS

[Jose Pereda]

On Tue, 26 May 2020 11:42:46 GMT, Ajit Ghaisas  wrote:

>> Jose Pereda has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Add new line at the end of the file
>
> modules/javafx.controls/src/ios/resources/com/sun/javafx/scene/control/skin/caspian/ios.css
>  line 58:
> 
>> 57: -fx-pref-height: 12;
>> 58: }
> 
> No newline at end of file.

Fixed

> modules/javafx.controls/src/ios/resources/com/sun/javafx/scene/control/skin/modena/ios.css
>  line 58:
> 
>> 57: -fx-pref-height: 12;
>> 58: }
> 
> No newline at end of file.

Fixed

-

PR: https://git.openjdk.java.net/jfx/pull/231

Re: RFR: 8245499: Text input controls should show handles on iOS

[Jose Pereda]

On Tue, 26 May 2020 11:46:54 GMT, Ajit Ghaisas  wrote:

>> Since this touches shared code, I'd like @aghaisas to look at this.
>
> Code changes look OK.
> I think, we need a note in PR description about what testing you have done 
> with this fix.

I've edited the PR description with details of the tests I've done.

-

PR: https://git.openjdk.java.net/jfx/pull/231

Re: [Rev 01] RFR: 8245499: Text input controls should show handles on iOS

[Jose Pereda]

> After JDK-8242167, a JavaFX control is used for text input on iOS instead of 
> the native control, on a touch enabled
> device. However, selection handles are not enabled and currently text 
> selection is not possible at all.
> This PR enables handles on iOS as in the rest of the platforms with touch 
> support.
> 
> It also tries to accommodate its style to the native style for handles, where 
> selection handles have a circle shape and
> are a little bit bigger, and there is no caret handle.

Jose Pereda has updated the pull request incrementally with one additional 
commit since the last revision:

  Add new line at the end of the file

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/231/files
  - new: https://git.openjdk.java.net/jfx/pull/231/files/4933c7d4..fc681a1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/231/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/231/webrev.00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/231.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/231/head:pull/231

PR: https://git.openjdk.java.net/jfx/pull/231

Re: Font rendering issue on macOS - cut off characters

[John Neffenger]

On 5/25/20 11:47 AM, Philip Race wrote:

Mmm .. it can't be the same bug even if the effect is similar.
We don't use freetype on macOS, that's for Linux.


Right. I meant the same visible bug (severe color fringes).


Can you check your display's settings ?


I'm using a Dell UltraSharp U2715H 27-inch monitor (2560 × 1440 px at 
109 ppi) on a Mac mini. The monitor's on-screen display shows "Input 
Color Format: RGB".


In any case, so far I've seen these color fringes only in JavaFX 
applications on my Mac.



Isn't everyone seeing it just when they move to catalina ?


The color fringes may have shown up when macOS switched to grayscale 
anti-aliasing in macOS 10.14 Mojave. [1]


Does anyone have two Macs available for testing on both 10.13 High 
Sierra (with subpixel rendering) and 10.15 Catalina (without)?


You might also want to check what color profile is set in System 
settings -> Display -> Color.


That shows DELL U2715H as my active display profile.

John

[1] See the short section on "Font antialiasing refinements" at 28:03 in 
this video from Apple WWDC 2018:

https://developer.apple.com/videos/play/wwdc2018/209/?time=1683

RFR: 8244657: ChoiceBox/ToolBarSkin: misbehavior on switching skin

[Jeanette Winzenburg]

Both skins have similar misbehavior when switching skins

- memory leak due to a manually added but not removed change listener
- NPE when modifying items after skin switch due to a not removed listener to 
the control's items

Fixed in both (for details see the issue). Added SkinCleanupTest for simple 
testing of per-control side-effects,
removed both skins from memory test exclusion list: failing before and passing 
after fix.

-

Commit messages:
 - 8244657: ChoiceBox/ToolBarSkin: misbehavior on switching skin

Changes: https://git.openjdk.java.net/jfx/pull/238/files
 Webrev: https://webrevs.openjdk.java.net/jfx/238/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244657
  Stats: 158 lines in 4 files changed: 150 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/238.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/238/head:pull/238

PR: https://git.openjdk.java.net/jfx/pull/238

Re: RFR: 8245499: Text input controls should show handles on iOS

[Ajit Ghaisas]

On Thu, 21 May 2020 17:41:02 GMT, Jose Pereda  wrote:

> After JDK-8242167, a JavaFX control is used for text input on iOS instead of 
> the native control, on a touch enabled
> device. However, selection handles are not enabled and currently text 
> selection is not possible at all.
> This PR enables handles on iOS as in the rest of the platforms with touch 
> support.
> 
> It also tries to accommodate its style to the native style for handles, where 
> selection handles have a circle shape and
> are a little bit bigger, and there is no caret handle.

modules/javafx.controls/src/ios/resources/com/sun/javafx/scene/control/skin/caspian/ios.css
 line 58:

> 57: -fx-pref-height: 12;
> 58: }

No newline at end of file.

modules/javafx.controls/src/ios/resources/com/sun/javafx/scene/control/skin/modena/ios.css
 line 58:

> 57: -fx-pref-height: 12;
> 58: }

No newline at end of file.

-

PR: https://git.openjdk.java.net/jfx/pull/231

Re: RFR: 8245499: Text input controls should show handles on iOS

[Ajit Ghaisas]

On Thu, 21 May 2020 18:11:59 GMT, Kevin Rushforth  wrote:

>> After JDK-8242167, a JavaFX control is used for text input on iOS instead of 
>> the native control, on a touch enabled
>> device. However, selection handles are not enabled and currently text 
>> selection is not possible at all.
>> This PR enables handles on iOS as in the rest of the platforms with touch 
>> support.
>> 
>> It also tries to accommodate its style to the native style for handles, 
>> where selection handles have a circle shape and
>> are a little bit bigger, and there is no caret handle.
>
> Since this touches shared code, I'd like @aghaisas to look at this.

Code changes look OK.
I think, we need a note in PR description about what testing you have done with 
this fix.

-

PR: https://git.openjdk.java.net/jfx/pull/231

Re: RFR: 8242523: Update the animation and clip envelope classes

[Nir Lisker]

On Mon, 11 May 2020 04:44:27 GMT, Ambarish Rapte  wrote:

>> Mostly refactoring in preparation of the upcoming fixes. The changes might 
>> look like a lot, but it's mostly rearranging
>> of methods. Summery of changes:
>> ### Animation
>> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` 
>> checks.
>> * Added `isStopped`, `isRunning` and `isPaused` convenience methods.
>> * Added `runHandler` method to deal with running the handler.
>> * Moved methods to be grouped closer to where they are used rather than by 
>> visibility.
>> * Removed the static import for `TickCalculation`.
>> * Various small subjective readability changes.
>> * Behavioral changes: switching `autoReverse` and `onFinished` properties 
>> from "Simple" to "Base" properties; and lazily
>>   initializing the `cuePoints` map.
>> 
>> ### Clip Envelopes
>> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and 
>> finite clip envelopes.
>> * Rearranged methods order to be consistent.
>> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`.
>> * Renamed `pos` to `cyclePos`.
>> * Extracted common methods: `changedDirection` and `ticksRateChange`
>> * Added internal documentation.
>> 
>> Also corrected a typo in `TicksCalculation` and added an explanation for an 
>> animation test.
>
> Overall looks good to me, Added few minor comments.

@kevinrushforth Do you have any other comments?

-

PR: https://git.openjdk.java.net/jfx/pull/196

RFR: 8234876: Unit test classes should not extend Application

[Ambarish Rapte]

Copied from JBS:
As a best practice, unit test classes that are run by Junit should not extend 
javafx.application.Application.
JUnit constructs an instance of a test class for each test method that it runs. 
This will be different from the
instance of the object that is constructed when Application.launch method is 
called, and this can lead to unexpected
behavior. Most of our tests use helper classes or nested (static) sub classes 
of Application, but the following two
test classes do not:

tests/system/src/test/java/test/com/sun/javafx/image/impl/ImageRaceTest.java
tests/system/src/test/java/test/javafx/scene/control/AccordionTitlePaneLeakTest.java


Changes in the tests are:
ImageRaceTest.java->  Does not require a sub class of Application.
AccordionTitlePaneLeakTest.java->  Required minor changes to create a static 
sub class.

-

Commit messages:
 - 8234876: Unit test classes should not extend Application

Changes: https://git.openjdk.java.net/jfx/pull/237/files
 Webrev: https://webrevs.openjdk.java.net/jfx/237/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234876
  Stats: 51 lines in 2 files changed: 4 ins; 25 del; 22 mod
  Patch: https://git.openjdk.java.net/jfx/pull/237.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/237/head:pull/237

PR: https://git.openjdk.java.net/jfx/pull/237

RFR: 8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

[Arun Joseph]

Cause: The test assumes that WebView/WebPage will be GCed right after 
`System.gc()`

Fix: Use `runFinalization()` and `sleep()` to wait for objects to get GCed

-

Commit messages:
 - Update copyright year
 - Remove unwanted line
 - 8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

Changes: https://git.openjdk.java.net/jfx/pull/236/files
 Webrev: https://webrevs.openjdk.java.net/jfx/236/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234540
  Stats: 33 lines in 1 file changed: 7 ins; 15 del; 11 mod
  Patch: https://git.openjdk.java.net/jfx/pull/236.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/236/head:pull/236

PR: https://git.openjdk.java.net/jfx/pull/236