From jvos at openjdk.java.net  Sun Dec  1 16:31:39 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Sun, 1 Dec 2019 16:31:39 GMT
Subject: RFR: 8235150: IosApplication does not pass the required object in
 _leaveNestedEventLoopImpl
In-Reply-To: <uJk8VqCR6Ch2m2AffaqnXWfaPdwrnu2h0bDMlshbLmM=.6307a231-f596-448e-8b33-c33d77e0930a@github.com>
References: <uJk8VqCR6Ch2m2AffaqnXWfaPdwrnu2h0bDMlshbLmM=.6307a231-f596-448e-8b33-c33d77e0930a@github.com>
Message-ID: <nEEkBJXSH47KnYSoxmnMPqm26XKp7Rv_yDdq7X9mtXE=.4700de12-fe16-4055-979d-f528a4322c96@github.com>

On Sat, 30 Nov 2019 18:23:07 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> In `GlassApplication.m` for iOS, the method
> `Java_com_sun_glass_ui_ios_IosApplication__1leaveNestedEventLoopImpl` has signature `(Ljava/lang/Object;)V`, however in `IosApplication.java`, `_leaveNestedEventLoopImpl()` signature doesn't match that.
> 
> This PR fixes this.
> 
> ----------------
> 
> Commits:
>  - e5fc04a9: Use correct signature in _leaveNestedEventLoopImpl
> 
> Changes: https://git.openjdk.java.net/jfx/pull/57/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/57/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8235150
>   Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/57.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/57/head:pull/57

Looks like a trivial fix to me.
It only impacts the iOS platform.

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

From jvos at openjdk.java.net  Sun Dec  1 16:32:41 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Sun, 1 Dec 2019 16:32:41 GMT
Subject: [Approved] RFR: 8235151: Inexistent notifyQuit method referred
 from iOS GlassHelper.m
In-Reply-To: <bw7I8YqqwjHyRSlNZ_Bi7B6MOMR6MbG9b4xwAiHitQI=.2f6f62b0-25e5-4d65-ab54-d86cc23ebda8@github.com>
References: <bw7I8YqqwjHyRSlNZ_Bi7B6MOMR6MbG9b4xwAiHitQI=.2f6f62b0-25e5-4d65-ab54-d86cc23ebda8@github.com>
Message-ID: <JCoB1KpbdsJcinTk5z5Tl68vnC5Rr6RIO_zmw8N3iRI=.17bf2a24-c3aa-46e9-b23d-fede181d09af@github.com>

On Sat, 30 Nov 2019 22:31:29 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> `GlassHelper.m` for iOS contains the public method `ApplicationNotifyQuitMethod()`, that tries to find via reflection the `notifyQuit()` method in the `com.sun.glass.ui.Application` class. 
> 
> But the method `notifyQuit` doesn't exist in that class. However `notifyWillQuit` exists, and it is used in the Mac platform, for instance, when `ApplicationNotifyWillQuitMethod()` is called.
> 
> This PR renames `notifyQuit` to `notifyWillQuit`, and therefore `ApplicationNotifyQuitMethod` is also renamed to `ApplicationNotifyWillQuitMethod`.
> 
> ----------------
> 
> Commits:
>  - 0fe426ab: Rename notifyQuit and ApplicationNotifyQuitMethod to notifyWillQuit and ApplicationNotifyWillQuitMethod
> 
> Changes: https://git.openjdk.java.net/jfx/pull/58/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/58/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8235151
>   Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/58.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/58/head:pull/58

Looks like a trivial fix to me, that only impacts files specific to iOS.

----------------

Approved by jvos (Reviewer).

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

From tsayao at openjdk.java.net  Mon Dec  2 11:09:20 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Mon, 2 Dec 2019 11:09:20 GMT
Subject: RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <fhY-j1ZziMV1Ozi9a5wp6bpECydwxdRA8NbQnGYkVHE=.3ed28189-f765-47fe-9745-26d4640865f4@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <WHeu0iFuPN8qHCyxHAdn2MAc3ZeEAS01_To7CluV1ho=.a134587b-1a77-4928-b213-b0aca1cc32f7@github.com>
 <SNC1IdvQgKGx-eBg5C2691cRcApNnZH5D_rPVStbKAU=.45a242e1-940d-4983-9d4f-9a75b6b55952@github.com>
 <NkFJa_BRX0vLBWjSLfCD4XzU-JGAjDTLnFkRG5ROY9g=.c7a684c8-7eec-4fb8-9630-085a360dbbbb@github.com>
 <fhY-j1ZziMV1Ozi9a5wp6bpECydwxdRA8NbQnGYkVHE=.3ed28189-f765-47fe-9745-26d4640865f4@github.com>
Message-ID: <p3ivxS3wnBT0E9RT0Hb_ZQPJmdGT6FDEf_OUTanjWC0=.962bb7e1-a13e-47d8-80ce-5cdf0a6b174d@github.com>

On Fri, 4 Oct 2019 23:03:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> On Wed, 2 Oct 2019 20:02:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
> 
>> On Wed, 2 Oct 2019 19:54:50 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:
>> 
>>> On Wed, 2 Oct 2019 19:54:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>>> 
>>>> On Wed, 2 Oct 2019 19:54:48 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:
>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8225571
>>>>> 
>>>>> To run tests (on the root of the source tree):
>>>>> ./gradlew apps
>>>>> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
>>>>> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
>>>>> 
>>>>> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
>>>>> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
>>>>> 
>>>>> ----------------
>>>>> 
>>>>> Commits:
>>>>>  - 3d650b2b: Gtk DND port for Linux
>>>>> 
>>>>> Changes: https://git.openjdk.java.net/jfx/pull/4/files
>>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/4/webrev.00
>>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8225571
>>>>>   Stats: 669 lines in 5 files changed: 81 ins; 442 del; 146 mod
>>>>>   Patch: https://git.openjdk.java.net/jfx/pull/4.diff
>>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/4/head:pull/4
>>>> 
>>>> @tsayao In your case `/covered` isn't what's needed. You have an OpenJDK ID so should do this instead:
>>>> 
>>>>> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user tsayao" as summary for the issue.
>>> 
>>> Yes, noticed that while reading the comment again. I have opened an issue. Thanks.
>> 
>> @pankaj-bansal can you review this as well?
> 
> Preliminary review was here: [javafxports/openjdk-jfx/pull/490](https://github.com/javafxports/openjdk-jfx/pull/490)

Just a reminder to take a look when time allows.

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

From arapte at openjdk.java.net  Mon Dec  2 12:13:39 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 2 Dec 2019 12:13:39 GMT
Subject: [Rev 01] RFR: 8212034: Potential memory leaks in jpegLoader.c in
 error case
In-Reply-To: <aTPbmeanY2V9d_Ga8WpkdsEfq7gT81eoYwKEEpxcpXM=.49df1afb-b005-4a13-8410-62e8c49e7cf4@github.com>
References: <aTPbmeanY2V9d_Ga8WpkdsEfq7gT81eoYwKEEpxcpXM=.49df1afb-b005-4a13-8410-62e8c49e7cf4@github.com>
Message-ID: <wEqQWHXahiCsIiNw_S8MYL1kNzmmH_ILn6Wjatx-mdQ=.3803decc-379d-406d-af85-0758082048cc@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - 8a48080a: correcting use of scanline_ptr

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/54/files
  - new: https://git.openjdk.java.net/jfx/pull/54/files/7af932b7..8a48080a

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

  Issue: https://bugs.openjdk.java.net/browse/JDK-8212034
  Stats: 23 lines in 1 file changed: 9 ins; 13 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/54.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/54/head:pull/54

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

From arapte at openjdk.java.net  Mon Dec  2 12:14:21 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 2 Dec 2019 12:14:21 GMT
Subject: RFR: 8212034: Potential memory leaks in jpegLoader.c in error case
In-Reply-To: <pQswEpPP10RpSjdbZ75FfrpfL8AJjTBO_EToCztmVgg=.e69e31aa-1dd5-4b04-b0b1-826950f2829b@github.com>
References: <aTPbmeanY2V9d_Ga8WpkdsEfq7gT81eoYwKEEpxcpXM=.49df1afb-b005-4a13-8410-62e8c49e7cf4@github.com>
 <pQswEpPP10RpSjdbZ75FfrpfL8AJjTBO_EToCztmVgg=.e69e31aa-1dd5-4b04-b0b1-826950f2829b@github.com>
Message-ID: <4Aw5l-7-Nb_RuCq_YeJmU3bq36dvbtuR1ynqAqe1GR4=.f1782f57-5773-4530-9d5d-e44ffe999fc8@github.com>

On Thu, 28 Nov 2019 11:12:42 GMT, Arunprasad Rajkumar <arajkumar at openjdk.org> wrote:

> On Wed, 27 Nov 2019 11:58:18 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
> 
>> Memory allocated in initDecompressor() and decompressIndirect() is not freed in error case.
>> In error case,
>> 1. Allocated memory should be freed.
>> 2. Appropriate de-initialization jpeg library calls should be added.
>> 
>> Verified that,
>> 1. All unit and systems tests pass on three platforms, and
>> 2. Memory consumption with and without fix is similar by comparing memory before and after showing 10 jpeg images for 100 times.
>> 
>> ----------------
>> 
>> Commits:
>>  - 7af932b7: 8212034: Memory leaks in jpegLoader.c in error case
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/54/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/54/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8212034
>>   Stats: 62 lines in 1 file changed: 36 ins; 14 del; 12 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/54.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/54/head:pull/54
> 
> modules/javafx.graphics/src/main/native-iio/jpegloader.c line 1625:
> 
>> 1624: 
>> 1625:     JSAMPROW scanline_ptr = (JSAMPROW) malloc(bytes_per_row * sizeof (JSAMPLE));
>> 1626:     if (scanline_ptr == NULL) {
> 
> You can remove quite a few calls to `free` if you move the memory allocation for `scanline_ptr` just [before it's usage](https://github.com/openjdk/jfx/blob/7af932b7f5215949776ec79fb2a5484c521b21a1/modules/javafx.graphics/src/main/native-iio/jpegloader.c#L1690). Also free it as soon as you are done with it.

PR is updated according to this comment, please have a look.

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

From arapte at openjdk.java.net  Mon Dec  2 14:49:50 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 2 Dec 2019 14:49:50 GMT
Subject: RFR: 8212034: Potential memory leaks in jpegLoader.c in error case
In-Reply-To: <4Aw5l-7-Nb_RuCq_YeJmU3bq36dvbtuR1ynqAqe1GR4=.f1782f57-5773-4530-9d5d-e44ffe999fc8@github.com>
References: <aTPbmeanY2V9d_Ga8WpkdsEfq7gT81eoYwKEEpxcpXM=.49df1afb-b005-4a13-8410-62e8c49e7cf4@github.com>
 <pQswEpPP10RpSjdbZ75FfrpfL8AJjTBO_EToCztmVgg=.e69e31aa-1dd5-4b04-b0b1-826950f2829b@github.com>
 <4Aw5l-7-Nb_RuCq_YeJmU3bq36dvbtuR1ynqAqe1GR4=.f1782f57-5773-4530-9d5d-e44ffe999fc8@github.com>
Message-ID: <n05dxIlA7kuW4L0CbZVybekXrOQSSRxa1RAP_PLjaVs=.6cd2a154-9a8e-4792-8f83-808400c1db92@github.com>

On Mon, 2 Dec 2019 12:14:21 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> On Thu, 28 Nov 2019 11:12:42 GMT, Arunprasad Rajkumar <arajkumar at openjdk.org> wrote:
> 
>> On Wed, 27 Nov 2019 11:58:18 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
>> 
>>> Memory allocated in initDecompressor() and decompressIndirect() is not freed in error case.
>>> In error case,
>>> 1. Allocated memory should be freed.
>>> 2. Appropriate de-initialization jpeg library calls should be added.
>>> 
>>> Verified that,
>>> 1. All unit and systems tests pass on three platforms, and
>>> 2. Memory consumption with and without fix is similar by comparing memory before and after showing 10 jpeg images for 100 times.
>>> 
>>> ----------------
>>> 
>>> Commits:
>>>  - 7af932b7: 8212034: Memory leaks in jpegLoader.c in error case
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/54/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/54/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8212034
>>>   Stats: 62 lines in 1 file changed: 36 ins; 14 del; 12 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/54.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/54/head:pull/54
>> 
>> modules/javafx.graphics/src/main/native-iio/jpegloader.c line 1625:
>> 
>>> 1624: 
>>> 1625:     JSAMPROW scanline_ptr = (JSAMPROW) malloc(bytes_per_row * sizeof (JSAMPLE));
>>> 1626:     if (scanline_ptr == NULL) {
>> 
>> You can remove quite a few calls to `free` if you move the memory allocation for `scanline_ptr` just [before it's usage](https://github.com/openjdk/jfx/blob/7af932b7f5215949776ec79fb2a5484c521b21a1/modules/javafx.graphics/src/main/native-iio/jpegloader.c#L1690). Also free it as soon as you are done with it.
> 
> PR is updated according to this comment, please have a look.

> In general, this makes sense. I need to look into more detail that the additional calls for freeing resources (in case of errors) don't cause e.g. segmentation violations and lead to a crash -- which would be worse than throwing an Exception.

The native code throws two Exceptions in case of error, 
1. OutOfMemory : This would exit the application.
2. IOException: There is no action on this exception for now. Only callstack is printed when -Dprism.verbose=true.

> I expect memory consumption to be similar before and after this patch if you don't run into errors, but did you check memory consumption before/after this patch in case of errors?
I verified this now, by changing native code to always throw an exception from different error cases. The memory is freed correctly and remains in same range for any number of images,

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

From arapte at openjdk.java.net  Mon Dec  2 15:03:45 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 2 Dec 2019 15:03:45 GMT
Subject: [Rev 01] RFR: 8196587: Remove use of deprecated finalize method
 from JPEGImageLoader
In-Reply-To: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
References: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
Message-ID: <c2Cbkibuh-J58WA42dEXOglq9WVApx0l87v0wnzFAL4=.d891e1a2-a553-428a-8056-df1be47e07bf@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - 3ba659f0: update the catch block

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/50/files
  - new: https://git.openjdk.java.net/jfx/pull/50/files/b48c8087..3ba659f0

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

  Issue: https://bugs.openjdk.java.net/browse/JDK-8196587
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/50.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/50/head:pull/50

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

From arapte at openjdk.java.net  Mon Dec  2 15:03:47 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 2 Dec 2019 15:03:47 GMT
Subject: RFR: 8196587: Remove use of deprecated finalize method from
 JPEGImageLoader
In-Reply-To: <on63OZdi5s4XwGo2VmD-l_ricIZhuQo7FRf08SAUPqU=.86d2c495-6d0b-4587-b8b3-fcadd2559df0@github.com>
References: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
 <on63OZdi5s4XwGo2VmD-l_ricIZhuQo7FRf08SAUPqU=.86d2c495-6d0b-4587-b8b3-fcadd2559df0@github.com>
Message-ID: <Ld0QEkQ__QoBHMB2NTCGTiwpj4oce6111BZhY_uNPqM=.24723215-35c5-4323-af63-67f26ecb514a@github.com>

On Tue, 26 Nov 2019 15:16:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> On Tue, 26 Nov 2019 15:16:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
> 
>> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
>> And so the JPEGImageLoader.finalize() method should be removed.
>> 
>> The change is,
>> 1. Remove finalize method from JPEGImageLoader class.
>> 
>> 2. Instance of JPEGImageLoader is created and used in ImageStorage class. JPEGImageLoader.dispose() should be called after it's use over. This would be a common call for the other (GIF, PNG, BMP) ImageLoader classes, which have empty dispose() method.
>> 
>> 3. JPEGImageLoader.load() method almost always calls the dispose() method after the image is loaded. In normal scenario JPEGImageLoader is disposed here. The calls to dispose() added in ImageStorage seem logically correct place to add and should be added.
>> 
>> Verification:
>> Verified :graphics:test and system tests on all three platforms.
>> Verified that JPEGImageLoader.dispose() is always initiated by JPEGImageLoader.load()
>> 
>> ----------------
>> 
>> Commits:
>>  - b48c8087: 8196587: Remove use of deprecated finalize method from JPEGImageLoader
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/50/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/50/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8196587
>>   Stats: 28 lines in 2 files changed: 14 ins; 12 del; 2 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/50.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/50/head:pull/50
> 
> I still need to double-check all calls to dispose, but I think this is essentially the right solution, and is ready to be submitted for review. I added one comment inline.
> 
> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 273:
> 
>> 272:             } else {
>> 273:                 throw new ImageStorageException("No loader for image data");
>> 274:             }
> 
> Now that this is moved inside a try/catch, this `ImageStorageException` will get wrapped in another `ImageStorageException` if it is ever thrown. You probably want to catch `ImageStorageException` below and re-throw it without wrapping it.

Updated the catch statement.

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

From kcr at openjdk.java.net  Mon Dec  2 15:36:43 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 2 Dec 2019 15:36:43 GMT
Subject: [Integrated] RFR: 8232064: Switch FX build to use JDK 13.0.1 as
 boot JDK
In-Reply-To: <JZ0Pl1wKJlLw4yd7KfzdRU2ks4-oYB020j3QaCiEjcg=.fb31ba95-4b6b-4d09-b6ad-73dad62e4a17@github.com>
References: <JZ0Pl1wKJlLw4yd7KfzdRU2ks4-oYB020j3QaCiEjcg=.fb31ba95-4b6b-4d09-b6ad-73dad62e4a17@github.com>
Message-ID: <eff280ee-209b-4c22-8cf6-b56e8e5e34ad@openjdk.org>

Changeset: 6892fa1b
Author:    Kevin Rushforth <kcr at openjdk.org>
Date:      2019-12-02 15:36:17 +0000
URL:       https://git.openjdk.java.net/jfx/commit/6892fa1b

8232064: Switch FX build to use JDK 13.0.1 as boot JDK

Reviewed-by: prr, jvos

! build.properties

From kcr at openjdk.java.net  Mon Dec  2 19:28:45 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 2 Dec 2019 19:28:45 GMT
Subject: [Approved] RFR: 8211308: Support HTTP/2 in WebView
In-Reply-To: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com>
References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com>
 <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com>
Message-ID: <v5ZSZvD0-0CuW1kwsMmN2Pz0rZBQKU6nCeZgIMgG5YI=.31a4e1ff-2eb2-4405-a3cf-7d7634382b73@github.com>

On Wed, 16 Oct 2019 17:57:58 GMT, Arunprasad Rajkumar <arajkumar at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - 1832c2db: Incorporate fixes provided by @kcr
> 
> Changes:
>   - all: https://git.openjdk.java.net/jfx/pull/14/files
>   - new: https://git.openjdk.java.net/jfx/pull/14/files/1798a661..1832c2db
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jfx/14/webrev.01
>  - incr: https://webrevs.openjdk.java.net/jfx/14/webrev.00-01
> 
>   Stats: 13 lines in 2 files changed: 5 ins; 0 del; 8 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/14.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/14/head:pull/14

Approved by kcr (Lead).

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

From kcr at openjdk.java.net  Mon Dec  2 20:36:20 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 2 Dec 2019 20:36:20 GMT
Subject: RFR: 8196587: Remove use of deprecated finalize method from
 JPEGImageLoader
In-Reply-To: <Ld0QEkQ__QoBHMB2NTCGTiwpj4oce6111BZhY_uNPqM=.24723215-35c5-4323-af63-67f26ecb514a@github.com>
References: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
 <on63OZdi5s4XwGo2VmD-l_ricIZhuQo7FRf08SAUPqU=.86d2c495-6d0b-4587-b8b3-fcadd2559df0@github.com>
 <Ld0QEkQ__QoBHMB2NTCGTiwpj4oce6111BZhY_uNPqM=.24723215-35c5-4323-af63-67f26ecb514a@github.com>
Message-ID: <ChGmYRXbE164LvbebezL26bel6wQ4Ks3QWPQb8G7v_U=.b3a77575-d2db-43a4-9e63-db663ac21b26@github.com>

On Mon, 2 Dec 2019 15:03:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> On Tue, 26 Nov 2019 15:16:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
> 
>> On Tue, 26 Nov 2019 15:16:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
>> 
>>> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
>>> And so the JPEGImageLoader.finalize() method should be removed.
>>> 
>>> The change is,
>>> 1. Remove finalize method from JPEGImageLoader class.
>>> 
>>> 2. Instance of JPEGImageLoader is created and used in ImageStorage class. JPEGImageLoader.dispose() should be called after it's use over. This would be a common call for the other (GIF, PNG, BMP) ImageLoader classes, which have empty dispose() method.
>>> 
>>> 3. JPEGImageLoader.load() method almost always calls the dispose() method after the image is loaded. In normal scenario JPEGImageLoader is disposed here. The calls to dispose() added in ImageStorage seem logically correct place to add and should be added.
>>> 
>>> Verification:
>>> Verified :graphics:test and system tests on all three platforms.
>>> Verified that JPEGImageLoader.dispose() is always initiated by JPEGImageLoader.load()
>>> 
>>> ----------------
>>> 
>>> Commits:
>>>  - b48c8087: 8196587: Remove use of deprecated finalize method from JPEGImageLoader
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/50/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/50/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8196587
>>>   Stats: 28 lines in 2 files changed: 14 ins; 12 del; 2 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/50.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/50/head:pull/50
>> 
>> I still need to double-check all calls to dispose, but I think this is essentially the right solution, and is ready to be submitted for review. I added one comment inline.
>> 
>> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 273:
>> 
>>> 272:             } else {
>>> 273:                 throw new ImageStorageException("No loader for image data");
>>> 274:             }
>> 
>> Now that this is moved inside a try/catch, this `ImageStorageException` will get wrapped in another `ImageStorageException` if it is ever thrown. You probably want to catch `ImageStorageException` below and re-throw it without wrapping it.
> 
> Updated the catch statement.

There is one more ImageLoader implementation class that still has a finalize method: [IosImageLoader.java(https://github.com/openjdk/jfx/blob/3ba659f0eb52496adb54a2b2c313e8da832e8389/modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ios/IosImageLoader.java#L215).

That method should also be removed, but @johanvos should confirm.

The rest looks fine to me.

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

From kcr at openjdk.java.net  Mon Dec  2 20:40:09 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 2 Dec 2019 20:40:09 GMT
Subject: RFR: 8196587: Remove use of deprecated finalize method from
 JPEGImageLoader
In-Reply-To: <ChGmYRXbE164LvbebezL26bel6wQ4Ks3QWPQb8G7v_U=.b3a77575-d2db-43a4-9e63-db663ac21b26@github.com>
References: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
 <on63OZdi5s4XwGo2VmD-l_ricIZhuQo7FRf08SAUPqU=.86d2c495-6d0b-4587-b8b3-fcadd2559df0@github.com>
 <Ld0QEkQ__QoBHMB2NTCGTiwpj4oce6111BZhY_uNPqM=.24723215-35c5-4323-af63-67f26ecb514a@github.com>
 <ChGmYRXbE164LvbebezL26bel6wQ4Ks3QWPQb8G7v_U=.b3a77575-d2db-43a4-9e63-db663ac21b26@github.com>
Message-ID: <mqWk-xzRuzNwdtQy4gwA0l0byl03lKE_21e9WXZIWWY=.4de02c38-92c4-4e17-9169-960bd552f5ba@github.com>

On Mon, 2 Dec 2019 20:36:20 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> On Mon, 2 Dec 2019 15:03:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
> 
>> On Tue, 26 Nov 2019 15:16:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>> 
>>> On Tue, 26 Nov 2019 15:16:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
>>> 
>>>> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
>>>> And so the JPEGImageLoader.finalize() method should be removed.
>>>> 
>>>> The change is,
>>>> 1. Remove finalize method from JPEGImageLoader class.
>>>> 
>>>> 2. Instance of JPEGImageLoader is created and used in ImageStorage class. JPEGImageLoader.dispose() should be called after it's use over. This would be a common call for the other (GIF, PNG, BMP) ImageLoader classes, which have empty dispose() method.
>>>> 
>>>> 3. JPEGImageLoader.load() method almost always calls the dispose() method after the image is loaded. In normal scenario JPEGImageLoader is disposed here. The calls to dispose() added in ImageStorage seem logically correct place to add and should be added.
>>>> 
>>>> Verification:
>>>> Verified :graphics:test and system tests on all three platforms.
>>>> Verified that JPEGImageLoader.dispose() is always initiated by JPEGImageLoader.load()
>>>> 
>>>> ----------------
>>>> 
>>>> Commits:
>>>>  - b48c8087: 8196587: Remove use of deprecated finalize method from JPEGImageLoader
>>>> 
>>>> Changes: https://git.openjdk.java.net/jfx/pull/50/files
>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/50/webrev.00
>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8196587
>>>>   Stats: 28 lines in 2 files changed: 14 ins; 12 del; 2 mod
>>>>   Patch: https://git.openjdk.java.net/jfx/pull/50.diff
>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/50/head:pull/50
>>> 
>>> I still need to double-check all calls to dispose, but I think this is essentially the right solution, and is ready to be submitted for review. I added one comment inline.
>>> 
>>> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 273:
>>> 
>>>> 272:             } else {
>>>> 273:                 throw new ImageStorageException("No loader for image data");
>>>> 274:             }
>>> 
>>> Now that this is moved inside a try/catch, this `ImageStorageException` will get wrapped in another `ImageStorageException` if it is ever thrown. You probably want to catch `ImageStorageException` below and re-throw it without wrapping it.
>> 
>> Updated the catch statement.
> 
> There is one more ImageLoader implementation class that still has a finalize method: [IosImageLoader.java(https://github.com/openjdk/jfx/blob/3ba659f0eb52496adb54a2b2c313e8da832e8389/modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ios/IosImageLoader.java#L215).
> 
> That method should also be removed, but @johanvos should confirm.
> 
> The rest looks fine to me.

This will need two reviewers anyway, so I tagged @johanvos to review as well.

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

From arapte at openjdk.java.net  Tue Dec  3 05:08:49 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 3 Dec 2019 05:08:49 GMT
Subject: RFR: 8232524: SynchronizedObservableMap cannot be be protected
 for copying/iterating
In-Reply-To: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
References: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
Message-ID: <g2pD-etRavCgoySEbJP2KrueHZD3pVkbv-bmr1UQDkE=.beac4c1c-9a19-470e-9b10-db66c8b2a991@github.com>

On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> By using the collection itself as synchronization lock we achieve behaviour that matches java.util.Collections classes.
> 
> I've create test cases that fail with the current way of synchronizing on a separate object.
> 
> I've removed unused constructors.
> 
> ----------------
> 
> Commits:
>  - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating
>  - 8ecf3545: JDK-8232524 fixed.
> 
> Changes: https://git.openjdk.java.net/jfx/pull/17/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232524
>   Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/17.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17

The change looks good to me, added a comment for a small change in test.

modules/javafx.base/src/test/java/test/javafx/collections/FXCollectionsTest.java line 730:

> 729:             } catch (ConcurrentModificationException e) {
> 730:                 fail("ConcurrentModificationException should not be thrown");
> 731:             }

The thread should be terminated here too, please add `thread.terminate();` before `fail()`

----------------

Changes requested by arapte (Reviewer).

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

From arajkumar at openjdk.java.net  Tue Dec  3 08:24:42 2019
From: arajkumar at openjdk.java.net (Arunprasad Rajkumar)
Date: Tue, 3 Dec 2019 08:24:42 GMT
Subject: [Integrated] RFR: 8211308: Support HTTP/2 in WebView
In-Reply-To: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com>
References: <-QIo4TUv5geTX_U95KMB6hg3MKjk9GnxyvFplJd5fms=.c78624c1-59b7-4a0d-857f-bb8dcd6ff11f@github.com>
Message-ID: <31a93848-c2fe-429d-8b5f-3dcbb67cb8f2@openjdk.org>

Changeset: 98035cb2
Author:    Arunprasad Rajkumar <arajkumar at openjdk.org>
Date:      2019-12-03 08:24:01 +0000
URL:       https://git.openjdk.java.net/jfx/commit/98035cb2

8211308: Support HTTP/2 in WebView

Reviewed-by: ghb, kcr

! modules/javafx.web/src/main/java/com/sun/webkit/network/ByteBufferPool.java
+ modules/javafx.web/src/main/java/com/sun/webkit/network/HTTP2Loader.java
! modules/javafx.web/src/main/java/com/sun/webkit/network/NetworkContext.java
! modules/javafx.web/src/main/java/com/sun/webkit/network/URLLoader.java
+ modules/javafx.web/src/main/java/com/sun/webkit/network/URLLoaderBase.java
! modules/javafx.web/src/main/java/module-info.java
! modules/javafx.web/src/main/native/Source/WebCore/mapfile-macosx
! modules/javafx.web/src/main/native/Source/WebCore/mapfile-vers
! modules/javafx.web/src/main/native/Source/WebCore/platform/java/IDNJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceHandle.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/ResourceHandleInternal.h
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/java/ResourceHandleJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/java/URLLoader.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/java/URLLoader.h

From thevenet.fred at free.fr  Tue Dec  3 15:11:27 2019
From: thevenet.fred at free.fr (thevenet.fred at free.fr)
Date: Tue, 3 Dec 2019 16:11:27 +0100 (CET)
Subject: Blank stages when running JavaFX app in a macOS virtual machine
In-Reply-To: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
References: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
Message-ID: <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>

Hello,

When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.

This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.

The problematic code is located at #96 in GlassView3D.m:

095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
096: if ((err == kCGLNoError) && (npix == 0))
097: {
098:   const CGLPixelFormatAttribute attributes2[] =
099:   {
100:     kCGLPFAAllowOfflineRenderers,
101:     (CGLPixelFormatAttribute)0
102:   };
103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
104: }


In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)

>From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html

I have verified that this change produces the expected behavior and I propose to submit a PR with this change (I have already signed the OCA)

A quick question before I do, however; should I file a new issue prior to submitting a PR or is it better that someone with privileges reopens JDK-8154148?

Regards,

Frederic Thevenet

From kevin.rushforth at oracle.com  Tue Dec  3 17:35:49 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 3 Dec 2019 09:35:49 -0800
Subject: Blank stages when running JavaFX app in a macOS virtual machine
In-Reply-To: <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
References: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
 <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
Message-ID: <df8e0306-897a-2d1e-8ed5-210aa93f8df1@oracle.com>

A new follow-on bug ID will be needed. We never reopen a JBS issue once 
it has been resolved as fixed by a changeset that has been pushed.

-- Kevin


On 12/3/2019 7:11 AM, thevenet.fred at free.fr wrote:
> Hello,
>
> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
>
> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
>
> The problematic code is located at #96 in GlassView3D.m:
>
> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
> 096: if ((err == kCGLNoError) && (npix == 0))
> 097: {
> 098:   const CGLPixelFormatAttribute attributes2[] =
> 099:   {
> 100:     kCGLPFAAllowOfflineRenderers,
> 101:     (CGLPixelFormatAttribute)0
> 102:   };
> 103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
> 104: }
>
>
> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>
>  From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
>
> I have verified that this change produces the expected behavior and I propose to submit a PR with this change (I have already signed the OCA)
>
> A quick question before I do, however; should I file a new issue prior to submitting a PR or is it better that someone with privileges reopens JDK-8154148?
>
> Regards,
>
> Frederic Thevenet


From thevenet.fred at free.fr  Tue Dec  3 17:46:57 2019
From: thevenet.fred at free.fr (thevenet.fred at free.fr)
Date: Tue, 3 Dec 2019 18:46:57 +0100 (CET)
Subject: Blank stages when running JavaFX app in a macOS virtual machine
In-Reply-To: <df8e0306-897a-2d1e-8ed5-210aa93f8df1@oracle.com>
References: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
 <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
 <df8e0306-897a-2d1e-8ed5-210aa93f8df1@oracle.com>
Message-ID: <2117685452.1579744887.1575395217009.JavaMail.zimbra@free.fr>

Ok thanks, will do that.

Regards,
Frederic Thevenet

----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
Envoy?: Mardi 3 D?cembre 2019 18:35:49
Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine

A new follow-on bug ID will be needed. We never reopen a JBS issue once 
it has been resolved as fixed by a changeset that has been pushed.

-- Kevin


On 12/3/2019 7:11 AM, thevenet.fred at free.fr wrote:
> Hello,
>
> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
>
> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
>
> The problematic code is located at #96 in GlassView3D.m:
>
> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
> 096: if ((err == kCGLNoError) && (npix == 0))
> 097: {
> 098:   const CGLPixelFormatAttribute attributes2[] =
> 099:   {
> 100:     kCGLPFAAllowOfflineRenderers,
> 101:     (CGLPixelFormatAttribute)0
> 102:   };
> 103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
> 104: }
>
>
> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>
>  From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
>
> I have verified that this change produces the expected behavior and I propose to submit a PR with this change (I have already signed the OCA)
>
> A quick question before I do, however; should I file a new issue prior to submitting a PR or is it better that someone with privileges reopens JDK-8154148?
>
> Regards,
>
> Frederic Thevenet

From Sergey.Bylokhov at oracle.com  Tue Dec  3 20:20:28 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 3 Dec 2019 12:20:28 -0800
Subject: Blank stages when running JavaFX app in a macOS virtual machine
In-Reply-To: <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
References: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
 <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
Message-ID: <c4881bc2-ef7d-7400-3022-899a4b1b840b@oracle.com>

Just curious what attribute caused the first request to fail.

Is it related to kCGLPFAAccelerated or XXXSize?

87             kCGLPFAAccelerated,
88             kCGLPFAColorSize, 32,
89             kCGLPFAAlphaSize, 8,
90             kCGLPFADepthSize, depth,
91         kCGLPFAAllowOfflineRenderers, // lets OpenGL know this context is offline renderer aware
92             (CGLPixelFormatAttribute)0


On 12/3/19 7:11 am, thevenet.fred at free.fr wrote:
> Hello,
> 
> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
> 
> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
> 
> The problematic code is located at #96 in GlassView3D.m:
> 
> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
> 096: if ((err == kCGLNoError) && (npix == 0))
> 097: {
> 098:   const CGLPixelFormatAttribute attributes2[] =
> 099:   {
> 100:     kCGLPFAAllowOfflineRenderers,
> 101:     (CGLPixelFormatAttribute)0
> 102:   };
> 103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
> 104: }
> 
> 
> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
> 
>  From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
> 
> I have verified that this change produces the expected behavior and I propose to submit a PR with this change (I have already signed the OCA)
> 
> A quick question before I do, however; should I file a new issue prior to submitting a PR or is it better that someone with privileges reopens JDK-8154148?
> 
> Regards,
> 
> Frederic Thevenet
> 


-- 
Best regards, Sergey.

From kcr at openjdk.java.net  Tue Dec  3 22:23:34 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 3 Dec 2019 22:23:34 GMT
Subject: RFR: WIP: 8231372: Correctly terminate secondary event loop in
 JFXPanel.setScene()
In-Reply-To: <OQxKpaF2kGA0qVxCvjpDI0nSkS_XNRn8NFqUpRSN-64=.70ed9c4b-5d05-4f7c-9a31-b9b06245b827@github.com>
References: <rT9S-dTBgnVycBj0mqrE1nAlPWTmSQolJigDPliClQY=.606a34f8-9609-4c39-bb48-b81221b7461f@github.com>
 <0YJvd4XIwHfRAuOVa3jtcjFVOhDVvaq94-fi6HKRKqY=.42af4fb5-cc1b-42eb-9fad-b9409971a9ca@github.com>
 <GGU561uh3ZbTqc0TY3IZYVRGtNz1BY463de5xed8gb0=.fa37d9a7-eba8-4d69-940e-e848817b08f1@github.com>
 <WQMiTRw6pK5COEW_w9ZOS_whMF9v1fCtAHOyYVDKS1Q=.0049519c-fe23-4241-8652-9b7fc6ab5bf5@github.com>
 <OQxKpaF2kGA0qVxCvjpDI0nSkS_XNRn8NFqUpRSN-64=.70ed9c4b-5d05-4f7c-9a31-b9b06245b827@github.com>
Message-ID: <yOf-zX9bT24Kfd8fjN-QUNnpvTvtnIAiFZi6X0AfCRs=.37078f6f-4438-4f4d-b9d0-182a4d0003f0@github.com>

On Wed, 13 Nov 2019 20:00:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> On Mon, 21 Oct 2019 22:52:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
> 
>> On Thu, 17 Oct 2019 15:28:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>> 
>>> On Thu, 17 Oct 2019 15:28:30 GMT, mruzicka <github.com+562920+mruzicka at openjdk.org> wrote:
>>> 
>>>> On Thu, 17 Oct 2019 15:28:28 GMT, mruzicka <github.com+562920+mruzicka at openjdk.org> wrote:
>>>> 
>>>>> Secondary event loop introduced as a means of synchronization with the JavaFX Application thread in [1] never terminates as the SecondaryLoop.exit() call is not reached because the thread is blocked in the SecondaryLoop.enter() call.
>>>>> This patch fixes the problem by submitting the UI work (including the call to the SecondaryLoop.exit() method) before entering the secondary loop.
>>>>> 
>>>>> [1] https://github.com/openjdk/jfx/commit/7cf2dfa0b3c5bfd0f1a2de36d46b62f7e9e256c4
>>>>> 
>>>>> ----------------
>>>>> 
>>>>> Commits:
>>>>>  - 9483ccde: 8231372: Correctly terminate secondary event loop in JFXPanel.setScene()
>>>>> 
>>>>> Changes: https://git.openjdk.java.net/jfx/pull/16/files
>>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/16/webrev.00
>>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8231372
>>>>>   Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod
>>>>>   Patch: https://git.openjdk.java.net/jfx/pull/16.diff
>>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/16/head:pull/16
>>>> 
>>>> @kevinrushforth I believe you should be able to move forward with the review of this PR now as I've filed a bug report for the problem and signed the OCA as required. (As I did not know I needed to have my github account associated with the OCA, I did not include it in my details. I've asked Dalibor Topic from the Java SE PM team to help me have that fixed or get in touch with you to confirm my signing of the OCA.)
>>> 
>>> @mruzicka once Dalibor connects your OCA with your GitHub account, this review will be able to proceed.
>> 
>> Do you have a test program that shows the bug?
>> 
>> Also, can you take a look at whether you could turn the test case into an automated test?
> 
> @mruzicka - are you interested in moving this forward? If so, there is a pending request for a test case that needs to be answered before the review can proceed.

Marking as WIP pending a test case to reproduce it. If you are still interested in pursuing this, please let us know.

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

From kcr at openjdk.java.net  Tue Dec  3 22:30:00 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 3 Dec 2019 22:30:00 GMT
Subject: RFR: 8235150: IosApplication does not pass the required object in
 _leaveNestedEventLoopImpl
In-Reply-To: <nEEkBJXSH47KnYSoxmnMPqm26XKp7Rv_yDdq7X9mtXE=.4700de12-fe16-4055-979d-f528a4322c96@github.com>
References: <uJk8VqCR6Ch2m2AffaqnXWfaPdwrnu2h0bDMlshbLmM=.6307a231-f596-448e-8b33-c33d77e0930a@github.com>
 <nEEkBJXSH47KnYSoxmnMPqm26XKp7Rv_yDdq7X9mtXE=.4700de12-fe16-4055-979d-f528a4322c96@github.com>
Message-ID: <St3mf1LRkntsKexLyDoDvIxkxHcT5kzr384ddx7YaqE=.48af85f7-d8f2-44f3-b360-b6c3e6477654@github.com>

On Sun, 1 Dec 2019 16:31:39 GMT, Johan Vos <jvos at openjdk.org> wrote:

> On Sat, 30 Nov 2019 18:23:07 GMT, Jose Pereda <jpereda at openjdk.org> wrote:
> 
>> In `GlassApplication.m` for iOS, the method
>> `Java_com_sun_glass_ui_ios_IosApplication__1leaveNestedEventLoopImpl` has signature `(Ljava/lang/Object;)V`, however in `IosApplication.java`, `_leaveNestedEventLoopImpl()` signature doesn't match that.
>> 
>> This PR fixes this.
>> 
>> ----------------
>> 
>> Commits:
>>  - e5fc04a9: Use correct signature in _leaveNestedEventLoopImpl
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/57/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/57/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8235150
>>   Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/57.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/57/head:pull/57
> 
> Looks like a trivial fix to me.
> It only impacts the iOS platform.

Yes, this looks like a simple, and correct fix. A single reviewer will be sufficient.

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

From thevenet.fred at free.fr  Wed Dec  4 07:21:35 2019
From: thevenet.fred at free.fr (Frederic Thevenet)
Date: Wed, 4 Dec 2019 08:21:35 +0100
Subject: Blank stages when running JavaFX app in a macOS virtual machine
In-Reply-To: <c4881bc2-ef7d-7400-3022-899a4b1b840b@oracle.com>
References: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
 <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
 <c4881bc2-ef7d-7400-3022-899a4b1b840b@oracle.com>
Message-ID: <004f01d5aa73$7842eab0$68c8c010$@free.fr>

In this precise case, it is kCGLPFAAccelerated

Regards
Frederic Thevenet

-----Original Message-----
From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] 
Sent: 03 December 2019 21:20
To: thevenet.fred at free.fr; openjfx-dev <openjfx-dev at openjdk.java.net>
Subject: Re: Blank stages when running JavaFX app in a macOS virtual machine

Just curious what attribute caused the first request to fail.

Is it related to kCGLPFAAccelerated or XXXSize?

87             kCGLPFAAccelerated,
88             kCGLPFAColorSize, 32,
89             kCGLPFAAlphaSize, 8,
90             kCGLPFADepthSize, depth,
91         kCGLPFAAllowOfflineRenderers, // lets OpenGL know this context is offline renderer aware
92             (CGLPixelFormatAttribute)0


On 12/3/19 7:11 am, thevenet.fred at free.fr wrote:
> Hello,
> 
> When running a JavaFX application in macOS guest VM, the main stage is 
> completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002 This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
> 
> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
> 
> The problematic code is located at #96 in GlassView3D.m:
> 
> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
> 096: if ((err == kCGLNoError) && (npix == 0))
> 097: {
> 098:   const CGLPixelFormatAttribute attributes2[] =
> 099:   {
> 100:     kCGLPFAAllowOfflineRenderers,
> 101:     (CGLPixelFormatAttribute)0
> 102:   };
> 103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
> 104: }
> 
> 
> In a comment in JDK-8154148, the following claim is made: "[...] an 
> error happens is when something bad or invalid has occurred. An 
> unsatisfied pixel format request is indicated by npix is 0 and pix is 
> NULL. Hence I feel it is a cleaner and clearer logic to request a 
> different format when npix is 0 and err is kCGLNoError." 
> (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=139
> 80465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-t
> abpanel#comment-13980465)
> 
>  From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
> This is further supported by a sample in Apple developer's 
> documentation on how to choose a pixel format: 
> https://developer.apple.com/library/archive/documentation/GraphicsImag
> ing/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelfor
> mats.html
> 
> I have verified that this change produces the expected behavior and I 
> propose to submit a PR with this change (I have already signed the 
> OCA)
> 
> A quick question before I do, however; should I file a new issue prior to submitting a PR or is it better that someone with privileges reopens JDK-8154148?
> 
> Regards,
> 
> Frederic Thevenet
> 


--
Best regards, Sergey.


From jvos at openjdk.java.net  Wed Dec  4 12:18:42 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 4 Dec 2019 12:18:42 GMT
Subject: [Integrated] RFR: 8235151: Inexistent notifyQuit method referred
 from iOS GlassHelper.m
In-Reply-To: <bw7I8YqqwjHyRSlNZ_Bi7B6MOMR6MbG9b4xwAiHitQI=.2f6f62b0-25e5-4d65-ab54-d86cc23ebda8@github.com>
References: <bw7I8YqqwjHyRSlNZ_Bi7B6MOMR6MbG9b4xwAiHitQI=.2f6f62b0-25e5-4d65-ab54-d86cc23ebda8@github.com>
Message-ID: <129956f2-8347-41a0-8f02-d49d80cddf8f@openjdk.org>

Changeset: 2d4096a8
Author:    Jose Pereda <jpereda at openjdk.org>
Committer: Johan Vos <jvos at openjdk.org>
Date:      2019-12-04 12:17:44 +0000
URL:       https://git.openjdk.java.net/jfx/commit/2d4096a8

8235151: Nonexistent notifyQuit method referred from iOS GlassHelper.m

Reviewed-by: jvos

! modules/javafx.graphics/src/main/native-glass/ios/GlassApplication.m
! modules/javafx.graphics/src/main/native-glass/ios/GlassHelper.h
! modules/javafx.graphics/src/main/native-glass/ios/GlassHelper.m

From jvos at openjdk.java.net  Wed Dec  4 12:21:01 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 4 Dec 2019 12:21:01 GMT
Subject: [Approved] RFR: 8235150: IosApplication does not pass the
 required object in _leaveNestedEventLoopImpl
In-Reply-To: <uJk8VqCR6Ch2m2AffaqnXWfaPdwrnu2h0bDMlshbLmM=.6307a231-f596-448e-8b33-c33d77e0930a@github.com>
References: <uJk8VqCR6Ch2m2AffaqnXWfaPdwrnu2h0bDMlshbLmM=.6307a231-f596-448e-8b33-c33d77e0930a@github.com>
Message-ID: <E_gS4JrwQVSLd0RSwWpkk0Vq8oRrI0Te-eELLyY8pJk=.dd5fe231-e043-445b-99f1-ff5adcd9563f@github.com>

On Sat, 30 Nov 2019 18:23:07 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> In `GlassApplication.m` for iOS, the method
> `Java_com_sun_glass_ui_ios_IosApplication__1leaveNestedEventLoopImpl` has signature `(Ljava/lang/Object;)V`, however in `IosApplication.java`, `_leaveNestedEventLoopImpl()` signature doesn't match that.
> 
> This PR fixes this.
> 
> ----------------
> 
> Commits:
>  - e5fc04a9: Use correct signature in _leaveNestedEventLoopImpl
> 
> Changes: https://git.openjdk.java.net/jfx/pull/57/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/57/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8235150
>   Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/57.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/57/head:pull/57

Approved by jvos (Reviewer).

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

From ajoseph at openjdk.java.net  Wed Dec  4 14:07:27 2019
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Wed, 4 Dec 2019 14:07:27 GMT
Subject: [Rev 02] RFR: 8233747: JVM crash in
 com.sun.webkit.dom.DocumentImpl.createAttribute
In-Reply-To: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
References: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
Message-ID: <jz3yKLz-FPFP07TuCLo1wCz3a-lf-zpZ6IaaPV9GEQQ=.5d8d515c-5e50-4257-89d9-4c3b0f569ae1@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - 7f6ed5bf: Added test for createAttribute

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/47/files
  - new: https://git.openjdk.java.net/jfx/pull/47/files/2bd56c11..7f6ed5bf

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/47/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/47/webrev.01-02

  Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
  Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47

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

From rlichten at openjdk.java.net  Wed Dec  4 14:50:19 2019
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 4 Dec 2019 14:50:19 GMT
Subject: [Rev 01] RFR: 8232524: SynchronizedObservableMap cannot be be
 protected for copying/iterating
In-Reply-To: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
References: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
Message-ID: <HuJCjph_ThJkg2grAhUpOMepGo3uLv81XA2-964bkRw=.b9dc44a8-23ed-4286-984c-dc29d5c6296d@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - 7c5cf198: 8232524: Test cleanup: terminate background thread upon failure.

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/17/files
  - new: https://git.openjdk.java.net/jfx/pull/17/files/7e80839f..7c5cf198

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

  Issue: https://bugs.openjdk.java.net/browse/JDK-8232524
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/17.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17

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

From rlichten at openjdk.java.net  Wed Dec  4 14:50:21 2019
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 4 Dec 2019 14:50:21 GMT
Subject: RFR: 8232524: SynchronizedObservableMap cannot be be protected
 for copying/iterating
In-Reply-To: <g2pD-etRavCgoySEbJP2KrueHZD3pVkbv-bmr1UQDkE=.beac4c1c-9a19-470e-9b10-db66c8b2a991@github.com>
References: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
 <g2pD-etRavCgoySEbJP2KrueHZD3pVkbv-bmr1UQDkE=.beac4c1c-9a19-470e-9b10-db66c8b2a991@github.com>
Message-ID: <eQ2MG8HapwgchzEgKHreNbDVDuaxlz6QvA4cg4ug1iU=.c44fc691-01c5-451d-a535-47bdc96d0491@github.com>

On Tue, 3 Dec 2019 05:08:49 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:
> 
>> By using the collection itself as synchronization lock we achieve behaviour that matches java.util.Collections classes.
>> 
>> I've create test cases that fail with the current way of synchronizing on a separate object.
>> 
>> I've removed unused constructors.
>> 
>> ----------------
>> 
>> Commits:
>>  - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating
>>  - 8ecf3545: JDK-8232524 fixed.
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/17/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232524
>>   Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/17.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17
> 
> The change looks good to me, added a comment for a small change in test.
> 
> modules/javafx.base/src/test/java/test/javafx/collections/FXCollectionsTest.java line 730:
> 
>> 729:             } catch (ConcurrentModificationException e) {
>> 730:                 fail("ConcurrentModificationException should not be thrown");
>> 731:             }
> 
> The thread should be terminated here too, please add `thread.terminate();` before `fail()`
> 
> ----------------
> 
> Changes requested by arapte (Reviewer).

You're right. I just pushed the fix.

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

From kcr at openjdk.java.net  Wed Dec  4 15:29:10 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 4 Dec 2019 15:29:10 GMT
Subject: [Approved] RFR: 8232524: SynchronizedObservableMap cannot be be
 protected for copying/iterating
In-Reply-To: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
References: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
 <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
Message-ID: <E8ZtGw_8CSAV77oR7s2LN6u7sklKdF6VdLtDLQxwqMc=.b23529cf-e04a-40ed-9d42-7d5a1b2da0e9@github.com>

On Wed, 4 Dec 2019 14:50:19 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - 7c5cf198: 8232524: Test cleanup: terminate background thread upon failure.
> 
> Changes:
>   - all: https://git.openjdk.java.net/jfx/pull/17/files
>   - new: https://git.openjdk.java.net/jfx/pull/17/files/7e80839f..7c5cf198
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jfx/17/webrev.01
>  - incr: https://webrevs.openjdk.java.net/jfx/17/webrev.00-01
> 
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232524
>   Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/17.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17

Looks good. I can confirm that the new tests fail without the fix and pass with the fix.

----------------

Approved by kcr (Lead).

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

From kcr at openjdk.java.net  Wed Dec  4 15:29:50 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 4 Dec 2019 15:29:50 GMT
Subject: RFR: 8232524: SynchronizedObservableMap cannot be be protected
 for copying/iterating
In-Reply-To: <eQ2MG8HapwgchzEgKHreNbDVDuaxlz6QvA4cg4ug1iU=.c44fc691-01c5-451d-a535-47bdc96d0491@github.com>
References: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
 <g2pD-etRavCgoySEbJP2KrueHZD3pVkbv-bmr1UQDkE=.beac4c1c-9a19-470e-9b10-db66c8b2a991@github.com>
 <eQ2MG8HapwgchzEgKHreNbDVDuaxlz6QvA4cg4ug1iU=.c44fc691-01c5-451d-a535-47bdc96d0491@github.com>
Message-ID: <Aa-ThsCft87G_YGz7jo4-D--IkmXI2D_QysDQvaIBSY=.7f74331f-dc0d-449d-9253-6c795aae2a9c@github.com>

On Wed, 4 Dec 2019 14:50:21 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> On Tue, 3 Dec 2019 05:08:49 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
> 
>> On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:
>> 
>>> By using the collection itself as synchronization lock we achieve behaviour that matches java.util.Collections classes.
>>> 
>>> I've create test cases that fail with the current way of synchronizing on a separate object.
>>> 
>>> I've removed unused constructors.
>>> 
>>> ----------------
>>> 
>>> Commits:
>>>  - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating
>>>  - 8ecf3545: JDK-8232524 fixed.
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/17/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232524
>>>   Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/17.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17
>> 
>> The change looks good to me, added a comment for a small change in test.
>> 
>> modules/javafx.base/src/test/java/test/javafx/collections/FXCollectionsTest.java line 730:
>> 
>>> 729:             } catch (ConcurrentModificationException e) {
>>> 730:                 fail("ConcurrentModificationException should not be thrown");
>>> 731:             }
>> 
>> The thread should be terminated here too, please add `thread.terminate();` before `fail()`
>> 
>> ----------------
>> 
>> Changes requested by arapte (Reviewer).
> 
> You're right. I just pushed the fix.

Note that this is still pending a second review from @arapte

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

From kcr at openjdk.java.net  Wed Dec  4 15:38:21 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 4 Dec 2019 15:38:21 GMT
Subject: [Approved] RFR: 8210955: DOMTest::testEventListenerCascade fails
In-Reply-To: <WOxJAldiex-BB1AbQ7wa3n72B2D7_4xkcDwIZ_3Ax8A=.f605bf1c-163a-4ed8-a27e-22b1b94fd587@github.com>
References: <WOxJAldiex-BB1AbQ7wa3n72B2D7_4xkcDwIZ_3Ax8A=.f605bf1c-163a-4ed8-a27e-22b1b94fd587@github.com>
Message-ID: <fmNDDyclfkk-aXDVKiocSumOl00NqjhEsfnx6ZeETy4=.20dde807-cb1a-4cdd-97d9-e4349158c1be@github.com>

On Tue, 19 Nov 2019 07:11:40 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> Modified the test to work with WebView's ordering of capturing and bubbling event listeners.
> 
> ----------------
> 
> Commits:
>  - cbef0069: DOMTest::testEventListenerCascade fails
> 
> Changes: https://git.openjdk.java.net/jfx/pull/46/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/46/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8210955
>   Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/46.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/46/head:pull/46

Approved by kcr (Lead).

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

From fastegal at openjdk.java.net  Wed Dec  4 15:49:47 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 4 Dec 2019 15:49:47 GMT
Subject: RFR: 8220722: ProgressBarSkin: adds strong listener to control's
 width property
Message-ID: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>

fix for https://bugs.openjdk.java.net/browse/JDK-8220722

- replaces the manually registered listener with registerChangeListener(...)
- added test that's failing before and passing after the fix (plus a sanity test that the skin still is listening to changes)

----------------

Commits:
 - 9f4fc409: 8220722: ProgressBarSkin: adds strong listener to control's width
 - 61f7361d: 8235151: Nonexistent notifyQuit method referred from iOS GlassHelper.m

Changes: https://git.openjdk.java.net/jfx/pull/59/files
 Webrev: https://webrevs.openjdk.java.net/jfx/59/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8220722
  Stats: 102 lines in 5 files changed: 88 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jfx/pull/59.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/59/head:pull/59

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

From fastegal at openjdk.java.net  Wed Dec  4 15:51:42 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 4 Dec 2019 15:51:42 GMT
Subject: RFR: 8220722: ProgressBarSkin: adds strong listener to control's
 width property
In-Reply-To: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
References: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
Message-ID: <2ay1JM71PatoMNKoK_7GC4zWDEaEFWPCSkfGOOzyRJI=.70d75942-942c-4837-ac5a-0318bd621a82@github.com>

On Wed, 4 Dec 2019 15:49:47 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> fix for https://bugs.openjdk.java.net/browse/JDK-8220722
> 
> - replaces the manually registered listener with registerChangeListener(...)
> - added test that's failing before and passing after the fix (plus a sanity test that the skin still is listening to changes)
> 
> ----------------
> 
> Commits:
>  - 9f4fc409: 8220722: ProgressBarSkin: adds strong listener to control's width
>  - 61f7361d: 8235151: Nonexistent notifyQuit method referred from iOS GlassHelper.m
> 
> Changes: https://git.openjdk.java.net/jfx/pull/59/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/59/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8220722
>   Stats: 102 lines in 5 files changed: 88 ins; 0 del; 14 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/59.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/59/head:pull/59

hmm ... somehow my rebase went wrong, sry. Don't know what exactly, though: Jose's changes are already integrated, so why do they appear here again? *grrrr

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

From arapte at openjdk.java.net  Wed Dec  4 15:56:10 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 4 Dec 2019 15:56:10 GMT
Subject: [Approved] RFR: 8232524: SynchronizedObservableMap cannot be be
 protected for copying/iterating
In-Reply-To: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
References: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
 <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
Message-ID: <XX6L121qWmJVqSqojscY0fIxsJiLdENqsD8zYFMru34=.47cb6b2a-e3c6-497b-a3ae-37c45d656c4d@github.com>

On Wed, 4 Dec 2019 14:50:19 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - 7c5cf198: 8232524: Test cleanup: terminate background thread upon failure.
> 
> Changes:
>   - all: https://git.openjdk.java.net/jfx/pull/17/files
>   - new: https://git.openjdk.java.net/jfx/pull/17/files/7e80839f..7c5cf198
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jfx/17/webrev.01
>  - incr: https://webrevs.openjdk.java.net/jfx/17/webrev.00-01
> 
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232524
>   Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/17.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17

Looks good to me.

----------------

Approved by arapte (Reviewer).

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

From arapte at openjdk.java.net  Wed Dec  4 15:57:11 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 4 Dec 2019 15:57:11 GMT
Subject: [Approved] RFR: 8232524: SynchronizedObservableMap cannot be be
 protected for copying/iterating
In-Reply-To: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
References: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
 <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
Message-ID: <FIH5tJ11F7n_HMaRjDqzIvro3gnNsbEecHHlb5OnU50=.755a3b41-1551-4125-92c4-43d796dd4cad@github.com>

On Wed, 4 Dec 2019 14:50:19 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - 7c5cf198: 8232524: Test cleanup: terminate background thread upon failure.
> 
> Changes:
>   - all: https://git.openjdk.java.net/jfx/pull/17/files
>   - new: https://git.openjdk.java.net/jfx/pull/17/files/7e80839f..7c5cf198
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jfx/17/webrev.01
>  - incr: https://webrevs.openjdk.java.net/jfx/17/webrev.00-01
> 
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232524
>   Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/17.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17

Approved by arapte (Reviewer).

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

From kcr at openjdk.java.net  Wed Dec  4 16:37:42 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 4 Dec 2019 16:37:42 GMT
Subject: [Integrated] RFR: 8210955: DOMTest::testEventListenerCascade fails
In-Reply-To: <WOxJAldiex-BB1AbQ7wa3n72B2D7_4xkcDwIZ_3Ax8A=.f605bf1c-163a-4ed8-a27e-22b1b94fd587@github.com>
References: <WOxJAldiex-BB1AbQ7wa3n72B2D7_4xkcDwIZ_3Ax8A=.f605bf1c-163a-4ed8-a27e-22b1b94fd587@github.com>
Message-ID: <41ef8263-4e18-4f24-a5f7-971d486f3db6@openjdk.org>

Changeset: 1c27fbd2
Author:    Arun Joseph <ajoseph at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2019-12-04 16:36:40 +0000
URL:       https://git.openjdk.java.net/jfx/commit/1c27fbd2

8210955: DOMTest::testEventListenerCascade fails

Reviewed-by: kcr

! modules/javafx.web/src/test/java/test/javafx/scene/web/DOMTest.java

From kcr at openjdk.java.net  Wed Dec  4 16:44:40 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 4 Dec 2019 16:44:40 GMT
Subject: [Approved] RFR: 8233747: JVM crash in
 com.sun.webkit.dom.DocumentImpl.createAttribute
In-Reply-To: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
References: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
 <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
Message-ID: <VIyAQzbFNP_bO5OfgA0iyjuwZdEExPKRR0kyvtDm2fM=.bcdb7370-05a0-496a-a4b2-3aaacc30b76a@github.com>

On Wed, 4 Dec 2019 14:07:27 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - 7f6ed5bf: Added test for createAttribute
> 
> Changes:
>   - all: https://git.openjdk.java.net/jfx/pull/47/files
>   - new: https://git.openjdk.java.net/jfx/pull/47/files/2bd56c11..7f6ed5bf
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jfx/47/webrev.02
>  - incr: https://webrevs.openjdk.java.net/jfx/47/webrev.01-02
> 
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
>   Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/47.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47

I can confirm that this fixes the problem. The test case attached to the bug and the new unit test you added fail (crash) without your fix and throw the expected exception with your fix.

I don't quite understand your earlier comment about needing to change the caller when the type is `ExceptionOr<Ref<T>>`. The specific case in question is one where object passed to `raiseDOMError` is of type `ExceptionOr<Ref<Attr>>`, and your change works fine. What am I missing?

I added a comment about formatting (missing spaces around a `+` operator) in the test, but you can fix that before you integrate.

This will need a second reviewer, so I request @guruhb to review.

modules/javafx.web/src/test/java/test/javafx/scene/web/DOMTest.java line 431:

> 430:             } catch (Throwable ex) {
> 431:                 fail("DOMException expected but instead threw "+ex.getClass().getName());
> 432:             }

Minor: there should be spaces surrounding the `+` here.

----------------

Approved by kcr (Lead).

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

From kcr at openjdk.java.net  Wed Dec  4 16:54:41 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 4 Dec 2019 16:54:41 GMT
Subject: RFR: 8220722: ProgressBarSkin: adds strong listener to control's
 width property
In-Reply-To: <2ay1JM71PatoMNKoK_7GC4zWDEaEFWPCSkfGOOzyRJI=.70d75942-942c-4837-ac5a-0318bd621a82@github.com>
References: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
 <2ay1JM71PatoMNKoK_7GC4zWDEaEFWPCSkfGOOzyRJI=.70d75942-942c-4837-ac5a-0318bd621a82@github.com>
Message-ID: <pipIjr9BMqxRkwnY5uj6VGsBQSQL6kWMIoohlLyL-jQ=.953e7974-1cbf-4b7d-b51e-ad6333e2e49e@github.com>

On Wed, 4 Dec 2019 15:51:42 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> On Wed, 4 Dec 2019 15:49:47 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:
> 
>> fix for https://bugs.openjdk.java.net/browse/JDK-8220722
>> 
>> - replaces the manually registered listener with registerChangeListener(...)
>> - added test that's failing before and passing after the fix (plus a sanity test that the skin still is listening to changes)
>> 
>> ----------------
>> 
>> Commits:
>>  - 9f4fc409: 8220722: ProgressBarSkin: adds strong listener to control's width
>>  - 61f7361d: 8235151: Nonexistent notifyQuit method referred from iOS GlassHelper.m
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/59/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/59/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8220722
>>   Stats: 102 lines in 5 files changed: 88 ins; 0 del; 14 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/59.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/59/head:pull/59
> 
> hmm ... somehow my rebase went wrong, sry. Don't know what exactly, though: Jose's changes are already integrated, so why do they appear here again? *grrrr

Yeah, something odd with the way you did the rebase, I guess. The commit hashes are different between the commit for Jose's fix in your branch, and the one in the upstream jfx master. When you get a moment, you will need to fix it. Since the review hasn't started yet, the easiest is to rebase your local branch on top of the upstream/master and then do a force push.

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

From kcr at openjdk.java.net  Wed Dec  4 23:19:29 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 4 Dec 2019 23:19:29 GMT
Subject: RFR: 8232524: SynchronizedObservableMap cannot be be protected
 for copying/iterating
In-Reply-To: <Aa-ThsCft87G_YGz7jo4-D--IkmXI2D_QysDQvaIBSY=.7f74331f-dc0d-449d-9253-6c795aae2a9c@github.com>
References: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
 <g2pD-etRavCgoySEbJP2KrueHZD3pVkbv-bmr1UQDkE=.beac4c1c-9a19-470e-9b10-db66c8b2a991@github.com>
 <eQ2MG8HapwgchzEgKHreNbDVDuaxlz6QvA4cg4ug1iU=.c44fc691-01c5-451d-a535-47bdc96d0491@github.com>
 <Aa-ThsCft87G_YGz7jo4-D--IkmXI2D_QysDQvaIBSY=.7f74331f-dc0d-449d-9253-6c795aae2a9c@github.com>
Message-ID: <5g2tHig3OhbKMKuXTQCLcaEF_c5_nKkkxkVzNr1RReQ=.234bc6c2-457b-466e-98ad-786260317cf0@github.com>

On Wed, 4 Dec 2019 15:29:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> On Wed, 4 Dec 2019 14:50:21 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:
> 
>> On Tue, 3 Dec 2019 05:08:49 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
>> 
>>> On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:
>>> 
>>>> By using the collection itself as synchronization lock we achieve behaviour that matches java.util.Collections classes.
>>>> 
>>>> I've create test cases that fail with the current way of synchronizing on a separate object.
>>>> 
>>>> I've removed unused constructors.
>>>> 
>>>> ----------------
>>>> 
>>>> Commits:
>>>>  - 7e80839f: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating
>>>>  - 8ecf3545: JDK-8232524 fixed.
>>>> 
>>>> Changes: https://git.openjdk.java.net/jfx/pull/17/files
>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/17/webrev.00
>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8232524
>>>>   Stats: 120 lines in 2 files changed: 95 ins; 17 del; 8 mod
>>>>   Patch: https://git.openjdk.java.net/jfx/pull/17.diff
>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/17/head:pull/17
>>> 
>>> The change looks good to me, added a comment for a small change in test.
>>> 
>>> modules/javafx.base/src/test/java/test/javafx/collections/FXCollectionsTest.java line 730:
>>> 
>>>> 729:             } catch (ConcurrentModificationException e) {
>>>> 730:                 fail("ConcurrentModificationException should not be thrown");
>>>> 731:             }
>>> 
>>> The thread should be terminated here too, please add `thread.terminate();` before `fail()`
>>> 
>>> ----------------
>>> 
>>> Changes requested by arapte (Reviewer).
>> 
>> You're right. I just pushed the fix.
> 
> Note that this is still pending a second review from @arapte

@effad you can now integrate this whenever you are ready. I will sponsor it.

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

From ajoseph at openjdk.java.net  Thu Dec  5 05:15:39 2019
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Thu, 5 Dec 2019 05:15:39 GMT
Subject: [Rev 03] RFR: 8233747: JVM crash in
 com.sun.webkit.dom.DocumentImpl.createAttribute
In-Reply-To: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
References: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
Message-ID: <MfLOu2lsbdy9CShftgcn_jN4otCiYlJf2FKSS9oxxIU=.826ae8f4-bac7-4a62-b6c1-9d6bff9d42bc@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - 472d77cf: Added spaces

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/47/files
  - new: https://git.openjdk.java.net/jfx/pull/47/files/7f6ed5bf..472d77cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/47/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/47/webrev.02-03

  Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47

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

From ajoseph at openjdk.java.net  Thu Dec  5 05:42:10 2019
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Thu, 5 Dec 2019 05:42:10 GMT
Subject: RFR: 8233747: JVM crash in
 com.sun.webkit.dom.DocumentImpl.createAttribute
In-Reply-To: <2P1UiDuRSSNhGKHtiqYXdKwnD0vk71hHSq9B8DJafRI=.b404a52a-f3bd-4966-be7f-d515fba2b2c5@github.com>
References: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
 <K3Rxg2Qu1PbiPwQHf_df1EnytQjpd7MUnCOxIzX-mek=.331da377-9513-4cb5-ba23-c969f19255fe@github.com>
 <2P1UiDuRSSNhGKHtiqYXdKwnD0vk71hHSq9B8DJafRI=.b404a52a-f3bd-4966-be7f-d515fba2b2c5@github.com>
Message-ID: <5AdtS0I6MjGhlH8-WmlvqEhrsU0ATW4gKDbk4jTblfI=.60c0d57a-3f75-4ae4-9c6a-6c2b43506346@github.com>

On Thu, 28 Nov 2019 13:16:19 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> On Wed, 20 Nov 2019 15:04:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
> 
>> On Wed, 20 Nov 2019 07:05:40 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:
>> 
>>> Issue: Native part of WebView throws a DOMException and then, continues executing the rest of the function assuming that value is present. This causes the JVM to crash when retrieving the value.
>>> 
>>> Fix: Return from the function if exception was raised (code is similar to exception handling in [WebKitLegacy/java/DOM/JavaTreeWalker.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaTreeWalker.cpp))
>>> 
>>> This fix also needs to be applied to all function calls in [WebKitLegacy/java/DOM](https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM) functions which raises DOMError similar to createAttributeImpl().
>>> 
>>> ----------------
>>> 
>>> Commits:
>>>  - acc52780: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/47/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/47/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
>>>   Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/47.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47
>> 
>> The proposed fix seems more like a workaround to me. There are dozens of very similar calls to `raiseOnDOMError` in this and other files, so I would think a more general solution is needed.
> 
> For calls to `raiseOnDOMError()` with argument of type `ExceptionOr<Ref<T>>`, the returned value is again passed through `WTF::getPtr()`. This doesn't modify the value returned, but removing it will require changing about 40 function calls.

In `createAttributeImpl` function in [JavaDocument.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaDocument.cpp), the value returned from `raiseOnDOMError` is passed to `WTF::getPtr` function. Now there are two calls to `WTF::getPtr`, one from `raiseOnDOMError` in the return statement and another in `createAttributeImpl`, instead of just one. So, this approach has an unnecessary call to `WTF::getPtr` which, if needed, has to removed at the `createAttributeImpl` end. This doesn't modify the `Attr` object returned because `WTF::getPtr` returns the same pointer when called multiple times.

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

From arapte at openjdk.java.net  Thu Dec  5 07:36:31 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 5 Dec 2019 07:36:31 GMT
Subject: RFR: 8227808: Make GTK3 libraries mandatory for building on Linux
Message-ID: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>

Need for the change [[JDK-8227808](https://bugs.openjdk.java.net/browse/JDK-8227808)]:
Currently GTK3 is the default on Linux. However, there is build logic that will skip building glassgtk3 if the gtk3 development libraries are not installed. This creates a situation where the build will succeed, but the resulting JavaFX library will fail to run unless you explicitly force GTK2 with "-Djdk.gtk.version=2". 

How to verify the change:
On a Linux system without gtk2 and gtk3 packages,
1. Clone jfx and run gradle sdk.
-> Build should fail with an error for missing GTK3 packages.

2. Install gtk3 packages, remove build directory and run gradle clean sdk.
-> Build should fail with an error for missing GTK2 packages.

3. Install gtk2 packages, remove build directory and run gradle clean sdk.
-> Build should finish without any error.

Build verification:
1. Run a JavaFX application with -Djdk.gtk.verbose=true
Verify the verbose message, the default glassgtk3 library should be used.

2. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=2
Verify the verbose message, glassgtk2 library should be used.

3. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=3
Verify the verbose message, glassgtk3 library should be used.

----------------

Commits:
 - 57157900: 8227808: Make GTK3 libraries mandatory for building on Linux

Changes: https://git.openjdk.java.net/jfx/pull/61/files
 Webrev: https://webrevs.openjdk.java.net/jfx/61/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8227808
  Stats: 18 lines in 1 file changed: 0 ins; 10 del; 8 mod
  Patch: https://git.openjdk.java.net/jfx/pull/61.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/61/head:pull/61

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

From arapte at openjdk.java.net  Thu Dec  5 08:12:02 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 5 Dec 2019 08:12:02 GMT
Subject: RFR: 8227808: Make GTK3 libraries mandatory for building on Linux
In-Reply-To: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
Message-ID: <O-xemfj8wnY7pAcgfaL19-aYf1YKOD0PBqkBuS3_3ms=.63f42cda-b4ce-409d-a8b6-79b245ec032e@github.com>

On Thu, 5 Dec 2019 07:36:31 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Need for the change [[JDK-8227808](https://bugs.openjdk.java.net/browse/JDK-8227808)]:
> Currently GTK3 is the default on Linux. However, there is build logic that will skip building glassgtk3 if the gtk3 development libraries are not installed. This creates a situation where the build will succeed, but the resulting JavaFX library will fail to run unless you explicitly force GTK2 with "-Djdk.gtk.version=2". 
> 
> How to verify the change:
> On a Linux system without gtk2 and gtk3 packages,
> 1. Clone jfx and run gradle sdk.
> -> Build should fail with an error for missing GTK3 packages.
> 
> 2. Install gtk3 packages, remove build directory and run gradle clean sdk.
> -> Build should fail with an error for missing GTK2 packages.
> 
> 3. Install gtk2 packages, remove build directory and run gradle clean sdk.
> -> Build should finish without any error.
> 
> Build verification:
> 1. Run a JavaFX application with -Djdk.gtk.verbose=true
> Verify the verbose message, the default glassgtk3 library should be used.
> 
> 2. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=2
> Verify the verbose message, glassgtk2 library should be used.
> 
> 3. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=3
> Verify the verbose message, glassgtk3 library should be used.
> 
> ----------------
> 
> Commits:
>  - 57157900: 8227808: Make GTK3 libraries mandatory for building on Linux
> 
> Changes: https://git.openjdk.java.net/jfx/pull/61/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/61/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8227808
>   Stats: 18 lines in 1 file changed: 0 ins; 10 del; 8 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/61.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/61/head:pull/61

buildSrc/linux.gradle line 138:

> 137:             gtk3CCFlags.addAll(cflagsGTK3.split(" "))
> 138:             gtk3LinkFlags.addAll(libsGTK3.split(" "))
> 139:         } else {

Here only variable names are changed to make them similar to the names used for gtk2 code.

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

From arapte at openjdk.java.net  Thu Dec  5 10:42:35 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 5 Dec 2019 10:42:35 GMT
Subject: [Rev 02] RFR: 8196587: Remove use of deprecated finalize method
 from JPEGImageLoader
In-Reply-To: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
References: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
Message-ID: <2Y8gm943ltI7JMPav-_r6lHGo9t-DJwcRkrUldTMCcg=.0cee0dfa-c66e-4251-9b68-bb1a8583b365@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - c2ba46fd: Remove finalize() from IosImageLoader too

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/50/files
  - new: https://git.openjdk.java.net/jfx/pull/50/files/3ba659f0..c2ba46fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/50/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/50/webrev.01-02

  Issue: https://bugs.openjdk.java.net/browse/JDK-8196587
  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/50.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/50/head:pull/50

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

From arapte at openjdk.java.net  Thu Dec  5 10:43:18 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 5 Dec 2019 10:43:18 GMT
Subject: RFR: 8196587: Remove use of deprecated finalize method from
 JPEGImageLoader
In-Reply-To: <mqWk-xzRuzNwdtQy4gwA0l0byl03lKE_21e9WXZIWWY=.4de02c38-92c4-4e17-9169-960bd552f5ba@github.com>
References: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
 <on63OZdi5s4XwGo2VmD-l_ricIZhuQo7FRf08SAUPqU=.86d2c495-6d0b-4587-b8b3-fcadd2559df0@github.com>
 <Ld0QEkQ__QoBHMB2NTCGTiwpj4oce6111BZhY_uNPqM=.24723215-35c5-4323-af63-67f26ecb514a@github.com>
 <ChGmYRXbE164LvbebezL26bel6wQ4Ks3QWPQb8G7v_U=.b3a77575-d2db-43a4-9e63-db663ac21b26@github.com>
 <mqWk-xzRuzNwdtQy4gwA0l0byl03lKE_21e9WXZIWWY=.4de02c38-92c4-4e17-9169-960bd552f5ba@github.com>
Message-ID: <PU_tjBDOzdywMg3Mg0KPHCGDTaS82-1XWY_rQ4bkcVc=.01bba897-18fa-480c-a609-263fa836a840@github.com>

On Mon, 2 Dec 2019 20:40:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> On Mon, 2 Dec 2019 20:36:20 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
> 
>> On Mon, 2 Dec 2019 15:03:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
>> 
>>> On Tue, 26 Nov 2019 15:16:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>>> 
>>>> On Tue, 26 Nov 2019 15:16:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
>>>> 
>>>>> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
>>>>> And so the JPEGImageLoader.finalize() method should be removed.
>>>>> 
>>>>> The change is,
>>>>> 1. Remove finalize method from JPEGImageLoader class.
>>>>> 
>>>>> 2. Instance of JPEGImageLoader is created and used in ImageStorage class. JPEGImageLoader.dispose() should be called after it's use over. This would be a common call for the other (GIF, PNG, BMP) ImageLoader classes, which have empty dispose() method.
>>>>> 
>>>>> 3. JPEGImageLoader.load() method almost always calls the dispose() method after the image is loaded. In normal scenario JPEGImageLoader is disposed here. The calls to dispose() added in ImageStorage seem logically correct place to add and should be added.
>>>>> 
>>>>> Verification:
>>>>> Verified :graphics:test and system tests on all three platforms.
>>>>> Verified that JPEGImageLoader.dispose() is always initiated by JPEGImageLoader.load()
>>>>> 
>>>>> ----------------
>>>>> 
>>>>> Commits:
>>>>>  - b48c8087: 8196587: Remove use of deprecated finalize method from JPEGImageLoader
>>>>> 
>>>>> Changes: https://git.openjdk.java.net/jfx/pull/50/files
>>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/50/webrev.00
>>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8196587
>>>>>   Stats: 28 lines in 2 files changed: 14 ins; 12 del; 2 mod
>>>>>   Patch: https://git.openjdk.java.net/jfx/pull/50.diff
>>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/50/head:pull/50
>>>> 
>>>> I still need to double-check all calls to dispose, but I think this is essentially the right solution, and is ready to be submitted for review. I added one comment inline.
>>>> 
>>>> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java line 273:
>>>> 
>>>>> 272:             } else {
>>>>> 273:                 throw new ImageStorageException("No loader for image data");
>>>>> 274:             }
>>>> 
>>>> Now that this is moved inside a try/catch, this `ImageStorageException` will get wrapped in another `ImageStorageException` if it is ever thrown. You probably want to catch `ImageStorageException` below and re-throw it without wrapping it.
>>> 
>>> Updated the catch statement.
>> 
>> There is one more ImageLoader implementation class that still has a finalize method: [IosImageLoader.java(https://github.com/openjdk/jfx/blob/3ba659f0eb52496adb54a2b2c313e8da832e8389/modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ios/IosImageLoader.java#L215).
>> 
>> That method should also be removed, but @johanvos should confirm.
>> 
>> The rest looks fine to me.
> 
> This will need two reviewers anyway, so I tagged @johanvos to review as well.

> There is one more ImageLoader implementation class that still has a finalize method: [IosImageLoader.java](https://github.com/openjdk/jfx/blob/3ba659f0eb52496adb54a2b2c313e8da832e8389/modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ios/IosImageLoader.java#L215).

Removed `finalize()` from `IosImageLoader.java`, updated PR.

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

From fastegal at openjdk.java.net  Thu Dec  5 11:39:41 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 5 Dec 2019 11:39:41 GMT
Subject: [Rev 01] RFR: 8220722: ProgressBarSkin: adds strong listener to
 control's width property
In-Reply-To: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
References: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
Message-ID: <DAy3cuvKza7xx20TNZ7igWdYDgEL2NpFoRkmWRLO8_s=.59acc09b-35f7-4c60-9821-b332d8936f25@github.com>

The pull request has been updated with a complete new set of changes (possibly due to a rebase).

----------------

Commits:
 - a4fae9d7: 8220722: ProgressBarSkin: adds strong listener to control's width

Changes: https://git.openjdk.java.net/jfx/pull/59/files
 Webrev: https://webrevs.openjdk.java.net/jfx/59/webrev.01
  Issue: https://bugs.openjdk.java.net/browse/JDK-8220722
  Stats: 93 lines in 2 files changed: 88 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/59.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/59/head:pull/59

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

From fastegal at openjdk.java.net  Thu Dec  5 11:42:01 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 5 Dec 2019 11:42:01 GMT
Subject: RFR: 8220722: ProgressBarSkin: adds strong listener to control's
 width property
In-Reply-To: <pipIjr9BMqxRkwnY5uj6VGsBQSQL6kWMIoohlLyL-jQ=.953e7974-1cbf-4b7d-b51e-ad6333e2e49e@github.com>
References: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
 <2ay1JM71PatoMNKoK_7GC4zWDEaEFWPCSkfGOOzyRJI=.70d75942-942c-4837-ac5a-0318bd621a82@github.com>
 <pipIjr9BMqxRkwnY5uj6VGsBQSQL6kWMIoohlLyL-jQ=.953e7974-1cbf-4b7d-b51e-ad6333e2e49e@github.com>
Message-ID: <MN5f4YJ7QT5pil3SQuH-eVltv0JIRrO0zBl0pOUI6nE=.4800c4b8-9aaa-4a36-9fd9-3f3ec294e552@github.com>

On Wed, 4 Dec 2019 16:54:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> On Wed, 4 Dec 2019 15:51:42 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:
> 
>> On Wed, 4 Dec 2019 15:49:47 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:
>> 
>>> fix for https://bugs.openjdk.java.net/browse/JDK-8220722
>>> 
>>> - replaces the manually registered listener with registerChangeListener(...)
>>> - added test that's failing before and passing after the fix (plus a sanity test that the skin still is listening to changes)
>>> 
>>> ----------------
>>> 
>>> Commits:
>>>  - 9f4fc409: 8220722: ProgressBarSkin: adds strong listener to control's width
>>>  - 61f7361d: 8235151: Nonexistent notifyQuit method referred from iOS GlassHelper.m
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/59/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/59/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8220722
>>>   Stats: 102 lines in 5 files changed: 88 ins; 0 del; 14 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/59.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/59/head:pull/59
>> 
>> hmm ... somehow my rebase went wrong, sry. Don't know what exactly, though: Jose's changes are already integrated, so why do they appear here again? *grrrr
> 
> Yeah, something odd with the way you did the rebase, I guess. The commit hashes are different between the commit for Jose's fix in your branch, and the one in the upstream jfx master. When you get a moment, you will need to fix it. Since the review hasn't started yet, the easiest is to rebase your local branch on top of the upstream/master and then do a force push.

done ... no idea what happened yesterday, maybe coffein level too low ;)

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

From jvos at openjdk.java.net  Thu Dec  5 12:04:00 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Thu, 5 Dec 2019 12:04:00 GMT
Subject: RFR: 8227808: Make GTK3 libraries mandatory for building on Linux
In-Reply-To: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
Message-ID: <Jv47qwFfCy0AVh0p-u7YDivcMzZtBUyygi1a8nA8dFA=.a8ddce6e-bb3d-4b32-8260-b4a35ada7169@github.com>

On Thu, 5 Dec 2019 07:36:31 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Need for the change [[JDK-8227808](https://bugs.openjdk.java.net/browse/JDK-8227808)]:
> Currently GTK3 is the default on Linux. However, there is build logic that will skip building glassgtk3 if the gtk3 development libraries are not installed. This creates a situation where the build will succeed, but the resulting JavaFX library will fail to run unless you explicitly force GTK2 with "-Djdk.gtk.version=2". 
> 
> How to verify the change:
> On a Linux system without gtk2 and gtk3 packages,
> 1. Clone jfx and run gradle sdk.
> -> Build should fail with an error for missing GTK3 packages.
> 
> 2. Install gtk3 packages, remove build directory and run gradle clean sdk.
> -> Build should fail with an error for missing GTK2 packages.
> 
> 3. Install gtk2 packages, remove build directory and run gradle clean sdk.
> -> Build should finish without any error.
> 
> Build verification:
> 1. Run a JavaFX application with -Djdk.gtk.verbose=true
> Verify the verbose message, the default glassgtk3 library should be used.
> 
> 2. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=2
> Verify the verbose message, glassgtk2 library should be used.
> 
> 3. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=3
> Verify the verbose message, glassgtk3 library should be used.
> 
> ----------------
> 
> Commits:
>  - 57157900: 8227808: Make GTK3 libraries mandatory for building on Linux
> 
> Changes: https://git.openjdk.java.net/jfx/pull/61/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/61/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8227808
>   Stats: 18 lines in 1 file changed: 0 ins; 10 del; 8 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/61.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/61/head:pull/61

buildSrc/linux.gradle line 225:

> 224: LINUX.glass.glass.compiler = compiler
> 225: LINUX.glass.glass.ccFlags = [ccFlags, gtk2CCFlags, gtk3CCFlags, "-Werror"].flatten()
> 226: LINUX.glass.glass.linker = linker

while this compiles, it might be confusing as it will pull in both the gtk2 and gtk3 headers and there is overlap.

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

From github.com+1413266+jgneff at openjdk.java.net  Thu Dec  5 12:06:18 2019
From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger)
Date: Thu, 5 Dec 2019 12:06:18 GMT
Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices
Message-ID: <dsOXhfyXVom4Nd6LGGBZbXc-W58RwUG_7AtUy9JiE0c=.e682c202-ecdc-4030-9a4c-15bb18eb478b@github.com>

This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* repository. Some of the changes were made to support the new device models, while others are minor changes to the existing support in JavaFX 13.

The following changes were made to support the new device models.

* Work around problems on the Kobo Glo HD Model N437.

    Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is ignored by the driver on the Kobo Glo HD where the error occurs, anyway.

    Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame buffer device driver can be an incorrect value.

* Work around problems on the Kobo Clara HD Model N249.

    The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*.

The following changes were made to the existing code that supports e-paper displays in JavaFX 13.

* Use the correct constant for the number of bytes per pixel.

    Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when calculating the capacity of the 32-bit off-screen byte buffer.

* Do not round the luma value to the nearest integer.

    Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 percent and doesn't seem worth it for a display with just 16 levels of gray.

* Change camel case of system property *y8inverted*.

    Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it is consistent with the other system properties containing Y1, Y4, and Y8 in their names.

* Improve error handling when mapping the frame buffer.

    Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a `null` return value from `EPDFrameBuffer.getMappedBuffer`.

* Replace non-ASCII characters with their ASCII equivalent.

    Replace non-ASCII characters in comments and log messages as follows:

    * "?" with "x" for display resolution and color depth,
    * "?" with "*" for multiplication,
    * "?" with "to" for transition, and
    * "?C" with "degrees Celsius" for temperature.

* Add descriptions to Monocle EPD system properties.

    Add Javadoc comments to each constant that defines a Monocle EPD system property.

* Rename `IntStructure.getInteger` to `IntStructure.get`.

    Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method `Integer.getInteger`, which gets the integer value of a system property.

Below are some of the more interesting test results.

* The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16.

* When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that displays black for values `0x7F` or less and white for values `0x80` or greater.

* The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame buffer. I plan to investigate the cause of the performance difference.

* In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold increase in the number of pixels in their displays. The table below shows the animation speed of each model in milliseconds per frame and frames per second.

    | Product Name  | Speed (ms) | Rate (fps) |
    | ------------- |:----------:|:----------:|
    | Kobo Touch B  | 125        | 8.0        |
    | Kobo Touch C  | 130        | 7.7        |
    | Kobo Glo HD   | 140        | 7.1        |
    | Kobo Clara HD | 145        | 6.9        |

----------------

Commits:
 - aa335246: 8227425: Add support for e-paper displays on i.MX6 devices

Changes: https://git.openjdk.java.net/jfx/pull/60/files
 Webrev: https://webrevs.openjdk.java.net/jfx/60/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8227425
  Stats: 238 lines in 7 files changed: 193 ins; 2 del; 43 mod
  Patch: https://git.openjdk.java.net/jfx/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/60/head:pull/60

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

From github.com+1413266+jgneff at openjdk.java.net  Thu Dec  5 12:06:18 2019
From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger)
Date: Thu, 5 Dec 2019 12:06:18 GMT
Subject: RFR: 8227425: Add support for e-paper displays on i.MX6 devices
In-Reply-To: <dsOXhfyXVom4Nd6LGGBZbXc-W58RwUG_7AtUy9JiE0c=.e682c202-ecdc-4030-9a4c-15bb18eb478b@github.com>
References: <dsOXhfyXVom4Nd6LGGBZbXc-W58RwUG_7AtUy9JiE0c=.e682c202-ecdc-4030-9a4c-15bb18eb478b@github.com>
Message-ID: <JNCq1tyMGpli-eXtRD2IEp7PU5rtjyC4bpc3O7bEAQs=.a4654d03-2d7f-4863-9ba6-9f99d84c17ca@github.com>

On Thu, 5 Dec 2019 12:06:18 GMT, John Neffenger <github.com+1413266+jgneff at openjdk.org> wrote:

> This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* repository. Some of the changes were made to support the new device models, while others are minor changes to the existing support in JavaFX 13.
> 
> The following changes were made to support the new device models.
> 
> * Work around problems on the Kobo Glo HD Model N437.
> 
>     Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is ignored by the driver on the Kobo Glo HD where the error occurs, anyway.
> 
>     Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame buffer device driver can be an incorrect value.
> 
> * Work around problems on the Kobo Clara HD Model N249.
> 
>     The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*.
> 
> The following changes were made to the existing code that supports e-paper displays in JavaFX 13.
> 
> * Use the correct constant for the number of bytes per pixel.
> 
>     Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when calculating the capacity of the 32-bit off-screen byte buffer.
> 
> * Do not round the luma value to the nearest integer.
> 
>     Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 percent and doesn't seem worth it for a display with just 16 levels of gray.
> 
> * Change camel case of system property *y8inverted*.
> 
>     Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it is consistent with the other system properties containing Y1, Y4, and Y8 in their names.
> 
> * Improve error handling when mapping the frame buffer.
> 
>     Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a `null` return value from `EPDFrameBuffer.getMappedBuffer`.
> 
> * Replace non-ASCII characters with their ASCII equivalent.
> 
>     Replace non-ASCII characters in comments and log messages as follows:
> 
>     * "?" with "x" for display resolution and color depth,
>     * "?" with "*" for multiplication,
>     * "?" with "to" for transition, and
>     * "?C" with "degrees Celsius" for temperature.
> 
> * Add descriptions to Monocle EPD system properties.
> 
>     Add Javadoc comments to each constant that defines a Monocle EPD system property.
> 
> * Rename `IntStructure.getInteger` to `IntStructure.get`.
> 
>     Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method `Integer.getInteger`, which gets the integer value of a system property.
> 
> Below are some of the more interesting test results.
> 
> * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16.
> 
> * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that displays black for values `0x7F` or less and white for values `0x80` or greater.
> 
> * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame buffer. I plan to investigate the cause of the performance difference.
> 
> * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold increase in the number of pixels in their displays. The table below shows the animation speed of each model in milliseconds per frame and frames per second.
> 
>     | Product Name  | Speed (ms) | Rate (fps) |
>     | ------------- |:----------:|:----------:|
>     | Kobo Touch B  | 125        | 8.0        |
>     | Kobo Touch C  | 130        | 7.7        |
>     | Kobo Glo HD   | 140        | 7.1        |
>     | Kobo Clara HD | 145        | 6.9        |
> 
> ----------------
> 
> Commits:
>  - aa335246: 8227425: Add support for e-paper displays on i.MX6 devices
> 
> Changes: https://git.openjdk.java.net/jfx/pull/60/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/60/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8227425
>   Stats: 238 lines in 7 files changed: 193 ins; 2 del; 43 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/60.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/60/head:pull/60

/signed

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

From jvos at openjdk.java.net  Thu Dec  5 12:17:13 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Thu, 5 Dec 2019 12:17:13 GMT
Subject: RFR: 8227808: Make GTK3 libraries mandatory for building on Linux
In-Reply-To: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
Message-ID: <8qBZUvcc-1EgQBYy6l-U3XiOuKbVt7mBEczIpNpP858=.dce61af4-224a-49ed-8949-7749fb29e33d@github.com>

On Thu, 5 Dec 2019 07:36:31 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Need for the change [[JDK-8227808](https://bugs.openjdk.java.net/browse/JDK-8227808)]:
> Currently GTK3 is the default on Linux. However, there is build logic that will skip building glassgtk3 if the gtk3 development libraries are not installed. This creates a situation where the build will succeed, but the resulting JavaFX library will fail to run unless you explicitly force GTK2 with "-Djdk.gtk.version=2". 
> 
> How to verify the change:
> On a Linux system without gtk2 and gtk3 packages,
> 1. Clone jfx and run gradle sdk.
> -> Build should fail with an error for missing GTK3 packages.
> 
> 2. Install gtk3 packages, remove build directory and run gradle clean sdk.
> -> Build should fail with an error for missing GTK2 packages.
> 
> 3. Install gtk2 packages, remove build directory and run gradle clean sdk.
> -> Build should finish without any error.
> 
> Build verification:
> 1. Run a JavaFX application with -Djdk.gtk.verbose=true
> Verify the verbose message, the default glassgtk3 library should be used.
> 
> 2. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=2
> Verify the verbose message, glassgtk2 library should be used.
> 
> 3. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=3
> Verify the verbose message, glassgtk3 library should be used.
> 
> ----------------
> 
> Commits:
>  - 57157900: 8227808: Make GTK3 libraries mandatory for building on Linux
> 
> Changes: https://git.openjdk.java.net/jfx/pull/61/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/61/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8227808
>   Stats: 18 lines in 1 file changed: 0 ins; 10 del; 8 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/61.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/61/head:pull/61

Works as expected. I recommend removing gtk-specific flags in the launcher.



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

From jvos at openjdk.java.net  Thu Dec  5 12:23:41 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Thu, 5 Dec 2019 12:23:41 GMT
Subject: [Integrated] RFR: 8235150: IosApplication does not pass the
 required object in _leaveNestedEventLoopImpl
In-Reply-To: <uJk8VqCR6Ch2m2AffaqnXWfaPdwrnu2h0bDMlshbLmM=.6307a231-f596-448e-8b33-c33d77e0930a@github.com>
References: <uJk8VqCR6Ch2m2AffaqnXWfaPdwrnu2h0bDMlshbLmM=.6307a231-f596-448e-8b33-c33d77e0930a@github.com>
Message-ID: <bb60fa23-b1fb-4e2a-a789-d3171d844dc3@openjdk.org>

Changeset: a68347cb
Author:    Jose Pereda <jpereda at openjdk.org>
Committer: Johan Vos <jvos at openjdk.org>
Date:      2019-12-05 12:23:10 +0000
URL:       https://git.openjdk.java.net/jfx/commit/a68347cb

8235150: IosApplication does not pass the required object in _leaveNestedEventLoopImpl

Reviewed-by: jvos

! modules/javafx.graphics/src/main/java/com/sun/glass/ui/ios/IosApplication.java

From kcr at openjdk.java.net  Thu Dec  5 12:51:40 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 5 Dec 2019 12:51:40 GMT
Subject: [Integrated] RFR: 8232524: SynchronizedObservableMap cannot be be
 protected for copying/iterating
In-Reply-To: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
References: <yz7MxTy68M2RY3SLRCDsEoeCAMKf6oGBzvkNAtQKmKE=.9c7f6626-bc91-4e35-b705-954171f40e63@github.com>
Message-ID: <b2247bac-d0db-447f-9eb1-088ecc4014cb@openjdk.org>

Changeset: 46338d02
Author:    Robert Lichtenberger <rlichten at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2019-12-05 12:51:11 +0000
URL:       https://git.openjdk.java.net/jfx/commit/46338d02

8232524: SynchronizedObservableMap cannot be be protected for copying/iterating

Reviewed-by: arapte, kcr

! modules/javafx.base/src/main/java/javafx/collections/FXCollections.java
! modules/javafx.base/src/test/java/test/javafx/collections/FXCollectionsTest.java

From kcr at openjdk.java.net  Thu Dec  5 15:15:23 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 5 Dec 2019 15:15:23 GMT
Subject: RFR: 8233747: JVM crash in
 com.sun.webkit.dom.DocumentImpl.createAttribute
In-Reply-To: <5AdtS0I6MjGhlH8-WmlvqEhrsU0ATW4gKDbk4jTblfI=.60c0d57a-3f75-4ae4-9c6a-6c2b43506346@github.com>
References: <425XkDr6IJiSBJbZzahPMfYluP8YMHgn52xXKrVl2T4=.65dcf6dd-dbf9-4307-8e53-6082e94ccb50@github.com>
 <K3Rxg2Qu1PbiPwQHf_df1EnytQjpd7MUnCOxIzX-mek=.331da377-9513-4cb5-ba23-c969f19255fe@github.com>
 <2P1UiDuRSSNhGKHtiqYXdKwnD0vk71hHSq9B8DJafRI=.b404a52a-f3bd-4966-be7f-d515fba2b2c5@github.com>
 <5AdtS0I6MjGhlH8-WmlvqEhrsU0ATW4gKDbk4jTblfI=.60c0d57a-3f75-4ae4-9c6a-6c2b43506346@github.com>
Message-ID: <SRsO_9lmDjTp485CKAUWCckGzmxl85b2Rimb7lWzOrc=.ef767b1a-7bff-4ed5-9fcf-5facc4fbbe3b@github.com>

On Thu, 5 Dec 2019 05:42:10 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:

> On Thu, 28 Nov 2019 13:16:19 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:
> 
>> On Wed, 20 Nov 2019 15:04:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
>> 
>>> On Wed, 20 Nov 2019 07:05:40 GMT, Arun Joseph <ajoseph at openjdk.org> wrote:
>>> 
>>>> Issue: Native part of WebView throws a DOMException and then, continues executing the rest of the function assuming that value is present. This causes the JVM to crash when retrieving the value.
>>>> 
>>>> Fix: Return from the function if exception was raised (code is similar to exception handling in [WebKitLegacy/java/DOM/JavaTreeWalker.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaTreeWalker.cpp))
>>>> 
>>>> This fix also needs to be applied to all function calls in [WebKitLegacy/java/DOM](https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM) functions which raises DOMError similar to createAttributeImpl().
>>>> 
>>>> ----------------
>>>> 
>>>> Commits:
>>>>  - acc52780: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute
>>>> 
>>>> Changes: https://git.openjdk.java.net/jfx/pull/47/files
>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/47/webrev.00
>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
>>>>   Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
>>>>   Patch: https://git.openjdk.java.net/jfx/pull/47.diff
>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47
>>> 
>>> The proposed fix seems more like a workaround to me. There are dozens of very similar calls to `raiseOnDOMError` in this and other files, so I would think a more general solution is needed.
>> 
>> For calls to `raiseOnDOMError()` with argument of type `ExceptionOr<Ref<T>>`, the returned value is again passed through `WTF::getPtr()`. This doesn't modify the value returned, but removing it will require changing about 40 function calls.
> 
> In `createAttributeImpl` function in [JavaDocument.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaDocument.cpp), the value returned from `raiseOnDOMError` is passed to `WTF::getPtr` function. Now there are two calls to `WTF::getPtr`, one from `raiseOnDOMError` in the return statement and another in `createAttributeImpl`, instead of just one. So, this approach has an unnecessary call to `WTF::getPtr` which, if needed, has to removed at the `createAttributeImpl` end. This doesn't modify the `Attr` object returned because `WTF::getPtr` returns the same pointer when called multiple times.

Thanks for the explanation. It seems fine the way it is, but if you want to file a follow-up issue, that would be fine, too.

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

From arapte at openjdk.java.net  Thu Dec  5 17:53:23 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 5 Dec 2019 17:53:23 GMT
Subject: RFR: 8227808: Make GTK3 libraries mandatory for building on Linux
In-Reply-To: <Jv47qwFfCy0AVh0p-u7YDivcMzZtBUyygi1a8nA8dFA=.a8ddce6e-bb3d-4b32-8260-b4a35ada7169@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
 <Jv47qwFfCy0AVh0p-u7YDivcMzZtBUyygi1a8nA8dFA=.a8ddce6e-bb3d-4b32-8260-b4a35ada7169@github.com>
Message-ID: <wjUTcLKRhw4GvoHX42dwqAmwnhiWBGLSm-qxfHUY2ak=.e8ed6778-c657-4428-a281-f0a5321a4714@github.com>

On Thu, 5 Dec 2019 12:04:00 GMT, Johan Vos <jvos at openjdk.org> wrote:

> On Thu, 5 Dec 2019 07:36:31 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:
> 
>> Need for the change [[JDK-8227808](https://bugs.openjdk.java.net/browse/JDK-8227808)]:
>> Currently GTK3 is the default on Linux. However, there is build logic that will skip building glassgtk3 if the gtk3 development libraries are not installed. This creates a situation where the build will succeed, but the resulting JavaFX library will fail to run unless you explicitly force GTK2 with "-Djdk.gtk.version=2". 
>> 
>> How to verify the change:
>> On a Linux system without gtk2 and gtk3 packages,
>> 1. Clone jfx and run gradle sdk.
>> -> Build should fail with an error for missing GTK3 packages.
>> 
>> 2. Install gtk3 packages, remove build directory and run gradle clean sdk.
>> -> Build should fail with an error for missing GTK2 packages.
>> 
>> 3. Install gtk2 packages, remove build directory and run gradle clean sdk.
>> -> Build should finish without any error.
>> 
>> Build verification:
>> 1. Run a JavaFX application with -Djdk.gtk.verbose=true
>> Verify the verbose message, the default glassgtk3 library should be used.
>> 
>> 2. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=2
>> Verify the verbose message, glassgtk2 library should be used.
>> 
>> 3. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=3
>> Verify the verbose message, glassgtk3 library should be used.
>> 
>> ----------------
>> 
>> Commits:
>>  - 57157900: 8227808: Make GTK3 libraries mandatory for building on Linux
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/61/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/61/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8227808
>>   Stats: 18 lines in 1 file changed: 0 ins; 10 del; 8 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/61.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/61/head:pull/61
> 
> buildSrc/linux.gradle line 225:
> 
>> 224: LINUX.glass.glass.compiler = compiler
>> 225: LINUX.glass.glass.ccFlags = [ccFlags, gtk2CCFlags, gtk3CCFlags, "-Werror"].flatten()
>> 226: LINUX.glass.glass.linker = linker
> 
> while this compiles, it might be confusing as it will pull in both the gtk2 and gtk3 headers and there is overlap.

Hi Johan,
Thanks for verifying the change, I also verified build by removing the gtk flags.
I shall remove these flags and update the PR.

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

From arapte at openjdk.java.net  Thu Dec  5 17:55:48 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 5 Dec 2019 17:55:48 GMT
Subject: [Rev 01] RFR: 8227808: Make GTK3 libraries mandatory for building
 on Linux
In-Reply-To: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
Message-ID: <MqS3QSREoojWi42jbjScXZ0BmaROUg8km1DCPnbmgws=.df5efb19-41b6-4336-94f2-383ca92970ce@github.com>

The pull request has been updated with additional changes.

----------------

Added commits:
 - 3a78eb04: remove gtk flags from launcher ccflags

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/61/files
  - new: https://git.openjdk.java.net/jfx/pull/61/files/57157900..3a78eb04

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

  Issue: https://bugs.openjdk.java.net/browse/JDK-8227808
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/61.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/61/head:pull/61

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

From prr at openjdk.java.net  Thu Dec  5 20:14:41 2019
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 5 Dec 2019 20:14:41 GMT
Subject: [Integrated] RFR: 8234916: [macos 10.15] Garbled text running
 with native-image
In-Reply-To: <9S_YdCiyOdK6lND2SPYkiNShFy85eM2i82uxhdtsYdI=.bb3a4050-f781-4f12-9dc1-3c75cec07618@github.com>
References: <9S_YdCiyOdK6lND2SPYkiNShFy85eM2i82uxhdtsYdI=.bb3a4050-f781-4f12-9dc1-3c75cec07618@github.com>
Message-ID: <4b829862-ccbd-4b64-8b40-21a0e91dd08c@openjdk.org>

Changeset: 4ddf5542
Author:    Jose Pereda <jpereda at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
Date:      2019-12-05 20:13:53 +0000
URL:       https://git.openjdk.java.net/jfx/commit/4ddf5542

8234916: [macos 10.15] Garbled text running with native-image

Reviewed-by: prr

! modules/javafx.graphics/src/main/native-font/coretext.c

From kcr at openjdk.java.net  Thu Dec  5 22:20:46 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 5 Dec 2019 22:20:46 GMT
Subject: RFR: 8220722: ProgressBarSkin: adds strong listener to control's
 width property
In-Reply-To: <MN5f4YJ7QT5pil3SQuH-eVltv0JIRrO0zBl0pOUI6nE=.4800c4b8-9aaa-4a36-9fd9-3f3ec294e552@github.com>
References: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
 <2ay1JM71PatoMNKoK_7GC4zWDEaEFWPCSkfGOOzyRJI=.70d75942-942c-4837-ac5a-0318bd621a82@github.com>
 <pipIjr9BMqxRkwnY5uj6VGsBQSQL6kWMIoohlLyL-jQ=.953e7974-1cbf-4b7d-b51e-ad6333e2e49e@github.com>
 <MN5f4YJ7QT5pil3SQuH-eVltv0JIRrO0zBl0pOUI6nE=.4800c4b8-9aaa-4a36-9fd9-3f3ec294e552@github.com>
Message-ID: <5FA-y1mOhJDB-n7ZfVaHdlsGCNWsk36-VoQ2zp1DKew=.9c284d83-58ef-497a-b4c4-1b4e0e9c8b35@github.com>

On Thu, 5 Dec 2019 11:42:01 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> On Wed, 4 Dec 2019 16:54:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
> 
>> On Wed, 4 Dec 2019 15:51:42 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:
>> 
>>> On Wed, 4 Dec 2019 15:49:47 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:
>>> 
>>>> fix for https://bugs.openjdk.java.net/browse/JDK-8220722
>>>> 
>>>> - replaces the manually registered listener with registerChangeListener(...)
>>>> - added test that's failing before and passing after the fix (plus a sanity test that the skin still is listening to changes)
>>>> 
>>>> ----------------
>>>> 
>>>> Commits:
>>>>  - 9f4fc409: 8220722: ProgressBarSkin: adds strong listener to control's width
>>>>  - 61f7361d: 8235151: Nonexistent notifyQuit method referred from iOS GlassHelper.m
>>>> 
>>>> Changes: https://git.openjdk.java.net/jfx/pull/59/files
>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/59/webrev.00
>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8220722
>>>>   Stats: 102 lines in 5 files changed: 88 ins; 0 del; 14 mod
>>>>   Patch: https://git.openjdk.java.net/jfx/pull/59.diff
>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/59/head:pull/59
>>> 
>>> hmm ... somehow my rebase went wrong, sry. Don't know what exactly, though: Jose's changes are already integrated, so why do they appear here again? *grrrr
>> 
>> Yeah, something odd with the way you did the rebase, I guess. The commit hashes are different between the commit for Jose's fix in your branch, and the one in the upstream jfx master. When you get a moment, you will need to fix it. Since the review hasn't started yet, the easiest is to rebase your local branch on top of the upstream/master and then do a force push.
> 
> done ... no idea what happened yesterday, maybe coffein level too low ;)

Reviewers: @aghaisas, @arapte

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

From kevin.rushforth at oracle.com  Thu Dec  5 23:05:08 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 5 Dec 2019 15:05:08 -0800
Subject: Test drive of Skara feature to automatically resolve JBS issues
Message-ID: <583b111a-7314-41e4-6b5f-06a582149f38@oracle.com>

The Skara team is ready for us to test drive the "gitupdater" feature of 
the Skara bot which will automatically resolve JBS issues as fixed when 
the associated pull request is integrated. It will also add a comment 
with the commit message.

I note that while it is far enough along for us to test, it isn't 
completely finished: the Skara bot will not set the fixVersion nor will 
it create a backport record (this latter isn't a concern yet, but will 
be in the future).

The plan is to put this into place tomorrow (Friday, Dec 6) and test 
drive it for a week or two so that the Skara team can get feedback on 
how it is working for our project (they already use it for the Skara 
project).

This means two things:

1. The Reviewers of a PR, as well as the Committer who will integrate 
(or sponsor) the fix, need to ensure that the JBS bug has the fix 
version set to the current release, which is openjfx14.

2. Once a fix is integrated, don't update the JBS bugs (other than you 
can remove the "review-requested" label if present). We want to give the 
Skara bot a change to do it's magic.

Let me know if you have any questions.

-- Kevin


From kcr at openjdk.java.net  Thu Dec  5 23:29:25 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 5 Dec 2019 23:29:25 GMT
Subject: [Approved] RFR: 8196587: Remove use of deprecated finalize method
 from JPEGImageLoader
In-Reply-To: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
References: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
 <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
Message-ID: <A_LxyqUMRDUZhv20NtzUIRvRJOqQuK2dhEKS84-2rrI=.02dc8acd-eb43-4f88-b17c-7e8888709d4f@github.com>

On Thu, 5 Dec 2019 10:42:35 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The pull request has been updated with additional changes.
> 
> ----------------
> 
> Added commits:
>  - c2ba46fd: Remove finalize() from IosImageLoader too
> 
> Changes:
>   - all: https://git.openjdk.java.net/jfx/pull/50/files
>   - new: https://git.openjdk.java.net/jfx/pull/50/files/3ba659f0..c2ba46fd
> 
> Webrevs:
>  - full: https://webrevs.openjdk.java.net/jfx/50/webrev.02
>  - incr: https://webrevs.openjdk.java.net/jfx/50/webrev.01-02
> 
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8196587
>   Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/50.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/50/head:pull/50

Approved by kcr (Lead).

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

From aghaisas at openjdk.java.net  Fri Dec  6 06:54:14 2019
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 6 Dec 2019 06:54:14 GMT
Subject: RFR: 8221334: TableViewSkin: must initialize flow's cellCount in
 constructor
In-Reply-To: <x0bZRO_ImjJesbinSBqEC9p2XAf1lpgw_C-pbhz3LDg=.7f29f5f5-4a6f-41c4-ba4f-daaf50f88be9@github.com>
References: <x0bZRO_ImjJesbinSBqEC9p2XAf1lpgw_C-pbhz3LDg=.7f29f5f5-4a6f-41c4-ba4f-daaf50f88be9@github.com>
Message-ID: <FvGuMRIunTjbmmtfFFH5QibHMlQwIxU7Z6Sz7J-gfJs=.ad510747-770a-463e-99db-3b4b6c23cc8d@github.com>

On Fri, 29 Nov 2019 15:08:16 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8221334
> 
> - fixed as outlined in the bug report: added updateItemCount() in skin constructor (that's what all sibling skins are doing)
> - added test which fails for TableViewSkin before, passes after the fix
> 
> ----------------
> 
> Commits:
>  - 55e588c7: 8221334: TableViewSkin: must initialize flow's cellCount in constructor
> 
> Changes: https://git.openjdk.java.net/jfx/pull/56/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/56/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8221334
>   Stats: 113 lines in 2 files changed: 113 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/56.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/56/head:pull/56

I verified the test fails before the fix and passes after the fix.

The fix looks trivial enough to have one reviewer.

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

From aghaisas at openjdk.java.net  Fri Dec  6 06:54:31 2019
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 6 Dec 2019 06:54:31 GMT
Subject: [Approved] RFR: 8221334: TableViewSkin: must initialize flow's
 cellCount in constructor
In-Reply-To: <x0bZRO_ImjJesbinSBqEC9p2XAf1lpgw_C-pbhz3LDg=.7f29f5f5-4a6f-41c4-ba4f-daaf50f88be9@github.com>
References: <x0bZRO_ImjJesbinSBqEC9p2XAf1lpgw_C-pbhz3LDg=.7f29f5f5-4a6f-41c4-ba4f-daaf50f88be9@github.com>
Message-ID: <OMPashuCCDKIyXWPCAS6767w7NNC47mbNrpxEUijVVM=.5e574ea0-8146-4d71-80bf-b1ba3adab5f6@github.com>

On Fri, 29 Nov 2019 15:08:16 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8221334
> 
> - fixed as outlined in the bug report: added updateItemCount() in skin constructor (that's what all sibling skins are doing)
> - added test which fails for TableViewSkin before, passes after the fix
> 
> ----------------
> 
> Commits:
>  - 55e588c7: 8221334: TableViewSkin: must initialize flow's cellCount in constructor
> 
> Changes: https://git.openjdk.java.net/jfx/pull/56/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/56/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8221334
>   Stats: 113 lines in 2 files changed: 113 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/56.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/56/head:pull/56

Approved by aghaisas (Reviewer).

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

From aghaisas at openjdk.java.net  Fri Dec  6 09:42:06 2019
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 6 Dec 2019 09:42:06 GMT
Subject: [Rev 01] RFR: 8220722: ProgressBarSkin: adds strong listener to
 control's width property
In-Reply-To: <DAy3cuvKza7xx20TNZ7igWdYDgEL2NpFoRkmWRLO8_s=.59acc09b-35f7-4c60-9821-b332d8936f25@github.com>
References: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
 <DAy3cuvKza7xx20TNZ7igWdYDgEL2NpFoRkmWRLO8_s=.59acc09b-35f7-4c60-9821-b332d8936f25@github.com>
Message-ID: <yJ9boJAoLhYSYyxEIAW6KRiLqs_kjBh_pZbdOUTT3PU=.0b671c7a-57e4-4cc2-8cfe-fe6554d9d3c2@github.com>

On Fri, 6 Dec 2019 09:42:05 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> fix for https://bugs.openjdk.java.net/browse/JDK-8220722
>> 
>> - replaces the manually registered listener with registerChangeListener(...)
>> - added test that's failing before and passing after the fix (plus a sanity test that the skin still is listening to changes)
> 
> The pull request has been updated with a new target base due to a merge or a rebase.



-------------

Marked as reviewed by aghaisas (Reviewer).

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

From aghaisas at openjdk.java.net  Fri Dec  6 11:25:48 2019
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 6 Dec 2019 11:25:48 GMT
Subject: [Integrated] RFR: 8221334: TableViewSkin: must initialize flow's
 cellCount in constructor
In-Reply-To: <x0bZRO_ImjJesbinSBqEC9p2XAf1lpgw_C-pbhz3LDg=.7f29f5f5-4a6f-41c4-ba4f-daaf50f88be9@github.com>
References: <x0bZRO_ImjJesbinSBqEC9p2XAf1lpgw_C-pbhz3LDg=.7f29f5f5-4a6f-41c4-ba4f-daaf50f88be9@github.com>
Message-ID: <628acc8a-a3ea-434e-866f-2670881e7784@openjdk.org>

Changeset: 07af89a9
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
Date:      2019-12-06 11:25:18 +0000
URL:       https://git.openjdk.java.net/jfx/commit/07af89a9

8221334: TableViewSkin: must initialize flow's cellCount in constructor

Reviewed-by: aghaisas

! modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkin.java
+ modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ConcreteVirtualContainerTest.java

From johan.vos at gluonhq.com  Fri Dec  6 21:05:29 2019
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 6 Dec 2019 22:05:29 +0100
Subject: request to backport JDK-8193445 to JavaFX 11
Message-ID: <CABxFH2GZ_pXM5g65BO4z=3FT-h35BrtRMqqZyb9VCQQ6_Qebow@mail.gmail.com>

Hi Kevin,

I request permission to backport the fix for
https://bugs.openjdk.java.net/browse/JDK-8193445 to the 11-dev repository (
hg.openjdk.java.net/openjfx/11-dev/rt)

The patch applies clean to the 11-dev repository.

- Johan

From kevin.rushforth at oracle.com  Fri Dec  6 22:54:42 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 6 Dec 2019 14:54:42 -0800
Subject: request to backport JDK-8193445 to JavaFX 11
In-Reply-To: <CABxFH2GZ_pXM5g65BO4z=3FT-h35BrtRMqqZyb9VCQQ6_Qebow@mail.gmail.com>
References: <CABxFH2GZ_pXM5g65BO4z=3FT-h35BrtRMqqZyb9VCQQ6_Qebow@mail.gmail.com>
Message-ID: <b6743fdb-9e39-71a5-2211-70f6e892da3d@oracle.com>

+1

On 12/6/2019 1:05 PM, Johan Vos wrote:
> Hi Kevin,
>
> I request permission to backport the fix for
> https://bugs.openjdk.java.net/browse/JDK-8193445 to the 11-dev repository (
> hg.openjdk.java.net/openjfx/11-dev/rt)
>
> The patch applies clean to the 11-dev repository.
>
> - Johan


From arapte at openjdk.java.net  Mon Dec  9 06:39:06 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 9 Dec 2019 06:39:06 GMT
Subject: [Rev 01] RFR: 8220722: ProgressBarSkin: adds strong listener to
 control's width property
In-Reply-To: <DAy3cuvKza7xx20TNZ7igWdYDgEL2NpFoRkmWRLO8_s=.59acc09b-35f7-4c60-9821-b332d8936f25@github.com>
References: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
 <DAy3cuvKza7xx20TNZ7igWdYDgEL2NpFoRkmWRLO8_s=.59acc09b-35f7-4c60-9821-b332d8936f25@github.com>
Message-ID: <daEoWCqr8gXH6pxb84eMissdxrmf92LSlKgtPOPMFQ8=.32bf885f-4941-4454-b8b1-27f5280da2e2@github.com>

On Mon, 9 Dec 2019 06:39:06 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> fix for https://bugs.openjdk.java.net/browse/JDK-8220722
>> 
>> - replaces the manually registered listener with registerChangeListener(...)
>> - added test that's failing before and passing after the fix (plus a sanity test that the skin still is listening to changes)
> 
> The pull request has been updated with a new target base due to a merge or a rebase.



-------------

Marked as reviewed by arapte (Reviewer).

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

From aghaisas at openjdk.java.net  Mon Dec  9 08:09:18 2019
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 9 Dec 2019 08:09:18 GMT
Subject: [Integrated] RFR: 8220722: ProgressBarSkin: adds strong listener
 to control's width property
In-Reply-To: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
References: <hoKf60IlUM5KG7LUPoqli09qL5pVYGSFsl6fDXiHAiI=.12367a2d-bb61-49d3-aa9c-4ba0a309b3f7@github.com>
Message-ID: <98b30387-b528-4041-98e7-023b84d55976@openjdk.org>

Changeset: 71ca899f
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
Date:      2019-12-09 08:08:34 +0000
URL:       https://git.openjdk.java.net/jfx/commit/71ca899f

8220722: ProgressBarSkin: adds strong listener to control's width property

Reviewed-by: aghaisas, arapte

! modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressBarSkin.java
! modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ProgressBarSkinTest.java

From fastegal at swingempire.de  Mon Dec  9 10:56:58 2019
From: fastegal at swingempire.de (Jeanette Winzenburg)
Date: Mon, 09 Dec 2019 11:56:58 +0100
Subject: Test drive of Skara feature to automatically resolve JBS issues
In-Reply-To: <583b111a-7314-41e4-6b5f-06a582149f38@oracle.com>
References: <583b111a-7314-41e4-6b5f-06a582149f38@oracle.com>
Message-ID: <20191209115658.Horde.4I3w_UUnrLEjGBILVVdx3Q2@webmail.df.eu>


Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:

> The plan is to put this into place tomorrow (Friday, Dec 6) and test  
> drive it for a week or two so that the Skara team can get feedback  
> on how it is working for our project (they already use it for the  
> Skara project).
>

hmm .. looks like https://github.com/openjdk/jfx/pull/56 was  
integrated too early for the magic to shine? (With a fix integrated  
today everything went fine :)

Should I update the corresponding issue manually?

-- CU, Jeanette





From ajoseph at openjdk.java.net  Mon Dec  9 13:12:12 2019
From: ajoseph at openjdk.java.net (Arun Joseph)
Date: Mon, 9 Dec 2019 13:12:12 GMT
Subject: RFR: 8234471: Canvas in webview displayed with wrong scale on Windows
Message-ID: <jTNfA1sy6_8Jdv8OrgcX1GtLw_lD_8s90_pP5_RTGTw=.73f3f734-3154-447f-8326-02c942807e5a@github.com>

This bug can be reproduced when the screen resolution is at 125%, 150% and 175% for Windows, which correpsonds to `pixelScale` values of 1.25, 1.5 and 1.75, respectively.

Issue: The rectangle inside canvas is rendered on `pixelScale` while the borders are rendered on `Math.ceil(pixelScale)`

Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform`

-------------

Commits:
 - fde17b8c: 8234471: Canvas in webview displayed with wrong scale on Windows

Changes: https://git.openjdk.java.net/jfx/pull/62/files
 Webrev: https://webrevs.openjdk.java.net/jfx/62/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234471
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/62/head:pull/62

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

From kevin.rushforth at oracle.com  Mon Dec  9 13:34:40 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 9 Dec 2019 05:34:40 -0800
Subject: Test drive of Skara feature to automatically resolve JBS issues
In-Reply-To: <20191209115658.Horde.4I3w_UUnrLEjGBILVVdx3Q2@webmail.df.eu>
References: <583b111a-7314-41e4-6b5f-06a582149f38@oracle.com>
 <20191209115658.Horde.4I3w_UUnrLEjGBILVVdx3Q2@webmail.df.eu>
Message-ID: <88ecd0ea-a477-22aa-6fe1-ab6e640245e7@oracle.com>

I was planning to do that this morning (I was going to do it Friday 
afternoon, but ran into the JBS maintenance window, and then ran out of 
time). They actually had turned it on before the below bug was 
integrated, but there was a configuration error in the Skara bot that 
prevented it from working, and they haven't implemented the retry logic yet.

Thanks.

-- Kevin


On 12/9/2019 2:56 AM, Jeanette Winzenburg wrote:
>
> Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:
>
>> The plan is to put this into place tomorrow (Friday, Dec 6) and test 
>> drive it for a week or two so that the Skara team can get feedback on 
>> how it is working for our project (they already use it for the Skara 
>> project).
>>
>
> hmm .. looks like https://github.com/openjdk/jfx/pull/56 was 
> integrated too early for the magic to shine? (With a fix integrated 
> today everything went fine :)
>
> Should I update the corresponding issue manually?
>
> -- CU, Jeanette
>
>
>
>


From fastegal at swingempire.de  Mon Dec  9 14:11:44 2019
From: fastegal at swingempire.de (Jeanette Winzenburg)
Date: Mon, 09 Dec 2019 15:11:44 +0100
Subject: Test drive of Skara feature to automatically resolve JBS issues
In-Reply-To: <88ecd0ea-a477-22aa-6fe1-ab6e640245e7@oracle.com>
References: <583b111a-7314-41e4-6b5f-06a582149f38@oracle.com>
 <20191209115658.Horde.4I3w_UUnrLEjGBILVVdx3Q2@webmail.df.eu>
 <88ecd0ea-a477-22aa-6fe1-ab6e640245e7@oracle.com>
Message-ID: <20191209151144.Horde.9m9t-eFGC-Sf8I4YzEVmkA1@webmail.df.eu>


Thanks for the cleanup :)

Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:

> I was planning to do that this morning (I was going to do it Friday  
> afternoon, but ran into the JBS maintenance window, and then ran out  
> of time). They actually had turned it on before the below bug was  
> integrated, but there was a configuration error in the Skara bot  
> that prevented it from working, and they haven't implemented the  
> retry logic yet.
>
> Thanks.
>
> -- Kevin
>
>
> On 12/9/2019 2:56 AM, Jeanette Winzenburg wrote:
>>
>> Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:
>>
>>> The plan is to put this into place tomorrow (Friday, Dec 6) and  
>>> test drive it for a week or two so that the Skara team can get  
>>> feedback on how it is working for our project (they already use it  
>>> for the Skara project).
>>>
>>
>> hmm .. looks like https://github.com/openjdk/jfx/pull/56 was  
>> integrated too early for the magic to shine? (With a fix integrated  
>> today everything went fine :)
>>
>> Should I update the corresponding issue manually?
>>
>> -- CU, Jeanette
>>
>>
>>
>>




From tsayao at openjdk.java.net  Mon Dec  9 18:29:57 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Mon, 9 Dec 2019 18:29:57 GMT
Subject: RFR: 8232811: Dialog's preferred size no longer accommodates
 multi-line strings
Message-ID: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>

https://bugs.openjdk.java.net/browse/JDK-8232811

This one was hard to tackle.

./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest

-------------

Commits:
 - 338bedbe: Fix mistake
 - a02894d6: Fix JDK-8232811
 - 7a23cdbd: Merge pull request #2 from openjdk/master
 - fc36a292: Merge pull request #1 from openjdk/master

Changes: https://git.openjdk.java.net/jfx/pull/63/files
 Webrev: https://webrevs.openjdk.java.net/jfx/63/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8232811
  Stats: 188 lines in 2 files changed: 176 ins; 11 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/63.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/63/head:pull/63

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

From thiago.sayao at clamed.com.br  Mon Dec  9 20:07:12 2019
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Mon, 9 Dec 2019 20:07:12 +0000
Subject: Minor code changes that aren't necessarily bugs
Message-ID: <CP2P15201MB2228CAD641C2C48F209AC24DDE580@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

While going across the source code I have noticed some code that might be incorrect , such as:

- WindowStage.setScene() has a call to requestFocus()

I might be missing something, but I think it does not belong there because the scene is usually set before show(), and while it may be set after the show and even multiple times, why should it requestFocus() ?

Removing it may also fix https://bugs.openjdk.java.net/browse/JDK-8212060. It is already fixed on glass side, but still...

- WindowStage.hadleFocusDisabled() calls requestToFront() and requestFocus() while requestToFront() already calls requestFocus()

- Intellij points me some cleanups such as null checks before instanceof, ifs that can be merged, etc.


Would those kind of PR be welcome, accepted (if correct) ?

Cheers.



From kevin.rushforth at oracle.com  Mon Dec  9 20:19:07 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 9 Dec 2019 12:19:07 -0800
Subject: Minor code changes that aren't necessarily bugs
In-Reply-To: <CP2P15201MB2228CAD641C2C48F209AC24DDE580@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
References: <CP2P15201MB2228CAD641C2C48F209AC24DDE580@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
Message-ID: <af2c4cba-59fd-1f02-d82f-4c04d8e85fd4@oracle.com>

It depends. Some cleanup like this can be good if it reduces overall 
maintenance going forward. In many cases, though, it would take more 
effort to get it reviewed and prove that there aren't any regressions 
than it is worth. In particular, I don't think there is high value in 
the sort of automatic refactoring that IDEs like to suggest.

In the specific case of removing a possibly-redundant call to setFocus, 
I'm not sure. One thing to consider is the case where the scene on the 
stage goes from null to non-null. You would need to make sure that the 
behavior doesn't change. Also, there is the case of multiple stages to 
consider.

-- Kevin


On 12/9/2019 12:07 PM, Thiago Milczarek Sayao wrote:
> While going across the source code I have noticed some code that might be incorrect , such as:
>
> - WindowStage.setScene() has a call to requestFocus()
>
> I might be missing something, but I think it does not belong there because the scene is usually set before show(), and while it may be set after the show and even multiple times, why should it requestFocus() ?
>
> Removing it may also fix https://bugs.openjdk.java.net/browse/JDK-8212060. It is already fixed on glass side, but still...
>
> - WindowStage.hadleFocusDisabled() calls requestToFront() and requestFocus() while requestToFront() already calls requestFocus()
>
> - Intellij points me some cleanups such as null checks before instanceof, ifs that can be merged, etc.
>
>
> Would those kind of PR be welcome, accepted (if correct) ?
>
> Cheers.
>
>


From kcr at openjdk.java.net  Mon Dec  9 20:58:49 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 9 Dec 2019 20:58:49 GMT
Subject: [Rev 05] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <jgyrznjFlcuhYXcXP3uIRbNTbR4V-1YjU2cyT8k2yo4=.af36bdb2-a728-418a-8f54-0e418e498c30@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <jgyrznjFlcuhYXcXP3uIRbNTbR4V-1YjU2cyT8k2yo4=.af36bdb2-a728-418a-8f54-0e418e498c30@github.com>
Message-ID: <xEH1ebDM4o5xphO7OExOSRWH8Ja-pcCRiVq3s0dPIWE=.3cc0b63a-9111-4f65-81d3-b660192a96c4@github.com>

On Mon, 9 Dec 2019 20:58:46 GMT, Hadzic Samir <shadzic at openjdk.org> wrote:

>> Allright, this is a fix for JDK-8207957
> 
> The pull request has been updated with 1 additional commit.

The fix looks good to me.

I left a few minor comments, including adding a missing comma in the API docs, which will also need to be changed in the CSR. Once this is updated I'll review the CSR and then you can move the CSR to Finalize.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 40:

> 39: import javafx.collections.WeakListChangeListener;
> 40: import javafx.css.*;
> 41: import javafx.css.converter.SizeConverter;

Please revert this change. In general, we do not use wildcard imports.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java line 605:

> 604:      * custom implementation (such as ones that exclude the header, exclude {@code null} content, compute the minimum
> 605:      * width etc.).
> 606:      *

There should be a `,` before `etc.`

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

add 2019, so:

  * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 56:

> 55:     @Before
> 56:     public void before(){
> 57:         ObservableList<Person> model = FXCollections.observableArrayList(

Minor: add a space before the `{`

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 80:

> 79:     @After
> 80:     public void after(){
> 81:         sl.dispose();

Minor: add a space before the `{`

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableColumnHeaderTest.java line 152:

> 151:         tableView.getItems().get(2).setFirstName("Orrin Davies");
> 152:         tableView.getItems().get(3).setFirstName("Emma Wilson");
> 153: 

It would be nice to not have to repeat the set of strings used. I recommend putting them in a static string array (they appears either 2 or 3 times in the test file). Maybe create 4 static strings for the 4 names?

-------------



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

From kcr at openjdk.java.net  Mon Dec  9 21:01:57 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 9 Dec 2019 21:01:57 GMT
Subject: [Rev 05] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <xEH1ebDM4o5xphO7OExOSRWH8Ja-pcCRiVq3s0dPIWE=.3cc0b63a-9111-4f65-81d3-b660192a96c4@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <jgyrznjFlcuhYXcXP3uIRbNTbR4V-1YjU2cyT8k2yo4=.af36bdb2-a728-418a-8f54-0e418e498c30@github.com>
 <xEH1ebDM4o5xphO7OExOSRWH8Ja-pcCRiVq3s0dPIWE=.3cc0b63a-9111-4f65-81d3-b660192a96c4@github.com>
Message-ID: <OtAAQoKEmvXJs1gD4SwJkXS95FLS8TiDHuasdfJvVqk=.65613f71-f069-4666-a269-9c36df5b9539@github.com>

On Mon, 9 Dec 2019 20:58:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> The fix looks good to me.
> 
> I left a few minor comments, including adding a missing comma in the API docs, which will also need to be changed in the CSR. Once this is updated I'll review the CSR and then you can move the CSR to Finalize.

I would like both @aghaisas and myself to review / approve this. I will sponsor it.

In addition, the CSR needs to be approved before this can be integrated.

-------------

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

From dlemmermann at gmail.com  Mon Dec  9 21:13:10 2019
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Mon, 9 Dec 2019 22:13:10 +0100
Subject: Difference in CSS styling / rendering.
Message-ID: <998C7A66-E1CD-4EB1-B6B0-7AF65E291D3E@gmail.com>

Hi,

I just noticed that the timeline in FlexGanttFX does not get rendered correctly anymore after updating to 14-ea+4. The borders around the date cells disappeared.

I assume that this must be somehow related to the CSS fix that made it into this version. 

This is just a heads-up. If possible I will try to create a standalone example for this issue, but considering the complexity of this control it might be difficult to do so.

Dirk



From kevin.rushforth at oracle.com  Mon Dec  9 21:20:04 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 9 Dec 2019 13:20:04 -0800
Subject: Difference in CSS styling / rendering.
In-Reply-To: <998C7A66-E1CD-4EB1-B6B0-7AF65E291D3E@gmail.com>
References: <998C7A66-E1CD-4EB1-B6B0-7AF65E291D3E@gmail.com>
Message-ID: <51b3d489-451e-0022-436b-4c985d22259e@oracle.com>

Thanks for the heads-up. Let us know what you find.

-- Kevin


On 12/9/2019 1:13 PM, Dirk Lemmermann wrote:
> Hi,
>
> I just noticed that the timeline in FlexGanttFX does not get rendered correctly anymore after updating to 14-ea+4. The borders around the date cells disappeared.
>
> I assume that this must be somehow related to the CSS fix that made it into this version.
>
> This is just a heads-up. If possible I will try to create a standalone example for this issue, but considering the complexity of this control it might be difficult to do so.
>
> Dirk
>
>


From shadzic at openjdk.java.net  Mon Dec  9 23:20:36 2019
From: shadzic at openjdk.java.net (Hadzic Samir)
Date: Mon, 9 Dec 2019 23:20:36 GMT
Subject: [Rev 05] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <OtAAQoKEmvXJs1gD4SwJkXS95FLS8TiDHuasdfJvVqk=.65613f71-f069-4666-a269-9c36df5b9539@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <jgyrznjFlcuhYXcXP3uIRbNTbR4V-1YjU2cyT8k2yo4=.af36bdb2-a728-418a-8f54-0e418e498c30@github.com>
 <xEH1ebDM4o5xphO7OExOSRWH8Ja-pcCRiVq3s0dPIWE=.3cc0b63a-9111-4f65-81d3-b660192a96c4@github.com>
 <OtAAQoKEmvXJs1gD4SwJkXS95FLS8TiDHuasdfJvVqk=.65613f71-f069-4666-a269-9c36df5b9539@github.com>
Message-ID: <21f1pJ4D38KMemipRY1jP-omCI5I_VJXTXb8gznQvx0=.928f2c83-97e0-4de9-8280-e1585701a153@github.com>

On Mon, 9 Dec 2019 21:01:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The fix looks good to me.
>> 
>> I left a few minor comments, including adding a missing comma in the API docs, which will also need to be changed in the CSR. Once this is updated I'll review the CSR and then you can move the CSR to Finalize.
> 
> I would like both @aghaisas and myself to review / approve this. I will sponsor it.
> 
> In addition, the CSR needs to be approved before this can be integrated.

Thanks for the review. I do not have access to a computer right now, I'll
update next week on Monday.

Le lun. 9 d?c. 2019 ? 17:01, Kevin Rushforth <notifications at github.com> a
?crit :

> I would like both @aghaisas <https://github.com/aghaisas> and myself to
> review / approve this. I will sponsor it.
>
> In addition, the CSR needs to be approved before this can be integrated.
>
> ?
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jfx/pull/6?email_source=notifications&email_token=ACEL43KWFAJ32FX3NNSM7ETQX2W3LA5CNFSM4I5EYYAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKV3YQ#issuecomment-563437026>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACEL43PNZLRK37IM33ROVGDQX2W3LANCNFSM4I5EYYAA>
> .
>

-------------

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

From thiago.sayao at clamed.com.br  Tue Dec 10 00:27:13 2019
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Tue, 10 Dec 2019 00:27:13 +0000
Subject: Questions about glass linux implementation
Message-ID: <CP2P15201MB22285E88519C88409F18A1DFDE5B0@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

Well, git blames Antem Ananiev - not sure you're around this list.

Question 1 - Why can't we use gtk_window_set_resizable () ?


Question 2 - Why do we keep separated geometry and not use gtk directly?


Thanks.

From tsayao at openjdk.java.net  Tue Dec 10 00:35:22 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Tue, 10 Dec 2019 00:35:22 GMT
Subject: [Rev 01] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
Message-ID: <XSnOkwzxPiT930OOD7aeKekNWiJ52J35494EemfNijQ=.5f744e58-118e-49fc-83e5-311800e7d4ed@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8232811
> 
> This one was hard to tackle.
> 
> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 7a8377e7: Asthetics

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/63/files
  - new: https://git.openjdk.java.net/jfx/pull/63/files/338bedbe..7a8377e7

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/63.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/63/head:pull/63

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

From tsayao at openjdk.java.net  Tue Dec 10 01:48:40 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Tue, 10 Dec 2019 01:48:40 GMT
Subject: [Rev 02] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
Message-ID: <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8232811
> 
> This one was hard to tackle.
> 
> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 7b723c3b: Revert unecessary change

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/63/files
  - new: https://git.openjdk.java.net/jfx/pull/63/files/7a8377e7..7b723c3b

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/63/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/63/webrev.01-02

  Stats: 14 lines in 1 file changed: 8 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/63.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/63/head:pull/63

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

From arapte at openjdk.java.net  Tue Dec 10 07:03:39 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 10 Dec 2019 07:03:39 GMT
Subject: RFR: 8223296: NullPointerException in GlassScene.java at line 325
Message-ID: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>

Issue: NPE in GlassScene.frameRendered().

Cause: scenePaintListener is set in setTKScenePaintListener(), used in frameRendered() and 
set to null in dispose().
setTKScenePaintListener() and dispose() are called on JavaFX Application Thread and 
frameRendered() is called by QuantumRenderer thread.
setTKScenePaintListener() and frameRendered() are synchronized but dispose() is not.

Fix:
dispose() should use the synchronized setTKScenePaintListener() to set scenePaintListener to null.

Verification:
This is a very rare issue and cannot be reliably reproduced with a test case.

-------------

Commits:
 - ca95597f: [WIP]8223296: NullPointerException in GlassScene.java at line 325

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

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

From arapte at openjdk.java.net  Tue Dec 10 07:04:07 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 10 Dec 2019 07:04:07 GMT
Subject: [Rev 01] RFR: 8227808: Make GTK3 libraries mandatory for building
 on Linux
In-Reply-To: <8qBZUvcc-1EgQBYy6l-U3XiOuKbVt7mBEczIpNpP858=.dce61af4-224a-49ed-8949-7749fb29e33d@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
 <8qBZUvcc-1EgQBYy6l-U3XiOuKbVt7mBEczIpNpP858=.dce61af4-224a-49ed-8949-7749fb29e33d@github.com>
Message-ID: <hqgGS1wmkMQUgfF7zNko-PTWkaw2zKWJURiQarFD7b8=.22591f84-2ca6-4c9b-bca6-c00d1497e64d@github.com>

On Thu, 5 Dec 2019 12:16:53 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> Works as expected. I recommend removing gtk-specific flags in the launcher.

> Works as expected. I recommend removing gtk-specific flags in the launcher.

Hi Johan, The PR is updated with this change, please take a look.

-------------

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

From thevenet.fred at free.fr  Tue Dec 10 10:33:27 2019
From: thevenet.fred at free.fr (thevenet.fred at free.fr)
Date: Tue, 10 Dec 2019 11:33:27 +0100 (CET)
Subject: Blank stages when running JavaFX app in a macOS virtual machine
In-Reply-To: <2117685452.1579744887.1575395217009.JavaMail.zimbra@free.fr>
References: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
 <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
 <df8e0306-897a-2d1e-8ed5-210aa93f8df1@oracle.com>
 <2117685452.1579744887.1575395217009.JavaMail.zimbra@free.fr>
Message-ID: <1792631178.1632354009.1575974007350.JavaMail.zimbra@free.fr>

Hi,

I've submitted bug report via https://bugreport.java.com/bugreport/ regarding the issue below about a week ago but I haven't heard from it yet.
I understand this might not be the best place to inquire about it, but since this prevents me from submitting a PR (as I don't have an issue number) I was hoping someone here could offer some guidance on how to get this moving forward.

Many thanks,
Fred.

----- Mail original -----
De: "thevenet fred" <thevenet.fred at free.fr>
?: "Kevin Rushforth" <kevin.rushforth at oracle.com>
Cc: "openjfx-dev" <openjfx-dev at openjdk.java.net>
Envoy?: Mardi 3 D?cembre 2019 18:46:57
Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine

Ok thanks, will do that.

Regards,
Frederic Thevenet

----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
Envoy?: Mardi 3 D?cembre 2019 18:35:49
Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine

A new follow-on bug ID will be needed. We never reopen a JBS issue once 
it has been resolved as fixed by a changeset that has been pushed.

-- Kevin


On 12/3/2019 7:11 AM, thevenet.fred at free.fr wrote:
> Hello,
>
> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
>
> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
>
> The problematic code is located at #96 in GlassView3D.m:
>
> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
> 096: if ((err == kCGLNoError) && (npix == 0))
> 097: {
> 098:   const CGLPixelFormatAttribute attributes2[] =
> 099:   {
> 100:     kCGLPFAAllowOfflineRenderers,
> 101:     (CGLPixelFormatAttribute)0
> 102:   };
> 103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
> 104: }
>
>
> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>
>  From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
>
> I have verified that this change produces the expected behavior and I propose to submit a PR with this change (I have already signed the OCA)
>
> A quick question before I do, however; should I file a new issue prior to submitting a PR or is it better that someone with privileges reopens JDK-8154148?
>
> Regards,
>
> Frederic Thevenet

From mp at jugs.org  Tue Dec 10 10:59:30 2019
From: mp at jugs.org (Michael Paus)
Date: Tue, 10 Dec 2019 11:59:30 +0100
Subject: Blank stages when running JavaFX app in a macOS virtual machine
In-Reply-To: <1792631178.1632354009.1575974007350.JavaMail.zimbra@free.fr>
References: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
 <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
 <df8e0306-897a-2d1e-8ed5-210aa93f8df1@oracle.com>
 <2117685452.1579744887.1575395217009.JavaMail.zimbra@free.fr>
 <1792631178.1632354009.1575974007350.JavaMail.zimbra@free.fr>
Message-ID: <b3f3040f-8ddc-08a1-47d7-15f900e6326e@jugs.org>

Hi,
maybe you lost the response mail or it went into your trash.
I guess this is your bug report in the JBS.
https://bugs.openjdk.java.net/browse/JDK-8235627
--Michael

Am 10.12.19 um 11:33 schrieb thevenet.fred at free.fr:
> Hi,
>
> I've submitted bug report via https://bugreport.java.com/bugreport/ regarding the issue below about a week ago but I haven't heard from it yet.
> I understand this might not be the best place to inquire about it, but since this prevents me from submitting a PR (as I don't have an issue number) I was hoping someone here could offer some guidance on how to get this moving forward.
>
> Many thanks,
> Fred.
>
> ----- Mail original -----
> De: "thevenet fred" <thevenet.fred at free.fr>
> ?: "Kevin Rushforth" <kevin.rushforth at oracle.com>
> Cc: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> Envoy?: Mardi 3 D?cembre 2019 18:46:57
> Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine
>
> Ok thanks, will do that.
>
> Regards,
> Frederic Thevenet
>
> ----- Mail original -----
> De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
> ?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> Envoy?: Mardi 3 D?cembre 2019 18:35:49
> Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine
>
> A new follow-on bug ID will be needed. We never reopen a JBS issue once
> it has been resolved as fixed by a changeset that has been pushed.
>
> -- Kevin
>
>
> On 12/3/2019 7:11 AM, thevenet.fred at free.fr wrote:
>> Hello,
>>
>> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
>> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
>>
>> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
>> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
>>
>> The problematic code is located at #96 in GlassView3D.m:
>>
>> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
>> 096: if ((err == kCGLNoError) && (npix == 0))
>> 097: {
>> 098:   const CGLPixelFormatAttribute attributes2[] =
>> 099:   {
>> 100:     kCGLPFAAllowOfflineRenderers,
>> 101:     (CGLPixelFormatAttribute)0
>> 102:   };
>> 103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
>> 104: }
>>
>>
>> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>>
>>    From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
>> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
>> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
>>
>> I have verified that this change produces the expected behavior and I propose to submit a PR with this change (I have already signed the OCA)
>>
>> A quick question before I do, however; should I file a new issue prior to submitting a PR or is it better that someone with privileges reopens JDK-8154148?
>>
>> Regards,
>>
>> Frederic Thevenet




From thevenet.fred at free.fr  Tue Dec 10 11:17:33 2019
From: thevenet.fred at free.fr (thevenet.fred at free.fr)
Date: Tue, 10 Dec 2019 12:17:33 +0100 (CET)
Subject: Blank stages when running JavaFX app in a macOS virtual machine
In-Reply-To: <b3f3040f-8ddc-08a1-47d7-15f900e6326e@jugs.org>
References: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
 <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
 <df8e0306-897a-2d1e-8ed5-210aa93f8df1@oracle.com>
 <2117685452.1579744887.1575395217009.JavaMail.zimbra@free.fr>
 <1792631178.1632354009.1575974007350.JavaMail.zimbra@free.fr>
 <b3f3040f-8ddc-08a1-47d7-15f900e6326e@jugs.org>
Message-ID: <405281271.1632613815.1575976653822.JavaMail.zimbra@free.fr>

Well yes, it is indeed my bug report, thanks!
I can't find a response in my mailbox, and searching for it it didn't yield any result (bug was created in JBS 9 hours ago; might not be indexed yet).
Anyway, it doesn't matter; I can now go forward with my PR.

Thanks again.
Fred.  


----- Mail original -----
De: "Michael Paus" <mp at jugs.org>
?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
Envoy?: Mardi 10 D?cembre 2019 11:59:30
Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine

Hi,
maybe you lost the response mail or it went into your trash.
I guess this is your bug report in the JBS.
https://bugs.openjdk.java.net/browse/JDK-8235627
--Michael

Am 10.12.19 um 11:33 schrieb thevenet.fred at free.fr:
> Hi,
>
> I've submitted bug report via https://bugreport.java.com/bugreport/ regarding the issue below about a week ago but I haven't heard from it yet.
> I understand this might not be the best place to inquire about it, but since this prevents me from submitting a PR (as I don't have an issue number) I was hoping someone here could offer some guidance on how to get this moving forward.
>
> Many thanks,
> Fred.
>
> ----- Mail original -----
> De: "thevenet fred" <thevenet.fred at free.fr>
> ?: "Kevin Rushforth" <kevin.rushforth at oracle.com>
> Cc: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> Envoy?: Mardi 3 D?cembre 2019 18:46:57
> Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine
>
> Ok thanks, will do that.
>
> Regards,
> Frederic Thevenet
>
> ----- Mail original -----
> De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
> ?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> Envoy?: Mardi 3 D?cembre 2019 18:35:49
> Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine
>
> A new follow-on bug ID will be needed. We never reopen a JBS issue once
> it has been resolved as fixed by a changeset that has been pushed.
>
> -- Kevin
>
>
> On 12/3/2019 7:11 AM, thevenet.fred at free.fr wrote:
>> Hello,
>>
>> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
>> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
>>
>> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
>> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
>>
>> The problematic code is located at #96 in GlassView3D.m:
>>
>> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
>> 096: if ((err == kCGLNoError) && (npix == 0))
>> 097: {
>> 098:   const CGLPixelFormatAttribute attributes2[] =
>> 099:   {
>> 100:     kCGLPFAAllowOfflineRenderers,
>> 101:     (CGLPixelFormatAttribute)0
>> 102:   };
>> 103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
>> 104: }
>>
>>
>> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>>
>>    From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
>> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
>> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
>>
>> I have verified that this change produces the expected behavior and I propose to submit a PR with this change (I have already signed the OCA)
>>
>> A quick question before I do, however; should I file a new issue prior to submitting a PR or is it better that someone with privileges reopens JDK-8154148?
>>
>> Regards,
>>
>> Frederic Thevenet

From aghaisas at openjdk.java.net  Tue Dec 10 12:26:28 2019
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 10 Dec 2019 12:26:28 GMT
Subject: [Rev 01] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <Ctsq9u7-Tk2-BPkW_z8ZG_gxPjM7tHqUJ3yycE0WWXQ=.f9cd53be-f361-4e08-8d25-a6199458edd6@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <Ctsq9u7-Tk2-BPkW_z8ZG_gxPjM7tHqUJ3yycE0WWXQ=.f9cd53be-f361-4e08-8d25-a6199458edd6@github.com>
Message-ID: <Y5ptHsJsrynNQyAZO1YT_Eg59bkqltJxOMFA0-krOZU=.bcdc9744-4927-4b90-8d28-08612347ad3b@github.com>

On Tue, 10 Dec 2019 12:26:27 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759
>> 
>> The issue is that default/cancel button on a scene are triggered even though a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug for details on both cause and fix.
>> 
>> There are additional/changed tests to verify the fix. All old tests are passing.
> 
> The pull request has been updated with 1 additional commit.

Changes look OK apart from one doubt I have listed.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java line 626:

> 625:     protected void fire(KeyEvent event) { } // TODO move to TextFieldBehavior
> 626:     protected void cancelEdit(KeyEvent event) { };
> 627: 

Will this code removal re-introduce JDK-8145515?

-------------



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

From kevin.rushforth at oracle.com  Tue Dec 10 12:44:43 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 10 Dec 2019 04:44:43 -0800
Subject: Blank stages when running JavaFX app in a macOS virtual machine
In-Reply-To: <405281271.1632613815.1575976653822.JavaMail.zimbra@free.fr>
References: <mailman.1042.1575319217.28667.openjfx-dev@openjdk.java.net>
 <907243350.1578852019.1575385887378.JavaMail.zimbra@free.fr>
 <df8e0306-897a-2d1e-8ed5-210aa93f8df1@oracle.com>
 <2117685452.1579744887.1575395217009.JavaMail.zimbra@free.fr>
 <1792631178.1632354009.1575974007350.JavaMail.zimbra@free.fr>
 <b3f3040f-8ddc-08a1-47d7-15f900e6326e@jugs.org>
 <405281271.1632613815.1575976653822.JavaMail.zimbra@free.fr>
Message-ID: <09c57516-703f-96f8-97a2-2c4f26bcd6db@oracle.com>

Yes, I see that it was transferred to the JDK project yesterday evening 
(or early morning today depending on your time zone). Usually it happens 
within a day or so, but sometimes there is a delay. Btw, if there is one 
that you or anyone else has submitted that you are ready to contribute a 
fix for, let me know and I can process it.

-- Kevin


On 12/10/2019 3:17 AM, thevenet.fred at free.fr wrote:
> Well yes, it is indeed my bug report, thanks!
> I can't find a response in my mailbox, and searching for it it didn't yield any result (bug was created in JBS 9 hours ago; might not be indexed yet).
> Anyway, it doesn't matter; I can now go forward with my PR.
>
> Thanks again.
> Fred.
>
>
> ----- Mail original -----
> De: "Michael Paus" <mp at jugs.org>
> ?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
> Envoy?: Mardi 10 D?cembre 2019 11:59:30
> Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine
>
> Hi,
> maybe you lost the response mail or it went into your trash.
> I guess this is your bug report in the JBS.
> https://bugs.openjdk.java.net/browse/JDK-8235627
> --Michael
>
> Am 10.12.19 um 11:33 schrieb thevenet.fred at free.fr:
>> Hi,
>>
>> I've submitted bug report via https://bugreport.java.com/bugreport/ regarding the issue below about a week ago but I haven't heard from it yet.
>> I understand this might not be the best place to inquire about it, but since this prevents me from submitting a PR (as I don't have an issue number) I was hoping someone here could offer some guidance on how to get this moving forward.
>>
>> Many thanks,
>> Fred.
>>
>> ----- Mail original -----
>> De: "thevenet fred" <thevenet.fred at free.fr>
>> ?: "Kevin Rushforth" <kevin.rushforth at oracle.com>
>> Cc: "openjfx-dev" <openjfx-dev at openjdk.java.net>
>> Envoy?: Mardi 3 D?cembre 2019 18:46:57
>> Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine
>>
>> Ok thanks, will do that.
>>
>> Regards,
>> Frederic Thevenet
>>
>> ----- Mail original -----
>> De: "Kevin Rushforth" <kevin.rushforth at oracle.com>
>> ?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
>> Envoy?: Mardi 3 D?cembre 2019 18:35:49
>> Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine
>>
>> A new follow-on bug ID will be needed. We never reopen a JBS issue once
>> it has been resolved as fixed by a changeset that has been pushed.
>>
>> -- Kevin
>>
>>
>> On 12/3/2019 7:11 AM, thevenet.fred at free.fr wrote:
>>> Hello,
>>>
>>> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
>>> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
>>>
>>> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
>>> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
>>>
>>> The problematic code is located at #96 in GlassView3D.m:
>>>
>>> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
>>> 096: if ((err == kCGLNoError) && (npix == 0))
>>> 097: {
>>> 098:   const CGLPixelFormatAttribute attributes2[] =
>>> 099:   {
>>> 100:     kCGLPFAAllowOfflineRenderers,
>>> 101:     (CGLPixelFormatAttribute)0
>>> 102:   };
>>> 103:   err = CGLChoosePixelFormat(attributes2, &pix, &npix);
>>> 104: }
>>>
>>>
>>> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>>>
>>>     From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
>>> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
>>> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
>>>
>>> I have verified that this change produces the expected behavior and I propose to submit a PR with this change (I have already signed the OCA)
>>>
>>> A quick question before I do, however; should I file a new issue prior to submitting a PR or is it better that someone with privileges reopens JDK-8154148?
>>>
>>> Regards,
>>>
>>> Frederic Thevenet


From fastegal at openjdk.java.net  Tue Dec 10 13:01:26 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 10 Dec 2019 13:01:26 GMT
Subject: [Rev 01] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <Y5ptHsJsrynNQyAZO1YT_Eg59bkqltJxOMFA0-krOZU=.bcdc9744-4927-4b90-8d28-08612347ad3b@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <Ctsq9u7-Tk2-BPkW_z8ZG_gxPjM7tHqUJ3yycE0WWXQ=.f9cd53be-f361-4e08-8d25-a6199458edd6@github.com>
 <Y5ptHsJsrynNQyAZO1YT_Eg59bkqltJxOMFA0-krOZU=.bcdc9744-4927-4b90-8d28-08612347ad3b@github.com>
Message-ID: <pPU6AUC15PX-lz4_RsUG1sOQMusPTa1KhCgwWlez91o=.579604d7-ef57-41de-9f48-7ccc0127e458@github.com>

On Tue, 10 Dec 2019 12:03:03 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java line 626:
> 
>> 625:     protected void fire(KeyEvent event) { } // TODO move to TextFieldBehavior
>> 626:     protected void cancelEdit(KeyEvent event) { };
>> 627: 
> 
> Will this code removal re-introduce JDK-8145515?

no don't think so: the fix for JDK-8145515 was to prevent the triggering of parent.fireEvent, so removing the method altogether should have no effect :) Could add a test to explicitly guard against this.

Please note that the old combo issue is back in the form of https://bugs.openjdk.java.net/browse/JDK-8229914 - before and after fixing this, combo does very bad things ;)

-------------

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

From fastegal at openjdk.java.net  Tue Dec 10 14:02:37 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 10 Dec 2019 14:02:37 GMT
Subject: [Rev 01] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <pPU6AUC15PX-lz4_RsUG1sOQMusPTa1KhCgwWlez91o=.579604d7-ef57-41de-9f48-7ccc0127e458@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <Ctsq9u7-Tk2-BPkW_z8ZG_gxPjM7tHqUJ3yycE0WWXQ=.f9cd53be-f361-4e08-8d25-a6199458edd6@github.com>
 <Y5ptHsJsrynNQyAZO1YT_Eg59bkqltJxOMFA0-krOZU=.bcdc9744-4927-4b90-8d28-08612347ad3b@github.com>
 <pPU6AUC15PX-lz4_RsUG1sOQMusPTa1KhCgwWlez91o=.579604d7-ef57-41de-9f48-7ccc0127e458@github.com>
Message-ID: <VcneiKtfTkOToINVYOCpC48QvUlalLtM5_DJroxTP34=.66d4ccfc-e0b9-4217-abbe-1b2f2d6a3ba2@github.com>

On Tue, 10 Dec 2019 13:01:15 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java line 626:
>> 
>>> 625:     protected void fire(KeyEvent event) { } // TODO move to TextFieldBehavior
>>> 626:     protected void cancelEdit(KeyEvent event) { };
>>> 627: 
>> 
>> Will this code removal re-introduce JDK-8145515?
> 
> no don't think so: the fix for JDK-8145515 was to prevent the triggering of parent.fireEvent, so removing the method altogether should have no effect :) Could add a test to explicitly guard against this.
> 
> Please note that the old combo issue is back in the form of https://bugs.openjdk.java.net/browse/JDK-8229914 - before and after fixing this, combo does very bad things ;)

just to let you know: locally added test to explicitly guard against JDK-8145515 (and an ignored one for the regression JDK-8229914) - they are passing/failing the same before/after this fix. Will push later ...

-------------

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

From kcr at openjdk.java.net  Tue Dec 10 16:13:16 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 10 Dec 2019 16:13:16 GMT
Subject: RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <p3ivxS3wnBT0E9RT0Hb_ZQPJmdGT6FDEf_OUTanjWC0=.962bb7e1-a13e-47d8-80ce-5cdf0a6b174d@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <WHeu0iFuPN8qHCyxHAdn2MAc3ZeEAS01_To7CluV1ho=.a134587b-1a77-4928-b213-b0aca1cc32f7@github.com>
 <SNC1IdvQgKGx-eBg5C2691cRcApNnZH5D_rPVStbKAU=.45a242e1-940d-4983-9d4f-9a75b6b55952@github.com>
 <NkFJa_BRX0vLBWjSLfCD4XzU-JGAjDTLnFkRG5ROY9g=.c7a684c8-7eec-4fb8-9630-085a360dbbbb@github.com>
 <fhY-j1ZziMV1Ozi9a5wp6bpECydwxdRA8NbQnGYkVHE=.3ed28189-f765-47fe-9745-26d4640865f4@github.com>
 <p3ivxS3wnBT0E9RT0Hb_ZQPJmdGT6FDEf_OUTanjWC0=.962bb7e1-a13e-47d8-80ce-5cdf0a6b174d@github.com>
Message-ID: <l3EenqjJFYkaNfuCNiEH9_l9fnL19XDbD29XPIi-84U=.622aeb5b-7599-48d1-a438-c2903eb30005@github.com>

On Mon, 2 Dec 2019 11:09:05 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Preliminary review was here: [javafxports/openjdk-jfx/pull/490](https://github.com/javafxports/openjdk-jfx/pull/490)
> 
> Just a reminder to take a look when time allows.

I'm starting to look at this. I see at least one behavioral difference that will need to be addressed. With the existing implementation, if I drag / drop onto a target that set up to receive the drop, the transfer completes with a transfer mode of `null`. With your patch, the transfer never completes -- the `DRAG_DONE` event is never sent.

This can be most easily seen by running the `DragDropWithControls` app and doing one of the following two things:

1.  Drag from the source rectangle and drop somewhere _other than_ the target rectangle, for example, in the status text box at the bottom.
2. Change the source data format to `HTML` (uncheck `PLAINTEXT`), leaving the target at `PLAINTEXT`, then drag from the source rectangle and drop onto the target rectangle

In addition to the drop not happening, I get the following assertion error on Ubuntu 16.04:

(java:22328): Gdk-CRITICAL **: gdk_frame_clock_get_frame_time: assertion 'GDK_IS_FRAME_CLOCK (frame_clock)' failed

I'm using the default GTK 3 library.

-------------

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

From kcr at openjdk.java.net  Tue Dec 10 16:27:26 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 10 Dec 2019 16:27:26 GMT
Subject: RFR: 8223296: NullPointerException in GlassScene.java at line 325
In-Reply-To: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
References: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
Message-ID: <7mDsBwxFZM7g_Wiqa2CE1z1S1sJcedl_MhoROCFH6v4=.cd69fc5c-1a4e-42ab-a5af-190f5ddffab1@github.com>

On Tue, 10 Dec 2019 07:00:50 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue: NPE in GlassScene.frameRendered().
> 
> Cause: scenePaintListener is set in setTKScenePaintListener(), used in frameRendered() and 
> set to null in dispose().
> setTKScenePaintListener() and dispose() are called on JavaFX Application Thread and 
> frameRendered() is called by QuantumRenderer thread.
> setTKScenePaintListener() and frameRendered() are synchronized but dispose() is not.
> 
> Fix:
> dispose() should use the synchronized setTKScenePaintListener() to set scenePaintListener to null.
> 
> Verification:
> This is a very rare issue and cannot be reliably reproduced with a test case.

The change looks OK as far as it goes, meaning that it will fix the specific NPE reported by the bug and is looks like a safe fix.

Two questions:

1. In addition to calling the synchronized `setTKScenePaintListener` method, you moved the call to the beginning of `dispose`. Is there a reason you needed to do this?
2. Do any of the other listeners or variables that are set in `dispose` have the same problem (i.e., are any the rest accessed from another thread)?

-------------



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

From kcr at openjdk.java.net  Tue Dec 10 18:38:06 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 10 Dec 2019 18:38:06 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
Message-ID: <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>

On Tue, 10 Dec 2019 18:38:04 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both.  TextFlow's tab size overrides that of contained Text nodes.
> 
> The pull request has been updated with 1 additional commit.

Overall this looks good to me with one "must fix" API issue and one additional minor comment.

In addition to the automated unit test, it might be nice to have a simple app (in `apps/toys`) with a slider to control the tab size of a Text and/or TextFlow. This could be done as a follow-on issue if you prefer.

Once you fix the public API issue, you can add ithe API to the CSR and I'll review it. The javadoc, public methods, and CSS additions for the three classes should go into the CSR in the specification section. See [JDK-8195139](https://bugs.openjdk.java.net/browse/JDK-8195139) for a good example.

@prrace still needs to review the implementation and API as well.

modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 78:

> 77: 
> 78:     static final int DEFAULT_TAB_SIZE = 8;
> 79: 

Although it doesn't matter, since fields of public interfaces are public by default, it might be clearer to add `public` here for consistency with the other members.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 509:

> 508: 
> 509:     final IntegerProperty tabSizeProperty() {
> 510:         if (tabSize == null) {

The `tabSizeProperty` method needs to be public in order for it to be part of the API and for `textSize` to be a property (which is what we want).

Also, please move `tabSizeProperty` above the set / get methods (leaving the javadoc comment block where it is). I realize that we aren't consistent in how we do this, but for new properties, we are trying to have the javadoc comments be on the property method (it's OK if the comment block is above the private instance of the `Property`), followed by the setter and getter.

-------------

Changes requested by kcr (Lead).

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

From kcr at openjdk.java.net  Tue Dec 10 18:54:16 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 10 Dec 2019 18:54:16 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
Message-ID: <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>

On Tue, 10 Dec 2019 18:37:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> Overall this looks good to me with one "must fix" API issue and one additional minor comment.
> 
> In addition to the automated unit test, it might be nice to have a simple app (in `apps/toys`) with a slider to control the tab size of a Text and/or TextFlow. This could be done as a follow-on issue if you prefer.
> 
> Once you fix the public API issue, you can add ithe API to the CSR and I'll review it. The javadoc, public methods, and CSS additions for the two classes should go into the CSR in the specification section. See [JDK-8195139](https://bugs.openjdk.java.net/browse/JDK-8195139) for a good example.
> 
> @prrace still needs to review the implementation and API as well.

> Should this PR also add a tabSize property to controls such as TextArea? Or should that be a different PR after this one is merged?

This would need to be a new enhancement and would first need to be discussed on the openjfx-dev mailing list. There are additional things to consider in order to support tab size for controls, and it isn't clear whether there is enough benefit in doing it.

-------------

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

From tsayao at openjdk.java.net  Tue Dec 10 19:41:19 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Tue, 10 Dec 2019 19:41:19 GMT
Subject: RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <l3EenqjJFYkaNfuCNiEH9_l9fnL19XDbD29XPIi-84U=.622aeb5b-7599-48d1-a438-c2903eb30005@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <WHeu0iFuPN8qHCyxHAdn2MAc3ZeEAS01_To7CluV1ho=.a134587b-1a77-4928-b213-b0aca1cc32f7@github.com>
 <SNC1IdvQgKGx-eBg5C2691cRcApNnZH5D_rPVStbKAU=.45a242e1-940d-4983-9d4f-9a75b6b55952@github.com>
 <NkFJa_BRX0vLBWjSLfCD4XzU-JGAjDTLnFkRG5ROY9g=.c7a684c8-7eec-4fb8-9630-085a360dbbbb@github.com>
 <fhY-j1ZziMV1Ozi9a5wp6bpECydwxdRA8NbQnGYkVHE=.3ed28189-f765-47fe-9745-26d4640865f4@github.com>
 <p3ivxS3wnBT0E9RT0Hb_ZQPJmdGT6FDEf_OUTanjWC0=.962bb7e1-a13e-47d8-80ce-5cdf0a6b174d@github.com>
 <l3EenqjJFYkaNfuCNiEH9_l9fnL19XDbD29XPIi-84U=.622aeb5b-7599-48d1-a438-c2903eb30005@github.com>
Message-ID: <OHUzoAQPQqQYpYTiZ7JPJzoLOzuRxlD9aC5eD0aB_e0=.7674951a-62fb-4b88-b290-94ea9af729db@github.com>

On Tue, 10 Dec 2019 16:13:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Just a reminder to take a look when time allows.
> 
> I'm starting to look at this. I see at least one behavioral difference that will need to be addressed. With the existing implementation, if I drag / drop onto a target that set up to receive the drop, the transfer completes with a transfer mode of `null`. With your patch, the transfer never completes -- the `DRAG_DONE` event is never sent.
> 
> This can be most easily seen by running the `DragDropWithControls` app and doing one of the following two things:
> 
> 1.  Drag from the source rectangle and drop somewhere _other than_ the target rectangle, for example, in the status text box at the bottom.
> 2. Change the source data format to `HTML` (uncheck `PLAINTEXT`), leaving the target at `PLAINTEXT`, then drag from the source rectangle and drop onto the target rectangle
> 
> In addition to the drop not happening, I get the following assertion error on Ubuntu 16.04:
> 
> (java:22328): Gdk-CRITICAL **: gdk_frame_clock_get_frame_time: assertion 'GDK_IS_FRAME_CLOCK (frame_clock)' failed
> 
> I'm using the default GTK 3 library.

@kevinrushforth I changed that behaviour. Since the drag does not complete i find it counter-intuitive to send the DRAG_DONE event.

Does it send the event on other platforms? I can test on Windows.

Will look into the assertion error - it does not happen on 18.04.

-------------

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

From kevin.rushforth at oracle.com  Tue Dec 10 21:45:43 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 10 Dec 2019 13:45:43 -0800
Subject: Proposed schedule for JavaFX 14
In-Reply-To: <cc85e35a-28c0-5f8a-521e-5cb447da4399@oracle.com>
References: <cc85e35a-28c0-5f8a-521e-5cb447da4399@oracle.com>
Message-ID: <536d8828-eb99-2aad-8e3b-d314f86c6b4a@oracle.com>

As a reminder, RDP1 for JavaFX 14 starts on January 6, 2020 (at 23:59 
Pacific time).

With the holidays approaching, please allow sufficient time for any 
feature that needs a CSR. New features should be far enough along in the 
review process so you can finalize the CSR before next Friday, Dec 20, 
or it is likely to miss the window for this release, in which case it 
can be targeted for JavaFX 15.

During rampdown of JavaFX 14, the "master" branch of the jfx repo will 
be open for JavaFX 15 fixes.

We will follow the same process as previous releases for getting fixes 
into JavaFX 14 during rampdown. I'll send a message with detailed 
information later, but generally candidates for fixing after RDP1 are 
P1-P3 bugs (as long as they are not risky) and test or doc bugs of any 
priority.

-- Kevin


On 9/20/2019 8:00 AM, Kevin Rushforth wrote:
> Here is the proposed schedule for JavaFX 14.
>
> RDP1: Jan 6, 2020 (aka ?feature freeze?)
> RDP2: Feb 3, 2020
> Freeze: Feb 24, 2020
> GA: March 10, 2020
>
> We plan to fork a jfx14 stabilization branch at RDP1. The GA date is 
> expected to be one week ahead of JDK 14, matching what we did for 13.
>
> Please let Johan or me know if you have any questions.
>
> -- Kevin
>


From kcr at openjdk.java.net  Tue Dec 10 23:52:04 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 10 Dec 2019 23:52:04 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
Message-ID: <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>

On Tue, 10 Dec 2019 18:54:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Overall this looks good to me with one "must fix" API issue and one additional minor comment.
>> 
>> In addition to the automated unit test, it might be nice to have a simple app (in `apps/toys`) with a slider to control the tab size of a Text and/or TextFlow. This could be done as a follow-on issue if you prefer.
>> 
>> Once you fix the public API issue, you can add ithe API to the CSR and I'll review it. The javadoc, public methods, and CSS additions for the two classes should go into the CSR in the specification section. See [JDK-8195139](https://bugs.openjdk.java.net/browse/JDK-8195139) for a good example.
>> 
>> @prrace still needs to review the implementation and API as well.
> 
>> Should this PR also add a tabSize property to controls such as TextArea? Or should that be a different PR after this one is merged?
> 
> This would need to be a new enhancement and would first need to be discussed on the openjfx-dev mailing list. There are additional things to consider in order to support tab size for controls, and it isn't clear whether there is enough benefit in doing it.

As a follow-on point to the missing public method in TextFlow, can you add unit tests for the API methods on both `Text` and `TextFlow`? A good way to do that is to have a test for all combinations of setting the value via the setter and the property method, and getting the value via the getter and the property method.

-------------

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

From kcr at openjdk.java.net  Tue Dec 10 23:53:38 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 10 Dec 2019 23:53:38 GMT
Subject: RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <OHUzoAQPQqQYpYTiZ7JPJzoLOzuRxlD9aC5eD0aB_e0=.7674951a-62fb-4b88-b290-94ea9af729db@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <WHeu0iFuPN8qHCyxHAdn2MAc3ZeEAS01_To7CluV1ho=.a134587b-1a77-4928-b213-b0aca1cc32f7@github.com>
 <SNC1IdvQgKGx-eBg5C2691cRcApNnZH5D_rPVStbKAU=.45a242e1-940d-4983-9d4f-9a75b6b55952@github.com>
 <NkFJa_BRX0vLBWjSLfCD4XzU-JGAjDTLnFkRG5ROY9g=.c7a684c8-7eec-4fb8-9630-085a360dbbbb@github.com>
 <fhY-j1ZziMV1Ozi9a5wp6bpECydwxdRA8NbQnGYkVHE=.3ed28189-f765-47fe-9745-26d4640865f4@github.com>
 <p3ivxS3wnBT0E9RT0Hb_ZQPJmdGT6FDEf_OUTanjWC0=.962bb7e1-a13e-47d8-80ce-5cdf0a6b174d@github.com>
 <l3EenqjJFYkaNfuCNiEH9_l9fnL19XDbD29XPIi-84U=.622aeb5b-7599-48d1-a438-c2903eb30005@github.com>
 <OHUzoAQPQqQYpYTiZ7JPJzoLOzuRxlD9aC5eD0aB_e0=.7674951a-62fb-4b88-b290-94ea9af729db@github.com>
Message-ID: <j91X09JTJiBqbnjlfOWg4asgRcsnEqGVbbOEOuvPJ-8=.635343a1-63fa-4987-aa7c-96226f9151ea@github.com>

On Tue, 10 Dec 2019 19:41:05 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> I'm starting to look at this. I see at least one behavioral difference that will need to be addressed. With the existing implementation, if I drag / drop onto a target that set up to receive the drop, the transfer completes with a transfer mode of `null`. With your patch, the transfer never completes -- the `DRAG_DONE` event is never sent.
>> 
>> This can be most easily seen by running the `DragDropWithControls` app and doing one of the following two things:
>> 
>> 1.  Drag from the source rectangle and drop somewhere _other than_ the target rectangle, for example, in the status text box at the bottom.
>> 2. Change the source data format to `HTML` (uncheck `PLAINTEXT`), leaving the target at `PLAINTEXT`, then drag from the source rectangle and drop onto the target rectangle
>> 
>> In addition to the drop not happening, I get the following assertion error on Ubuntu 16.04:
>> 
>> (java:22328): Gdk-CRITICAL **: gdk_frame_clock_get_frame_time: assertion 'GDK_IS_FRAME_CLOCK (frame_clock)' failed
>> 
>> I'm using the default GTK 3 library.
> 
> @kevinrushforth I changed that behaviour. Since the drag does not complete i find it counter-intuitive to send the DRAG_DONE event.
> 
> Does it send the event on other platforms? I can test on Windows.
> 
> Will look into the assertion error - it does not happen on 18.04.

> Does it send the event on other platforms? I can test on Windows.

Yes, it always sends the `DRAG_DONE` event on all platforms today (I tested it on Mac, Windows, and Linux).

> Will look into the assertion error - it does not happen on 18.04.

It doesn't happen on 19.10 either. Only 16.04 as far as I have tested. I'll also test on Oracle Linux 7.x.

-------------

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

From kcr at openjdk.java.net  Wed Dec 11 00:21:36 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 11 Dec 2019 00:21:36 GMT
Subject: RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <j91X09JTJiBqbnjlfOWg4asgRcsnEqGVbbOEOuvPJ-8=.635343a1-63fa-4987-aa7c-96226f9151ea@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <WHeu0iFuPN8qHCyxHAdn2MAc3ZeEAS01_To7CluV1ho=.a134587b-1a77-4928-b213-b0aca1cc32f7@github.com>
 <SNC1IdvQgKGx-eBg5C2691cRcApNnZH5D_rPVStbKAU=.45a242e1-940d-4983-9d4f-9a75b6b55952@github.com>
 <NkFJa_BRX0vLBWjSLfCD4XzU-JGAjDTLnFkRG5ROY9g=.c7a684c8-7eec-4fb8-9630-085a360dbbbb@github.com>
 <fhY-j1ZziMV1Ozi9a5wp6bpECydwxdRA8NbQnGYkVHE=.3ed28189-f765-47fe-9745-26d4640865f4@github.com>
 <p3ivxS3wnBT0E9RT0Hb_ZQPJmdGT6FDEf_OUTanjWC0=.962bb7e1-a13e-47d8-80ce-5cdf0a6b174d@github.com>
 <l3EenqjJFYkaNfuCNiEH9_l9fnL19XDbD29XPIi-84U=.622aeb5b-7599-48d1-a438-c2903eb30005@github.com>
 <OHUzoAQPQqQYpYTiZ7JPJzoLOzuRxlD9aC5eD0aB_e0=.7674951a-62fb-4b88-b290-94ea9af729db@github.com>
 <j91X09JTJiBqbnjlfOWg4asgRcsnEqGVbbOEOuvPJ-8=.635343a1-63fa-4987-aa7c-96226f9151ea@github.com>
Message-ID: <qlhWDpZ-Ph8WOyOgUuToJoNRJEhyopT-HNC9Qmh1dwY=.2e07ac1d-12b3-45b1-84d4-b2f6958836fe@github.com>

On Tue, 10 Dec 2019 23:53:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @kevinrushforth I changed that behaviour. Since the drag does not complete i find it counter-intuitive to send the DRAG_DONE event.
>> 
>> Does it send the event on other platforms? I can test on Windows.
>> 
>> Will look into the assertion error - it does not happen on 18.04.
> 
>> Does it send the event on other platforms? I can test on Windows.
> 
> Yes, it always sends the `DRAG_DONE` event on all platforms today (I tested it on Mac, Windows, and Linux).
> 
>> Will look into the assertion error - it does not happen on 18.04.
> 
> It doesn't happen on 19.10 either. Only 16.04 as far as I have tested. I'll also test on Oracle Linux 7.x.

I don't get an assertion error on Oracle Linux 7.7 -- so far only on Ubuntu 16.04. I will resume reviewing once you restore the `DRAG_DONE` behavior.

-------------

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

From kcr at openjdk.java.net  Wed Dec 11 00:22:35 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 11 Dec 2019 00:22:35 GMT
Subject: [Rev 02] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <Bxi0nXEHvko4vGnDCIkPnwTyqVAsAKLqgcdOdYMNjr0=.11a7e106-02e4-4e85-8fb9-ba3d869823b3@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <uT_F0PLNvqSOmLGOxFr9QZC8peVoblo420PaCvBVY_s=.ee21a610-58bc-42d7-970d-f826fb14467c@github.com>
 <LohiEWCZSrtL2p7thWCfSRxHMJ_EbcPtpHODBqP7Egg=.2d50d792-90eb-49a2-8cb2-6f1cbef5b93f@github.com>
 <Bxi0nXEHvko4vGnDCIkPnwTyqVAsAKLqgcdOdYMNjr0=.11a7e106-02e4-4e85-8fb9-ba3d869823b3@github.com>
Message-ID: <ZLdq32EF0yZQXiufvXpOlBUDnsdOfDVcGjVb80ZgNDw=.20a69f73-8abd-4d03-9264-93667341a4cb@github.com>

On Wed, 27 Nov 2019 10:51:10 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1895:
>> 
>>> 1894:                     }
>>> 1895:                     @Override public void set(int v) { super.set((v < 1) ? 1 : v); }
>>> 1896:                     @Override protected void invalidated() {
>> 
>> For mutable properties, we usually clamp on usage, so that we don't have problems binding to the value. This preserves the invariant that `set(val); get() == val` for all values. If that is what we end up doing, then this overridden method should be removed.
> 
> Hmm ... so you are saying the clamping is the responsibility of client code (internal as well as external)?

In this case, yes.

-------------

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

From kcr at openjdk.java.net  Wed Dec 11 00:32:51 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 11 Dec 2019 00:32:51 GMT
Subject: [Rev 05] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <21f1pJ4D38KMemipRY1jP-omCI5I_VJXTXb8gznQvx0=.928f2c83-97e0-4de9-8280-e1585701a153@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <jgyrznjFlcuhYXcXP3uIRbNTbR4V-1YjU2cyT8k2yo4=.af36bdb2-a728-418a-8f54-0e418e498c30@github.com>
 <xEH1ebDM4o5xphO7OExOSRWH8Ja-pcCRiVq3s0dPIWE=.3cc0b63a-9111-4f65-81d3-b660192a96c4@github.com>
 <OtAAQoKEmvXJs1gD4SwJkXS95FLS8TiDHuasdfJvVqk=.65613f71-f069-4666-a269-9c36df5b9539@github.com>
 <21f1pJ4D38KMemipRY1jP-omCI5I_VJXTXb8gznQvx0=.928f2c83-97e0-4de9-8280-e1585701a153@github.com>
Message-ID: <SqH9DD8EmBI5NZ4rkcy7-OYrpm2Ecun0K2OdRWyTJMA=.db42e730-6a2d-4336-94b1-4279d6e7030c@github.com>

On Mon, 9 Dec 2019 23:20:19 GMT, Hadzic Samir <shadzic at openjdk.org> wrote:

>> I would like both @aghaisas and myself to review / approve this. I will sponsor it.
>> 
>> In addition, the CSR needs to be approved before this can be integrated.
> 
> Thanks for the review. I do not have access to a computer right now, I'll
> update next week on Monday.
> 
> Le lun. 9 d?c. 2019 ? 17:01, Kevin Rushforth <notifications at github.com> a
> ?crit :
> 
>> I would like both @aghaisas <https://github.com/aghaisas> and myself to
>> review / approve this. I will sponsor it.
>>
>> In addition, the CSR needs to be approved before this can be integrated.
>>
>> ?
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/openjdk/jfx/pull/6?email_source=notifications&email_token=ACEL43KWFAJ32FX3NNSM7ETQX2W3LA5CNFSM4I5EYYAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKV3YQ#issuecomment-563437026>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/ACEL43PNZLRK37IM33ROVGDQX2W3LANCNFSM4I5EYYAA>
>> .
>>

I took the liberty of updating the CSR to add the missing comma, so I could mark it as Reviewed. You can Finalize the CSR when you are ready.

-------------

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

From tsayao at openjdk.java.net  Wed Dec 11 00:40:32 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 11 Dec 2019 00:40:32 GMT
Subject: [Rev 01] RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
Message-ID: <7nfExP1I2um0gRZI4g12NOLoaH9OzMZmLP3NROHw-eY=.5279b200-df59-469c-bebc-5c0dcc84a923@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8225571
> 
> To run tests (on the root of the source tree):
> ./gradlew apps
> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
> 
> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - d16fc2c6: Restore DRAG_DONE behaviour

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/4/files
  - new: https://git.openjdk.java.net/jfx/pull/4/files/3d650b2b..d16fc2c6

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

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/4.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/4/head:pull/4

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

From tsayao at openjdk.java.net  Wed Dec 11 00:41:32 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 11 Dec 2019 00:41:32 GMT
Subject: [Rev 02] RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
Message-ID: <aU6lR0H1r1mHEPBNMtMhb9hLNFTZ24rllx3gen1w6dk=.e794fb7c-e4bb-4db9-8870-ba7084efc0bb@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8225571
> 
> To run tests (on the root of the source tree):
> ./gradlew apps
> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
> 
> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 554734c0: Remove blank line

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/4/files
  - new: https://git.openjdk.java.net/jfx/pull/4/files/d16fc2c6..554734c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/4/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/4/webrev.01-02

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

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

From tsayao at openjdk.java.net  Wed Dec 11 00:44:00 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 11 Dec 2019 00:44:00 GMT
Subject: [Rev 03] RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
Message-ID: <2HqFjCC9XBa2DGuiHsnCeAAqPHKJsZ7OA8EzsBsDABg=.9b45fbea-bceb-4af6-afa1-41fe01846db9@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8225571
> 
> To run tests (on the root of the source tree):
> ./gradlew apps
> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
> 
> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor

Previous commits in this pull request have been removed, probably due to a force push. The incremental views will show differences compared to the previous content of the PR.

-------------

Added commits:
 - 47155b08: Remove blank line

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/4/files
  - new: https://git.openjdk.java.net/jfx/pull/4/files/554734c0..47155b08

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/4/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/4/webrev.02-03

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

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

From swpalmer at openjdk.java.net  Wed Dec 11 01:04:24 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Wed, 11 Dec 2019 01:04:24 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
 <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
Message-ID: <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>

On Tue, 10 Dec 2019 23:51:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> Should this PR also add a tabSize property to controls such as TextArea? Or should that be a different PR after this one is merged?
>> 
>> This would need to be a new enhancement and would first need to be discussed on the openjfx-dev mailing list. There are additional things to consider in order to support tab size for controls, and it isn't clear whether there is enough benefit in doing it.
> 
> As a follow-on point to the missing public method in TextFlow, can you add unit tests for the API methods on both `Text` and `TextFlow`? A good way to do that is to have a test for all combinations of setting the value via the setter and the property method, and getting the value via the getter and the property method.

The unit tests that were already added to `TextTest.java` cover the new methods on Text, but not in every combination.  I'll add a couple more to ensure all combinations are covered. `TextFlow` has no existing unit tests that I could find!  Shall I add a new `TextFlowText.java` file for just these tests?

The apps/toys folder seems to use ant-based projects.  The existing ones don't build for me. If I made a new project there could I use the JavaFX Gradle plugin and configure it to get JavaFX from the build/sdk folder?

-------------

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

From kcr at openjdk.java.net  Wed Dec 11 01:18:55 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 11 Dec 2019 01:18:55 GMT
Subject: [Rev 01] RFR: 8227808: Make GTK3 libraries mandatory for building
 on Linux
In-Reply-To: <MqS3QSREoojWi42jbjScXZ0BmaROUg8km1DCPnbmgws=.df5efb19-41b6-4336-94f2-383ca92970ce@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
 <MqS3QSREoojWi42jbjScXZ0BmaROUg8km1DCPnbmgws=.df5efb19-41b6-4336-94f2-383ca92970ce@github.com>
Message-ID: <gEc1q6EYhmEnMzxH-47DeQEJTjzbvq7XaT5zbL3b9Rk=.12ee4ff1-3ef9-4322-babc-29e172ebc469@github.com>

On Wed, 11 Dec 2019 01:18:55 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Need for the change [[JDK-8227808](https://bugs.openjdk.java.net/browse/JDK-8227808)]:
>> Currently GTK3 is the default on Linux. However, there is build logic that will skip building glassgtk3 if the gtk3 development libraries are not installed. This creates a situation where the build will succeed, but the resulting JavaFX library will fail to run unless you explicitly force GTK2 with "-Djdk.gtk.version=2". 
>> 
>> How to verify the change:
>> On a Linux system without gtk2 and gtk3 packages,
>> 1. Clone jfx and run gradle sdk.
>> -> Build should fail with an error for missing GTK3 packages.
>> 
>> 2. Install gtk3 packages, remove build directory and run gradle clean sdk.
>> -> Build should fail with an error for missing GTK2 packages.
>> 
>> 3. Install gtk2 packages, remove build directory and run gradle clean sdk.
>> -> Build should finish without any error.
>> 
>> Build verification:
>> 1. Run a JavaFX application with -Djdk.gtk.verbose=true
>> Verify the verbose message, the default glassgtk3 library should be used.
>> 
>> 2. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=2
>> Verify the verbose message, glassgtk2 library should be used.
>> 
>> 3. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=3
>> Verify the verbose message, glassgtk3 library should be used.
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.java.net  Wed Dec 11 01:19:16 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 11 Dec 2019 01:19:16 GMT
Subject: [Rev 01] RFR: 8227808: Make GTK3 libraries mandatory for building
 on Linux
In-Reply-To: <gEc1q6EYhmEnMzxH-47DeQEJTjzbvq7XaT5zbL3b9Rk=.12ee4ff1-3ef9-4322-babc-29e172ebc469@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
 <MqS3QSREoojWi42jbjScXZ0BmaROUg8km1DCPnbmgws=.df5efb19-41b6-4336-94f2-383ca92970ce@github.com>
 <gEc1q6EYhmEnMzxH-47DeQEJTjzbvq7XaT5zbL3b9Rk=.12ee4ff1-3ef9-4322-babc-29e172ebc469@github.com>
Message-ID: <Qg1PQQgoY0asN8XM6IBd8irz_bNzm9OR2dVtW-uxtlM=.9288acfa-d8a4-4618-9356-39aff2046bdd@github.com>

On Wed, 11 Dec 2019 01:18:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> 

This will also need a second review from @johanvos

-------------

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

From kcr at openjdk.java.net  Wed Dec 11 01:23:04 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 11 Dec 2019 01:23:04 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
 <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
 <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>
Message-ID: <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>

On Wed, 11 Dec 2019 01:04:15 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> As a follow-on point to the missing public method in TextFlow, can you add unit tests for the API methods on both `Text` and `TextFlow`? A good way to do that is to have a test for all combinations of setting the value via the setter and the property method, and getting the value via the getter and the property method.
> 
> The unit tests that were already added to `TextTest.java` cover the new methods on Text, but not in every combination.  I'll add a couple more to ensure all combinations are covered. `TextFlow` has no existing unit tests that I could find!  Shall I add a new `TextFlowText.java` file for just these tests?
> 
> The apps/toys folder seems to use ant-based projects.  The existing ones don't build for me. If I made a new project there could I use the JavaFX Gradle plugin and configure it to get JavaFX from the build/sdk folder?

I think a new `TextFlowTest.java` would be a good place for those tests.

Our build is set up to use `ant` so if you want to wire it up to the build, you'll need that (it should be as simple as having `ANT_HOME` set to `apache-ant-1.10.5`). It would be fine to defer this if you can't get it working.

-------------

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

From fastegal at openjdk.java.net  Wed Dec 11 12:26:27 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 11 Dec 2019 12:26:27 GMT
Subject: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
Message-ID: <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>

> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759
> 
> The issue is that default/cancel button on a scene are triggered even though a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug for details on both cause and fix.
> 
> There are additional/changed tests to verify the fix. All old tests are passing.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 7c10ad1d: added tests to guard against JDK-8145515

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/15/files
  - new: https://git.openjdk.java.net/jfx/pull/15/files/fdf97072..7c10ad1d

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/15/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/15/webrev.01-02

  Stats: 40 lines in 1 file changed: 40 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/15.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/15/head:pull/15

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

From fastegal at openjdk.java.net  Wed Dec 11 12:35:06 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 11 Dec 2019 12:35:06 GMT
Subject: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <VcneiKtfTkOToINVYOCpC48QvUlalLtM5_DJroxTP34=.66d4ccfc-e0b9-4217-abbe-1b2f2d6a3ba2@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <Ctsq9u7-Tk2-BPkW_z8ZG_gxPjM7tHqUJ3yycE0WWXQ=.f9cd53be-f361-4e08-8d25-a6199458edd6@github.com>
 <Y5ptHsJsrynNQyAZO1YT_Eg59bkqltJxOMFA0-krOZU=.bcdc9744-4927-4b90-8d28-08612347ad3b@github.com>
 <pPU6AUC15PX-lz4_RsUG1sOQMusPTa1KhCgwWlez91o=.579604d7-ef57-41de-9f48-7ccc0127e458@github.com>
 <VcneiKtfTkOToINVYOCpC48QvUlalLtM5_DJroxTP34=.66d4ccfc-e0b9-4217-abbe-1b2f2d6a3ba2@github.com>
Message-ID: <M2aMMCeIfp3pAb9PTDH07XRw3T9M3iFDU2wrC3IwGto=.a130450c-38d5-4926-94ca-2aa3863fe8ab@github.com>

On Tue, 10 Dec 2019 14:02:23 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> no don't think so: the fix for JDK-8145515 was to prevent the triggering of parent.fireEvent, so removing the method altogether should have no effect :) Could add a test to explicitly guard against this.
>> 
>> Please note that the old combo issue is back in the form of https://bugs.openjdk.java.net/browse/JDK-8229914 - before and after fixing this, combo does very bad things ;)
> 
> just to let you know: locally added test to explicitly guard against JDK-8145515 (and an ignored one for the regression JDK-8229914) - they are passing/failing the same before/after this fix. Will push later ...

pushed

-------------

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

From fastegal at openjdk.java.net  Wed Dec 11 15:07:50 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 11 Dec 2019 15:07:50 GMT
Subject: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <M2aMMCeIfp3pAb9PTDH07XRw3T9M3iFDU2wrC3IwGto=.a130450c-38d5-4926-94ca-2aa3863fe8ab@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <Ctsq9u7-Tk2-BPkW_z8ZG_gxPjM7tHqUJ3yycE0WWXQ=.f9cd53be-f361-4e08-8d25-a6199458edd6@github.com>
 <Y5ptHsJsrynNQyAZO1YT_Eg59bkqltJxOMFA0-krOZU=.bcdc9744-4927-4b90-8d28-08612347ad3b@github.com>
 <pPU6AUC15PX-lz4_RsUG1sOQMusPTa1KhCgwWlez91o=.579604d7-ef57-41de-9f48-7ccc0127e458@github.com>
 <VcneiKtfTkOToINVYOCpC48QvUlalLtM5_DJroxTP34=.66d4ccfc-e0b9-4217-abbe-1b2f2d6a3ba2@github.com>
 <M2aMMCeIfp3pAb9PTDH07XRw3T9M3iFDU2wrC3IwGto=.a130450c-38d5-4926-94ca-2aa3863fe8ab@github.com>
Message-ID: <jYNGe_E7KIY5048WQbji5S4uOLKsmkwqPdmn4_ZyCDc=.871f0d2a-31af-4870-a18a-53d1be29f7eb@github.com>

On Wed, 11 Dec 2019 12:34:51 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> just to let you know: locally added test to explicitly guard against JDK-8145515 (and an ignored one for the regression JDK-8229914) - they are passing/failing the same before/after this fix. Will push later ...
> 
> pushed

fwiw: wrote a short summary of enter handling in comboBox (that is JDK-8145515 and related) https://github.com/kleopatra/swingempire-fx/wiki/ComboBoxEnterHandling

-------------

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

From arapte at openjdk.java.net  Wed Dec 11 15:55:40 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 11 Dec 2019 15:55:40 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
Message-ID: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>

The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed.

The change is,
1. Remove finalize method from PiscesRenderer and AbstractSurface classes.
2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize().  For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java.
3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method.

Verification:
Verified that the newly added dispose() methods get invoked as required and no OOM occurs.
1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop.
2. Run the program using -Dprism.order=sw,  -Dprism.verbose=true. (optional -Xmx50m)
Expected Behavior: 
a. Maximum memory consumption after this change should reduce or remain same as that of before this change.
b. No OOM should occur with this change or without this change.

-------------

Commits:
 - 31df0ebc: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface

Changes: https://git.openjdk.java.net/jfx/pull/66/files
 Webrev: https://webrevs.openjdk.java.net/jfx/66/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8235772
  Stats: 111 lines in 5 files changed: 40 ins; 52 del; 19 mod
  Patch: https://git.openjdk.java.net/jfx/pull/66.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/66/head:pull/66

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

From kcr at openjdk.java.net  Wed Dec 11 16:07:08 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 11 Dec 2019 16:07:08 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
Message-ID: <tvfZ7QacQJrnkY4xkfVUXnd3hoB_LAQlP1pE9wkcf3Q=.3f0339ae-0fc8-4ee5-8500-5f1c31f2de11@github.com>

On Wed, 11 Dec 2019 15:41:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
> And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed.
> 
> The change is,
> 1. Remove finalize method from PiscesRenderer and AbstractSurface classes.
> 2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize().  For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java.
> 3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method.
> 
> Verification:
> Verified that the newly added dispose() methods get invoked as required and no OOM occurs.
> 1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop.
> 2. Run the program using -Dprism.order=sw,  -Dprism.verbose=true. (optional -Xmx50m)
> Expected Behavior: 
> a. Maximum memory consumption after this change should reduce or remain same as that of before this change.
> b. No OOM should occur with this change or without this change.

This will need two reviewers.

-------------

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

From nlisker at openjdk.java.net  Wed Dec 11 16:24:08 2019
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 11 Dec 2019 16:24:08 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <tvfZ7QacQJrnkY4xkfVUXnd3hoB_LAQlP1pE9wkcf3Q=.3f0339ae-0fc8-4ee5-8500-5f1c31f2de11@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
 <tvfZ7QacQJrnkY4xkfVUXnd3hoB_LAQlP1pE9wkcf3Q=.3f0339ae-0fc8-4ee5-8500-5f1c31f2de11@github.com>
Message-ID: <7Bd9VDNpJzT9qomxTeN5VcX5pWSWkTM9bd45-arj06I=.97428321-6b8e-40f5-92b1-c2a18696f594@github.com>

On Wed, 11 Dec 2019 16:06:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
>> And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed.
>> 
>> The change is,
>> 1. Remove finalize method from PiscesRenderer and AbstractSurface classes.
>> 2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize().  For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java.
>> 3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method.
>> 
>> Verification:
>> Verified that the newly added dispose() methods get invoked as required and no OOM occurs.
>> 1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop.
>> 2. Run the program using -Dprism.order=sw,  -Dprism.verbose=true. (optional -Xmx50m)
>> Expected Behavior: 
>> a. Maximum memory consumption after this change should reduce or remain same as that of before this change.
>> b. No OOM should occur with this change or without this change.
> 
> This will need two reviewers.

Isn't Pisces going to be completely removed anyway?

-------------

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

From kcr at openjdk.java.net  Wed Dec 11 16:31:46 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 11 Dec 2019 16:31:46 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <7Bd9VDNpJzT9qomxTeN5VcX5pWSWkTM9bd45-arj06I=.97428321-6b8e-40f5-92b1-c2a18696f594@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
 <tvfZ7QacQJrnkY4xkfVUXnd3hoB_LAQlP1pE9wkcf3Q=.3f0339ae-0fc8-4ee5-8500-5f1c31f2de11@github.com>
 <7Bd9VDNpJzT9qomxTeN5VcX5pWSWkTM9bd45-arj06I=.97428321-6b8e-40f5-92b1-c2a18696f594@github.com>
Message-ID: <_MbbQTIujkzkZh6KD6vxS-CG91SHX886OlT4n3QQMZY=.997206e1-3095-4bb4-8a0f-cdfaeb31e9f4@github.com>

On Wed, 11 Dec 2019 16:23:49 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> This will need two reviewers.
> 
> Isn't Pisces going to be completely removed anyway?

The Pisces rasterizer will be removed, but as it turns out, the two classes in question are used by the prism-sw pipeline as part of the Pisces-based software renderer.

See the comment I added to [JDK-8196079](https://bugs.openjdk.java.net/browse/JDK-8196079).

-------------

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

From arapte at openjdk.java.net  Wed Dec 11 17:10:50 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 11 Dec 2019 17:10:50 GMT
Subject: RFR: 8223296: NullPointerException in GlassScene.java at line 325
In-Reply-To: <7mDsBwxFZM7g_Wiqa2CE1z1S1sJcedl_MhoROCFH6v4=.cd69fc5c-1a4e-42ab-a5af-190f5ddffab1@github.com>
References: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
 <7mDsBwxFZM7g_Wiqa2CE1z1S1sJcedl_MhoROCFH6v4=.cd69fc5c-1a4e-42ab-a5af-190f5ddffab1@github.com>
Message-ID: <0RBgCac9Puzvny45Z95_HQ4hlwLFx5kdUjXXrQYcIx4=.ae6ca62a-ac0f-4eef-a8b7-6b9a702cce6c@github.com>

On Tue, 10 Dec 2019 16:27:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Issue: NPE in GlassScene.frameRendered().
>> 
>> Cause: scenePaintListener is set in setTKScenePaintListener(), used in frameRendered() and 
>> set to null in dispose().
>> setTKScenePaintListener() and dispose() are called on JavaFX Application Thread and 
>> frameRendered() is called by QuantumRenderer thread.
>> setTKScenePaintListener() and frameRendered() are synchronized but dispose() is not.
>> 
>> Fix:
>> dispose() should use the synchronized setTKScenePaintListener() to set scenePaintListener to null.
>> 
>> Verification:
>> This is a very rare issue and cannot be reliably reproduced with a test case.
> 
> The change looks OK as far as it goes, meaning that it will fix the specific NPE reported by the bug and is looks like a safe fix.
> 
> Two questions:
> 
> 1. In addition to calling the synchronized `setTKScenePaintListener` method, you moved the call to the beginning of `dispose`. Is there a reason you needed to do this?
> 2. Do any of the other listeners or variables that are set in `dispose` have the same problem (i.e., are any of the rest accessed from another thread)?

>     1. In addition to calling the synchronized `setTKScenePaintListener` method, you moved the call to the beginning of `dispose`. Is there a reason you needed to do this?

This is moved only to make first operation when disposing. However the race condition is very rare, but this will just reduce the chances little more.

>     2. Do any of the other listeners or variables that are set in `dispose` have the same problem (i.e., are any of the rest accessed from another thread)?

Other variable do not have a race condition. All are set or accessed on JavaFX Application thread.
There are some other variable (not in dispose()) like entireSceneDirty, painting, which are accessed on both threads but those are synchronized access.

-------------

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

From swpalmer at gmail.com  Wed Dec 11 18:42:18 2019
From: swpalmer at gmail.com (Scott Palmer)
Date: Wed, 11 Dec 2019 13:42:18 -0500
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
 <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
 <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>
 <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>
Message-ID: <108D6A55-DD3F-4255-83EA-16F59DB0A245@gmail.com>



> On Dec 10, 2019, at 8:23 PM, Kevin Rushforth <kcr at openjdk.java.net> wrote:
...
> 
> I think a new `TextFlowTest.java` would be a good place for those tests.

My first attempt at unit tests for TextFlow are failing.  I believe the StubTextLayout is not equipped to handle TextFlow.  This may be a bigger job?

This fragment triggers a NPE:
...
        Toolkit tk = (StubToolkit) Toolkit.getToolkit();
        HBox root = new HBox();
        Scene scene = new Scene(root);
        Stage stage = new Stage();
        stage.setScene(scene);
        stage.setWidth(300);
        stage.setHeight(200);

        try {
            Text text1 = new Text("\tfirst");
            Text text2 = new Text("\tsecond");
            TextFlow textFlow = new TextFlow(text1, text2);
            root.getChildren().addAll(textFlow);
            stage.show();
...

test.javafx.scene.text.TextFlowTest > testTabSize FAILED
    java.lang.NullPointerException
        at test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:88)
        at test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:82)
        at javafx.graphics/javafx.scene.text.TextFlow.computePrefWidth(TextFlow.java:254)
        at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
        at javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
        at javafx.graphics/javafx.scene.layout.Region.computeChildPrefAreaWidth(Region.java:1946)
        at javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:465)
        at javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:540)
        at javafx.graphics/javafx.scene.layout.HBox.computePrefWidth(HBox.java:433)
        at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
        at javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
        at javafx.graphics/javafx.scene.Scene.getPreferredWidth(Scene.java:1799)
        at javafx.graphics/javafx.scene.Scene.resizeRootToPreferredSize(Scene.java:1779)
        at javafx.graphics/javafx.scene.Scene.preferredSize(Scene.java:1747)
        at javafx.graphics/javafx.scene.Scene$2.preferredSize(Scene.java:393)
        at javafx.graphics/com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
        at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1086)
        at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
        at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
        at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1174)
        at javafx.graphics/javafx.stage.Window.show(Window.java:1189)
        at javafx.graphics/javafx.stage.Stage.show(Stage.java:273)
        at test.javafx.scene.text.TextFlowTest.testTabSize(TextFlowTest.java:60)


Scott


From kcr at openjdk.java.net  Wed Dec 11 18:43:40 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 11 Dec 2019 18:43:40 GMT
Subject: RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <qlhWDpZ-Ph8WOyOgUuToJoNRJEhyopT-HNC9Qmh1dwY=.2e07ac1d-12b3-45b1-84d4-b2f6958836fe@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <WHeu0iFuPN8qHCyxHAdn2MAc3ZeEAS01_To7CluV1ho=.a134587b-1a77-4928-b213-b0aca1cc32f7@github.com>
 <SNC1IdvQgKGx-eBg5C2691cRcApNnZH5D_rPVStbKAU=.45a242e1-940d-4983-9d4f-9a75b6b55952@github.com>
 <NkFJa_BRX0vLBWjSLfCD4XzU-JGAjDTLnFkRG5ROY9g=.c7a684c8-7eec-4fb8-9630-085a360dbbbb@github.com>
 <fhY-j1ZziMV1Ozi9a5wp6bpECydwxdRA8NbQnGYkVHE=.3ed28189-f765-47fe-9745-26d4640865f4@github.com>
 <p3ivxS3wnBT0E9RT0Hb_ZQPJmdGT6FDEf_OUTanjWC0=.962bb7e1-a13e-47d8-80ce-5cdf0a6b174d@github.com>
 <l3EenqjJFYkaNfuCNiEH9_l9fnL19XDbD29XPIi-84U=.622aeb5b-7599-48d1-a438-c2903eb30005@github.com>
 <OHUzoAQPQqQYpYTiZ7JPJzoLOzuRxlD9aC5eD0aB_e0=.7674951a-62fb-4b88-b290-94ea9af729db@github.com>
 <j91X09JTJiBqbnjlfOWg4asgRcsnEqGVbbOEOuvPJ-8=.635343a1-63fa-4987-aa7c-96226f9151ea@github.com>
 <qlhWDpZ-Ph8WOyOgUuToJoNRJEhyopT-HNC9Qmh1dwY=.2e07ac1d-12b3-45b1-84d4-b2f6958836fe@github.com>
Message-ID: <qoFYfiHIbnLEBOofh-X5SIwCkHY1xLLQW67qu4fZA5I=.43e4d901-66b9-4fab-9a7e-072a168daa61@github.com>

On Wed, 11 Dec 2019 00:21:20 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> Does it send the event on other platforms? I can test on Windows.
>> 
>> Yes, it always sends the `DRAG_DONE` event on all platforms today (I tested it on Mac, Windows, and Linux).
>> 
>>> Will look into the assertion error - it does not happen on 18.04.
>> 
>> It doesn't happen on 19.10 either. Only 16.04 as far as I have tested. I'll also test on Oracle Linux 7.x.
> 
> I don't get an assertion error on Oracle Linux 7.7 -- so far only on Ubuntu 16.04. I will resume reviewing once you restore the `DRAG_DONE` behavior.

With your latest patch, which reverts the changes to `GtkDnDClipboard.java`, I now get the DRAG_DONE event, but the following warning printed to the console in the case of a `DRAG_DONE` event with a null transfer mode:

GOT A dragExit when dndGesture is null!

This is coming from [Scene.java#L2925](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java#L2925).

-------------

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

From tsayao at openjdk.java.net  Wed Dec 11 19:06:06 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 11 Dec 2019 19:06:06 GMT
Subject: RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <qoFYfiHIbnLEBOofh-X5SIwCkHY1xLLQW67qu4fZA5I=.43e4d901-66b9-4fab-9a7e-072a168daa61@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <WHeu0iFuPN8qHCyxHAdn2MAc3ZeEAS01_To7CluV1ho=.a134587b-1a77-4928-b213-b0aca1cc32f7@github.com>
 <SNC1IdvQgKGx-eBg5C2691cRcApNnZH5D_rPVStbKAU=.45a242e1-940d-4983-9d4f-9a75b6b55952@github.com>
 <NkFJa_BRX0vLBWjSLfCD4XzU-JGAjDTLnFkRG5ROY9g=.c7a684c8-7eec-4fb8-9630-085a360dbbbb@github.com>
 <fhY-j1ZziMV1Ozi9a5wp6bpECydwxdRA8NbQnGYkVHE=.3ed28189-f765-47fe-9745-26d4640865f4@github.com>
 <p3ivxS3wnBT0E9RT0Hb_ZQPJmdGT6FDEf_OUTanjWC0=.962bb7e1-a13e-47d8-80ce-5cdf0a6b174d@github.com>
 <l3EenqjJFYkaNfuCNiEH9_l9fnL19XDbD29XPIi-84U=.622aeb5b-7599-48d1-a438-c2903eb30005@github.com>
 <OHUzoAQPQqQYpYTiZ7JPJzoLOzuRxlD9aC5eD0aB_e0=.7674951a-62fb-4b88-b290-94ea9af729db@github.com>
 <j91X09JTJiBqbnjlfOWg4asgRcsnEqGVbbOEOuvPJ-8=.635343a1-63fa-4987-aa7c-96226f9151ea@github.com>
 <qlhWDpZ-Ph8WOyOgUuToJoNRJEhyopT-HNC9Qmh1dwY=.2e07ac1d-12b3-45b1-84d4-b2f6958836fe@github.com>
 <qoFYfiHIbnLEBOofh-X5SIwCkHY1xLLQW67
 qu4fZA5I=.43e4d901-66b9-4fab-9a7e-072a168daa61@github.com>
Message-ID: <KnzfbQPYiMsaOasONVBxqX0DyRvmrOXIwkVEfpiNq_M=.31b4d45d-ddf5-449e-b904-a3a9ef09d44b@github.com>

On Wed, 11 Dec 2019 18:43:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I don't get an assertion error on Oracle Linux 7.7 -- so far only on Ubuntu 16.04. I will resume reviewing once you restore the `DRAG_DONE` behavior.
> 
> With your latest patch, which reverts the changes to `GtkDnDClipboard.java`, I now get the DRAG_DONE event, but the following warning printed to the console in the case of a `DRAG_DONE` event with a null transfer mode:
> 
> GOT A dragExit when dndGesture is null!
> 
> This is coming from [Scene.java#L2925](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java#L2925).

My mistake. I saw that and thought it was from the test app.

Will fix.

-------------

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

From tsayao at openjdk.java.net  Thu Dec 12 11:54:26 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 12 Dec 2019 11:54:26 GMT
Subject: [Rev 04] RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
Message-ID: <eyXaSGR06zfVnqLGw2qCC253QVU-dnB6wTydHdsMGfg=.a6265dae-c240-4dca-af00-2a993f2ca8d2@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8225571
> 
> To run tests (on the root of the source tree):
> ./gradlew apps
> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
> 
> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - b24f407f: Fix "GOT A dragExit when dndGesture is null!"

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/4/files
  - new: https://git.openjdk.java.net/jfx/pull/4/files/47155b08..b24f407f

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/4/webrev.04
 - incr: https://webrevs.openjdk.java.net/jfx/4/webrev.03-04

  Stats: 17 lines in 1 file changed: 12 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/4.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/4/head:pull/4

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

From swpalmer at openjdk.java.net  Thu Dec 12 15:16:00 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Thu, 12 Dec 2019 15:16:00 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
 <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
 <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>
 <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>
Message-ID: <qg80wHqxsLjEl1aA_m7qSu2pgRuZ9zrNzi_-0ZCEbNM=.33aa5bfa-3d2b-4437-8336-19798c177aad@github.com>

On Wed, 11 Dec 2019 01:22:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The unit tests that were already added to `TextTest.java` cover the new methods on Text, but not in every combination.  I'll add a couple more to ensure all combinations are covered. `TextFlow` has no existing unit tests that I could find!  Shall I add a new `TextFlowText.java` file for just these tests?
>> 
>> The apps/toys folder seems to use ant-based projects.  The existing ones don't build for me. If I made a new project there could I use the JavaFX Gradle plugin and configure it to get JavaFX from the build/sdk folder?
> 
> I think a new `TextFlowTest.java` would be a good place for those tests.
> 
> Our build is set up to use `ant` so if you want to wire it up to the build, you'll need that (it should be as simple as having `ANT_HOME` set to `apache-ant-1.10.5`). It would be fine to defer this if you can't get it working.

I just noticed while updating the CSR that, while I mentioned it on the mailing list, the fact that TextFlow's tabSize override that of any contained Text nodes is not documented.
Shall I add to the javadoc for tabSize  in TextFlow : "This value overrides the tabSize of contained Text nodes." ?

-------------

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

From kcr at openjdk.java.net  Thu Dec 12 15:19:58 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Dec 2019 15:19:58 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <qg80wHqxsLjEl1aA_m7qSu2pgRuZ9zrNzi_-0ZCEbNM=.33aa5bfa-3d2b-4437-8336-19798c177aad@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
 <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
 <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>
 <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>
 <qg80wHqxsLjEl1aA_m7qSu2pgRuZ9zrNzi_-0ZCEbNM=.33aa5bfa-3d2b-4437-8336-19798c177aad@github.com>
Message-ID: <LRbIEq9NIK0s6a7-CFFmEl1YXER7jcS2GIbrpRpObCc=.8fa1397a-abc8-4594-9e61-833a0fd0f8b9@github.com>

On Thu, 12 Dec 2019 15:15:38 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> I think a new `TextFlowTest.java` would be a good place for those tests.
>> 
>> Our build is set up to use `ant` so if you want to wire it up to the build, you'll need that (it should be as simple as having `ANT_HOME` set to `apache-ant-1.10.5`). It would be fine to defer this if you can't get it working.
> 
> I just noticed while updating the CSR that, while I mentioned it on the mailing list, the fact that TextFlow's tabSize override that of any contained Text nodes is not documented.
> Shall I add to the javadoc for tabSize  in TextFlow : "This value overrides the tabSize of contained Text nodes." ?

Good catch. Yes, please update it as you suggested.

-------------

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

From kcr at openjdk.java.net  Thu Dec 12 15:52:42 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Dec 2019 15:52:42 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <LRbIEq9NIK0s6a7-CFFmEl1YXER7jcS2GIbrpRpObCc=.8fa1397a-abc8-4594-9e61-833a0fd0f8b9@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
 <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
 <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>
 <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>
 <qg80wHqxsLjEl1aA_m7qSu2pgRuZ9zrNzi_-0ZCEbNM=.33aa5bfa-3d2b-4437-8336-19798c177aad@github.com>
 <LRbIEq9NIK0s6a7-CFFmEl1YXER7jcS2GIbrpRpObCc=.8fa1397a-abc8-4594-9e61-833a0fd0f8b9@github.com>
Message-ID: <SfS_I3cfqr9Y_jPDe-3PDI6G1HKVrE6MWsKmoz_EXEQ=.bb2be5df-0676-4be6-9c5e-6dbca129c7e1@github.com>

On Thu, 12 Dec 2019 15:19:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I just noticed while updating the CSR that, while I mentioned it on the mailing list, the fact that TextFlow's tabSize override that of any contained Text nodes is not documented.
>> Shall I add to the javadoc for tabSize  in TextFlow : "This value overrides the tabSize of contained Text nodes." ?
> 
> Good catch. Yes, please update it as you suggested.

The following comment from @swpalmer sent to the openjfx-dev mailing list wasn't mirrored in the PR (I have alerted the Skara team about this).

----
From: Scott Palmer

> I think a new `TextFlowTest.java` would be a good place for those tests.

My first attempt at unit tests for TextFlow are failing.  I believe the StubTextLayout is not equipped to handle TextFlow.  This may be a bigger job?

This fragment triggers a NPE:
...
        Toolkit tk = (StubToolkit) Toolkit.getToolkit();
        HBox root = new HBox();
        Scene scene = new Scene(root);
        Stage stage = new Stage();
        stage.setScene(scene);
        stage.setWidth(300);
        stage.setHeight(200);

        try {
            Text text1 = new Text("\tfirst");
            Text text2 = new Text("\tsecond");
            TextFlow textFlow = new TextFlow(text1, text2);
            root.getChildren().addAll(textFlow);
            stage.show();
...

test.javafx.scene.text.TextFlowTest > testTabSize FAILED
    java.lang.NullPointerException
        at test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:88)
        at test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:82)
        at javafx.graphics/javafx.scene.text.TextFlow.computePrefWidth(TextFlow.java:254)
        at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
        at javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
        at javafx.graphics/javafx.scene.layout.Region.computeChildPrefAreaWidth(Region.java:1946)
        at javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:465)
        at javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:540)
        at javafx.graphics/javafx.scene.layout.HBox.computePrefWidth(HBox.java:433)
        at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
        at javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
        at javafx.graphics/javafx.scene.Scene.getPreferredWidth(Scene.java:1799)
        at javafx.graphics/javafx.scene.Scene.resizeRootToPreferredSize(Scene.java:1779)
        at javafx.graphics/javafx.scene.Scene.preferredSize(Scene.java:1747)
        at javafx.graphics/javafx.scene.Scene$2.preferredSize(Scene.java:393)
        at javafx.graphics/com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
        at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1086)
        at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
        at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
        at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1174)
        at javafx.graphics/javafx.stage.Window.show(Window.java:1189)
        at javafx.graphics/javafx.stage.Stage.show(Stage.java:273)
        at test.javafx.scene.text.TextFlowTest.testTabSize(TextFlowTest.java:60)

Scott

-------------

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

From kcr at openjdk.java.net  Thu Dec 12 15:54:27 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Dec 2019 15:54:27 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <SfS_I3cfqr9Y_jPDe-3PDI6G1HKVrE6MWsKmoz_EXEQ=.bb2be5df-0676-4be6-9c5e-6dbca129c7e1@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
 <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
 <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>
 <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>
 <qg80wHqxsLjEl1aA_m7qSu2pgRuZ9zrNzi_-0ZCEbNM=.33aa5bfa-3d2b-4437-8336-19798c177aad@github.com>
 <LRbIEq9NIK0s6a7-CFFmEl1YXER7jcS2GIbrpRpObCc=.8fa1397a-abc8-4594-9e61-833a0fd0f8b9@github.com>
 <SfS_I3cfqr9Y_jPDe-3PDI6G1HKVrE6MWsKmoz_EXEQ=.bb2be5df-0676-4be6-9c5e-6dbca129c7e1@github.com>
Message-ID: <H0rvFyagYvA69okywfYDjD52SwxNN885X-vfOTaIzm8=.0559f77d-3a1f-452c-bf54-c1267f1d0e93@github.com>

On Thu, 12 Dec 2019 15:52:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Good catch. Yes, please update it as you suggested.
> 
> The following comment from @swpalmer sent to the openjfx-dev mailing list wasn't mirrored in the PR (I have alerted the Skara team about this).
> 
> ----
> From: Scott Palmer
> 
>> I think a new `TextFlowTest.java` would be a good place for those tests.
> 
> My first attempt at unit tests for TextFlow are failing.  I believe the StubTextLayout is not equipped to handle TextFlow.  This may be a bigger job?
> 
> This fragment triggers a NPE:
> ...
>         Toolkit tk = (StubToolkit) Toolkit.getToolkit();
>         HBox root = new HBox();
>         Scene scene = new Scene(root);
>         Stage stage = new Stage();
>         stage.setScene(scene);
>         stage.setWidth(300);
>         stage.setHeight(200);
> 
>         try {
>             Text text1 = new Text("\tfirst");
>             Text text2 = new Text("\tsecond");
>             TextFlow textFlow = new TextFlow(text1, text2);
>             root.getChildren().addAll(textFlow);
>             stage.show();
> ...
> 
> test.javafx.scene.text.TextFlowTest > testTabSize FAILED
>     java.lang.NullPointerException
>         at test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:88)
>         at test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:82)
>         at javafx.graphics/javafx.scene.text.TextFlow.computePrefWidth(TextFlow.java:254)
>         at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
>         at javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
>         at javafx.graphics/javafx.scene.layout.Region.computeChildPrefAreaWidth(Region.java:1946)
>         at javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:465)
>         at javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:540)
>         at javafx.graphics/javafx.scene.layout.HBox.computePrefWidth(HBox.java:433)
>         at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
>         at javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
>         at javafx.graphics/javafx.scene.Scene.getPreferredWidth(Scene.java:1799)
>         at javafx.graphics/javafx.scene.Scene.resizeRootToPreferredSize(Scene.java:1779)
>         at javafx.graphics/javafx.scene.Scene.preferredSize(Scene.java:1747)
>         at javafx.graphics/javafx.scene.Scene$2.preferredSize(Scene.java:393)
>         at javafx.graphics/com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
>         at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1086)
>         at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
>         at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
>         at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1174)
>         at javafx.graphics/javafx.stage.Window.show(Window.java:1189)
>         at javafx.graphics/javafx.stage.Stage.show(Stage.java:273)
>         at test.javafx.scene.text.TextFlowTest.testTabSize(TextFlowTest.java:60)
> 
> Scott

In that case, I recommend just doing the API get/set tests for `TextFlow` without creating a `Scene` or `Stage`. This won't need anything from the `StubToolkit`.

-------------

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

From kcr at openjdk.java.net  Thu Dec 12 19:47:59 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Dec 2019 19:47:59 GMT
Subject: RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <KnzfbQPYiMsaOasONVBxqX0DyRvmrOXIwkVEfpiNq_M=.31b4d45d-ddf5-449e-b904-a3a9ef09d44b@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <WHeu0iFuPN8qHCyxHAdn2MAc3ZeEAS01_To7CluV1ho=.a134587b-1a77-4928-b213-b0aca1cc32f7@github.com>
 <SNC1IdvQgKGx-eBg5C2691cRcApNnZH5D_rPVStbKAU=.45a242e1-940d-4983-9d4f-9a75b6b55952@github.com>
 <NkFJa_BRX0vLBWjSLfCD4XzU-JGAjDTLnFkRG5ROY9g=.c7a684c8-7eec-4fb8-9630-085a360dbbbb@github.com>
 <fhY-j1ZziMV1Ozi9a5wp6bpECydwxdRA8NbQnGYkVHE=.3ed28189-f765-47fe-9745-26d4640865f4@github.com>
 <p3ivxS3wnBT0E9RT0Hb_ZQPJmdGT6FDEf_OUTanjWC0=.962bb7e1-a13e-47d8-80ce-5cdf0a6b174d@github.com>
 <l3EenqjJFYkaNfuCNiEH9_l9fnL19XDbD29XPIi-84U=.622aeb5b-7599-48d1-a438-c2903eb30005@github.com>
 <OHUzoAQPQqQYpYTiZ7JPJzoLOzuRxlD9aC5eD0aB_e0=.7674951a-62fb-4b88-b290-94ea9af729db@github.com>
 <j91X09JTJiBqbnjlfOWg4asgRcsnEqGVbbOEOuvPJ-8=.635343a1-63fa-4987-aa7c-96226f9151ea@github.com>
 <qlhWDpZ-Ph8WOyOgUuToJoNRJEhyopT-HNC9Qmh1dwY=.2e07ac1d-12b3-45b1-84d4-b2f6958836fe@github.com>
 <qoFYfiHIbnLEBOofh-X5SIwCkHY1xLLQW67
 qu4fZA5I=.43e4d901-66b9-4fab-9a7e-072a168daa61@github.com>
 <KnzfbQPYiMsaOasONVBxqX0DyRvmrOXIwkVEfpiNq_M=.31b4d45d-ddf5-449e-b904-a3a9ef09d44b@github.com>
Message-ID: <2YkgO7lKyGUVgnPgZMQLZeUMhNtylEClW_l0ONYUfjY=.aa2d5dcc-9c96-44d3-b47a-084fc342da2a@github.com>

On Wed, 11 Dec 2019 19:05:54 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> With your latest patch, which reverts the changes to `GtkDnDClipboard.java`, I now get the DRAG_DONE event, but the following warning printed to the console in the case of a `DRAG_DONE` event with a null transfer mode:
>> 
>> GOT A dragExit when dndGesture is null!
>> 
>> This is coming from [Scene.java#L2925](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/Scene.java#L2925).
> 
> My mistake. I saw that and thought it was from the test app.
> 
> Will fix.

All my testing looks good now. I tried both of the programs you listed in the description, as well as `tests/manual/dnd/DndTest.java`, on Ubuntu 16.04, Ubuntu 19.04, and Oracle Linux 7.7. I ran with the default gtk-3 implementation as well as gtk-2.

I'll do a final code review, probably early next week.

This will need a second reviewer.

@pankaj-bansal can you also review this.

-------------

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

From swpalmer at openjdk.java.net  Thu Dec 12 19:48:50 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Thu, 12 Dec 2019 19:48:50 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <H0rvFyagYvA69okywfYDjD52SwxNN885X-vfOTaIzm8=.0559f77d-3a1f-452c-bf54-c1267f1d0e93@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
 <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
 <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>
 <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>
 <qg80wHqxsLjEl1aA_m7qSu2pgRuZ9zrNzi_-0ZCEbNM=.33aa5bfa-3d2b-4437-8336-19798c177aad@github.com>
 <LRbIEq9NIK0s6a7-CFFmEl1YXER7jcS2GIbrpRpObCc=.8fa1397a-abc8-4594-9e61-833a0fd0f8b9@github.com>
 <SfS_I3cfqr9Y_jPDe-3PDI6G1HKVrE6MWsKmoz_EXEQ=.bb2be5df-0676-4be6-9c5e-6dbca129c7e1@github.com>
 <H0rvFyagYvA69okywfYDjD52SwxNN885X-v
 fOTaIzm8=.0559f77d-3a1f-452c-bf54-c1267f1d0e93@github.com>
Message-ID: <pf06hU7t_7s_e2iziaa-L_YtG6RZIqtmqPOkkmEeM9c=.8b5558ef-2729-45e4-953e-69934e284505@github.com>

On Thu, 12 Dec 2019 15:54:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The following comment from @swpalmer sent to the openjfx-dev mailing list wasn't mirrored in the PR (I have alerted the Skara team about this).
>> 
>> ----
>> From: Scott Palmer
>> 
>>> I think a new `TextFlowTest.java` would be a good place for those tests.
>> 
>> My first attempt at unit tests for TextFlow are failing.  I believe the StubTextLayout is not equipped to handle TextFlow.  This may be a bigger job?
>> 
>> This fragment triggers a NPE:
>> ...
>>         Toolkit tk = (StubToolkit) Toolkit.getToolkit();
>>         HBox root = new HBox();
>>         Scene scene = new Scene(root);
>>         Stage stage = new Stage();
>>         stage.setScene(scene);
>>         stage.setWidth(300);
>>         stage.setHeight(200);
>> 
>>         try {
>>             Text text1 = new Text("\tfirst");
>>             Text text2 = new Text("\tsecond");
>>             TextFlow textFlow = new TextFlow(text1, text2);
>>             root.getChildren().addAll(textFlow);
>>             stage.show();
>> ...
>> 
>> test.javafx.scene.text.TextFlowTest > testTabSize FAILED
>>     java.lang.NullPointerException
>>         at test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:88)
>>         at test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:82)
>>         at javafx.graphics/javafx.scene.text.TextFlow.computePrefWidth(TextFlow.java:254)
>>         at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
>>         at javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
>>         at javafx.graphics/javafx.scene.layout.Region.computeChildPrefAreaWidth(Region.java:1946)
>>         at javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:465)
>>         at javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:540)
>>         at javafx.graphics/javafx.scene.layout.HBox.computePrefWidth(HBox.java:433)
>>         at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
>>         at javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
>>         at javafx.graphics/javafx.scene.Scene.getPreferredWidth(Scene.java:1799)
>>         at javafx.graphics/javafx.scene.Scene.resizeRootToPreferredSize(Scene.java:1779)
>>         at javafx.graphics/javafx.scene.Scene.preferredSize(Scene.java:1747)
>>         at javafx.graphics/javafx.scene.Scene$2.preferredSize(Scene.java:393)
>>         at javafx.graphics/com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
>>         at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1086)
>>         at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
>>         at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
>>         at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1174)
>>         at javafx.graphics/javafx.stage.Window.show(Window.java:1189)
>>         at javafx.graphics/javafx.stage.Stage.show(Stage.java:273)
>>         at test.javafx.scene.text.TextFlowTest.testTabSize(TextFlowTest.java:60)
>> 
>> Scott
> 
> In that case, I recommend just doing the API get/set tests for `TextFlow` without creating a `Scene` or `Stage`. This won't need anything from the `StubToolkit`.

In my attempts to address the issue with StubTextLayout I discovered bugs.  TextFlow is NOT properly overriding the tabSize of the Text nodes.  If you set the Text node tab size later, the layout reacts and adjusts to the tabSize of the Text node even though it is contained in a TextFlow.  Whichever node changes the tabSize last affects the layout.   I'm going to have to study this more, but this change isn't ready at this point.

-------------

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

From swpalmer at openjdk.java.net  Thu Dec 12 21:22:07 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Thu, 12 Dec 2019 21:22:07 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <pf06hU7t_7s_e2iziaa-L_YtG6RZIqtmqPOkkmEeM9c=.8b5558ef-2729-45e4-953e-69934e284505@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <6XsEkjzIyDXuStAYENghfoGkUPFxZrxt_uMRvMQfzNA=.8f1df5d2-6572-45ac-960c-aa19a6485503@github.com>
 <USWSAL-IQcclxEX7DhIAxFScoOeyj8rW6zEGt32eAHk=.f8be9544-9c21-4e62-b288-d6fe5515712c@github.com>
 <zNkZTdgTzAmyCIZLfF12rKltw1J_JDVgH5Px801eIog=.7ffebe54-61e3-438d-ad53-29dcd94952ad@github.com>
 <NPWt2DWxsI7JXGdnjSHZFQcOotlsfzzFcTh8W0sFYJI=.b318c91f-c924-4e9b-9586-575fae60b145@github.com>
 <g1PR5qL5ardGoXce9-mRmVplmprvFZCjblvKmzEByL4=.96d50b5e-e792-46d0-b4f5-34b4a0afa9a7@github.com>
 <qg80wHqxsLjEl1aA_m7qSu2pgRuZ9zrNzi_-0ZCEbNM=.33aa5bfa-3d2b-4437-8336-19798c177aad@github.com>
 <LRbIEq9NIK0s6a7-CFFmEl1YXER7jcS2GIbrpRpObCc=.8fa1397a-abc8-4594-9e61-833a0fd0f8b9@github.com>
 <SfS_I3cfqr9Y_jPDe-3PDI6G1HKVrE6MWsKmoz_EXEQ=.bb2be5df-0676-4be6-9c5e-6dbca129c7e1@github.com>
 <H0rvFyagYvA69okywfYDjD52SwxNN885X-v
 fOTaIzm8=.0559f77d-3a1f-452c-bf54-c1267f1d0e93@github.com>
 <pf06hU7t_7s_e2iziaa-L_YtG6RZIqtmqPOkkmEeM9c=.8b5558ef-2729-45e4-953e-69934e284505@github.com>
Message-ID: <NU-Eg0yGhlYDuS3Hsxx9AZ8CayieSZi1lboe1sQlq9w=.ffe6fba8-d9cf-4c5e-82e3-9105d2d85cbc@github.com>

On Thu, 12 Dec 2019 19:48:37 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> In that case, I recommend just doing the API get/set tests for `TextFlow` without creating a `Scene` or `Stage`. This won't need anything from the `StubToolkit`.
> 
> In my attempts to address the issue with StubTextLayout I discovered bugs.  TextFlow is NOT properly overriding the tabSize of the Text nodes.  If you set the Text node tab size later, the layout reacts and adjusts to the tabSize of the Text node even though it is contained in a TextFlow.  Whichever node changes the tabSize last affects the layout.   I'm going to have to study this more, but this change isn't ready at this point.

Looks like I was missing a check for isSpan() in the invalidated method of the tabSize property of Text.  I've fixed StubTextLayout to work with TextFlow now.

-------------

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

From swpalmer at openjdk.java.net  Thu Dec 12 21:22:45 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Thu, 12 Dec 2019 21:22:45 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
Message-ID: <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>

> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both.  TextFlow's tab size overrides that of contained Text nodes.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - f99a3aa9: 8130738: Add tabSize property to Text and TextFlow

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/32/files
  - new: https://git.openjdk.java.net/jfx/pull/32/files/af959665..f99a3aa9

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/32/webrev.04
 - incr: https://webrevs.openjdk.java.net/jfx/32/webrev.03-04

  Stats: 170 lines in 6 files changed: 147 ins; 9 del; 14 mod
  Patch: https://git.openjdk.java.net/jfx/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32

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

From nlisker at openjdk.java.net  Thu Dec 12 21:52:11 2019
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 12 Dec 2019 21:52:11 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
Message-ID: <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>

On Thu, 12 Dec 2019 21:52:05 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both.  TextFlow's tab size overrides that of contained Text nodes.
> 
> The pull request has been updated with 1 additional commit.

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1273:

> 1272:     /**
> 1273:      * The size of a tab stop in spaces.
> 1274:      * Values less than 1 are treated as 1.

"tab stop" seems to be an uncommon term. Better are "horizontal tab" (used in the [JLS](https://docs.oracle.com/javase/specs/jls/se13/html/jls-3.html#jls-3.10.6)), "tab character" (used in [`Pattern`](https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/regex/Pattern.html), "horizontal tabulation" or the like.

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1276:

> 1275:      *
> 1276:      * @defaultValue {@code 8}
> 1277:      *

No need for `@code` with numeric constants.

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1450:

> 1449:         private static final CssMetaData<Text,Number> TAB_SIZE =
> 1450:                 new CssMetaData<Text,Number>("-fx-tab-size",
> 1451:                 SizeConverter.getInstance(), TextLayout.DEFAULT_TAB_SIZE) {

I think that type parameters should have space separation after a comma: `Text, Number`, though I've seen without too.

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1882:

> 1881:                         return StyleableProperties.TAB_SIZE;
> 1882:                     }
> 1883:                     @Override protected void invalidated() {

The `SimpleStyleableIntegerProperty` subclass can be used instead of `StyleableIntegerProperty` to make the code cleaner:
new SimpleStyleableIntegerProperty(StyleableProperties.TAB_SIZE, Text.this, "tabSize", TextLayout.DEFAULT_TAB_SIZE);

(This can be done for many places in the library)

modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1883:

> 1882:                     }
> 1883:                     @Override protected void invalidated() {
> 1884:                         TextLayout layout = getTextLayout();

I think that annotations tend to go on a line above what they annotate,

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 575:

> 574:         private static final CssMetaData<TextFlow,Number> TAB_SIZE =
> 575:                 new CssMetaData<TextFlow,Number>("-fx-tab-size",
> 576:                 SizeConverter.getInstance(), TextLayout.DEFAULT_TAB_SIZE) {

Same comment as for `Text`.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 517:

> 516:                 }
> 517:                 @Override protected void invalidated() {
> 518:                     TextLayout layout = getTextLayout();

Same comments as for `Text`.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 495:

> 494:      *
> 495:      * @defaultValue {@code 8}
> 496:      *

Same comments as for `Text`.

-------------

Changes requested by nlisker (Committer).

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

From nlisker at openjdk.java.net  Thu Dec 12 22:02:28 2019
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 12 Dec 2019 22:02:28 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
Message-ID: <IQcJprXrM5yDUVauVql-zIycS_F5F4u971CRMsxQlhQ=.da9fd03a-1499-48f5-a88b-94c5adaa7011@github.com>

On Thu, 12 Dec 2019 22:02:27 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both.  TextFlow's tab size overrides that of contained Text nodes.
> 
> The pull request has been updated with 1 additional commit.

modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 494:

> 493:      * Values less than 1 are treated as 1. This value overrides the
> 494:      * {@code tabSize} of contained {@link javafx.scene.text.Text Text} nodes.
> 495:      *

`{@link Text}` is enough, but the FQN is also fine.

Does `Text`'s `tabSize` need a note that its value is overriden if the text is contained in a `TextFlow`?

-------------

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

From kcr at openjdk.java.net  Thu Dec 12 22:03:07 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Dec 2019 22:03:07 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
Message-ID: <PBsNZeLVPrDjUJXnjyyccfaOzzlINkFAW0Rj_bO7BrY=.19910b7d-5f1a-401a-9823-18898202077b@github.com>

On Thu, 12 Dec 2019 21:16:32 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1273:
> 
>> 1272:     /**
>> 1273:      * The size of a tab stop in spaces.
>> 1274:      * Values less than 1 are treated as 1.
> 
> "tab stop" seems to be an uncommon term. Better are "horizontal tab" (used in the [JLS](https://docs.oracle.com/javase/specs/jls/se13/html/jls-3.html#jls-3.10.6)), "tab character" (used in [`Pattern`](https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/regex/Pattern.html), "horizontal tabulation" or the like.

The terms "tab character" or "horizontal tab" refer to the ASCII tab character itself. Since a tab character isn't a fixed number of spaces, changing it to "size of a tab character" could be misleading. I'd be fine with another alternative, though, if someone could come up with a better one.

-------------

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

From kcr at openjdk.java.net  Thu Dec 12 23:29:24 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Dec 2019 23:29:24 GMT
Subject: RFR: 8223296: NullPointerException in GlassScene.java at line 325
In-Reply-To: <0RBgCac9Puzvny45Z95_HQ4hlwLFx5kdUjXXrQYcIx4=.ae6ca62a-ac0f-4eef-a8b7-6b9a702cce6c@github.com>
References: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
 <7mDsBwxFZM7g_Wiqa2CE1z1S1sJcedl_MhoROCFH6v4=.cd69fc5c-1a4e-42ab-a5af-190f5ddffab1@github.com>
 <0RBgCac9Puzvny45Z95_HQ4hlwLFx5kdUjXXrQYcIx4=.ae6ca62a-ac0f-4eef-a8b7-6b9a702cce6c@github.com>
Message-ID: <U6j-Bdgk10U7w01n0Ss5lA9Hw6Q-x0getYhWCUSc_fs=.76304807-ff4b-4246-bbb0-4c288b62557e@github.com>

On Wed, 11 Dec 2019 17:10:37 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The change looks OK as far as it goes, meaning that it will fix the specific NPE reported by the bug and is looks like a safe fix.
>> 
>> Two questions:
>> 
>> 1. In addition to calling the synchronized `setTKScenePaintListener` method, you moved the call to the beginning of `dispose`. Is there a reason you needed to do this?
>> 2. Do any of the other listeners or variables that are set in `dispose` have the same problem (i.e., are any of the rest accessed from another thread)?
> 
>>     1. In addition to calling the synchronized `setTKScenePaintListener` method, you moved the call to the beginning of `dispose`. Is there a reason you needed to do this?
> 
> This is moved only to make first operation when disposing. However the race condition is very rare, but this will just reduce the chances little more.
> 
>>     2. Do any of the other listeners or variables that are set in `dispose` have the same problem (i.e., are any of the rest accessed from another thread)?
> 
> Other variable do not have a race condition. All are set or accessed on JavaFX Application thread.
> There are some other variable (not in dispose()) like entireSceneDirty, painting, which are accessed on both threads but those are synchronized access.

> This is moved only to make first operation when disposing. However the race condition is very rare, but this will just reduce the chances little more.

Can you elaborate? Why would there still be a race condition?

-------------

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

From kcr at openjdk.java.net  Thu Dec 12 23:41:56 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Dec 2019 23:41:56 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
Message-ID: <4V8d97UJlwysrtlU1QFjmQbHft7wIYVtaE4ROqTnOKo=.d8f18fe0-eed8-4f35-8511-6646af034109@github.com>

On Thu, 12 Dec 2019 21:40:34 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1882:
> 
>> 1881:                         return StyleableProperties.TAB_SIZE;
>> 1882:                     }
>> 1883:                     @Override protected void invalidated() {
> 
> The `SimpleStyleableIntegerProperty` subclass can be used instead of `StyleableIntegerProperty` to make the code cleaner:
> new SimpleStyleableIntegerProperty(StyleableProperties.TAB_SIZE, Text.this, "tabSize", TextLayout.DEFAULT_TAB_SIZE);
> 
> (This can be done for many places in the library)

I'd probably leave it as is for this PR, since it matches other attributes in this file.

-------------

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

From kcr at openjdk.java.net  Thu Dec 12 23:52:44 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 12 Dec 2019 23:52:44 GMT
Subject: RFR: 8232811: Dialog's preferred size no longer accommodates
 multi-line strings
In-Reply-To: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
Message-ID: <egH2JL5ten1xKHny_HQiU7egQngHhGe3SiBH7AXAtME=.32a28f6f-cacd-48bf-bf1e-2fb576084615@github.com>

On Mon, 9 Dec 2019 18:27:25 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8232811
> 
> This one was hard to tackle.
> 
> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest

This will need two reviewers.

-------------

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

From swpalmer at openjdk.java.net  Fri Dec 13 01:11:07 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Fri, 13 Dec 2019 01:11:07 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
Message-ID: <vhhwmBDtOU61CzYxRt9bTjJhSgHg22eGOutIpcreoOI=.0bf43730-6ffe-42f5-8438-8bf7feea5226@github.com>

On Thu, 12 Dec 2019 21:29:06 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1450:
> 
>> 1449:         private static final CssMetaData<Text,Number> TAB_SIZE =
>> 1450:                 new CssMetaData<Text,Number>("-fx-tab-size",
>> 1451:                 SizeConverter.getInstance(), TextLayout.DEFAULT_TAB_SIZE) {
> 
> I think that type parameters should have space separation after a comma: `Text, Number`, though I've seen without too.

Most of the instances where CssMetaData is used in the rest of the file don't have a space. The exceptions seem to be where there is a wildcard in the type parameter.  It could be left as-is simply to maintain consistency within the file.  Though I tend to agree that a space makes sense.

-------------

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

From swpalmer at openjdk.java.net  Fri Dec 13 01:15:46 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Fri, 13 Dec 2019 01:15:46 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
Message-ID: <C2Xihf9pxz1vcXX9L3fYzFoe32Bgw7AWVMSX17D1lbo=.e5d4eada-e1e4-44c1-9b3c-617e5dc9acbc@github.com>

On Thu, 12 Dec 2019 21:41:12 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1883:
> 
>> 1882:                     }
>> 1883:                     @Override protected void invalidated() {
>> 1884:                         TextLayout layout = getTextLayout();
> 
> I think that annotations tend to go on a line above what they annotate,

I'm following the pattern established elsewhere in the file for other property overrides. (underline, strikethrough, textAlignment, selectionEnd, etc.).  I would keep this for consistency and compactness, unless there are more votes against it.

-------------

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

From swpalmer at openjdk.java.net  Fri Dec 13 01:20:56 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Fri, 13 Dec 2019 01:20:56 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <IQcJprXrM5yDUVauVql-zIycS_F5F4u971CRMsxQlhQ=.da9fd03a-1499-48f5-a88b-94c5adaa7011@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
 <IQcJprXrM5yDUVauVql-zIycS_F5F4u971CRMsxQlhQ=.da9fd03a-1499-48f5-a88b-94c5adaa7011@github.com>
Message-ID: <p9VBYxCrhmucAyOOt56TqA1Z4F1vZ0VNJEvD1gvInNI=.d271a859-85a8-4732-b109-e38f4180c8ab@github.com>

On Thu, 12 Dec 2019 22:02:14 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 494:
> 
>> 493:      * Values less than 1 are treated as 1. This value overrides the
>> 494:      * {@code tabSize} of contained {@link javafx.scene.text.Text Text} nodes.
>> 495:      *
> 
> `{@link Text}` is enough, but the FQN is also fine.
> 
> Does `Text`'s `tabSize` need a note that its value is overriden if the text is contained in a `TextFlow`?

TextFlow isn't mentioned in the JavaDoc for any of the other Text properties where the same rule applies.  Perhaps that should be remedied with a follow-up task?

-------------

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

From prr at openjdk.java.net  Fri Dec 13 01:29:55 2019
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 13 Dec 2019 01:29:55 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <PBsNZeLVPrDjUJXnjyyccfaOzzlINkFAW0Rj_bO7BrY=.19910b7d-5f1a-401a-9823-18898202077b@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
 <PBsNZeLVPrDjUJXnjyyccfaOzzlINkFAW0Rj_bO7BrY=.19910b7d-5f1a-401a-9823-18898202077b@github.com>
Message-ID: <subnbq9YI0oAvL_clxXEtdjduyAdVfVRI9tZIT5m1SI=.dd550d7d-ef82-45b2-9341-72345b0157da@github.com>

On Thu, 12 Dec 2019 22:02:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1273:
>> 
>>> 1272:     /**
>>> 1273:      * The size of a tab stop in spaces.
>>> 1274:      * Values less than 1 are treated as 1.
>> 
>> "tab stop" seems to be an uncommon term. Better are "horizontal tab" (used in the [JLS](https://docs.oracle.com/javase/specs/jls/se13/html/jls-3.html#jls-3.10.6)), "tab character" (used in [`Pattern`](https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/regex/Pattern.html), "horizontal tabulation" or the like.
> 
> The terms "tab character" or "horizontal tab" refer to the ASCII tab character itself. Since a tab character isn't a fixed number of spaces, changing it to "size of a tab character" could be misleading. I'd be fine with another alternative, though, if someone could come up with a better one.

We are referring to the character here aren't we ? ie the actual character and the rest of it is about how it renders.
Paraphrasing the java doc it says :
If you display <the tab character> it will display as N instances of <the space character>

-------------

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

From swpalmer at openjdk.java.net  Fri Dec 13 04:42:16 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Fri, 13 Dec 2019 04:42:16 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <subnbq9YI0oAvL_clxXEtdjduyAdVfVRI9tZIT5m1SI=.dd550d7d-ef82-45b2-9341-72345b0157da@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
 <PBsNZeLVPrDjUJXnjyyccfaOzzlINkFAW0Rj_bO7BrY=.19910b7d-5f1a-401a-9823-18898202077b@github.com>
 <subnbq9YI0oAvL_clxXEtdjduyAdVfVRI9tZIT5m1SI=.dd550d7d-ef82-45b2-9341-72345b0157da@github.com>
Message-ID: <1yp15PLM00hNWcmuorWi1LXB_-23h_7eWpcOlQLUY9Y=.91d24322-6460-4d2c-b8b2-a3fd26e84465@github.com>

On Fri, 13 Dec 2019 01:29:47 GMT, Phil Race <prr at openjdk.org> wrote:

>> The terms "tab character" or "horizontal tab" refer to the ASCII tab character itself. Since a tab character isn't a fixed number of spaces, changing it to "size of a tab character" could be misleading. I'd be fine with another alternative, though, if someone could come up with a better one.
> 
> We are referring to the character here aren't we ? ie the actual character and the rest of it is about how it renders.
> Paraphrasing the java doc it says :
> If you display <the tab character> it will display as N instances of <the space character>

I find "size of the tab character" to be a bit confusing.  The number of space you advance is not a constant for one, so tab characters don't really have a fixed size in that sense.  The javadoc could be rephrased as "the distance between tab stops".  However, that keeps the unfamiliar, but correct IMO, "tab stop" wording.  For the record the top google hit for "tab stop" results in: "A tab stop is a term used to describe the location the cursor stops after the Tab key is pressed." Wikipedia says something similar and adds, "In text editors on a computer, the same concept is implemented simplistically with automatic, fixed tab stops."

-------------

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

From prr at openjdk.java.net  Fri Dec 13 05:12:06 2019
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 13 Dec 2019 05:12:06 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <1yp15PLM00hNWcmuorWi1LXB_-23h_7eWpcOlQLUY9Y=.91d24322-6460-4d2c-b8b2-a3fd26e84465@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
 <PBsNZeLVPrDjUJXnjyyccfaOzzlINkFAW0Rj_bO7BrY=.19910b7d-5f1a-401a-9823-18898202077b@github.com>
 <subnbq9YI0oAvL_clxXEtdjduyAdVfVRI9tZIT5m1SI=.dd550d7d-ef82-45b2-9341-72345b0157da@github.com>
 <1yp15PLM00hNWcmuorWi1LXB_-23h_7eWpcOlQLUY9Y=.91d24322-6460-4d2c-b8b2-a3fd26e84465@github.com>
Message-ID: <ovekSMd0fiSgmQtiBRzUO-8Fi5AHsqBB6H2Xmonh63Y=.49eb5339-eca3-4d55-80d4-5b8fbfed1308@github.com>

On Fri, 13 Dec 2019 04:42:07 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> We are referring to the character here aren't we ? ie the actual character and the rest of it is about how it renders.
>> Paraphrasing the java doc it says :
>> If you display <the tab character> it will display as N instances of <the space character>
> 
> I find "size of the tab character" to be a bit confusing.  The number of space you advance is not a constant for one, so tab characters don't really have a fixed size in that sense.  The javadoc could be rephrased as "the distance between tab stops".  However, that keeps the unfamiliar, but correct IMO, "tab stop" wording.  For the record the top google hit for "tab stop" results in: "A tab stop is a term used to describe the location the cursor stops after the Tab key is pressed." Wikipedia says something similar and adds, "In text editors on a computer, the same concept is implemented simplistically with automatic, fixed tab stops."

OK. Lets not do this to death. I knew what you meant by tab stop.

-------------

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

From arapte at openjdk.java.net  Fri Dec 13 10:48:46 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 13 Dec 2019 10:48:46 GMT
Subject: RFR: 8223296: NullPointerException in GlassScene.java at line 325
In-Reply-To: <U6j-Bdgk10U7w01n0Ss5lA9Hw6Q-x0getYhWCUSc_fs=.76304807-ff4b-4246-bbb0-4c288b62557e@github.com>
References: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
 <7mDsBwxFZM7g_Wiqa2CE1z1S1sJcedl_MhoROCFH6v4=.cd69fc5c-1a4e-42ab-a5af-190f5ddffab1@github.com>
 <0RBgCac9Puzvny45Z95_HQ4hlwLFx5kdUjXXrQYcIx4=.ae6ca62a-ac0f-4eef-a8b7-6b9a702cce6c@github.com>
 <U6j-Bdgk10U7w01n0Ss5lA9Hw6Q-x0getYhWCUSc_fs=.76304807-ff4b-4246-bbb0-4c288b62557e@github.com>
Message-ID: <eHgdKAFmLLaTwP-mt5l9m9fvBgBACgfVr_IwAJXMdeY=.5aadcc38-97f2-4f28-b179-3192eb734534@github.com>

On Thu, 12 Dec 2019 23:29:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>>     1. In addition to calling the synchronized `setTKScenePaintListener` method, you moved the call to the beginning of `dispose`. Is there a reason you needed to do this?
>> 
>> This is moved only to make first operation when disposing. However the race condition is very rare, but this will just reduce the chances little more.
>> 
>>>     2. Do any of the other listeners or variables that are set in `dispose` have the same problem (i.e., are any of the rest accessed from another thread)?
>> 
>> Other variable do not have a race condition. All are set or accessed on JavaFX Application thread.
>> There are some other variable (not in dispose()) like entireSceneDirty, painting, which are accessed on both threads but those are synchronized access.
> 
>> This is moved only to make first operation when disposing. However the race condition is very rare, but this will just reduce the chances little more.
> 
> Can you elaborate? Why would there still be a race condition?

> Can you elaborate? Why would there still be a race condition?
Hi Kevin, Looks like I made a confusing statement.
There won't be a race condition after this change but there can be a situation when `frameRendered()` gets executed while `dispose()` is in progress.
Consider scenario:
1. `dispose()` is called on Application thread, and `setTKScenePaintListener(null)` is not executed yet.
2. `frameRendered()` is called on Renderer thread, and it will find that scenePaintListener is not null and `scenePaintListener.frameRendered()` call will be executed.
3. Then `dispose()` executes `setTKScenePaintListener(null)`

If `setTKScenePaintListener(null)` is the first operation in 'dispose()' then chances of above situation reduce little more. However the situation is very rare.
This is to make it more sure that `scenePaintListener.frameRendered()` does not get executed once `dispose()` has begun.

-------------

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

From kcr at openjdk.java.net  Fri Dec 13 14:11:55 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Dec 2019 14:11:55 GMT
Subject: RFR: 8223296: NullPointerException in GlassScene.java at line 325
In-Reply-To: <eHgdKAFmLLaTwP-mt5l9m9fvBgBACgfVr_IwAJXMdeY=.5aadcc38-97f2-4f28-b179-3192eb734534@github.com>
References: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
 <7mDsBwxFZM7g_Wiqa2CE1z1S1sJcedl_MhoROCFH6v4=.cd69fc5c-1a4e-42ab-a5af-190f5ddffab1@github.com>
 <0RBgCac9Puzvny45Z95_HQ4hlwLFx5kdUjXXrQYcIx4=.ae6ca62a-ac0f-4eef-a8b7-6b9a702cce6c@github.com>
 <U6j-Bdgk10U7w01n0Ss5lA9Hw6Q-x0getYhWCUSc_fs=.76304807-ff4b-4246-bbb0-4c288b62557e@github.com>
 <eHgdKAFmLLaTwP-mt5l9m9fvBgBACgfVr_IwAJXMdeY=.5aadcc38-97f2-4f28-b179-3192eb734534@github.com>
Message-ID: <trRjMJqxxIS6oLa63QD0Zr0o7E-z2MV5viMRcykxyD8=.2babb0a7-2b68-4037-84da-5ddf68deffa7@github.com>

On Fri, 13 Dec 2019 10:48:37 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>>> This is moved only to make first operation when disposing. However the race condition is very rare, but this will just reduce the chances little more.
>> 
>> Can you elaborate? Why would there still be a race condition?
> 
>> Can you elaborate? Why would there still be a race condition?
> 
> Hi Kevin, Looks like I made a confusing statement.
> There won't be a race condition after this change but there can be a situation when `frameRendered()` gets executed while `dispose()` is in progress.
> Consider scenario:
> 1. `dispose()` is called on Application thread, and `setTKScenePaintListener(null)` is not executed yet.
> 2. `frameRendered()` is called on Renderer thread, and it will find that scenePaintListener is not null and `scenePaintListener.frameRendered()` call will be executed.
> 3. Then `dispose()` executes `setTKScenePaintListener(null)`
> 
> If `setTKScenePaintListener(null)` is the first operation in 'dispose()' then chances of above situation reduce little more. However the situation is very rare.
> This is to make it more sure that `scenePaintListener.frameRendered()` does not get executed once `dispose()` has begun.

OK, thanks. That's what I would have expected, but wanted to make sure there wasn't still an outstanding race condition after your fix.

This is a safe enough fix that one reviewer is sufficient.

-------------

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

From kcr at openjdk.java.net  Fri Dec 13 14:12:14 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Dec 2019 14:12:14 GMT
Subject: RFR: 8223296: NullPointerException in GlassScene.java at line 325
In-Reply-To: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
References: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
Message-ID: <F328hlErJMWrJ-cXQFtSK_UFXvitA2H8gzCiO9KyxHM=.17d66ab5-6aaf-41e0-8044-c3df977cb33c@github.com>

On Tue, 10 Dec 2019 07:00:50 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Issue: NPE in GlassScene.frameRendered().
> 
> Cause: scenePaintListener is set in setTKScenePaintListener(), used in frameRendered() and 
> set to null in dispose().
> setTKScenePaintListener() and dispose() are called on JavaFX Application Thread and 
> frameRendered() is called by QuantumRenderer thread.
> setTKScenePaintListener() and frameRendered() are synchronized but dispose() is not.
> 
> Fix:
> dispose() should use the synchronized setTKScenePaintListener() to set scenePaintListener to null.
> 
> Verification:
> This is a very rare issue and cannot be reliably reproduced with a test case.



-------------

Marked as reviewed by kcr (Lead).

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

From arapte at openjdk.java.net  Fri Dec 13 17:18:15 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 13 Dec 2019 17:18:15 GMT
Subject: [Integrated] RFR: 8223296: NullPointerException in
 GlassScene.java at line 325
In-Reply-To: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
References: <MDQx2tk9sYhDb5wq-VDwY746j27npVoPjJ1-2eeGHCM=.a9d42675-5a0d-4d0a-ad40-ee8a03b98534@github.com>
Message-ID: <1ab87e8b-0ee6-4645-a39c-e85019c886e5@openjdk.org>

Changeset: fc539b57
Author:    Ambarish Rapte <arapte at openjdk.org>
Date:      2019-12-13 17:17:42 +0000
URL:       https://git.openjdk.java.net/jfx/commit/fc539b57

8223296: NullPointerException in GlassScene.java at line 325

Reviewed-by: kcr

! modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java

From kcr at openjdk.java.net  Sat Dec 14 16:37:40 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 14 Dec 2019 16:37:40 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <vhhwmBDtOU61CzYxRt9bTjJhSgHg22eGOutIpcreoOI=.0bf43730-6ffe-42f5-8438-8bf7feea5226@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
 <vhhwmBDtOU61CzYxRt9bTjJhSgHg22eGOutIpcreoOI=.0bf43730-6ffe-42f5-8438-8bf7feea5226@github.com>
Message-ID: <Bw3t5v0qajRjgdBP3wOPUJyXQKoFqkFv1yWdPBOMSFc=.ea9b8bed-88d1-4c15-b5e3-3812fdd677b7@github.com>

On Fri, 13 Dec 2019 01:10:48 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1450:
>> 
>>> 1449:         private static final CssMetaData<Text,Number> TAB_SIZE =
>>> 1450:                 new CssMetaData<Text,Number>("-fx-tab-size",
>>> 1451:                 SizeConverter.getInstance(), TextLayout.DEFAULT_TAB_SIZE) {
>> 
>> I think that type parameters should have space separation after a comma: `Text, Number`, though I've seen without too.
> 
> Most of the instances where CssMetaData is used in the rest of the file don't have a space. The exceptions seem to be where there is a wildcard in the type parameter.  It could be left as-is simply to maintain consistency within the file.  Though I tend to agree that a space makes sense.

Either is fine with me in this case.

-------------

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

From kcr at openjdk.java.net  Sat Dec 14 16:38:39 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 14 Dec 2019 16:38:39 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <p9VBYxCrhmucAyOOt56TqA1Z4F1vZ0VNJEvD1gvInNI=.d271a859-85a8-4732-b109-e38f4180c8ab@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
 <IQcJprXrM5yDUVauVql-zIycS_F5F4u971CRMsxQlhQ=.da9fd03a-1499-48f5-a88b-94c5adaa7011@github.com>
 <p9VBYxCrhmucAyOOt56TqA1Z4F1vZ0VNJEvD1gvInNI=.d271a859-85a8-4732-b109-e38f4180c8ab@github.com>
Message-ID: <7nhl4ulu-6-UG-hGjPgPr0xoxigOPbzISc9Wjie5LvQ=.8937e402-6dde-4298-abdf-ffb953a3a302@github.com>

On Fri, 13 Dec 2019 01:20:47 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 494:
>> 
>>> 493:      * Values less than 1 are treated as 1. This value overrides the
>>> 494:      * {@code tabSize} of contained {@link javafx.scene.text.Text Text} nodes.
>>> 495:      *
>> 
>> `{@link Text}` is enough, but the FQN is also fine.
>> 
>> Does `Text`'s `tabSize` need a note that its value is overriden if the text is contained in a `TextFlow`?
> 
> TextFlow isn't mentioned in the JavaDoc for any of the other Text properties where the same rule applies.  Perhaps that should be remedied with a follow-up task?

A follow-up issue would be fine.

-------------

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

From swpalmer at openjdk.java.net  Sat Dec 14 20:35:30 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Sat, 14 Dec 2019 20:35:30 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <7nhl4ulu-6-UG-hGjPgPr0xoxigOPbzISc9Wjie5LvQ=.8937e402-6dde-4298-abdf-ffb953a3a302@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
 <IQcJprXrM5yDUVauVql-zIycS_F5F4u971CRMsxQlhQ=.da9fd03a-1499-48f5-a88b-94c5adaa7011@github.com>
 <p9VBYxCrhmucAyOOt56TqA1Z4F1vZ0VNJEvD1gvInNI=.d271a859-85a8-4732-b109-e38f4180c8ab@github.com>
 <7nhl4ulu-6-UG-hGjPgPr0xoxigOPbzISc9Wjie5LvQ=.8937e402-6dde-4298-abdf-ffb953a3a302@github.com>
Message-ID: <LTAzjiaE0PkKfYRIix09A02jPeb0JHj7q8AZAWeUadE=.27ce5071-4f9a-4e3a-8412-9ad0b1882ffe@github.com>

On Sat, 14 Dec 2019 16:38:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> TextFlow isn't mentioned in the JavaDoc for any of the other Text properties where the same rule applies.  Perhaps that should be remedied with a follow-up task?
> 
> A follow-up issue would be fine.

I've created https://bugs.openjdk.java.net/browse/JDK-8235958 as a follow-up javadoc enhancement.

-------------

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

From swpalmer at openjdk.java.net  Sat Dec 14 20:47:16 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Sat, 14 Dec 2019 20:47:16 GMT
Subject: [Rev 05] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
Message-ID: <-EQiBrSkLEbmDIE2fwRic4XLsKmRuk9f7MTNnRKvgzA=.591b8ad4-0598-47a1-b721-86203f2adbab@github.com>

> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both.  TextFlow's tab size overrides that of contained Text nodes.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - f846ad6d: 8130738: Add tabSize property to Text and TextFlow

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/32/files
  - new: https://git.openjdk.java.net/jfx/pull/32/files/f99a3aa9..f846ad6d

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/32/webrev.05
 - incr: https://webrevs.openjdk.java.net/jfx/32/webrev.04-05

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

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

From farrukh.najm at gmail.com  Sun Dec 15 23:13:35 2019
From: farrukh.najm at gmail.com (Farrukh Najmi)
Date: Sun, 15 Dec 2019 18:13:35 -0500
Subject: openjfx 13 MediaPlayer vodeo stutter
Message-ID: <CAN0VY+-jRZAQ1FebKY_odgZK7Z9yf-h0T4xnXE0fUbcMG86S1A@mail.gmail.com>

On Ubuntu linux 18.04 I have been successfully using openjfx 13 during
development of a new app. My app plays the same video over and over
using javafx.scene.media.MediaView and javafx.scene.media.MediaPlayer.
At first the video plays flawlessly. After a few hours the video becomes
choppy and starts displaying stutter. I have analyzed my app for memory
leaks and thread leaks and do not believe it has any.
I observe that "top -H" command shows the following with QuantumRenderer at
top:

Threads: 575 total,   6 running, 515 sleeping,   0 stopped,   1 zombie
%Cpu(s): 64.3 us,  8.1 sy,  0.0 ni, 25.0 id,  0.0 wa,  0.0 hi,  2.6 si,
 0.0 st
KiB Mem : 26.7/7988780  [|||||||||||||||||||||||||||
                                                  ]
KiB Swap:  0.0/2097148  [
                                                 ]

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND

 1432 root      20   0  0.101t 702424  90656 R 93.5  8.8   1471:14
QuantumRenderer
 9901 root      20   0  0.101t 702424  90656 R 60.1  8.8 424:41.22
queue7:src
 2592 root      20   0  0.101t 702424  90656 S 59.8  8.8 505:55.76
queue5:src
 1133 ubuntu    20   0  912192 172908  87736 R 58.2  2.2   1133:23 Xorg

 1335 root      20   0  334104  34200   9968 S  5.6  0.4  77:41.33 val

 9900 root      20   0  0.101t 702424  90656 S  4.2  8.8  28:22.37
qtdemux3:sink
 2594 root      20   0  0.101t 702424  90656 S  2.9  8.8  30:41.56
qtdemux2:sink
 2590 root      20   0  0.101t 702424  90656 S  1.6  8.8  16:05.02
queue4:src
 9903 root      20   0  0.101t 702424  90656 S  1.6  8.8  11:08.72
queue6:src
 1976 ubuntu    -6   0 1172376  12012   8796 S  1.6  0.2  26:16.32
alsa-sink-ALC25
 9546 ubuntu    20   0   51728   4560   3544 R  1.6  0.1   0:00.26 top

 1620 root      20   0  0.101t 702424  90656 S  0.7  8.8  14:45.24 JavaFX
Applicat
 9887 root      20   0  0.101t 702424  90656 S  0.7  8.8   4:27.78 Timer-47

 9902 root      20   0  0.101t 702424  90656 S  0.7  8.8   2:46.59
threaded-ml
 9905 root      20   0  0.101t 702424  90656 S  0.7  8.8   4:37.95 Timer-49

 1454 ubuntu    20   0 3389116 131052  68972 S  0.7  1.6   3:11.03
gnome-shell
 1487 ubuntu     9 -11 1172376  12012   8796 S  0.7  0.2  10:28.21
pulseaudio
  912 root      20   0  0.101t 702424  90656 S  0.3  8.8   1:09.97 GC
Thread#0
  916 root      20   0  0.101t 702424  90656 S  0.3  8.8   0:30.33 G1 Young
RemSet
  920 root      20   0  0.101t 702424  90656 S  0.3  8.8   0:43.78 VM
Thread
 1619 root      20   0  0.101t 702424  90656 S  0.3  8.8   4:41.19
InvokeLaterDisp
 2228 root      20   0  0.101t 702424  90656 S  0.3  8.8   1:06.68 GC
Thread#3
 9883 root      20   0  0.101t 702424  90656 S  0.3  8.8   1:25.20 JFXMedia
Player

I am looking for suggestions on how to fix the video stutter issue. Is this
a known issue. If so, please share link to issue.
If it is a known issue, has it been fixed in openjfx 14-ea+4? I tried using
that EA release but with that as dependency my video seems to stop and
first frame and does not play at all.
I am wondering if there are any migration steps that I may be missing.

TIA for any suggestion on how to fix my video stutter issue with openjfx 13
or openjfx 14-ea+4.

-- 
Regards,
Farrukh

From nlisker at gmail.com  Mon Dec 16 02:06:11 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 16 Dec 2019 04:06:11 +0200
Subject: [openjdk/jfx] 8234712: Add pivot properties for scale and
 rotation in Node, ScaleTransition and RotateTransition (#53)
In-Reply-To: <openjdk/jfx/pull/53/c565731609@github.com>
References: <openjdk/jfx/pull/53@github.com>
 <openjdk/jfx/pull/53/c565731609@github.com>
Message-ID: <CA+0ynh-TG1aig3Ut0pgTjcAD8XdR76dGXNoisBzGqdLV99Dq=Q@mail.gmail.com>

Replying on the mailing list to the questions raised on GitHub.

The state of whether to use the computed center pivot or the value of the
> pivot attribute is implicit with no way for an application to know which it
> is, and no way to set it back to using the computed center (i.e., the state
> is sticky once you set it). Perhaps if you defined a null value as meaning
> "computed center" then an app could at least reset it to the "computed
> center" state, although there would still be no way for the app to know
> that it was in that state.
>

In the JBS issue <https://bugs.openjdk.java.net/browse/JDK-8234712> I
alluded to this in point 5. I think that null should represent the default
(node center). However, if we use 3 doubles instead of a Point3D we might
need to use Double.NaN for this instead, which would also be the default
for this case. The docs will explain this.

Do we need separate properties for scale pivot and center pivot?
>

I say yes, otherwise the enhancement will be very limited. I think of this
enhancement as adding pivot control to Rotate/Scale transitions, and adding
them to Node is a necessary (and desirable) step.

   ... you need to worry about what coordinate space the rotation pivot is
> defined in. Perhaps if the rotation pivot were defined in unscaled space,
> it might work.
>

Isn't it already? If I set the rotation pivot to the edge of the node, then
scale it down, then rotate, the rotation pivot would be outside of the
node's boundaries. In scaled space it would still be on the edge. Or did I
misunderstand you? In any case, I don't think that there's a single correct
answer here.

Should the pivot be specified as a Point3D or 3 separate doubles? Separate
> doubles... there would be no out-of-band null value to use


See my point above about Double.NaN.
The doubles vs Point3D is an important choice. We might want to look into
the future even where Point3D (and 2D) could be made into an Inline class
with Valhalla, which will help with the performance aspect. Binding to one
of the coordinates is sill a problem there, however.

On Sat, Dec 14, 2019 at 6:25 PM Kevin Rushforth <notifications at github.com>
wrote:

> This will need discussion on the openjfx-dev mailing list. Here are the
> questions that need to be resolved:
>
>    1.
>
>    The state of whether to use the computed center pivot or the value of
>    the pivot attribute is implicit with no way for an application to know
>    which it is, and no way to set it back to using the computed center (i.e.,
>    the state is sticky once you set it). Perhaps if you defined a null value
>    as meaning "computed center" then an app could at least reset it to the
>    "computed center" state, although there would still be no way for the app
>    to know that it was in that state.
>    2.
>
>    Do we need separate properties for scale pivot and center pivot? A
>    single pivot property would be easier to define, but wouldn't allow you to
>    set it from a RotationTransition and a ScaleTransition if you wanted
>    to apply both to the same Node. With two separate properties, as you
>    have defined it, it is more flexible, but you need to worry about what
>    coordinate space the rotation pivot is defined in. The current transform
>    chain looks like this:
>
> T(layout+translate) * T(pivot) * T(rot) * T(scale) * T(-pivot)
>     * transform[0] * transform [1] ...
>
> Perhaps if the rotation pivot were defined in unscaled space, it might
> work. The transform chain would then look like this:
>
> T(layout+translate) * T(pivotRot/scale) * T(rot) * T(-pivotRot/scale) * T(pivotScale) * T(scale) * T(-pivotScale)
>     * transform[0] * transform [1] ...
>
> In any case, you need to think about the implications of having one of
> scale or rotate being set explicitly and the other being the computed
> center.
>
>    1. Should the pivot be specified as a Point3D or 3 separate doubles? I
>    can see pros / cons of either approach. Separate doubles are more
>    consistent with the the pivot values in the Rotate and Scale Transform
>    objects, and are easier to using in binding. On the other hand, there would
>    be no out-of-band null value to use (see issue 1 above), so you would
>    need a boolean property for each of scale pivot and rotation pivot to
>    indicate whether the computed value or the value of the pivot properties
>    should be used. I don't think that the fact that the rotation axis is
>    defined as a Point3D should have any bearing on whether the pivot
>    should be so defined. I'd probably lean towards separate doubles.
>
> ?
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jfx/pull/53?email_source=notifications&email_token=AI5QOM6KRPRRP7VS5OUH6QLQYUCF7A5CNFSM4JR3TYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4GCGI#issuecomment-565731609>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AI5QOM4UKZQVDEN2A2HYYETQYUCF7ANCNFSM4JR3TYYQ>
> .
>

From aghaisas at openjdk.java.net  Mon Dec 16 08:53:11 2019
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 16 Dec 2019 08:53:11 GMT
Subject: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
Message-ID: <5SDz-Lu-Jwm9MAxHPE3vAWz6FQz_t_guzALkhdCxOCI=.136693af-b0a5-4ec4-af54-27fdc254431d@github.com>

On Mon, 16 Dec 2019 08:53:10 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759
>> 
>> The issue is that default/cancel button on a scene are triggered even though a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug for details on both cause and fix.
>> 
>> There are additional/changed tests to verify the fix. All old tests are passing.
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by aghaisas (Reviewer).

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

From shadzic at openjdk.java.net  Mon Dec 16 09:18:17 2019
From: shadzic at openjdk.java.net (Hadzic Samir)
Date: Mon, 16 Dec 2019 09:18:17 GMT
Subject: [Rev 06] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
Message-ID: <f2DJ-EsqJepI20bkxOxtowqyXYKGXqkl06eDI1Vx47Q=.35f8dc7b-54e5-48ac-a74d-d59cc4a7b85e@github.com>

> Allright, this is a fix for JDK-8207957

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 9991ec48: Minor typo fix upon Kevin's review

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/6/files
  - new: https://git.openjdk.java.net/jfx/pull/6/files/e1a9d2d0..9991ec48

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/6/webrev.06
 - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.05-06

  Stats: 27 lines in 2 files changed: 8 ins; 3 del; 16 mod
  Patch: https://git.openjdk.java.net/jfx/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6

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

From shadzic at openjdk.java.net  Mon Dec 16 09:20:25 2019
From: shadzic at openjdk.java.net (Hadzic Samir)
Date: Mon, 16 Dec 2019 09:20:25 GMT
Subject: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
Message-ID: <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>

> Allright, this is a fix for JDK-8207957

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 79817025: Remove trailing spaces

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/6/files
  - new: https://git.openjdk.java.net/jfx/pull/6/files/9991ec48..79817025

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/6/webrev.07
 - incr: https://webrevs.openjdk.java.net/jfx/6/webrev.06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/6/head:pull/6

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

From shadzic at openjdk.java.net  Mon Dec 16 09:41:39 2019
From: shadzic at openjdk.java.net (Hadzic Samir)
Date: Mon, 16 Dec 2019 09:41:39 GMT
Subject: [Rev 05] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <SqH9DD8EmBI5NZ4rkcy7-OYrpm2Ecun0K2OdRWyTJMA=.db42e730-6a2d-4336-94b1-4279d6e7030c@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <jgyrznjFlcuhYXcXP3uIRbNTbR4V-1YjU2cyT8k2yo4=.af36bdb2-a728-418a-8f54-0e418e498c30@github.com>
 <xEH1ebDM4o5xphO7OExOSRWH8Ja-pcCRiVq3s0dPIWE=.3cc0b63a-9111-4f65-81d3-b660192a96c4@github.com>
 <OtAAQoKEmvXJs1gD4SwJkXS95FLS8TiDHuasdfJvVqk=.65613f71-f069-4666-a269-9c36df5b9539@github.com>
 <21f1pJ4D38KMemipRY1jP-omCI5I_VJXTXb8gznQvx0=.928f2c83-97e0-4de9-8280-e1585701a153@github.com>
 <SqH9DD8EmBI5NZ4rkcy7-OYrpm2Ecun0K2OdRWyTJMA=.db42e730-6a2d-4336-94b1-4279d6e7030c@github.com>
Message-ID: <J9NqacCal6BAqJpmiTT1xtPNHKhzw3JoKxWOSIc1ppg=.aca958a3-1e25-486b-bfe0-04399c4247c7@github.com>

On Wed, 11 Dec 2019 00:32:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Thanks for the review. I do not have access to a computer right now, I'll
>> update next week on Monday.
>> 
>> Le lun. 9 d?c. 2019 ? 17:01, Kevin Rushforth <notifications at github.com> a
>> ?crit :
>> 
>>> I would like both @aghaisas <https://github.com/aghaisas> and myself to
>>> review / approve this. I will sponsor it.
>>>
>>> In addition, the CSR needs to be approved before this can be integrated.
>>>
>>> ?
>>> You are receiving this because you authored the thread.
>>> Reply to this email directly, view it on GitHub
>>> <https://github.com/openjdk/jfx/pull/6?email_source=notifications&email_token=ACEL43KWFAJ32FX3NNSM7ETQX2W3LA5CNFSM4I5EYYAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGKV3YQ#issuecomment-563437026>,
>>> or unsubscribe
>>> <https://github.com/notifications/unsubscribe-auth/ACEL43PNZLRK37IM33ROVGDQX2W3LANCNFSM4I5EYYAA>
>>> .
>>>
> 
> I took the liberty of updating the CSR to add the missing comma, so I could mark it as Reviewed. You can Finalize the CSR when you are ready.

> 
> 
> I took the liberty of updating the CSR to add the missing comma, so I could mark it as Reviewed. You can Finalize the CSR when you are ready.

Thank you, I have committed new changes according to your review. I have also moved the CSR to "finalize".

Let me know if I need to do something else, sorry for the delay.

-------------

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

From fastegal at openjdk.java.net  Mon Dec 16 11:21:58 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 16 Dec 2019 11:21:58 GMT
Subject: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <5SDz-Lu-Jwm9MAxHPE3vAWz6FQz_t_guzALkhdCxOCI=.136693af-b0a5-4ec4-af54-27fdc254431d@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <5SDz-Lu-Jwm9MAxHPE3vAWz6FQz_t_guzALkhdCxOCI=.136693af-b0a5-4ec4-af54-27fdc254431d@github.com>
Message-ID: <we6UiWngwOHLkVE0GqzeDJ6lQGe0UgTj62_T7f6Yvk4=.32c49dfd-8114-4e21-8608-1a402b6995fc@github.com>

On Mon, 16 Dec 2019 08:52:56 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> 

Zitat von "openjdk[bot]" <notifications at github.com>:

> @kleopatra This change can now be integrated. The commit message will be:
> ```

Ajit, Kevin,

hmm .. wondering if this message is a bot-error? Kevin stated that it  
needs two reviewers (approving, I assume?) but currently have one only  
- so question is: should I post the /integrate comment or not yet?

-- Jeanette



> 8207759: VK_ENTER not consumed by TextField when default Button exists
>
> Reviewed-by: aghaisas
> ```
> - If you would like to add a summary, use the `/summary` command.
> - To list additional contributors, use the `/contributor` command.
>
> Since the source branch of this PR was last updated there have been  
> 53 commits pushed to the `master` branch:
>  * fc539b57fbbebaab3c99c509d6e5f0e3b88858fa: 8223296:  
> NullPointerException in GlassScene.java at line 325
>  * 71ca899fbfc74d825c29b20a778d6d9eb243f90f: 8220722:  
> ProgressBarSkin: adds strong listener to control's width property
>  * 07af89a9e1a5e044d416e73dd14a84056fadf53c: 8221334: TableViewSkin:  
> must initialize flow's cellCount in constructor
>  * 4ddf55428d06dddadfc8cd14baabdc4d17318ee2: 8234916: [macos 10.15]  
> Garbled text running with native-image
>  * 46338d02754a5b5d475b065d492315fa307a0e3d: 8232524:  
> SynchronizedObservableMap cannot be be protected for copying/iterating
>  * a68347cbbf2191c981472c82c2b64d77bfbc613d: 8235150: IosApplication  
> does not pass the required object in _leaveNestedEventLoopImpl
>  * 1c27fbd218f1be2beac5cacbe93f202c11de439f: 8210955:  
> DOMTest::testEventListenerCascade fails
>  * 2d4096a8ffefb787bd71eb535231766a045e515f: 8235151: Nonexistent  
> notifyQuit method referred from iOS GlassHelper.m
>  * 98035cb2afef0c230d55095f0addeab73693d0ac: 8211308: Support HTTP/2  
> in WebView
>  * 6892fa1b3bbcfdb0e643a26441622916be987a38: 8232064: Switch FX  
> build to use JDK 13.0.1 as boot JDK
>  * 1d670f18d16d060dc40e83733cb3595c41df2a97: 8200224: Multiple press  
> event when JFXPanel gains focus
>  * 83eb0a7c9150566aae96db8ce9d1f78b714c9d1b: 8193445: JavaFX CSS is  
> applied redundantly leading to significant performance degradation
>  * 798afbcaeb73b90ba4bd511380786f7956e1b443: 8230610: Upgrade  
> GStreamer to version 1.16.1
>  * 126896db9928ae334332d38486fb61ad3a2e00a0: 8234704: Fix  
> attribution in libxslt.md
>  * 4d3c723e2f18efaca32a9df234063c7895b5540c: 8234593: Mark  
> LeakTest.testGarbageCollectability as unstable
>  * 5a398244af8f029d99d9cffc291667fc9c1ad9df: 8234056: Upgrade to  
> libxslt 1.1.34
>  * 8bea7b71454ada53881847c751add63e8fc99ea3: 8229472: Deprecate for  
> removal JavaBeanXxxPropertyBuilders constructors
>  * aad1720608856e910edaf05d0d53e87942642326: 8233420: Upgrade to gcc  
> 8.3 on Linux
>  * 42040c4cdb58eb0c6029a727df61b00248ee8e2b: 8232063: Upgrade gradle  
> to version 6.0
>  * aab07a4d01604355516de641b6141c91a30e0dc7: 8234239: [TEST_BUG]  
> Reenable few ignored web tests
>  * 95ad6017dc85b9504a4c20dd20f31094d9075f42: 8233421: Upgrade to  
> Visual Studio 2017 version 15.9.16
>  * 3e0557a815b6336d4e2eeaf5e833fe65f4298833: 8234303: [TEST_BUG]  
> Correct ignore tag in graphics unit tests
>  * e37cb37005b71edbf462eaa360c529a1e68c8656: 8234150: Address  
> ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and  
> TextInputControlTest
>  * 4f496d417915b450880cbe664cba9130ab76ca08: 8234194: [TEST_BUG]  
> Reenable few graphics unit tests
>  * 927fc8a0f88adcaeb069bf0a7218a9c3f875d707: 8234174: Change IDEA  
> VCS mapping to Git
>  * 3d0cb4966a240ce81d18acffd64939757b79bed5: 8234189: [TEST_BUG]  
> Remove ignored and invalid graphics unit tests
>  * dc0130944365b61ac4a4333df29d684e9566d3cf: 8234110:  
> SwingFXUtilsTest is unsuitable for unit test framework
>  * 5b96ee42ac786ec23b99564715679d352c1637be: 8231188: Update SQLite  
> to version 3.30.1
>  * d46dcae7a571724f10d58e424842d703ea1cb0e3: 8233338: FX javadoc  
> headings are out of sequence
>  * 94bcf3fcfce83bae8d2014f15e993ba2edf24e0f: 8231692: Test  
> Infrastructure: enhance KeyEventFirer to inject keyEvents into scene
>  * 286d1b5427a2b9724cb400335741ed99295c5141: 8230492: font-family  
> not set in HTMLEditor if font name has a number in it
>  * f74f3afba53404e5169d97ef0d78c3ef2eeb42ef: 8233040:  
> ComboBoxPopupControl: remove eventFilter for F4
>  * a1cc4ab03698e9e9add95ecad191c9d89c6f35dd: 8232210: Update Mesa  
> 3-D Headers to version 19.2.1
>  * dca8df4e5d9071622dbaf83be48ae71b0927e6ae: 8232943: Gesture  
> support is not initialized on iOS
>  * 5a70b0c58cd723b535a6385fc8b431175ef44565: 8189092:  
> ArrayIndexOutOfBoundsException on Linux in getCachedGlyph
>  * ac71396c9b1eb390cf09fde928fe5fbd9c31e089: 8232929: Duplicate  
> symbols when building static libraries
>  * ab6ea3b936f319cdea997aabed63ffdc639a75e1: 8232158: [macOS]  
> Fallback to command line tools if xcode is missing
>  * 2ae171a2a0e6d1c24e6943f4f9a48987f6ed8ef4: 8232687: No static JNI  
> loader for libprism-sw
>  * a09a0fa595de95d4311495b6584804910d7fa5b9: 8232522: FX: Update  
> copyright year in docs, readme files to 2020
>  * 582d9993d5908be1ceef2376e0242208a886ed0f: Merge
>  * b6e53f4f349a9fd5678500c56d34133c4fee2ac6: 8218640: Update ICU4C  
> to version 64.2
>  * bada612a59bbf46c14b3712e2b599044ef3872f7: Merge
>  * 64aaeb840aa157e358eb41001c3705aa5c2fee30: 8226754: FX build fails  
> using gradle 5.6+ or 6
>  * a4bc22d25f79f3f9658f5c6fc0d90f2bf34aa4cf: Merge
>  * 2593dea30b3610fef713ff4a215b6ae9d699ca3f: Merge
>  * 9df20c561473cd62375d5908234f9a81b39889a6: Merge
>  * a1aa38a479bf0449e39d14075980448058c8a0d3: Merge
>  * 0ff02bbcb5db2cc276c75ba0c18eb846fba8f0ad: Merge
>  * a433bf2752ace3d4dc0a9db0313d75768b64b253: Merge
>  * 561153dbc218d00dc0486b58db1a7a8cfeffb64a: Merge
>  * 75d439e969d9e4c7022f2eeb981787b371014456: Merge
>  * 758252f9c4e6c283bd9872ad2e2b7b95a2e0a94d: Merge
>  * 35e0caea17dd612cf69c1876a0649a8897ab88f0: 8227402: Improve XSLT processing
>
> Since there are no conflicts, your changes will automatically be  
> rebased on top of the above commits when integrating. If you prefer  
> to do this manually, please merge `master` into your branch first.
>
> As you do not have Committer status in this project, an existing  
> [Committer](https://openjdk.java.net/bylaws#committer) must agree to  
> [sponsor](https://openjdk.java.net/sponsor/) your change. Possible  
> candidates are the reviewers of this PR (@aghaisas) but any other  
> Committer may sponsor as well.
>
> - To flag this PR as ready for integration with the above commit  
> message, type `/integrate` in a new comment. (Afterwards, your  
> sponsor types `/sponsor` in a new comment to perform the integration).
> 
>
> --
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub:
> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995

-------------

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

From mp at jugs.org  Mon Dec 16 11:35:44 2019
From: mp at jugs.org (Michael Paus)
Date: Mon, 16 Dec 2019 12:35:44 +0100
Subject: [openjdk/jfx] 8234712: Add pivot properties for scale and
 rotation in Node, ScaleTransition and RotateTransition (#53)
In-Reply-To: <CA+0ynh-TG1aig3Ut0pgTjcAD8XdR76dGXNoisBzGqdLV99Dq=Q@mail.gmail.com>
References: <openjdk/jfx/pull/53@github.com>
 <openjdk/jfx/pull/53/c565731609@github.com>
 <CA+0ynh-TG1aig3Ut0pgTjcAD8XdR76dGXNoisBzGqdLV99Dq=Q@mail.gmail.com>
Message-ID: <f416433e-8bba-708f-6e08-799984b2b346@jugs.org>

I don't think there are clearly right or wrong answers to all these 
questions,
so I would just like to provide a view thoughts on this.

The governing principle should be a principle of "least surprise" from a 
users
point of view. That means we should not make things more complicated as
they already are and should always keep the practical use-cases in mind.
If you need full flexibility, you can always use the explicit transforms.

We currently have the notion of the "Node's center" which is used for 
scaling
and rotation and I think we should stick to that. The documentation later
explains that "The pivot point about which the rotation occurs is the center
of the untransformed layoutBounds." which is a completely arbitrary decision
because, e.g., from a mathematically point of view the geometric center 
of the
node would seem to be more natural but is more difficult to compute for 
general
shapes. So, we should just extend this scheme in such a way that the 
user can
replace the single computed center with a single user-defined center
specified in untransformed coordinates. Introducing two separate centers
for rotation and scaling is, to my opinion, just academic without any 
practical
use-case and in the end much more complicated for the user.

I would also specify this center point as a Point3D for two reasons:
1. Three doubles always use their full space even if you don't need them.
2. Using Double.NaNs as a switch between computed and user-provided center
 ??? is just confusing and error-prone.
 ??? What would be the meaning of setting x to some value but leaving y 
and z as
 ??? NaN? Would you implicitly set them to 0.0 or use the computed values or
 ??? would you discard this user setting completely and use all the 
computed
 ??? values if any of the components is NaN? I bet most users will 
forget to set the
 ??? Z-value anyway if they are thinking 2D. A simple null value is much 
easier
 ??? to handle and explain.

Just my two ?ent.

--Michael

Am 16.12.19 um 03:06 schrieb Nir Lisker:
> Replying on the mailing list to the questions raised on GitHub.
>
> The state of whether to use the computed center pivot or the value of the
>> pivot attribute is implicit with no way for an application to know which it
>> is, and no way to set it back to using the computed center (i.e., the state
>> is sticky once you set it). Perhaps if you defined a null value as meaning
>> "computed center" then an app could at least reset it to the "computed
>> center" state, although there would still be no way for the app to know
>> that it was in that state.
>>
> In the JBS issue <https://bugs.openjdk.java.net/browse/JDK-8234712> I
> alluded to this in point 5. I think that null should represent the default
> (node center). However, if we use 3 doubles instead of a Point3D we might
> need to use Double.NaN for this instead, which would also be the default
> for this case. The docs will explain this.
>
> Do we need separate properties for scale pivot and center pivot?
> I say yes, otherwise the enhancement will be very limited. I think of this
> enhancement as adding pivot control to Rotate/Scale transitions, and adding
> them to Node is a necessary (and desirable) step.
>
>     ... you need to worry about what coordinate space the rotation pivot is
>> defined in. Perhaps if the rotation pivot were defined in unscaled space,
>> it might work.
>>
> Isn't it already? If I set the rotation pivot to the edge of the node, then
> scale it down, then rotate, the rotation pivot would be outside of the
> node's boundaries. In scaled space it would still be on the edge. Or did I
> misunderstand you? In any case, I don't think that there's a single correct
> answer here.
>
> Should the pivot be specified as a Point3D or 3 separate doubles? Separate
>> doubles... there would be no out-of-band null value to use
>
> See my point above about Double.NaN.
> The doubles vs Point3D is an important choice. We might want to look into
> the future even where Point3D (and 2D) could be made into an Inline class
> with Valhalla, which will help with the performance aspect. Binding to one
> of the coordinates is sill a problem there, however.
>
> On Sat, Dec 14, 2019 at 6:25 PM Kevin Rushforth <notifications at github.com>
> wrote:
>
>> This will need discussion on the openjfx-dev mailing list. Here are the
>> questions that need to be resolved:
>>
>>     1.
>>
>>     The state of whether to use the computed center pivot or the value of
>>     the pivot attribute is implicit with no way for an application to know
>>     which it is, and no way to set it back to using the computed center (i.e.,
>>     the state is sticky once you set it). Perhaps if you defined a null value
>>     as meaning "computed center" then an app could at least reset it to the
>>     "computed center" state, although there would still be no way for the app
>>     to know that it was in that state.
>>     2.
>>
>>     Do we need separate properties for scale pivot and center pivot? A
>>     single pivot property would be easier to define, but wouldn't allow you to
>>     set it from a RotationTransition and a ScaleTransition if you wanted
>>     to apply both to the same Node. With two separate properties, as you
>>     have defined it, it is more flexible, but you need to worry about what
>>     coordinate space the rotation pivot is defined in. The current transform
>>     chain looks like this:
>>
>> T(layout+translate) * T(pivot) * T(rot) * T(scale) * T(-pivot)
>>      * transform[0] * transform [1] ...
>>
>> Perhaps if the rotation pivot were defined in unscaled space, it might
>> work. The transform chain would then look like this:
>>
>> T(layout+translate) * T(pivotRot/scale) * T(rot) * T(-pivotRot/scale) * T(pivotScale) * T(scale) * T(-pivotScale)
>>      * transform[0] * transform [1] ...
>>
>> In any case, you need to think about the implications of having one of
>> scale or rotate being set explicitly and the other being the computed
>> center.
>>
>>     1. Should the pivot be specified as a Point3D or 3 separate doubles? I
>>     can see pros / cons of either approach. Separate doubles are more
>>     consistent with the the pivot values in the Rotate and Scale Transform
>>     objects, and are easier to using in binding. On the other hand, there would
>>     be no out-of-band null value to use (see issue 1 above), so you would
>>     need a boolean property for each of scale pivot and rotation pivot to
>>     indicate whether the computed value or the value of the pivot properties
>>     should be used. I don't think that the fact that the rotation axis is
>>     defined as a Point3D should have any bearing on whether the pivot
>>     should be so defined. I'd probably lean towards separate doubles.
>>
>> ?
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/openjdk/jfx/pull/53?email_source=notifications&email_token=AI5QOM6KRPRRP7VS5OUH6QLQYUCF7A5CNFSM4JR3TYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4GCGI#issuecomment-565731609>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AI5QOM4UKZQVDEN2A2HYYETQYUCF7ANCNFSM4JR3TYYQ>
>> .
>>


From aghaisas at openjdk.java.net  Mon Dec 16 11:47:16 2019
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 16 Dec 2019 11:47:16 GMT
Subject: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>
Message-ID: <pRzmcqHIMvdIRCiS87m6u0aU0pPVJ6DMDCPrFd93RVQ=.935ef274-c291-4210-8bf0-031054554545@github.com>

On Mon, 16 Dec 2019 11:47:15 GMT, Hadzic Samir <shadzic at openjdk.org> wrote:

>> Allright, this is a fix for JDK-8207957
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by aghaisas (Reviewer).

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

From fastegal at openjdk.java.net  Mon Dec 16 12:12:46 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 16 Dec 2019 12:12:46 GMT
Subject: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <pRzmcqHIMvdIRCiS87m6u0aU0pPVJ6DMDCPrFd93RVQ=.935ef274-c291-4210-8bf0-031054554545@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>
 <pRzmcqHIMvdIRCiS87m6u0aU0pPVJ6DMDCPrFd93RVQ=.935ef274-c291-4210-8bf0-031054554545@github.com>
Message-ID: <_6hq7HKsRwiMauF_HkzXkQPB1DisrVgyBzthZGJfWII=.ffef16de-17e6-4ce7-9938-822b587d5803@github.com>

On Mon, 16 Dec 2019 11:46:57 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> 

hmm ... think that the bot isn't yet clever enough: this pull request needs approval of two reviewer with _review_ role (mine is only informal)

-------------

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

From fastegal at swingempire.de  Mon Dec 16 12:23:55 2019
From: fastegal at swingempire.de (Jeanette Winzenburg)
Date: Mon, 16 Dec 2019 13:23:55 +0100
Subject: Skara - bot sending can-be-integrated message prematurely?
Message-ID: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>


Looks like it assumes a pull request as properly reviewed as soon as  
it gets a single approve - independent on how many reviewers are  
required, see f.i.

https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
https://github.com/openjdk/jfx/pull/6#issuecomment-566028296

-- Jeanette


From nlisker at gmail.com  Mon Dec 16 12:48:53 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 16 Dec 2019 14:48:53 +0200
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
Message-ID: <CA+0ynh9GFvex=WXfHPy4N4DkN4NJFNAhwBdkgPDyAyga95TOag@mail.gmail.com>

The bot doesn't know how many reviewers are needed. This was brought up
before in point 3 in
http://mail.openjdk.java.net/pipermail/openjfx-dev/2019-October/023662.html.

- Nir

On Mon, Dec 16, 2019 at 2:24 PM Jeanette Winzenburg <fastegal at swingempire.de>
wrote:

>
> Looks like it assumes a pull request as properly reviewed as soon as
> it gets a single approve - independent on how many reviewers are
> required, see f.i.
>
> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>
> -- Jeanette
>
>

From fastegal at swingempire.de  Mon Dec 16 13:07:37 2019
From: fastegal at swingempire.de (Jeanette Winzenburg)
Date: Mon, 16 Dec 2019 14:07:37 +0100
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <CA+0ynh9GFvex=WXfHPy4N4DkN4NJFNAhwBdkgPDyAyga95TOag@mail.gmail.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <CA+0ynh9GFvex=WXfHPy4N4DkN4NJFNAhwBdkgPDyAyga95TOag@mail.gmail.com>
Message-ID: <20191216140737.Horde.tvYSxNLlxhST3oWp6TGzVQ1@webmail.df.eu>


Zitat von Nir Lisker <nlisker at gmail.com>:

> The bot doesn't know how many reviewers are needed. This was brought up
> before in point 3 in
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2019-October/023662.html.
>

missed that - thanks for the pointer :)

> - Nir
>
> On Mon, Dec 16, 2019 at 2:24 PM Jeanette Winzenburg <fastegal at swingempire.de>
> wrote:
>
>>
>> Looks like it assumes a pull request as properly reviewed as soon as
>> it gets a single approve - independent on how many reviewers are
>> required, see f.i.
>>
>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>
>> -- Jeanette
>>
>>




From kcr at openjdk.java.net  Mon Dec 16 13:48:43 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 16 Dec 2019 13:48:43 GMT
Subject: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <we6UiWngwOHLkVE0GqzeDJ6lQGe0UgTj62_T7f6Yvk4=.32c49dfd-8114-4e21-8608-1a402b6995fc@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
 <5SDz-Lu-Jwm9MAxHPE3vAWz6FQz_t_guzALkhdCxOCI=.136693af-b0a5-4ec4-af54-27fdc254431d@github.com>
 <we6UiWngwOHLkVE0GqzeDJ6lQGe0UgTj62_T7f6Yvk4=.32c49dfd-8114-4e21-8608-1a402b6995fc@github.com>
Message-ID: <mVb3yVcMgO6qr_d8AkUeqcNgTjkMvHzZO-i9hd8dZMQ=.4d5796f7-301e-4c64-a8fd-68a17416081c@github.com>

On Mon, 16 Dec 2019 11:21:45 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>>
> 
> Zitat von "openjdk[bot]" <notifications at github.com>:
> 
>> @kleopatra This change can now be integrated. The commit message will be:
>> ```
> 
> Ajit, Kevin,
> 
> hmm .. wondering if this message is a bot-error? Kevin stated that it  
> needs two reviewers (approving, I assume?) but currently have one only  
> - so question is: should I post the /integrate comment or not yet?
> 
> -- Jeanette
> 
> 
> 
>> 8207759: VK_ENTER not consumed by TextField when default Button exists
>>
>> Reviewed-by: aghaisas
>> ```
>> - If you would like to add a summary, use the `/summary` command.
>> - To list additional contributors, use the `/contributor` command.
>>
>> Since the source branch of this PR was last updated there have been  
>> 53 commits pushed to the `master` branch:
>>  * fc539b57fbbebaab3c99c509d6e5f0e3b88858fa: 8223296:  
>> NullPointerException in GlassScene.java at line 325
>>  * 71ca899fbfc74d825c29b20a778d6d9eb243f90f: 8220722:  
>> ProgressBarSkin: adds strong listener to control's width property
>>  * 07af89a9e1a5e044d416e73dd14a84056fadf53c: 8221334: TableViewSkin:  
>> must initialize flow's cellCount in constructor
>>  * 4ddf55428d06dddadfc8cd14baabdc4d17318ee2: 8234916: [macos 10.15]  
>> Garbled text running with native-image
>>  * 46338d02754a5b5d475b065d492315fa307a0e3d: 8232524:  
>> SynchronizedObservableMap cannot be be protected for copying/iterating
>>  * a68347cbbf2191c981472c82c2b64d77bfbc613d: 8235150: IosApplication  
>> does not pass the required object in _leaveNestedEventLoopImpl
>>  * 1c27fbd218f1be2beac5cacbe93f202c11de439f: 8210955:  
>> DOMTest::testEventListenerCascade fails
>>  * 2d4096a8ffefb787bd71eb535231766a045e515f: 8235151: Nonexistent  
>> notifyQuit method referred from iOS GlassHelper.m
>>  * 98035cb2afef0c230d55095f0addeab73693d0ac: 8211308: Support HTTP/2  
>> in WebView
>>  * 6892fa1b3bbcfdb0e643a26441622916be987a38: 8232064: Switch FX  
>> build to use JDK 13.0.1 as boot JDK
>>  * 1d670f18d16d060dc40e83733cb3595c41df2a97: 8200224: Multiple press  
>> event when JFXPanel gains focus
>>  * 83eb0a7c9150566aae96db8ce9d1f78b714c9d1b: 8193445: JavaFX CSS is  
>> applied redundantly leading to significant performance degradation
>>  * 798afbcaeb73b90ba4bd511380786f7956e1b443: 8230610: Upgrade  
>> GStreamer to version 1.16.1
>>  * 126896db9928ae334332d38486fb61ad3a2e00a0: 8234704: Fix  
>> attribution in libxslt.md
>>  * 4d3c723e2f18efaca32a9df234063c7895b5540c: 8234593: Mark  
>> LeakTest.testGarbageCollectability as unstable
>>  * 5a398244af8f029d99d9cffc291667fc9c1ad9df: 8234056: Upgrade to  
>> libxslt 1.1.34
>>  * 8bea7b71454ada53881847c751add63e8fc99ea3: 8229472: Deprecate for  
>> removal JavaBeanXxxPropertyBuilders constructors
>>  * aad1720608856e910edaf05d0d53e87942642326: 8233420: Upgrade to gcc  
>> 8.3 on Linux
>>  * 42040c4cdb58eb0c6029a727df61b00248ee8e2b: 8232063: Upgrade gradle  
>> to version 6.0
>>  * aab07a4d01604355516de641b6141c91a30e0dc7: 8234239: [TEST_BUG]  
>> Reenable few ignored web tests
>>  * 95ad6017dc85b9504a4c20dd20f31094d9075f42: 8233421: Upgrade to  
>> Visual Studio 2017 version 15.9.16
>>  * 3e0557a815b6336d4e2eeaf5e833fe65f4298833: 8234303: [TEST_BUG]  
>> Correct ignore tag in graphics unit tests
>>  * e37cb37005b71edbf462eaa360c529a1e68c8656: 8234150: Address  
>> ignored tests in ComboBoxTest, LabeledTest, HyperLinkTest and  
>> TextInputControlTest
>>  * 4f496d417915b450880cbe664cba9130ab76ca08: 8234194: [TEST_BUG]  
>> Reenable few graphics unit tests
>>  * 927fc8a0f88adcaeb069bf0a7218a9c3f875d707: 8234174: Change IDEA  
>> VCS mapping to Git
>>  * 3d0cb4966a240ce81d18acffd64939757b79bed5: 8234189: [TEST_BUG]  
>> Remove ignored and invalid graphics unit tests
>>  * dc0130944365b61ac4a4333df29d684e9566d3cf: 8234110:  
>> SwingFXUtilsTest is unsuitable for unit test framework
>>  * 5b96ee42ac786ec23b99564715679d352c1637be: 8231188: Update SQLite  
>> to version 3.30.1
>>  * d46dcae7a571724f10d58e424842d703ea1cb0e3: 8233338: FX javadoc  
>> headings are out of sequence
>>  * 94bcf3fcfce83bae8d2014f15e993ba2edf24e0f: 8231692: Test  
>> Infrastructure: enhance KeyEventFirer to inject keyEvents into scene
>>  * 286d1b5427a2b9724cb400335741ed99295c5141: 8230492: font-family  
>> not set in HTMLEditor if font name has a number in it
>>  * f74f3afba53404e5169d97ef0d78c3ef2eeb42ef: 8233040:  
>> ComboBoxPopupControl: remove eventFilter for F4
>>  * a1cc4ab03698e9e9add95ecad191c9d89c6f35dd: 8232210: Update Mesa  
>> 3-D Headers to version 19.2.1
>>  * dca8df4e5d9071622dbaf83be48ae71b0927e6ae: 8232943: Gesture  
>> support is not initialized on iOS
>>  * 5a70b0c58cd723b535a6385fc8b431175ef44565: 8189092:  
>> ArrayIndexOutOfBoundsException on Linux in getCachedGlyph
>>  * ac71396c9b1eb390cf09fde928fe5fbd9c31e089: 8232929: Duplicate  
>> symbols when building static libraries
>>  * ab6ea3b936f319cdea997aabed63ffdc639a75e1: 8232158: [macOS]  
>> Fallback to command line tools if xcode is missing
>>  * 2ae171a2a0e6d1c24e6943f4f9a48987f6ed8ef4: 8232687: No static JNI  
>> loader for libprism-sw
>>  * a09a0fa595de95d4311495b6584804910d7fa5b9: 8232522: FX: Update  
>> copyright year in docs, readme files to 2020
>>  * 582d9993d5908be1ceef2376e0242208a886ed0f: Merge
>>  * b6e53f4f349a9fd5678500c56d34133c4fee2ac6: 8218640: Update ICU4C  
>> to version 64.2
>>  * bada612a59bbf46c14b3712e2b599044ef3872f7: Merge
>>  * 64aaeb840aa157e358eb41001c3705aa5c2fee30: 8226754: FX build fails  
>> using gradle 5.6+ or 6
>>  * a4bc22d25f79f3f9658f5c6fc0d90f2bf34aa4cf: Merge
>>  * 2593dea30b3610fef713ff4a215b6ae9d699ca3f: Merge
>>  * 9df20c561473cd62375d5908234f9a81b39889a6: Merge
>>  * a1aa38a479bf0449e39d14075980448058c8a0d3: Merge
>>  * 0ff02bbcb5db2cc276c75ba0c18eb846fba8f0ad: Merge
>>  * a433bf2752ace3d4dc0a9db0313d75768b64b253: Merge
>>  * 561153dbc218d00dc0486b58db1a7a8cfeffb64a: Merge
>>  * 75d439e969d9e4c7022f2eeb981787b371014456: Merge
>>  * 758252f9c4e6c283bd9872ad2e2b7b95a2e0a94d: Merge
>>  * 35e0caea17dd612cf69c1876a0649a8897ab88f0: 8227402: Improve XSLT processing
>>
>> Since there are no conflicts, your changes will automatically be  
>> rebased on top of the above commits when integrating. If you prefer  
>> to do this manually, please merge `master` into your branch first.
>>
>> As you do not have Committer status in this project, an existing  
>> [Committer](https://openjdk.java.net/bylaws#committer) must agree to  
>> [sponsor](https://openjdk.java.net/sponsor/) your change. Possible  
>> candidates are the reviewers of this PR (@aghaisas) but any other  
>> Committer may sponsor as well.
>>
>> - To flag this PR as ready for integration with the above commit  
>> message, type `/integrate` in a new comment. (Afterwards, your  
>> sponsor types `/sponsor` in a new comment to perform the integration).
>> 
>>
>> --
>> You are receiving this because you were mentioned.
>> Reply to this email directly or view it on GitHub:
>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995

Right, this still needs one more review (I hope to get to it today).

The bot doesn't know whether all criteria have been met. It can't, for example, know whether there are outstanding comments from some reviewers that need to be addressed. Nor does it know which PRs need two reviewers (or sometimes a third if there is a specific person we would like to review it), which ones need a CSR, etc.

So having it state authoritatively that the PR is ready to integrate is a bit misleading in this case. This is documented in the Code Review section of the [CONTRIBUTING](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) doc:

>NOTE: while the Skara tooling will indicate that the PR is ready to integrate once the first reviewer with a "Reviewer" role in the project has approved it, this may or may not be sufficient depending on the type of fix. For example, you must wait for a second approval for enhancements or high-impact bug fixes.

I wonder if there is a way to improve this?

-------------

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

From kcr at openjdk.java.net  Mon Dec 16 13:52:52 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 16 Dec 2019 13:52:52 GMT
Subject: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <_6hq7HKsRwiMauF_HkzXkQPB1DisrVgyBzthZGJfWII=.ffef16de-17e6-4ce7-9938-822b587d5803@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>
 <pRzmcqHIMvdIRCiS87m6u0aU0pPVJ6DMDCPrFd93RVQ=.935ef274-c291-4210-8bf0-031054554545@github.com>
 <_6hq7HKsRwiMauF_HkzXkQPB1DisrVgyBzthZGJfWII=.ffef16de-17e6-4ce7-9938-822b587d5803@github.com>
Message-ID: <t7iBEr8aEFeDlDVDXmhszh_OkBCjfnO7LKeKuPVVfLs=.d993ea1f-0562-4c34-975c-337ac64cd9a6@github.com>

On Mon, 16 Dec 2019 12:12:31 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>>
> 
> hmm ... think that the bot isn't yet clever enough: this pull request needs approval of two reviewer with _review_ role (mine is only informal)

This one still needs an approved CSR (the CSR is Finalized, but needs to be marked as Approved), and I still need to finish my review.

The Skara bot can't know whether all criteria have been met. It can't, for example, know whether there are outstanding comments from some reviewers that need to be addressed. Nor does it know which PRs need two reviewers (or sometimes a third if there is a specific person we would like to review it), which ones need a CSR, etc.

So having it state authoritatively that the PR is ready to integrate is a bit misleading in this case. This is documented in the Code Review section of the [CONTRIBUTING](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) doc:

>NOTE: while the Skara tooling will indicate that the PR is ready to integrate once the first reviewer with a "Reviewer" role in the project has approved it, this may or may not be sufficient depending on the type of fix. For example, you must wait for a second approval for enhancements or high-impact bug fixes.

I wonder if there is a way to improve this?

-------------

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

From kevin.rushforth at oracle.com  Mon Dec 16 13:56:00 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 16 Dec 2019 05:56:00 -0800
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
Message-ID: <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>

I added a comment to the two PRs in question, but it bears discussion here.

The Skara bot can't know whether all criteria have been met. It can't, 
for example, know whether there are outstanding comments from some 
reviewers that need to be addressed. Nor does it know which PRs need two 
reviewers (or sometimes a third if there is a specific person we would 
like to review it), which ones need a CSR, etc.

So having it state authoritatively that the PR is ready to integrate is 
a bit misleading. This is documented in the Code Review section of the 
CONTRIBUTING [1] doc:

> NOTE: while the Skara tooling will indicate that the PR is ready to 
> integrate once the first reviewer with a "Reviewer" role in the 
> project has approved it, this may or may not be sufficient depending 
> on the type of fix. For example, you must wait for a second approval 
> for enhancements or high-impact bug fixes.

If anyone can think of a way to improve this and make it more clear, 
that would be helpful.

-- Kevin

[1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md


On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>
> Looks like it assumes a pull request as properly reviewed as soon as 
> it gets a single approve - independent on how many reviewers are 
> required, see f.i.
>
> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>
> -- Jeanette
>


From fastegal at swingempire.de  Mon Dec 16 14:41:49 2019
From: fastegal at swingempire.de (Jeanette Winzenburg)
Date: Mon, 16 Dec 2019 15:41:49 +0100
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
Message-ID: <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>


Kevin,

thanks for the clarification :) My bad that I didn't re-read the  
contrib.md. But then, who does? The lazy like myself do it  
occasionally only (down to once and then forget about it <g>)

Maybe the bot message can be improved? With some indication that its  
(the bot's) knowledge about review requirements is limited, so would  
require a careful check by the contributor before actually post the  
/integrate comment? Actually, I think I goofed the other day, was  
safed only by Ajit who waited for the 2nd review before his /sponsor.

-- Jeanette

Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:

> I added a comment to the two PRs in question, but it bears discussion here.
>
> The Skara bot can't know whether all criteria have been met. It  
> can't, for example, know whether there are outstanding comments from  
> some reviewers that need to be addressed. Nor does it know which PRs  
> need two reviewers (or sometimes a third if there is a specific  
> person we would like to review it), which ones need a CSR, etc.
>
> So having it state authoritatively that the PR is ready to integrate  
> is a bit misleading. This is documented in the Code Review section  
> of the CONTRIBUTING [1] doc:
>
>> NOTE: while the Skara tooling will indicate that the PR is ready to  
>> integrate once the first reviewer with a "Reviewer" role in the  
>> project has approved it, this may or may not be sufficient  
>> depending on the type of fix. For example, you must wait for a  
>> second approval for enhancements or high-impact bug fixes.
>
> If anyone can think of a way to improve this and make it more clear,  
> that would be helpful.
>
> -- Kevin
>
> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>
>
> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>>
>> Looks like it assumes a pull request as properly reviewed as soon  
>> as it gets a single approve - independent on how many reviewers are  
>> required, see f.i.
>>
>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>
>> -- Jeanette
>>




From kevin.rushforth at oracle.com  Mon Dec 16 15:38:00 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 16 Dec 2019 07:38:00 -0800
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
Message-ID: <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>

That's a good question about whether we can ask for a slight rewording 
of the Skara bot message to indicate that there might be other things to 
check before "/integrate". I'll raise that question with the Skara team.

As an aside, I noticed the other day that you typed "/integrate" after a 
single review, but in that case, there was no clear indication from Ajit 
(the first reviewer and the sponsor) that a second review was required, 
so I didn't comment on it.

-- Kevin


On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>
> Kevin,
>
> thanks for the clarification :) My bad that I didn't re-read the 
> contrib.md. But then, who does? The lazy like myself do it 
> occasionally only (down to once and then forget about it <g>)
>
> Maybe the bot message can be improved? With some indication that its 
> (the bot's) knowledge about review requirements is limited, so would 
> require a careful check by the contributor before actually post the 
> /integrate comment? Actually, I think I goofed the other day, was 
> safed only by Ajit who waited for the 2nd review before his /sponsor.
>
> -- Jeanette
>
> Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:
>
>> I added a comment to the two PRs in question, but it bears discussion 
>> here.
>>
>> The Skara bot can't know whether all criteria have been met. It 
>> can't, for example, know whether there are outstanding comments from 
>> some reviewers that need to be addressed. Nor does it know which PRs 
>> need two reviewers (or sometimes a third if there is a specific 
>> person we would like to review it), which ones need a CSR, etc.
>>
>> So having it state authoritatively that the PR is ready to integrate 
>> is a bit misleading. This is documented in the Code Review section of 
>> the CONTRIBUTING [1] doc:
>>
>>> NOTE: while the Skara tooling will indicate that the PR is ready to 
>>> integrate once the first reviewer with a "Reviewer" role in the 
>>> project has approved it, this may or may not be sufficient depending 
>>> on the type of fix. For example, you must wait for a second approval 
>>> for enhancements or high-impact bug fixes.
>>
>> If anyone can think of a way to improve this and make it more clear, 
>> that would be helpful.
>>
>> -- Kevin
>>
>> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>>
>>
>> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>>>
>>> Looks like it assumes a pull request as properly reviewed as soon as 
>>> it gets a single approve - independent on how many reviewers are 
>>> required, see f.i.
>>>
>>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>>
>>> -- Jeanette
>>>
>
>
>


From kevin.rushforth at oracle.com  Mon Dec 16 19:34:57 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 16 Dec 2019 11:34:57 -0800
Subject: Proposed schedule for JavaFX 14
In-Reply-To: <536d8828-eb99-2aad-8e3b-d314f86c6b4a@oracle.com>
References: <cc85e35a-28c0-5f8a-521e-5cb447da4399@oracle.com>
 <536d8828-eb99-2aad-8e3b-d314f86c6b4a@oracle.com>
Message-ID: <27fe44eb-610e-5204-8cb4-a3d98b3d6e8b@oracle.com>

The announced RDP1 date is the first Monday of the new year. In taking a 
closer look at the upcoming holiday schedule and accounting for 
additional days off some will be taking before or after, this doesn't 
allow enough time for the final stages of the review process to 
complete, including CSR approval. It is quite possible that an 
enhancement with a mostly-completed review and a CSR that is Finalized 
this Thursday or Friday (Dec 19 or 20), won't be approved in time for 
integration.

To address this, we are delaying RDP1 by three days. The new RDP1 date is:

Thursday, Jan 9, 23:59 PST

The dates for RDP2, code freeze, and GA are unchanged.

Please be aware that this three-day extension isn't an invitation to try 
to get additional features into 14 at the last minute, but rather an 
adjustment to better align with the holiday schedule in order to give 
the already-in-flight features that are nearing completion a little more 
time to make it. It is still the case that if an enhancement isn't ready 
(meaning API discussed & approved, code review mostly done, and CSR 
finalized) by this Friday, it should be retargeted to JavaFX 15.

-- Kevin


On 12/10/2019 1:45 PM, Kevin Rushforth wrote:
> As a reminder, RDP1 for JavaFX 14 starts on January 6, 2020 (at 23:59 
> Pacific time).
>
> With the holidays approaching, please allow sufficient time for any 
> feature that needs a CSR. New features should be far enough along in 
> the review process so you can finalize the CSR before next Friday, Dec 
> 20, or it is likely to miss the window for this release, in which case 
> it can be targeted for JavaFX 15.
>
> During rampdown of JavaFX 14, the "master" branch of the jfx repo will 
> be open for JavaFX 15 fixes.
>
> We will follow the same process as previous releases for getting fixes 
> into JavaFX 14 during rampdown. I'll send a message with detailed 
> information later, but generally candidates for fixing after RDP1 are 
> P1-P3 bugs (as long as they are not risky) and test or doc bugs of any 
> priority.
>
> -- Kevin
>
>
> On 9/20/2019 8:00 AM, Kevin Rushforth wrote:
>> Here is the proposed schedule for JavaFX 14.
>>
>> RDP1: Jan 6, 2020 (aka ?feature freeze?)
>> RDP2: Feb 3, 2020
>> Freeze: Feb 24, 2020
>> GA: March 10, 2020
>>
>> We plan to fork a jfx14 stabilization branch at RDP1. The GA date is 
>> expected to be one week ahead of JDK 14, matching what we did for 13.
>>
>> Please let Johan or me know if you have any questions.
>>
>> -- Kevin
>>
>


From kcr at openjdk.java.net  Mon Dec 16 21:33:12 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 16 Dec 2019 21:33:12 GMT
Subject: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>
Message-ID: <RsFqcFBdBoq1U0sLXZ-RcYRYf8WUQsYS3z-oCJHw6Eg=.68d90bde-3473-4d09-8bc7-3e48d61d86e9@github.com>

On Mon, 16 Dec 2019 21:33:11 GMT, Hadzic Samir <shadzic at openjdk.org> wrote:

>> Allright, this is a fix for JDK-8207957
> 
> The pull request has been updated with 1 additional commit.

Looks good.

Once the CSR is approved, this can be integrated.

-------------

Marked as reviewed by kcr (Lead).

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

From farrukh.najm at gmail.com  Mon Dec 16 21:51:17 2019
From: farrukh.najm at gmail.com (Farrukh Najmi)
Date: Mon, 16 Dec 2019 16:51:17 -0500
Subject: openjfx 13 MediaPlayer vodeo stutter
In-Reply-To: <CAN0VY+-jRZAQ1FebKY_odgZK7Z9yf-h0T4xnXE0fUbcMG86S1A@mail.gmail.com>
References: <CAN0VY+-jRZAQ1FebKY_odgZK7Z9yf-h0T4xnXE0fUbcMG86S1A@mail.gmail.com>
Message-ID: <CAN0VY+9UbaByGZ4s9Xajy8Jo4Ft-iNoXHreVaAUA+s0EAk12eQ@mail.gmail.com>

Sorry I just realized that this is the dev team mailing list and my post
may not be appropriate here. I have posted a question on this at
stackoverflow along with a minimal standalone test program:

https://stackoverflow.com/questions/59364435/javafx-video-stutter-after-playing-same-video-over-and-over-for-a-couple-of-hour

On Sun, Dec 15, 2019 at 6:13 PM Farrukh Najmi <farrukh.najm at gmail.com>
wrote:

> On Ubuntu linux 18.04 I have been successfully using openjfx 13 during
> development of a new app. My app plays the same video over and over
> using javafx.scene.media.MediaView and javafx.scene.media.MediaPlayer.
> At first the video plays flawlessly. After a few hours the video becomes
> choppy and starts displaying stutter. I have analyzed my app for memory
> leaks and thread leaks and do not believe it has any.
> I observe that "top -H" command shows the following with QuantumRenderer
> at top:
>
> Threads: 575 total,   6 running, 515 sleeping,   0 stopped,   1 zombie
> %Cpu(s): 64.3 us,  8.1 sy,  0.0 ni, 25.0 id,  0.0 wa,  0.0 hi,  2.6 si,
>  0.0 st
> KiB Mem : 26.7/7988780  [|||||||||||||||||||||||||||
>                                                   ]
> KiB Swap:  0.0/2097148  [
>                                                    ]
>
>   PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
>
>  1432 root      20   0  0.101t 702424  90656 R 93.5  8.8   1471:14
> QuantumRenderer
>  9901 root      20   0  0.101t 702424  90656 R 60.1  8.8 424:41.22
> queue7:src
>  2592 root      20   0  0.101t 702424  90656 S 59.8  8.8 505:55.76
> queue5:src
>  1133 ubuntu    20   0  912192 172908  87736 R 58.2  2.2   1133:23 Xorg
>
>  1335 root      20   0  334104  34200   9968 S  5.6  0.4  77:41.33 val
>
>  9900 root      20   0  0.101t 702424  90656 S  4.2  8.8  28:22.37
> qtdemux3:sink
>  2594 root      20   0  0.101t 702424  90656 S  2.9  8.8  30:41.56
> qtdemux2:sink
>  2590 root      20   0  0.101t 702424  90656 S  1.6  8.8  16:05.02
> queue4:src
>  9903 root      20   0  0.101t 702424  90656 S  1.6  8.8  11:08.72
> queue6:src
>  1976 ubuntu    -6   0 1172376  12012   8796 S  1.6  0.2  26:16.32
> alsa-sink-ALC25
>  9546 ubuntu    20   0   51728   4560   3544 R  1.6  0.1   0:00.26 top
>
>  1620 root      20   0  0.101t 702424  90656 S  0.7  8.8  14:45.24 JavaFX
> Applicat
>  9887 root      20   0  0.101t 702424  90656 S  0.7  8.8   4:27.78
> Timer-47
>  9902 root      20   0  0.101t 702424  90656 S  0.7  8.8   2:46.59
> threaded-ml
>  9905 root      20   0  0.101t 702424  90656 S  0.7  8.8   4:37.95
> Timer-49
>  1454 ubuntu    20   0 3389116 131052  68972 S  0.7  1.6   3:11.03
> gnome-shell
>  1487 ubuntu     9 -11 1172376  12012   8796 S  0.7  0.2  10:28.21
> pulseaudio
>   912 root      20   0  0.101t 702424  90656 S  0.3  8.8   1:09.97 GC
> Thread#0
>   916 root      20   0  0.101t 702424  90656 S  0.3  8.8   0:30.33 G1
> Young RemSet
>   920 root      20   0  0.101t 702424  90656 S  0.3  8.8   0:43.78 VM
> Thread
>  1619 root      20   0  0.101t 702424  90656 S  0.3  8.8   4:41.19
> InvokeLaterDisp
>  2228 root      20   0  0.101t 702424  90656 S  0.3  8.8   1:06.68 GC
> Thread#3
>  9883 root      20   0  0.101t 702424  90656 S  0.3  8.8   1:25.20
> JFXMedia Player
>
> I am looking for suggestions on how to fix the video stutter issue. Is
> this a known issue. If so, please share link to issue.
> If it is a known issue, has it been fixed in openjfx 14-ea+4? I tried
> using that EA release but with that as dependency my video seems to stop
> and first frame and does not play at all.
> I am wondering if there are any migration steps that I may be missing.
>
> TIA for any suggestion on how to fix my video stutter issue with openjfx
> 13 or openjfx 14-ea+4.
>
> --
> Regards,
> Farrukh
>


-- 
Regards,
Farrukh

From kcr at openjdk.java.net  Mon Dec 16 23:41:38 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 16 Dec 2019 23:41:38 GMT
Subject: [Rev 02] RFR: 8207759: VK_ENTER not consumed by TextField when
 default Button exists
In-Reply-To: <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
 <W-XdvM0Ly8-Yw1ENKvSULcTYBQ_2bOmBEl_wfrcngBY=.1322718e-3bbb-4d26-b5a4-b8f0544ea89e@github.com>
Message-ID: <h8s53iK3U7pAEyNil4HP3MK3_HbPZJBU6kUYTY8q1vk=.277b237a-9816-473f-8e4c-061a6e462236@github.com>

On Mon, 16 Dec 2019 23:41:37 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> This is a fix for https://bugs.openjdk.java.net/browse/JDK-8207759
>> 
>> The issue is that default/cancel button on a scene are triggered even though a onKeyPressed handler for ENTER/CANCEL consumes the keyEvent. See the bug for details on both cause and fix.
>> 
>> There are additional/changed tests to verify the fix. All old tests are passing.
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by kcr (Lead).

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

From nlisker at gmail.com  Tue Dec 17 00:01:14 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 17 Dec 2019 02:01:14 +0200
Subject: [openjdk/jfx] 8234712: Add pivot properties for scale and
 rotation in Node, ScaleTransition and RotateTransition (#53)
In-Reply-To: <f416433e-8bba-708f-6e08-799984b2b346@jugs.org>
References: <openjdk/jfx/pull/53@github.com>
 <openjdk/jfx/pull/53/c565731609@github.com>
 <CA+0ynh-TG1aig3Ut0pgTjcAD8XdR76dGXNoisBzGqdLV99Dq=Q@mail.gmail.com>
 <f416433e-8bba-708f-6e08-799984b2b346@jugs.org>
Message-ID: <CA+0ynh_x5=m7KiW_E75=K4ckLO=o4yb6VopUp+=rUPMiLuK3xA@mail.gmail.com>

Thanks for the input Michael,


> Introducing two separate centers for rotation and scaling is, to my
> opinion, just academic without any practical use-case and in the end much
> more complicated for the user.


I have a practical use case in my app. I assume that the people who
requested these enhancements also had one. I also don't think that it's
"much" more complicated as it just aligns with the existing transforms
functionality.

1. Three doubles always use their full space even if you don't need them.


No sure what you mean by "full space". Properties are initialized lazily,
so if a value was not set, the reference is null, and the default pivot
value applies (computed center).

2. Using Double.NaNs as a switch between computed and user-provided
> center is just confusing and error-prone.


It is confusing indeed, but I don't think it's error prone as you'd be hard
pressed to fall on a NaN value for a pivot point as a result of a
computation. We could use one of the INFINITY values instead if it's
better. We should create a constant, public static final double CENTER =
Double.NaN (placeholder name), just like Animation.INDEFINITE = -1,
Region.USE_PREF_SIZE
= Double.NEGATIVE_INFINITY, Region.USE_COMPUTED_SIZE = -1 etc. It's not
ideal, but it's a solution for allowing the user to revert to the default
behavior without additional boolean properties.


> What would be the meaning of setting x to some value but leaving y and z
> as NaN?
>

That y and z are the computed center (Node computes the x, y and z of the
center separately to being with), and x is the user value.

I bet most users will forget to set the Z-value anyway if they are thinking
> 2D.


They wouldn't need to, it will behave as it does now (overall, backwards
compatibility is guaranteed).


> A simple null value is much easier to handle and explain.


Yes, it's certainly an advantage of a Point3D, which was my initial
implementation. The main issue with it, I would say, is that it's difficult
to bind to.

- Nir

On Mon, Dec 16, 2019 at 1:36 PM Michael Paus <mp at jugs.org> wrote:

> I don't think there are clearly right or wrong answers to all these
> questions,
> so I would just like to provide a view thoughts on this.
>
> The governing principle should be a principle of "least surprise" from a
> users
> point of view. That means we should not make things more complicated as
> they already are and should always keep the practical use-cases in mind.
> If you need full flexibility, you can always use the explicit transforms.
>
> We currently have the notion of the "Node's center" which is used for
> scaling
> and rotation and I think we should stick to that. The documentation later
> explains that "The pivot point about which the rotation occurs is the
> center
> of the untransformed layoutBounds." which is a completely arbitrary
> decision
> because, e.g., from a mathematically point of view the geometric center
> of the
> node would seem to be more natural but is more difficult to compute for
> general
> shapes. So, we should just extend this scheme in such a way that the
> user can
> replace the single computed center with a single user-defined center
> specified in untransformed coordinates. Introducing two separate centers
> for rotation and scaling is, to my opinion, just academic without any
> practical
> use-case and in the end much more complicated for the user.
>
> I would also specify this center point as a Point3D for two reasons:
> 1. Three doubles always use their full space even if you don't need them.
> 2. Using Double.NaNs as a switch between computed and user-provided center
>      is just confusing and error-prone.
>      What would be the meaning of setting x to some value but leaving y
> and z as
>      NaN? Would you implicitly set them to 0.0 or use the computed values
> or
>      would you discard this user setting completely and use all the
> computed
>      values if any of the components is NaN? I bet most users will
> forget to set the
>      Z-value anyway if they are thinking 2D. A simple null value is much
> easier
>      to handle and explain.
>
> Just my two ?ent.
>
> --Michael
>
> Am 16.12.19 um 03:06 schrieb Nir Lisker:
> > Replying on the mailing list to the questions raised on GitHub.
> >
> > The state of whether to use the computed center pivot or the value of the
> >> pivot attribute is implicit with no way for an application to know
> which it
> >> is, and no way to set it back to using the computed center (i.e., the
> state
> >> is sticky once you set it). Perhaps if you defined a null value as
> meaning
> >> "computed center" then an app could at least reset it to the "computed
> >> center" state, although there would still be no way for the app to know
> >> that it was in that state.
> >>
> > In the JBS issue <https://bugs.openjdk.java.net/browse/JDK-8234712> I
> > alluded to this in point 5. I think that null should represent the
> default
> > (node center). However, if we use 3 doubles instead of a Point3D we might
> > need to use Double.NaN for this instead, which would also be the default
> > for this case. The docs will explain this.
> >
> > Do we need separate properties for scale pivot and center pivot?
> > I say yes, otherwise the enhancement will be very limited. I think of
> this
> > enhancement as adding pivot control to Rotate/Scale transitions, and
> adding
> > them to Node is a necessary (and desirable) step.
> >
> >     ... you need to worry about what coordinate space the rotation pivot
> is
> >> defined in. Perhaps if the rotation pivot were defined in unscaled
> space,
> >> it might work.
> >>
> > Isn't it already? If I set the rotation pivot to the edge of the node,
> then
> > scale it down, then rotate, the rotation pivot would be outside of the
> > node's boundaries. In scaled space it would still be on the edge. Or did
> I
> > misunderstand you? In any case, I don't think that there's a single
> correct
> > answer here.
> >
> > Should the pivot be specified as a Point3D or 3 separate doubles?
> Separate
> >> doubles... there would be no out-of-band null value to use
> >
> > See my point above about Double.NaN.
> > The doubles vs Point3D is an important choice. We might want to look into
> > the future even where Point3D (and 2D) could be made into an Inline class
> > with Valhalla, which will help with the performance aspect. Binding to
> one
> > of the coordinates is sill a problem there, however.
> >
> > On Sat, Dec 14, 2019 at 6:25 PM Kevin Rushforth <
> notifications at github.com>
> > wrote:
> >
> >> This will need discussion on the openjfx-dev mailing list. Here are the
> >> questions that need to be resolved:
> >>
> >>     1.
> >>
> >>     The state of whether to use the computed center pivot or the value
> of
> >>     the pivot attribute is implicit with no way for an application to
> know
> >>     which it is, and no way to set it back to using the computed center
> (i.e.,
> >>     the state is sticky once you set it). Perhaps if you defined a null
> value
> >>     as meaning "computed center" then an app could at least reset it to
> the
> >>     "computed center" state, although there would still be no way for
> the app
> >>     to know that it was in that state.
> >>     2.
> >>
> >>     Do we need separate properties for scale pivot and center pivot? A
> >>     single pivot property would be easier to define, but wouldn't allow
> you to
> >>     set it from a RotationTransition and a ScaleTransition if you wanted
> >>     to apply both to the same Node. With two separate properties, as you
> >>     have defined it, it is more flexible, but you need to worry about
> what
> >>     coordinate space the rotation pivot is defined in. The current
> transform
> >>     chain looks like this:
> >>
> >> T(layout+translate) * T(pivot) * T(rot) * T(scale) * T(-pivot)
> >>      * transform[0] * transform [1] ...
> >>
> >> Perhaps if the rotation pivot were defined in unscaled space, it might
> >> work. The transform chain would then look like this:
> >>
> >> T(layout+translate) * T(pivotRot/scale) * T(rot) * T(-pivotRot/scale) *
> T(pivotScale) * T(scale) * T(-pivotScale)
> >>      * transform[0] * transform [1] ...
> >>
> >> In any case, you need to think about the implications of having one of
> >> scale or rotate being set explicitly and the other being the computed
> >> center.
> >>
> >>     1. Should the pivot be specified as a Point3D or 3 separate
> doubles? I
> >>     can see pros / cons of either approach. Separate doubles are more
> >>     consistent with the the pivot values in the Rotate and Scale
> Transform
> >>     objects, and are easier to using in binding. On the other hand,
> there would
> >>     be no out-of-band null value to use (see issue 1 above), so you
> would
> >>     need a boolean property for each of scale pivot and rotation pivot
> to
> >>     indicate whether the computed value or the value of the pivot
> properties
> >>     should be used. I don't think that the fact that the rotation axis
> is
> >>     defined as a Point3D should have any bearing on whether the pivot
> >>     should be so defined. I'd probably lean towards separate doubles.
> >>
> >> ?
> >> You are receiving this because you authored the thread.
> >> Reply to this email directly, view it on GitHub
> >> <
> https://github.com/openjdk/jfx/pull/53?email_source=notifications&email_token=AI5QOM6KRPRRP7VS5OUH6QLQYUCF7A5CNFSM4JR3TYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4GCGI#issuecomment-565731609
> >,
> >> or unsubscribe
> >> <
> https://github.com/notifications/unsubscribe-auth/AI5QOM4UKZQVDEN2A2HYYETQYUCF7ANCNFSM4JR3TYYQ
> >
> >> .
> >>
>
>

From kevin.rushforth at oracle.com  Tue Dec 17 00:07:09 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 16 Dec 2019 16:07:09 -0800
Subject: [openjdk/jfx] 8234712: Add pivot properties for scale and
 rotation in Node, ScaleTransition and RotateTransition (#53)
In-Reply-To: <CA+0ynh-TG1aig3Ut0pgTjcAD8XdR76dGXNoisBzGqdLV99Dq=Q@mail.gmail.com>
References: <openjdk/jfx/pull/53@github.com>
 <openjdk/jfx/pull/53/c565731609@github.com>
 <CA+0ynh-TG1aig3Ut0pgTjcAD8XdR76dGXNoisBzGqdLV99Dq=Q@mail.gmail.com>
Message-ID: <3c9f3961-08be-458a-89b6-e9029ff89685@oracle.com>



On 12/15/2019 6:06 PM, Nir Lisker wrote:
> Replying on the mailing list to the questions raised on GitHub.
>
>     The state of whether to use the computed center pivot or the value
>     of the pivot attribute is implicit with no way for an application
>     to know which it is, and no way to set it back to using the
>     computed center (i.e., the state is sticky once you set it).
>     Perhaps if you defined a null value as meaning "computed center"
>     then an app could at least reset it to the "computed center"
>     state, although there would still be no way for the app to know
>     that it was in that state.
>
>
> In the JBS issue <https://bugs.openjdk.java.net/browse/JDK-8234712> I 
> alluded to this in point 5. I think that null should represent?the 
> default (node center). However, if we use 3 doubles instead of a 
> Point3D we might need to use Double.NaN for this instead, which would 
> also be the?default for this case. The docs will explain this.

Using Double.NaN as an out of band value would be odd, and probably not 
what we want. In addition to the fact that it is somewhat artificial, it 
would mean that X, Y, and Z would independently be treated as coming 
from the set value or from the computed center. I guess this is one 
argument for using a Point3D object, but as you note, there are other 
drawbacks.

>     Do we need separate properties for scale pivot and center pivot?
>
>
> I say yes, otherwise the enhancement will be very limited. I think of 
> this enhancement as adding pivot control to Rotate/Scale transitions, 
> and adding them to Node is a necessary (and desirable) step.

Yeah, I figured this was the case.

>     ?... you need to worry about what coordinate space the rotation
>     pivot is defined in. Perhaps if the rotation pivot were defined in
>     unscaled space, it might work.
>
>
> Isn't it already? If I set the rotation pivot to the edge of the node, 
> then scale it down, then rotate, the rotation pivot would be outside 
> of the node's boundaries. In scaled space it would still be on the 
> edge. Or did I misunderstand you?

I think I was wrong in the comment I added to the PR.

What I meant is that you would need to define the coordinate space that 
the pivot values are in, and it needs to be defined in a way that it is 
consistent with current behavior. Today, the part of the matrix 
transformation that does the scale and rotate, including the computed 
pivot, is this:

 ??? T(pivot) * T(rotate) * T(scale) * T(-pivot) * object coords

As long as you do the following, it should work as expected:


 ??? T(pivotRot) * T(rotate) * T(-pivotRot) * T(pivotScale) * T(scale) * 
T(-pivotScale) * object coords

Importantly, this will work exactly as it does today when pivotRot == 
pivotScale which is the case I was most concerned about.

> In any case, I don't think that there's a single correct answer here.

It needs to be consistent with current behavior, and match what an 
application would expect. I think it should not be a problem if defined 
as above.

>     Should the pivot be specified as a |Point3D|?or 3 separate
>     doubles? Separate doubles... there would be no out-of-band
>     |null|?value to use
>
> See my point above about Double.NaN.

OK, there is no "natural" out of band value that is likely to be 
satisfying. We'd probably end up wanting a boolean that controls 
computed versus explicit (either a single flag or one for each of 
scalePivot and rotatePivot)

> The doubles vs Point3D is an important choice. We might want to look 
> into the future even where Point3D (and 2D) could be made into an 
> Inline class with Valhalla, which will help with the performance 
> aspect. Binding to one of the coordinates is sill a problem there, 
> however.

I think this (doubles vs Point3D) is really the main question. I don't 
know what the best answer is, but I'd like to hear from other developers.

-- Kevin


> On Sat, Dec 14, 2019 at 6:25 PM Kevin Rushforth 
> <notifications at github.com <mailto:notifications at github.com>> wrote:
>
>     This will need discussion on the openjfx-dev mailing list. Here
>     are the questions that need to be resolved:
>
>     1.
>
>         The state of whether to use the computed center pivot or the
>         value of the pivot attribute is implicit with no way for an
>         application to know which it is, and no way to set it back to
>         using the computed center (i.e., the state is sticky once you
>         set it). Perhaps if you defined a null value as meaning
>         "computed center" then an app could at least reset it to the
>         "computed center" state, although there would still be no way
>         for the app to know that it was in that state.
>
>     2.
>
>         Do we need separate properties for scale pivot and center
>         pivot? A single pivot property would be easier to define, but
>         wouldn't allow you to set it from a |RotationTransition| and a
>         |ScaleTransition| if you wanted to apply both to the same
>         |Node|. With two separate properties, as you have defined it,
>         it is more flexible, but you need to worry about what
>         coordinate space the rotation pivot is defined in. The current
>         transform chain looks like this:
>
>     |T(layout+translate) * T(pivot) * T(rot) * T(scale) * T(-pivot) *
>     transform[0] * transform [1] ... |
>
>     Perhaps if the rotation pivot were defined in unscaled space, it
>     might work. The transform chain would then look like this:
>
>     |T(layout+translate) * T(pivotRot/scale) * T(rot) *
>     T(-pivotRot/scale) * T(pivotScale) * T(scale) * T(-pivotScale) *
>     transform[0] * transform [1] ... |
>
>     In any case, you need to think about the implications of having
>     one of scale or rotate being set explicitly and the other being
>     the computed center.
>
>      3. Should the pivot be specified as a |Point3D| or 3 separate
>         doubles? I can see pros / cons of either approach. Separate
>         doubles are more consistent with the the pivot values in the
>         |Rotate| and |Scale| |Transform| objects, and are easier to
>         using in binding. On the other hand, there would be no
>         out-of-band |null| value to use (see issue 1 above), so you
>         would need a boolean property for each of scale pivot and
>         rotation pivot to indicate whether the computed value or the
>         value of the pivot properties should be used. I don't think
>         that the fact that the rotation axis is defined as a |Point3D|
>         should have any bearing on whether the pivot should be so
>         defined. I'd probably lean towards separate doubles.
>
>     ?
>     You are receiving this because you authored the thread.
>     Reply to this email directly, view it on GitHub
>     <https://github.com/openjdk/jfx/pull/53?email_source=notifications&email_token=AI5QOM6KRPRRP7VS5OUH6QLQYUCF7A5CNFSM4JR3TYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4GCGI#issuecomment-565731609>,
>     or unsubscribe
>     <https://github.com/notifications/unsubscribe-auth/AI5QOM4UKZQVDEN2A2HYYETQYUCF7ANCNFSM4JR3TYYQ>.
>


From nlisker at gmail.com  Tue Dec 17 00:14:39 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 17 Dec 2019 02:14:39 +0200
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
 <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
Message-ID: <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>

Do other projects also have multi-reviewers requirements?

I would think that at least for a CSR, which is OpenJDK-wide, a request
could be put in with the Skara to track it. A Reviewer (or Committer?)
could invoke a /csr command which will require the PR author to provide a
link to the CSR, and check that it was approved as part of the patch
approval process.

Not sure how complicated it would be to implement.

- Nir

On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> That's a good question about whether we can ask for a slight rewording
> of the Skara bot message to indicate that there might be other things to
> check before "/integrate". I'll raise that question with the Skara team.
>
> As an aside, I noticed the other day that you typed "/integrate" after a
> single review, but in that case, there was no clear indication from Ajit
> (the first reviewer and the sponsor) that a second review was required,
> so I didn't comment on it.
>
> -- Kevin
>
>
> On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
> >
> > Kevin,
> >
> > thanks for the clarification :) My bad that I didn't re-read the
> > contrib.md. But then, who does? The lazy like myself do it
> > occasionally only (down to once and then forget about it <g>)
> >
> > Maybe the bot message can be improved? With some indication that its
> > (the bot's) knowledge about review requirements is limited, so would
> > require a careful check by the contributor before actually post the
> > /integrate comment? Actually, I think I goofed the other day, was
> > safed only by Ajit who waited for the 2nd review before his /sponsor.
> >
> > -- Jeanette
> >
> > Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:
> >
> >> I added a comment to the two PRs in question, but it bears discussion
> >> here.
> >>
> >> The Skara bot can't know whether all criteria have been met. It
> >> can't, for example, know whether there are outstanding comments from
> >> some reviewers that need to be addressed. Nor does it know which PRs
> >> need two reviewers (or sometimes a third if there is a specific
> >> person we would like to review it), which ones need a CSR, etc.
> >>
> >> So having it state authoritatively that the PR is ready to integrate
> >> is a bit misleading. This is documented in the Code Review section of
> >> the CONTRIBUTING [1] doc:
> >>
> >>> NOTE: while the Skara tooling will indicate that the PR is ready to
> >>> integrate once the first reviewer with a "Reviewer" role in the
> >>> project has approved it, this may or may not be sufficient depending
> >>> on the type of fix. For example, you must wait for a second approval
> >>> for enhancements or high-impact bug fixes.
> >>
> >> If anyone can think of a way to improve this and make it more clear,
> >> that would be helpful.
> >>
> >> -- Kevin
> >>
> >> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
> >>
> >>
> >> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
> >>>
> >>> Looks like it assumes a pull request as properly reviewed as soon as
> >>> it gets a single approve - independent on how many reviewers are
> >>> required, see f.i.
> >>>
> >>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
> >>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
> >>>
> >>> -- Jeanette
> >>>
> >
> >
> >
>
>

From nlisker at gmail.com  Tue Dec 17 00:46:55 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 17 Dec 2019 02:46:55 +0200
Subject: [openjdk/jfx] 8234712: Add pivot properties for scale and
 rotation in Node, ScaleTransition and RotateTransition (#53)
In-Reply-To: <3c9f3961-08be-458a-89b6-e9029ff89685@oracle.com>
References: <openjdk/jfx/pull/53@github.com>
 <openjdk/jfx/pull/53/c565731609@github.com>
 <CA+0ynh-TG1aig3Ut0pgTjcAD8XdR76dGXNoisBzGqdLV99Dq=Q@mail.gmail.com>
 <3c9f3961-08be-458a-89b6-e9029ff89685@oracle.com>
Message-ID: <CA+0ynh90NUUu9DyisYjbpO1xGYnB3oxwoKoty9T-QNfh8kyp+Q@mail.gmail.com>

>
> As long as you do the following, it should work as expected:
>
>     T(pivotRot) * T(rotate) * T(-pivotRot) * T(pivotScale) * T(scale) *
> T(-pivotScale) * object coords
>

 I think that this is what the PR does already. Line 5061 onward is:

localToParentTx = localToParentTx.deriveWithTranslation(rotPivotX,
rotPivotY, rotPivotZ)
                                 .deriveWithRotation(rotAngle, rotAxisX,
rotAxisY, rotAxisZ)
                                 .deriveWithTranslation(-rotPivotX,
-rotPivotY, -rotPivotZ);
...
localToParentTx = localToParentTx.deriveWithTranslation(scalePivotX,
scalePivotY, scalePivotZ)
                                 .deriveWithScale(getScaleX(), getScaleY(),
getScaleZ())
                                 .deriveWithTranslation(-scalePivotX,
-scalePivotY, -scalePivotZ);

On Tue, Dec 17, 2019 at 2:07 AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

>
>
> On 12/15/2019 6:06 PM, Nir Lisker wrote:
>
> Replying on the mailing list to the questions raised on GitHub.
>
> The state of whether to use the computed center pivot or the value of the
>> pivot attribute is implicit with no way for an application to know which it
>> is, and no way to set it back to using the computed center (i.e., the state
>> is sticky once you set it). Perhaps if you defined a null value as meaning
>> "computed center" then an app could at least reset it to the "computed
>> center" state, although there would still be no way for the app to know
>> that it was in that state.
>>
>
> In the JBS issue <https://bugs.openjdk.java.net/browse/JDK-8234712> I
> alluded to this in point 5. I think that null should represent the default
> (node center). However, if we use 3 doubles instead of a Point3D we might
> need to use Double.NaN for this instead, which would also be the default
> for this case. The docs will explain this.
>
>
> Using Double.NaN as an out of band value would be odd, and probably not
> what we want. In addition to the fact that it is somewhat artificial, it
> would mean that X, Y, and Z would independently be treated as coming from
> the set value or from the computed center. I guess this is one argument for
> using a Point3D object, but as you note, there are other drawbacks.
>
> Do we need separate properties for scale pivot and center pivot?
>>
>
> I say yes, otherwise the enhancement will be very limited. I think of this
> enhancement as adding pivot control to Rotate/Scale transitions, and adding
> them to Node is a necessary (and desirable) step.
>
>
> Yeah, I figured this was the case.
>
>    ... you need to worry about what coordinate space the rotation pivot is
>> defined in. Perhaps if the rotation pivot were defined in unscaled space,
>> it might work.
>>
>
> Isn't it already? If I set the rotation pivot to the edge of the node,
> then scale it down, then rotate, the rotation pivot would be outside of the
> node's boundaries. In scaled space it would still be on the edge. Or did I
> misunderstand you?
>
>
> I think I was wrong in the comment I added to the PR.
>
> What I meant is that you would need to define the coordinate space that
> the pivot values are in, and it needs to be defined in a way that it is
> consistent with current behavior. Today, the part of the matrix
> transformation that does the scale and rotate, including the computed
> pivot, is this:
>
>     T(pivot) * T(rotate) * T(scale) * T(-pivot) * object coords
>
> As long as you do the following, it should work as expected:
>
>
>     T(pivotRot) * T(rotate) * T(-pivotRot) * T(pivotScale) * T(scale) *
> T(-pivotScale) * object coords
>
> Importantly, this will work exactly as it does today when pivotRot ==
> pivotScale which is the case I was most concerned about.
>
> In any case, I don't think that there's a single correct answer here.
>
>
> It needs to be consistent with current behavior, and match what an
> application would expect. I think it should not be a problem if defined as
> above.
>
> Should the pivot be specified as a Point3D or 3 separate doubles?
>> Separate doubles... there would be no out-of-band null value to use
>
>
> See my point above about Double.NaN.
>
>
> OK, there is no "natural" out of band value that is likely to be
> satisfying. We'd probably end up wanting a boolean that controls computed
> versus explicit (either a single flag or one for each of scalePivot and
> rotatePivot)
>
> The doubles vs Point3D is an important choice. We might want to look into
> the future even where Point3D (and 2D) could be made into an Inline class
> with Valhalla, which will help with the performance aspect. Binding to one
> of the coordinates is sill a problem there, however.
>
>
> I think this (doubles vs Point3D) is really the main question. I don't
> know what the best answer is, but I'd like to hear from other developers.
>
> -- Kevin
>
>
> On Sat, Dec 14, 2019 at 6:25 PM Kevin Rushforth <notifications at github.com>
> wrote:
>
>> This will need discussion on the openjfx-dev mailing list. Here are the
>> questions that need to be resolved:
>>
>>    1.
>>
>>    The state of whether to use the computed center pivot or the value of
>>    the pivot attribute is implicit with no way for an application to know
>>    which it is, and no way to set it back to using the computed center (i.e.,
>>    the state is sticky once you set it). Perhaps if you defined a null value
>>    as meaning "computed center" then an app could at least reset it to the
>>    "computed center" state, although there would still be no way for the app
>>    to know that it was in that state.
>>    2.
>>
>>    Do we need separate properties for scale pivot and center pivot? A
>>    single pivot property would be easier to define, but wouldn't allow you to
>>    set it from a RotationTransition and a ScaleTransition if you wanted
>>    to apply both to the same Node. With two separate properties, as you
>>    have defined it, it is more flexible, but you need to worry about what
>>    coordinate space the rotation pivot is defined in. The current transform
>>    chain looks like this:
>>
>> T(layout+translate) * T(pivot) * T(rot) * T(scale) * T(-pivot)
>>     * transform[0] * transform [1] ...
>>
>> Perhaps if the rotation pivot were defined in unscaled space, it might
>> work. The transform chain would then look like this:
>>
>> T(layout+translate) * T(pivotRot/scale) * T(rot) * T(-pivotRot/scale) * T(pivotScale) * T(scale) * T(-pivotScale)
>>     * transform[0] * transform [1] ...
>>
>> In any case, you need to think about the implications of having one of
>> scale or rotate being set explicitly and the other being the computed
>> center.
>>
>>    1. Should the pivot be specified as a Point3D or 3 separate doubles?
>>    I can see pros / cons of either approach. Separate doubles are more
>>    consistent with the the pivot values in the Rotate and Scale Transform
>>    objects, and are easier to using in binding. On the other hand, there would
>>    be no out-of-band null value to use (see issue 1 above), so you would
>>    need a boolean property for each of scale pivot and rotation pivot to
>>    indicate whether the computed value or the value of the pivot properties
>>    should be used. I don't think that the fact that the rotation axis is
>>    defined as a Point3D should have any bearing on whether the pivot
>>    should be so defined. I'd probably lean towards separate doubles.
>>
>> ?
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/openjdk/jfx/pull/53?email_source=notifications&email_token=AI5QOM6KRPRRP7VS5OUH6QLQYUCF7A5CNFSM4JR3TYY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4GCGI#issuecomment-565731609>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AI5QOM4UKZQVDEN2A2HYYETQYUCF7ANCNFSM4JR3TYYQ>
>> .
>>
>
>

From aghaisas at openjdk.java.net  Tue Dec 17 11:45:12 2019
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 17 Dec 2019 11:45:12 GMT
Subject: [Integrated] RFR: 8207759: VK_ENTER not consumed by TextField
 when default Button exists
In-Reply-To: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
References: <oWfQjG4nfXg3xMXDB7tbSjpy4_aBPBtvsi2RTnQkXaU=.46378ed2-f138-4c55-a0ae-b6ee04670b15@github.com>
Message-ID: <5970ab58-df83-44d3-baa6-d6ef8fb017ad@openjdk.org>

Changeset: d2d44b4a
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
Date:      2019-12-17 11:44:42 +0000
URL:       https://git.openjdk.java.net/jfx/commit/d2d44b4a

8207759: VK_ENTER not consumed by TextField when default Button exists

Reviewed-by: aghaisas, kcr

! modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java
! modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java
+ modules/javafx.controls/src/test/java/test/javafx/scene/control/DefaultCancelButtonTestBase.java
+ modules/javafx.controls/src/test/java/test/javafx/scene/control/PasswordFieldDefaultCancelButtonTest.java
+ modules/javafx.controls/src/test/java/test/javafx/scene/control/TextAreaDefaultCancelButtonTest.java
+ modules/javafx.controls/src/test/java/test/javafx/scene/control/TextFieldDefaultCancelButtonTest.java
! modules/javafx.controls/src/test/java/test/javafx/scene/control/TextFieldTest.java
+ modules/javafx.controls/src/test/java/test/javafx/scene/control/TextFieldWithFormatterDefaultCancelButtonTest.java

From jvos at openjdk.java.net  Tue Dec 17 14:29:32 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 17 Dec 2019 14:29:32 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
Message-ID: <FTLU9msATCFecKkKSMDbRIfoti3oHeNByOX3RMv9xwg=.831b1744-1059-40a3-a64b-b0cce08e4540@github.com>

On Wed, 11 Dec 2019 15:41:38 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
> And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed.
> 
> The change is,
> 1. Remove finalize method from PiscesRenderer and AbstractSurface classes.
> 2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize().  For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java.
> 3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method.
> 
> Verification:
> Verified that the newly added dispose() methods get invoked as required and no OOM occurs.
> 1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop.
> 2. Run the program using -Dprism.order=sw,  -Dprism.verbose=true. (optional -Xmx50m)
> Expected Behavior: 
> a. Maximum memory consumption after this change should reduce or remain same as that of before this change.
> b. No OOM should occur with this change or without this change.

modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 63:

> 62:     }
> 63: }
> 64: 

there are no checks on memory errors as used to be in the finalize implementation. Are those not needed anymore?

-------------

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

From thiago.sayao at clamed.com.br  Tue Dec 17 16:34:26 2019
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Tue, 17 Dec 2019 16:34:26 +0000
Subject: How can a stage decoration change?
Message-ID: <CP2P15201MB2228EFF370E80DA2DE6205EEDE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

Hi.

Window.setBounds() doc specifies:


* Gravity values specify how to correct window location if only its size
* changes (for example when stage decorations are added). User initiated
* resizing should be ignored and must not influence window location through
* this mechanism.

How can I test this mechanism since initStyle() only works when before show() ?

Cheers.

From kevin.rushforth at oracle.com  Tue Dec 17 16:49:30 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 17 Dec 2019 08:49:30 -0800
Subject: How can a stage decoration change?
In-Reply-To: <CP2P15201MB2228EFF370E80DA2DE6205EEDE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
References: <CP2P15201MB2228EFF370E80DA2DE6205EEDE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
Message-ID: <29b7137a-3d37-8e41-dd84-0d123854f6f6@oracle.com>

Taking a quick look, I'm not sure I believe that comment, but in any 
case I don't think it's talking about changing from an undecorated Stage 
to a decorated Stage. Rather, I think it means that when a decorated 
Stage is created, the window might be initially created and then the 
decorations added in a second step.

-- Kevin


On 12/17/2019 8:34 AM, Thiago Milczarek Sayao wrote:
> Hi.
>
> Window.setBounds() doc specifies:
>
>
> * Gravity values specify how to correct window location if only its size
> * changes (for example when stage decorations are added). User initiated
> * resizing should be ignored and must not influence window location through
> * this mechanism.
>
> How can I test this mechanism since initStyle() only works when before show() ?
>
> Cheers.


From thiago.sayao at clamed.com.br  Tue Dec 17 17:05:02 2019
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Tue, 17 Dec 2019 17:05:02 +0000
Subject: How can a stage decoration change?
In-Reply-To: <29b7137a-3d37-8e41-dd84-0d123854f6f6@oracle.com>
References: <CP2P15201MB2228EFF370E80DA2DE6205EEDE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>,
 <29b7137a-3d37-8e41-dd84-0d123854f6f6@oracle.com>
Message-ID: <CP2P15201MB22286EAE0BCCD02E1B809692DE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

But there is no way managed JavaFx would know window manager decoration sizes to pass to setBounds().

Asking a more direct question. Why are xGravity and yGravity necessary?

Thanks.
________________________________
De: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> em nome de Kevin Rushforth <kevin.rushforth at oracle.com>
Enviado: ter?a-feira, 17 de dezembro de 2019 13:49
Para: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
Assunto: Re: How can a stage decoration change?

Taking a quick look, I'm not sure I believe that comment, but in any
case I don't think it's talking about changing from an undecorated Stage
to a decorated Stage. Rather, I think it means that when a decorated
Stage is created, the window might be initially created and then the
decorations added in a second step.

-- Kevin


On 12/17/2019 8:34 AM, Thiago Milczarek Sayao wrote:
> Hi.
>
> Window.setBounds() doc specifies:
>
>
> * Gravity values specify how to correct window location if only its size
> * changes (for example when stage decorations are added). User initiated
> * resizing should be ignored and must not influence window location through
> * this mechanism.
>
> How can I test this mechanism since initStyle() only works when before show() ?
>
> Cheers.


From kcr at openjdk.java.net  Tue Dec 17 17:29:02 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 17 Dec 2019 17:29:02 GMT
Subject: [Rev 04] RFR: 8225571: Port DND source to use GTK instead of GDK
In-Reply-To: <eyXaSGR06zfVnqLGw2qCC253QVU-dnB6wTydHdsMGfg=.a6265dae-c240-4dca-af00-2a993f2ca8d2@github.com>
References: <yGeCvJ869LfLO1sDwMfj_uLe_H_WVXgyan6EUlxvITc=.819b4b77-d10f-4f9e-b53b-a01e7a39eb78@github.com>
 <eyXaSGR06zfVnqLGw2qCC253QVU-dnB6wTydHdsMGfg=.a6265dae-c240-4dca-af00-2a993f2ca8d2@github.com>
Message-ID: <UwtjafDJviMqD--J3O0Nc_y-V3SeMDHc-wEPqdYImvY=.ac23f330-7ba2-4771-aced-83971fbb0034@github.com>

On Tue, 17 Dec 2019 17:29:02 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8225571
>> 
>> To run tests (on the root of the source tree):
>> ./gradlew apps
>> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
>> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
>> 
>> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls
>> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor
> 
> The pull request has been updated with 1 additional commit.

Looks good.

Pending 2nd reviewer.

-------------

Marked as reviewed by kcr (Lead).

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

From jvos at openjdk.java.net  Tue Dec 17 19:44:52 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 17 Dec 2019 19:44:52 GMT
Subject: [Rev 01] RFR: 8227808: Make GTK3 libraries mandatory for building
 on Linux
In-Reply-To: <MqS3QSREoojWi42jbjScXZ0BmaROUg8km1DCPnbmgws=.df5efb19-41b6-4336-94f2-383ca92970ce@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
 <MqS3QSREoojWi42jbjScXZ0BmaROUg8km1DCPnbmgws=.df5efb19-41b6-4336-94f2-383ca92970ce@github.com>
Message-ID: <jg8r9oC4FOiHPsItp2nDVerNsR8HDpErhXKl1EE_LRI=.0736e3f0-2b65-4e32-97d9-27b1f7124104@github.com>

On Tue, 17 Dec 2019 19:44:52 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Need for the change [[JDK-8227808](https://bugs.openjdk.java.net/browse/JDK-8227808)]:
>> Currently GTK3 is the default on Linux. However, there is build logic that will skip building glassgtk3 if the gtk3 development libraries are not installed. This creates a situation where the build will succeed, but the resulting JavaFX library will fail to run unless you explicitly force GTK2 with "-Djdk.gtk.version=2". 
>> 
>> How to verify the change:
>> On a Linux system without gtk2 and gtk3 packages,
>> 1. Clone jfx and run gradle sdk.
>> -> Build should fail with an error for missing GTK3 packages.
>> 
>> 2. Install gtk3 packages, remove build directory and run gradle clean sdk.
>> -> Build should fail with an error for missing GTK2 packages.
>> 
>> 3. Install gtk2 packages, remove build directory and run gradle clean sdk.
>> -> Build should finish without any error.
>> 
>> Build verification:
>> 1. Run a JavaFX application with -Djdk.gtk.verbose=true
>> Verify the verbose message, the default glassgtk3 library should be used.
>> 
>> 2. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=2
>> Verify the verbose message, glassgtk2 library should be used.
>> 
>> 3. Run a JavaFX application with -Djdk.gtk.verbose=true -Djdk.gtk.version=3
>> Verify the verbose message, glassgtk3 library should be used.
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by jvos (Reviewer).

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

From jvos at openjdk.java.net  Tue Dec 17 20:12:52 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 17 Dec 2019 20:12:52 GMT
Subject: [Rev 02] RFR: 8196587: Remove use of deprecated finalize method
 from JPEGImageLoader
In-Reply-To: <2Y8gm943ltI7JMPav-_r6lHGo9t-DJwcRkrUldTMCcg=.0cee0dfa-c66e-4251-9b68-bb1a8583b365@github.com>
References: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
 <2Y8gm943ltI7JMPav-_r6lHGo9t-DJwcRkrUldTMCcg=.0cee0dfa-c66e-4251-9b68-bb1a8583b365@github.com>
Message-ID: <J2nQIzxvQFjIrSbURzDGJvzJS3CLS6vJyKRezrl4VPA=.399505c7-03f4-4b7e-bf75-2a39c2c20ec5@github.com>

On Tue, 17 Dec 2019 20:12:52 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
>> And so the JPEGImageLoader.finalize() method should be removed.
>> 
>> The change is,
>> 1. Remove finalize method from JPEGImageLoader class.
>> 
>> 2. Instance of JPEGImageLoader is created and used in ImageStorage class. JPEGImageLoader.dispose() should be called after it's use over. This would be a common call for the other (GIF, PNG, BMP) ImageLoader classes, which have empty dispose() method.
>> 
>> 3. JPEGImageLoader.load() method almost always calls the dispose() method after the image is loaded. In normal scenario JPEGImageLoader is disposed here. The calls to dispose() added in ImageStorage seem logically correct place to add and should be added.
>> 
>> Verification:
>> Verified :graphics:test and system tests on all three platforms.
>> Verified that JPEGImageLoader.dispose() is always initiated by JPEGImageLoader.load()
> 
> The pull request has been updated with 1 additional commit.

While it's hard to proof that the dispose() is now called in all possible end scenario's, I don't see a path where it would not be called after applying the PR. 
The iOS change is fine.

-------------

Marked as reviewed by jvos (Reviewer).

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

From kcr at openjdk.java.net  Tue Dec 17 21:43:34 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 17 Dec 2019 21:43:34 GMT
Subject: [Rev 02] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
Message-ID: <1fpPz0revVBK7SKsGQh9T7hkoXSFc2xXLBlDtsYW8f4=.863e828b-17d3-40e8-93c0-d6c99830573d@github.com>

On Tue, 17 Dec 2019 21:43:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8232811
>> 
>> This one was hard to tackle.
>> 
>> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest
> 
> The pull request has been updated with 1 additional commit.

The fix looks good (with a minor formatting comment). The test needs a couple of changes.

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1053:

> 1052:         return;
> 1053: 
> 1054:     }

Minor: This blank line is not related to the change; probably best to remove it.

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1289:

> 1288:         }
> 1289: 
> 1290:         gtk_window_resize(GTK_WINDOW(gtk_widget), newWidth, newHeight);

Ditto.

tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 63:

> 62:     @Test(timeout = 15000)
> 63:     public void dialogWithOwnerSizingTest() throws Exception {
> 64:         Thread.sleep(500);

This test fails on Windows 10 with 125% screen scaling. The size of the two dialogs are not exactly the same: 181.6 vs 180.0. I recommend either excluding the test or else adding a 2 pixel tolerance if the DPI scaling factor is non-integral.

tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 68:

> 67:         Assert.assertEquals(dialog.getDialogPane().getWidth(), dialog2.getDialogPane().getWidth(), 0.0);
> 68:         Assert.assertEquals(dialog.getDialogPane().getHeight(), dialog2.getDialogPane().getHeight(), 0.0);
> 69:         hide();

The expected and actual values are backwards. When it fails, it's the first dialog that is wrong, so the expected values should come from dialog2.

tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 69:

> 68:         Assert.assertEquals(dialog.getDialogPane().getHeight(), dialog2.getDialogPane().getHeight(), 0.0);
> 69:         hide();
> 70:     }

When running the test on Linux without your fix, it gets the expected assertion failure, but then crashes. It looks like there is some interaction between the dialog still being open and the eventual call to `stage.hide()` and `Platform.exit`. I'll file a separate bug for this, since it is unrelated to your fix (I can make it happen with or without your fix).

I recommend putting the call to `hide()` in a try ... finally.

-------------



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

From kevin.rushforth at oracle.com  Tue Dec 17 21:49:29 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 17 Dec 2019 13:49:29 -0800
Subject: How can a stage decoration change?
In-Reply-To: <CP2P15201MB22286EAE0BCCD02E1B809692DE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
References: <CP2P15201MB2228EFF370E80DA2DE6205EEDE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
 <29b7137a-3d37-8e41-dd84-0d123854f6f6@oracle.com>
 <CP2P15201MB22286EAE0BCCD02E1B809692DE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
Message-ID: <69334412-1900-e964-2969-a7da8fb53c34@oracle.com>

In that case, I'm not sure. You'll have to look at all of the callers to 
this function and see how it is used.

-- Kevin


On 12/17/2019 9:05 AM, Thiago Milczarek Sayao wrote:
> But there is no way managed JavaFx would know window manager 
> decoration sizes to pass to setBounds().
>
> Asking a more direct question. Why are xGravity and yGravity necessary?
>
> Thanks.
> ------------------------------------------------------------------------
> *De:* openjfx-dev <openjfx-dev-bounces at openjdk.java.net> em nome de 
> Kevin Rushforth <kevin.rushforth at oracle.com>
> *Enviado:* ter?a-feira, 17 de dezembro de 2019 13:49
> *Para:* openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
> *Assunto:* Re: How can a stage decoration change?
> Taking a quick look, I'm not sure I believe that comment, but in any
> case I don't think it's talking about changing from an undecorated Stage
> to a decorated Stage. Rather, I think it means that when a decorated
> Stage is created, the window might be initially created and then the
> decorations added in a second step.
>
> -- Kevin
>
>
> On 12/17/2019 8:34 AM, Thiago Milczarek Sayao wrote:
> > Hi.
> >
> > Window.setBounds() doc specifies:
> >
> >
> > * Gravity values specify how to correct window location if only its size
> > * changes (for example when stage decorations are added). User initiated
> > * resizing should be ignored and must not influence window location 
> through
> > * this mechanism.
> >
> > How can I test this mechanism since initStyle() only works when 
> before show() ?
> >
> > Cheers.
>


From kevin.rushforth at oracle.com  Tue Dec 17 21:56:50 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 17 Dec 2019 13:56:50 -0800
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
 <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
 <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
Message-ID: <cfcf1324-15b1-597b-a450-29ffaa658b4a@oracle.com>

Yes, other projects have multiple review requirements. And similar to 
JavaFX, the answer to how many reviewers are needed is "it depends"; 
sometimes one is enough for certain sub-projects or simple fixes; other 
sub-projects want two reviewers; sometimes you want a specific expert to 
review a tricky change in one area being touched by a fix in addition to 
the two primary reviewers.

I think if Skara tries to get into the business of covering all cases, 
we will be adding a lot of complexity and still not be satisfied. The 
current approach, which I think is the right one for now, is to for the 
tool to enforce the minimum requirement for any fix to be integrated. 
Beyond that it is up to the Committer and Reviewer(s) to make sure that 
the all criteria for integrating a fix have been met.

-- Kevin


On 12/16/2019 4:14 PM, Nir Lisker wrote:
> Do other projects also have multi-reviewers requirements?
>
> I would think that at least for a CSR, which is OpenJDK-wide, a 
> request could be put in with the Skara to track it. A Reviewer (or 
> Committer?) could invoke a /csr command which will require?the PR 
> author to provide a link to the CSR, and check that it was approved as 
> part of the patch approval?process.
>
> Not sure how complicated it would be to implement.
>
> - Nir
>
> On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     That's a good question about whether we can ask for a slight
>     rewording
>     of the Skara bot message to indicate that there might be other
>     things to
>     check before "/integrate". I'll raise that question with the Skara
>     team.
>
>     As an aside, I noticed the other day that you typed "/integrate"
>     after a
>     single review, but in that case, there was no clear indication
>     from Ajit
>     (the first reviewer and the sponsor) that a second review was
>     required,
>     so I didn't comment on it.
>
>     -- Kevin
>
>
>     On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>     >
>     > Kevin,
>     >
>     > thanks for the clarification :) My bad that I didn't re-read the
>     > contrib.md. But then, who does? The lazy like myself do it
>     > occasionally only (down to once and then forget about it <g>)
>     >
>     > Maybe the bot message can be improved? With some indication that
>     its
>     > (the bot's) knowledge about review requirements is limited, so
>     would
>     > require a careful check by the contributor before actually post the
>     > /integrate comment? Actually, I think I goofed the other day, was
>     > safed only by Ajit who waited for the 2nd review before his
>     /sponsor.
>     >
>     > -- Jeanette
>     >
>     > Zitat von Kevin Rushforth <kevin.rushforth at oracle.com
>     <mailto:kevin.rushforth at oracle.com>>:
>     >
>     >> I added a comment to the two PRs in question, but it bears
>     discussion
>     >> here.
>     >>
>     >> The Skara bot can't know whether all criteria have been met. It
>     >> can't, for example, know whether there are outstanding comments
>     from
>     >> some reviewers that need to be addressed. Nor does it know
>     which PRs
>     >> need two reviewers (or sometimes a third if there is a specific
>     >> person we would like to review it), which ones need a CSR, etc.
>     >>
>     >> So having it state authoritatively that the PR is ready to
>     integrate
>     >> is a bit misleading. This is documented in the Code Review
>     section of
>     >> the CONTRIBUTING [1] doc:
>     >>
>     >>> NOTE: while the Skara tooling will indicate that the PR is
>     ready to
>     >>> integrate once the first reviewer with a "Reviewer" role in the
>     >>> project has approved it, this may or may not be sufficient
>     depending
>     >>> on the type of fix. For example, you must wait for a second
>     approval
>     >>> for enhancements or high-impact bug fixes.
>     >>
>     >> If anyone can think of a way to improve this and make it more
>     clear,
>     >> that would be helpful.
>     >>
>     >> -- Kevin
>     >>
>     >> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>     >>
>     >>
>     >> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>     >>>
>     >>> Looks like it assumes a pull request as properly reviewed as
>     soon as
>     >>> it gets a single approve - independent on how many reviewers are
>     >>> required, see f.i.
>     >>>
>     >>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>     >>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>     >>>
>     >>> -- Jeanette
>     >>>
>     >
>     >
>     >
>


From christian.carlow at gmail.com  Tue Dec 17 22:38:47 2019
From: christian.carlow at gmail.com (Christian Carlow)
Date: Tue, 17 Dec 2019 16:38:47 -0600
Subject: Fwd: Draggable pane in relation to Docking
In-Reply-To: <CADrUJQcF96uZTBsT33mENWnfHb4LYTCZmcGR7+3BonyGmHhT_g@mail.gmail.com>
References: <CADrUJQc_tGiav68i7Ak8DVAa0-kv2gFPpAPep4EMB2zipe5WDw@mail.gmail.com>
 <CADrUJQcF96uZTBsT33mENWnfHb4LYTCZmcGR7+3BonyGmHhT_g@mail.gmail.com>
Message-ID: <CADrUJQf72ZuDtuMa4YA0n1HY-0iZwKQ39nAaKOW4mdFhy+0s5g@mail.gmail.com>

Sent a message to openfx-discuss last month but got not response.  That
list doesn't seem very popular so I figured I'd forward to this list.

Any thoughts on draggable tabs supporting docking behaviors?

---------- Forwarded message ---------
From: Christian Carlow <christian.carlow at gmail.com>
Date: Sun, Nov 24, 2019 at 9:50 AM
Subject: Draggable pane in relation to Docking
To: <openjfx-discuss at openjdk.java.net>


This mailing list seems to have little activity so hopefully this message
finds the proper audience.

I've been searching for a descent docking system for JavaFX for the past
year and haven't found one sufficient enough to meet my needs to I started
my own:
https://github.com/ccarlow/DndDockFX

Tabs are used as the primary drag control within the project which is
consistent with many applications like Chrome, Firefox, Gimp, etc.

Draggable tabs aren't implemented in JavaFX yet so I have a custom
implementation which partially relates to the following issue intended to
implement them:
https://bugs.openjdk.java.net/browse/JDK-8092098

The descriptions seem to describe a partial docking system that allow tabs
be removed from TabPanes and placed in another.  If this is the intention
then does it make sense to support all docking capabilities such as
attaching to a SplitPane instead of only a TabPane and also allow Tabs to
exist in separate windows?

My intention is to provide feedback that may help the implementation of the
issue above as well as receive feedback about the best way to implement my
docking library.  The main conflict seems likely to come from the behavior
that occurs when tabs detect a drag.

The current tab reordering implementation seems to be derived from the
following project: https://github.com/sibvisions/javafx.DndTabPane.  It
shows a divider between each tab to indicate the new position where the tab
will be dropped.  That behavior conflicts with the behavior that I've
implemented which displays a context menu over a tab when dragged over
which lists docking options which includes tabbing left or right along with
splitting left, right, top, or bottom.

From kcr at openjdk.java.net  Tue Dec 17 23:02:02 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 17 Dec 2019 23:02:02 GMT
Subject: [Rev 02] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
Message-ID: <zumT4t2DP62BXmKXtvE5r697Hb5gQt12STEUS-iFkXY=.e403c4be-8ffd-4dfb-bfbf-984463643ab4@github.com>

On Tue, 17 Dec 2019 23:02:02 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8232811
>> 
>> This one was hard to tackle.
>> 
>> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest
> 
> The pull request has been updated with 1 additional commit.

tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 124:

> 123: 
> 124:             stage.initStyle(StageStyle.UNDECORATED);
> 125:             stage.setOnShown(e -> Platform.runLater(startupLatch::countDown));

Since this is a Robot test that relies on the Stage being in front of other windows, can you add the following?

    stage.setAlwaysOnTop(true);

-------------

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

From swpalmer at gmail.com  Wed Dec 18 00:50:25 2019
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 17 Dec 2019 19:50:25 -0500
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <cfcf1324-15b1-597b-a450-29ffaa658b4a@oracle.com>
References: <cfcf1324-15b1-597b-a450-29ffaa658b4a@oracle.com>
Message-ID: <78386D33-1FE7-43FA-9B16-2E9D6459C42E@gmail.com>

Perhaps the language in the message should be tweaked?
Maybe use, ?This change can be integrated if there are no further review requirements.?

Scott

> On Dec 17, 2019, at 4:57 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> ?Yes, other projects have multiple review requirements. And similar to JavaFX, the answer to how many reviewers are needed is "it depends"; sometimes one is enough for certain sub-projects or simple fixes; other sub-projects want two reviewers; sometimes you want a specific expert to review a tricky change in one area being touched by a fix in addition to the two primary reviewers.
> 
> I think if Skara tries to get into the business of covering all cases, we will be adding a lot of complexity and still not be satisfied. The current approach, which I think is the right one for now, is to for the tool to enforce the minimum requirement for any fix to be integrated. Beyond that it is up to the Committer and Reviewer(s) to make sure that the all criteria for integrating a fix have been met.
> 
> -- Kevin
> 
> 
>> On 12/16/2019 4:14 PM, Nir Lisker wrote:
>> Do other projects also have multi-reviewers requirements?
>> 
>> I would think that at least for a CSR, which is OpenJDK-wide, a request could be put in with the Skara to track it. A Reviewer (or Committer?) could invoke a /csr command which will require the PR author to provide a link to the CSR, and check that it was approved as part of the patch approval process.
>> 
>> Not sure how complicated it would be to implement.
>> 
>> - Nir
>> 
>> On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>> 
>>    That's a good question about whether we can ask for a slight
>>    rewording
>>    of the Skara bot message to indicate that there might be other
>>    things to
>>    check before "/integrate". I'll raise that question with the Skara
>>    team.
>> 
>>    As an aside, I noticed the other day that you typed "/integrate"
>>    after a
>>    single review, but in that case, there was no clear indication
>>    from Ajit
>>    (the first reviewer and the sponsor) that a second review was
>>    required,
>>    so I didn't comment on it.
>> 
>>    -- Kevin
>> 
>> 
>>    On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>>    >
>>    > Kevin,
>>    >
>>    > thanks for the clarification :) My bad that I didn't re-read the
>>    > contrib.md. But then, who does? The lazy like myself do it
>>    > occasionally only (down to once and then forget about it <g>)
>>    >
>>    > Maybe the bot message can be improved? With some indication that
>>    its
>>    > (the bot's) knowledge about review requirements is limited, so
>>    would
>>    > require a careful check by the contributor before actually post the
>>    > /integrate comment? Actually, I think I goofed the other day, was
>>    > safed only by Ajit who waited for the 2nd review before his
>>    /sponsor.
>>    >
>>    > -- Jeanette
>>    >
>>    > Zitat von Kevin Rushforth <kevin.rushforth at oracle.com
>>    <mailto:kevin.rushforth at oracle.com>>:
>>    >
>>    >> I added a comment to the two PRs in question, but it bears
>>    discussion
>>    >> here.
>>    >>
>>    >> The Skara bot can't know whether all criteria have been met. It
>>    >> can't, for example, know whether there are outstanding comments
>>    from
>>    >> some reviewers that need to be addressed. Nor does it know
>>    which PRs
>>    >> need two reviewers (or sometimes a third if there is a specific
>>    >> person we would like to review it), which ones need a CSR, etc.
>>    >>
>>    >> So having it state authoritatively that the PR is ready to
>>    integrate
>>    >> is a bit misleading. This is documented in the Code Review
>>    section of
>>    >> the CONTRIBUTING [1] doc:
>>    >>
>>    >>> NOTE: while the Skara tooling will indicate that the PR is
>>    ready to
>>    >>> integrate once the first reviewer with a "Reviewer" role in the
>>    >>> project has approved it, this may or may not be sufficient
>>    depending
>>    >>> on the type of fix. For example, you must wait for a second
>>    approval
>>    >>> for enhancements or high-impact bug fixes.
>>    >>
>>    >> If anyone can think of a way to improve this and make it more
>>    clear,
>>    >> that would be helpful.
>>    >>
>>    >> -- Kevin
>>    >>
>>    >> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>>    >>
>>    >>
>>    >> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>>    >>>
>>    >>> Looks like it assumes a pull request as properly reviewed as
>>    soon as
>>    >>> it gets a single approve - independent on how many reviewers are
>>    >>> required, see f.i.
>>    >>>
>>    >>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>>    >>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>    >>>
>>    >>> -- Jeanette
>>    >>>
>>    >
>>    >
>>    >
>> 
> 

From almatvee at openjdk.java.net  Wed Dec 18 01:05:55 2019
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 18 Dec 2019 01:05:55 GMT
Subject: RFR: 8232589: Remove CoreAudio Utility Classes
Message-ID: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>

https://bugs.openjdk.java.net/browse/JDK-8232589

- Removed CoreAudio Utility classes.
- Spectrum which was depended on CoreAudio Utility classes for doing computations will now run GStreamer spectrum element to do spectrum. Element will be run without pipeline and will be used as utility library to do spectrum calculation. I added extra APIs to bypass proper element initialization.
- Equalizer and audio unit (volume and balance) where modified, so we can run then directly without CoreAudio pipeline.

-------------

Commits:
 - 7e2785b1: 8232589: Remove CoreAudio Utility Classes

Changes: https://git.openjdk.java.net/jfx/pull/69/files
 Webrev: https://webrevs.openjdk.java.net/jfx/69/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8232589
  Stats: 14666 lines in 64 files changed: 343 ins; 14067 del; 256 mod
  Patch: https://git.openjdk.java.net/jfx/pull/69.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/69/head:pull/69

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

From kevin.rushforth at oracle.com  Wed Dec 18 01:19:35 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 17 Dec 2019 17:19:35 -0800
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <78386D33-1FE7-43FA-9B16-2E9D6459C42E@gmail.com>
References: <cfcf1324-15b1-597b-a450-29ffaa658b4a@oracle.com>
 <78386D33-1FE7-43FA-9B16-2E9D6459C42E@gmail.com>
Message-ID: <c82b0d5a-40f9-01ad-3a39-47ac26ffe416@oracle.com>

I like that suggestion. I'll run it by the Skara team.

-- Kevin


On 12/17/2019 4:50 PM, Scott Palmer wrote:
> Perhaps the language in the message should be tweaked?
> Maybe use, ?This change can be integrated if there are no further review requirements.?
>
> Scott
>
>> On Dec 17, 2019, at 4:57 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>
>> ?Yes, other projects have multiple review requirements. And similar to JavaFX, the answer to how many reviewers are needed is "it depends"; sometimes one is enough for certain sub-projects or simple fixes; other sub-projects want two reviewers; sometimes you want a specific expert to review a tricky change in one area being touched by a fix in addition to the two primary reviewers.
>>
>> I think if Skara tries to get into the business of covering all cases, we will be adding a lot of complexity and still not be satisfied. The current approach, which I think is the right one for now, is to for the tool to enforce the minimum requirement for any fix to be integrated. Beyond that it is up to the Committer and Reviewer(s) to make sure that the all criteria for integrating a fix have been met.
>>
>> -- Kevin
>>
>>
>>> On 12/16/2019 4:14 PM, Nir Lisker wrote:
>>> Do other projects also have multi-reviewers requirements?
>>>
>>> I would think that at least for a CSR, which is OpenJDK-wide, a request could be put in with the Skara to track it. A Reviewer (or Committer?) could invoke a /csr command which will require the PR author to provide a link to the CSR, and check that it was approved as part of the patch approval process.
>>>
>>> Not sure how complicated it would be to implement.
>>>
>>> - Nir
>>>
>>> On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>>>
>>>     That's a good question about whether we can ask for a slight
>>>     rewording
>>>     of the Skara bot message to indicate that there might be other
>>>     things to
>>>     check before "/integrate". I'll raise that question with the Skara
>>>     team.
>>>
>>>     As an aside, I noticed the other day that you typed "/integrate"
>>>     after a
>>>     single review, but in that case, there was no clear indication
>>>     from Ajit
>>>     (the first reviewer and the sponsor) that a second review was
>>>     required,
>>>     so I didn't comment on it.
>>>
>>>     -- Kevin
>>>
>>>
>>>     On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>>>     >
>>>     > Kevin,
>>>     >
>>>     > thanks for the clarification :) My bad that I didn't re-read the
>>>     > contrib.md. But then, who does? The lazy like myself do it
>>>     > occasionally only (down to once and then forget about it <g>)
>>>     >
>>>     > Maybe the bot message can be improved? With some indication that
>>>     its
>>>     > (the bot's) knowledge about review requirements is limited, so
>>>     would
>>>     > require a careful check by the contributor before actually post the
>>>     > /integrate comment? Actually, I think I goofed the other day, was
>>>     > safed only by Ajit who waited for the 2nd review before his
>>>     /sponsor.
>>>     >
>>>     > -- Jeanette
>>>     >
>>>     > Zitat von Kevin Rushforth <kevin.rushforth at oracle.com
>>>     <mailto:kevin.rushforth at oracle.com>>:
>>>     >
>>>     >> I added a comment to the two PRs in question, but it bears
>>>     discussion
>>>     >> here.
>>>     >>
>>>     >> The Skara bot can't know whether all criteria have been met. It
>>>     >> can't, for example, know whether there are outstanding comments
>>>     from
>>>     >> some reviewers that need to be addressed. Nor does it know
>>>     which PRs
>>>     >> need two reviewers (or sometimes a third if there is a specific
>>>     >> person we would like to review it), which ones need a CSR, etc.
>>>     >>
>>>     >> So having it state authoritatively that the PR is ready to
>>>     integrate
>>>     >> is a bit misleading. This is documented in the Code Review
>>>     section of
>>>     >> the CONTRIBUTING [1] doc:
>>>     >>
>>>     >>> NOTE: while the Skara tooling will indicate that the PR is
>>>     ready to
>>>     >>> integrate once the first reviewer with a "Reviewer" role in the
>>>     >>> project has approved it, this may or may not be sufficient
>>>     depending
>>>     >>> on the type of fix. For example, you must wait for a second
>>>     approval
>>>     >>> for enhancements or high-impact bug fixes.
>>>     >>
>>>     >> If anyone can think of a way to improve this and make it more
>>>     clear,
>>>     >> that would be helpful.
>>>     >>
>>>     >> -- Kevin
>>>     >>
>>>     >> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>>>     >>
>>>     >>
>>>     >> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>>>     >>>
>>>     >>> Looks like it assumes a pull request as properly reviewed as
>>>     soon as
>>>     >>> it gets a single approve - independent on how many reviewers are
>>>     >>> required, see f.i.
>>>     >>>
>>>     >>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>>>     >>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>>     >>>
>>>     >>> -- Jeanette
>>>     >>>
>>>     >
>>>     >
>>>     >
>>>


From philip.race at oracle.com  Wed Dec 18 02:04:19 2019
From: philip.race at oracle.com (Philip Race)
Date: Tue, 17 Dec 2019 18:04:19 -0800
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
 <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
 <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
Message-ID: <5DF98923.4070409@oracle.com>



On 12/16/19, 4:14 PM, Nir Lisker wrote:
> Do other projects also have multi-reviewers requirements?

The client libraries in the OpenJDK do as a default rule, excusing 
simple fixes.

>
> I would think that at least for a CSR, which is OpenJDK-wide, a request
> could be put in with the Skara to track it. A Reviewer (or Committer?)
> could invoke a /csr command which will require the PR author to provide a
> link to the CSR, and check that it was approved as part of the patch
> approval process.

I think that if there is a CSR sub-task in JBS skara can key off whether 
that is approved.
This does mean skara needs to probe JBS but SFAIK its doing that a 
hundred times
a minute anyway.

-phil.

>
> Not sure how complicated it would be to implement.
>
> - Nir
>
> On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth<kevin.rushforth at oracle.com>
> wrote:
>
>> That's a good question about whether we can ask for a slight rewording
>> of the Skara bot message to indicate that there might be other things to
>> check before "/integrate". I'll raise that question with the Skara team.
>>
>> As an aside, I noticed the other day that you typed "/integrate" after a
>> single review, but in that case, there was no clear indication from Ajit
>> (the first reviewer and the sponsor) that a second review was required,
>> so I didn't comment on it.
>>
>> -- Kevin
>>
>>
>> On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>>> Kevin,
>>>
>>> thanks for the clarification :) My bad that I didn't re-read the
>>> contrib.md. But then, who does? The lazy like myself do it
>>> occasionally only (down to once and then forget about it<g>)
>>>
>>> Maybe the bot message can be improved? With some indication that its
>>> (the bot's) knowledge about review requirements is limited, so would
>>> require a careful check by the contributor before actually post the
>>> /integrate comment? Actually, I think I goofed the other day, was
>>> safed only by Ajit who waited for the 2nd review before his /sponsor.
>>>
>>> -- Jeanette
>>>
>>> Zitat von Kevin Rushforth<kevin.rushforth at oracle.com>:
>>>
>>>> I added a comment to the two PRs in question, but it bears discussion
>>>> here.
>>>>
>>>> The Skara bot can't know whether all criteria have been met. It
>>>> can't, for example, know whether there are outstanding comments from
>>>> some reviewers that need to be addressed. Nor does it know which PRs
>>>> need two reviewers (or sometimes a third if there is a specific
>>>> person we would like to review it), which ones need a CSR, etc.
>>>>
>>>> So having it state authoritatively that the PR is ready to integrate
>>>> is a bit misleading. This is documented in the Code Review section of
>>>> the CONTRIBUTING [1] doc:
>>>>
>>>>> NOTE: while the Skara tooling will indicate that the PR is ready to
>>>>> integrate once the first reviewer with a "Reviewer" role in the
>>>>> project has approved it, this may or may not be sufficient depending
>>>>> on the type of fix. For example, you must wait for a second approval
>>>>> for enhancements or high-impact bug fixes.
>>>> If anyone can think of a way to improve this and make it more clear,
>>>> that would be helpful.
>>>>
>>>> -- Kevin
>>>>
>>>> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>>>>
>>>>
>>>> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>>>>> Looks like it assumes a pull request as properly reviewed as soon as
>>>>> it gets a single approve - independent on how many reviewers are
>>>>> required, see f.i.
>>>>>
>>>>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>>>>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>>>>
>>>>> -- Jeanette
>>>>>
>>>
>>>
>>

From thiago.sayao at clamed.com.br  Wed Dec 18 11:59:28 2019
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Wed, 18 Dec 2019 11:59:28 +0000
Subject: How can a stage decoration change?
In-Reply-To: <69334412-1900-e964-2969-a7da8fb53c34@oracle.com>
References: <CP2P15201MB2228EFF370E80DA2DE6205EEDE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>
 <29b7137a-3d37-8e41-dd84-0d123854f6f6@oracle.com>
 <CP2P15201MB22286EAE0BCCD02E1B809692DE500@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>,
 <69334412-1900-e964-2969-a7da8fb53c34@oracle.com>
Message-ID: <CP2P15201MB222875F5011283B29BB0DE09DE530@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>

Well, Windows glass native implementation just ignores it.

I am working on some changes on linux glass implementation because the current implementation has too many special case handling (I have added some myself to fix some bugs). I want to do a more "direct flow" code. Will file a bug and provide a PR when it's ready and pass the tests.

Cheers.
________________________________
De: Kevin Rushforth <kevin.rushforth at oracle.com>
Enviado: ter?a-feira, 17 de dezembro de 2019 18:49
Para: Thiago Milczarek Sayao <thiago.sayao at clamed.com.br>; openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
Assunto: Re: How can a stage decoration change?

In that case, I'm not sure. You'll have to look at all of the callers to this function and see how it is used.

-- Kevin


On 12/17/2019 9:05 AM, Thiago Milczarek Sayao wrote:
But there is no way managed JavaFx would know window manager decoration sizes to pass to setBounds().

Asking a more direct question. Why are xGravity and yGravity necessary?

Thanks.
________________________________
De: openjfx-dev <openjfx-dev-bounces at openjdk.java.net><mailto:openjfx-dev-bounces at openjdk.java.net> em nome de Kevin Rushforth <kevin.rushforth at oracle.com><mailto:kevin.rushforth at oracle.com>
Enviado: ter?a-feira, 17 de dezembro de 2019 13:49
Para: openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net> <openjfx-dev at openjdk.java.net><mailto:openjfx-dev at openjdk.java.net>
Assunto: Re: How can a stage decoration change?

Taking a quick look, I'm not sure I believe that comment, but in any
case I don't think it's talking about changing from an undecorated Stage
to a decorated Stage. Rather, I think it means that when a decorated
Stage is created, the window might be initially created and then the
decorations added in a second step.

-- Kevin


On 12/17/2019 8:34 AM, Thiago Milczarek Sayao wrote:
> Hi.
>
> Window.setBounds() doc specifies:
>
>
> * Gravity values specify how to correct window location if only its size
> * changes (for example when stage decorations are added). User initiated
> * resizing should be ignored and must not influence window location through
> * this mechanism.
>
> How can I test this mechanism since initStyle() only works when before show() ?
>
> Cheers.



From jvos at openjdk.java.net  Wed Dec 18 12:52:13 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 18 Dec 2019 12:52:13 GMT
Subject: [Rev 01] RFR: 8087980: Add property to disable Monocle cursor
In-Reply-To: <q8SnX5X_3xnnD3H-V5wqxgaTbyHmuORA4vxNlw8a3io=.1ae2b80c-c82e-4288-a334-9029a98cf44a@github.com>
References: <6oGs5VTOw0fh_hel0b-jkSNGwwnXY8RCyYbLQfacX0Y=.42838ee2-f3cf-47f7-a048-4a6404d1b3d4@github.com>
 <q8SnX5X_3xnnD3H-V5wqxgaTbyHmuORA4vxNlw8a3io=.1ae2b80c-c82e-4288-a334-9029a98cf44a@github.com>
Message-ID: <0IRAm4s9xg7Mt5cJ8kOtx-zyHJsvGW01Y5Qxi2WgdAo=.2cd54920-d581-470b-a4c7-1df5fd2a9c18@github.com>

On Wed, 18 Dec 2019 12:52:12 GMT, Dell Green <github.com+12861109+dellgreen at openjdk.org> wrote:

>> Often on embedded systems a cursor is not a valid input modality. On some of these systems, when the javafx toolkit initialises the native hardware cursor, it produces artefacts which can be seen on screen (in the framebuffer for example). This change adds a system property "monocle.cursor.enabled" that can disable the creation of a native cursor in each of the Monocle NativePlatform implementations in favour of a NullCursor which is a no-op implementation of the NativeCursor abstract class that all native cursors have to implement.
>> 
>> NullCursor class already existed and was being returned for some implementations like AndroidPlatform and HeadlessPlatform. This change builds upon that and conditionally returns NullCursor for all platforms.
>> 
>> A system property "monocle.debugcursor" has also been added to turn on logging of which NativeCursor has been selected when the toolkit initialises.
> 
> The pull request has been updated with 1 additional commit.

LGTM

-------------

Marked as reviewed by jvos (Reviewer).

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

From christian.carlow at gmail.com  Tue Dec 17 06:10:24 2019
From: christian.carlow at gmail.com (Christian Carlow)
Date: Tue, 17 Dec 2019 00:10:24 -0600
Subject: Fwd: Draggable pane in relation to Docking
In-Reply-To: <CADrUJQc_tGiav68i7Ak8DVAa0-kv2gFPpAPep4EMB2zipe5WDw@mail.gmail.com>
References: <CADrUJQc_tGiav68i7Ak8DVAa0-kv2gFPpAPep4EMB2zipe5WDw@mail.gmail.com>
Message-ID: <CADrUJQcF96uZTBsT33mENWnfHb4LYTCZmcGR7+3BonyGmHhT_g@mail.gmail.com>

Sent a message to openfx-discuss last month but got not response.  That
list doesn't seem very popular so I figured I'd forward to this list.

Any thoughts on draggable tabs supporting docking behaviors?

---------- Forwarded message ---------
From: Christian Carlow <christian.carlow at gmail.com>
Date: Sun, Nov 24, 2019 at 9:50 AM
Subject: Draggable pane in relation to Docking
To: <openjfx-discuss at openjdk.java.net>


This mailing list seems to have little activity so hopefully this message
finds the proper audience.

I've been searching for a descent docking system for JavaFX for the past
year and haven't found one sufficient enough to meet my needs to I started
my own:
https://github.com/ccarlow/DndDockFX

Tabs are used as the primary drag control within the project which is
consistent with many applications like Chrome, Firefox, Gimp, etc.

Draggable tabs aren't implemented in JavaFX yet so I have a custom
implementation which partially relates to the following issue intended to
implement them:
https://bugs.openjdk.java.net/browse/JDK-8092098

The descriptions seem to describe a partial docking system that allow tabs
be removed from TabPanes and placed in another.  If this is the intention
then does it make sense to support all docking capabilities such as
attaching to a SplitPane instead of only a TabPane and also allow Tabs to
exist in separate windows?

My intention is to provide feedback that may help the implementation of the
issue above as well as receive feedback about the best way to implement my
docking library.  The main conflict seems likely to come from the behavior
that occurs when tabs detect a drag.

The current tab reordering implementation seems to be derived from the
following project: https://github.com/sibvisions/javafx.DndTabPane.  It
shows a divider between each tab to indicate the new position where the tab
will be dropped.  That behavior conflicts with the behavior that I've
implemented which displays a context menu over a tab when dragged over
which lists docking options which includes tabbing left or right along with
splitting left, right, top, or bottom.

From ebresiedev at gmail.com  Mon Dec 16 16:07:44 2019
From: ebresiedev at gmail.com (Eric Bresie)
Date: Mon, 16 Dec 2019 10:07:44 -0600
Subject: Skara - bot sending can-be-integrated message
 prematurely?
In-Reply-To: 3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com
References: 20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu
 97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com
 20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu
 20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu
Message-ID: <6cd9ebd5-f859-4b77-a968-d0d79921eff6@Erics-iPhone-X>

So is there some ?review complete? or ?review closed? or some following state available for the bot to key on maybe instead of reacting to one reviewer completion?

Eric Bresie
Ebresie at gmail.com
> On December 16, 2019 at 9:38:00 AM CST, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> That's a good question about whether we can ask for a slight rewording
> of the Skara bot message to indicate that there might be other things to
> check before "/integrate". I'll raise that question with the Skara team.
>
> As an aside, I noticed the other day that you typed "/integrate" after a
> single review, but in that case, there was no clear indication from Ajit
> (the first reviewer and the sponsor) that a second review was required,
> so I didn't comment on it.
>
> -- Kevin
>
>
> On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
> >
> > Kevin,
> >
> > thanks for the clarification :) My bad that I didn't re-read the
> > contrib.md. But then, who does? The lazy like myself do it
> > occasionally only (down to once and then forget about it <g>)
> >
> > Maybe the bot message can be improved? With some indication that its
> > (the bot's) knowledge about review requirements is limited, so would
> > require a careful check by the contributor before actually post the
> > /integrate comment? Actually, I think I goofed the other day, was
> > safed only by Ajit who waited for the 2nd review before his /sponsor.
> >
> > -- Jeanette
> >
> > Zitat von Kevin Rushforth <kevin.rushforth at oracle.com>:
> >
> > > I added a comment to the two PRs in question, but it bears discussion
> > > here.
> > >
> > > The Skara bot can't know whether all criteria have been met. It
> > > can't, for example, know whether there are outstanding comments from
> > > some reviewers that need to be addressed. Nor does it know which PRs
> > > need two reviewers (or sometimes a third if there is a specific
> > > person we would like to review it), which ones need a CSR, etc.
> > >
> > > So having it state authoritatively that the PR is ready to integrate
> > > is a bit misleading. This is documented in the Code Review section of
> > > the CONTRIBUTING [1] doc:
> > >
> > > > NOTE: while the Skara tooling will indicate that the PR is ready to
> > > > integrate once the first reviewer with a "Reviewer" role in the
> > > > project has approved it, this may or may not be sufficient depending
> > > > on the type of fix. For example, you must wait for a second approval
> > > > for enhancements or high-impact bug fixes.
> > >
> > > If anyone can think of a way to improve this and make it more clear,
> > > that would be helpful.
> > >
> > > -- Kevin
> > >
> > > [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
> > >
> > >
> > > On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
> > > >
> > > > Looks like it assumes a pull request as properly reviewed as soon as
> > > > it gets a single approve - independent on how many reviewers are
> > > > required, see f.i.
> > > >
> > > > https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
> > > > https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
> > > >
> > > > -- Jeanette
> > > >
> >
> >
> >
>

From arapte at openjdk.java.net  Wed Dec 18 16:55:44 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 18 Dec 2019 16:55:44 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <FTLU9msATCFecKkKSMDbRIfoti3oHeNByOX3RMv9xwg=.831b1744-1059-40a3-a64b-b0cce08e4540@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
 <FTLU9msATCFecKkKSMDbRIfoti3oHeNByOX3RMv9xwg=.831b1744-1059-40a3-a64b-b0cce08e4540@github.com>
Message-ID: <LAVvWfJ57Y7a2gFvc1FF8IeTFc91TROv6qnNnY4M97k=.39ebda86-18f3-46e1-af69-9e60e954f5cf@github.com>

On Tue, 17 Dec 2019 14:29:22 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> The finalize() method is deprecated in JDK9. See [Java 9 deprecated features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html).
>> And so the [PiscesRenderer.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/PiscesRenderer.java#L439) and [AbstractSurface.finalize()](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/pisces/AbstractSurface.java#L100) method should be removed.
>> 
>> The change is,
>> 1. Remove finalize method from PiscesRenderer and AbstractSurface classes.
>> 2. Use [Disposer](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/prism/impl/Disposer.java#L48) class for cleanup instead of finalize().  For SW pipeline the cleanup is initiated in [here](https://github.com/openjdk/jfx/blob/71ca899fbfc74d825c29b20a778d6d9eb243f90f/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java#L195) in UploadingPainer.java.
>> 3. Added new JNI methods to JPiscesRenderer.c and JAbstractSurface.c and removed the ones which were used previously with finalize() method.
>> 
>> Verification:
>> Verified that the newly added dispose() methods get invoked as required and no OOM occurs.
>> 1. Create a sample program which adds and removes non 3D shapes and/or controls to stage in a loop.
>> 2. Run the program using -Dprism.order=sw,  -Dprism.verbose=true. (optional -Xmx50m)
>> Expected Behavior: 
>> a. Maximum memory consumption after this change should reduce or remain same as that of before this change.
>> b. No OOM should occur with this change or without this change.
> 
> modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 63:
> 
>> 62:     }
>> 63: }
>> 64: 
> 
> there are no checks on memory errors as used to be in the finalize implementation. Are those not needed anymore?

Hi Johan,
The `readAndClearMemErrorFlag()` method checks if the variable `mem_Error_Flag` is `JNI_TRUE`.
A call should be made to `setMemErrorFlag()` to set `mem_Error_Flag` to `JNI_TRUE`.

The methods used to dispose Surface and renderer only `free()` the allocated memory and 
do not result in making a call to `setMemErrorFlag().`
So we do not need to check for `readAndClearMemErrorFlag()`
And I think it was not required before this change too.

-------------

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

From arapte at openjdk.java.net  Wed Dec 18 17:03:39 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 18 Dec 2019 17:03:39 GMT
Subject: [Integrated] RFR: 8196587: Remove use of deprecated finalize
 method from JPEGImageLoader
In-Reply-To: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
References: <bvYyjZcnVhmwD8EYnwHv_8dHRSTcvRzhyXlrFoIZE1E=.28fe0d81-cbc3-41f0-8f76-492289bc17a9@github.com>
Message-ID: <47612b50-70c9-4a10-ad3d-bd4c58313898@openjdk.org>

Changeset: 1140d343
Author:    Ambarish Rapte <arapte at openjdk.org>
Date:      2019-12-18 17:03:12 +0000
URL:       https://git.openjdk.java.net/jfx/commit/1140d343

8196587: Remove use of deprecated finalize method from JPEGImageLoader

Reviewed-by: kcr, jvos

! modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ImageStorage.java
! modules/javafx.graphics/src/main/java/com/sun/javafx/iio/ios/IosImageLoader.java
! modules/javafx.graphics/src/main/java/com/sun/javafx/iio/jpeg/JPEGImageLoader.java

From arapte at openjdk.java.net  Wed Dec 18 17:06:34 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 18 Dec 2019 17:06:34 GMT
Subject: [Integrated] RFR: 8227808: Make GTK3 libraries mandatory for
 building on Linux
In-Reply-To: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
References: <n-hxXU6cXW3otou0JRHvaYrzHS0OUvJN1CoHypx1HiQ=.ab795e31-84fe-4877-ae6b-09979bc84bdb@github.com>
Message-ID: <4c2ede68-fa19-4e44-bf39-903c25af443b@openjdk.org>

Changeset: 4e005e4e
Author:    Ambarish Rapte <arapte at openjdk.org>
Date:      2019-12-18 17:05:51 +0000
URL:       https://git.openjdk.java.net/jfx/commit/4e005e4e

8227808: Make GTK3 libraries mandatory for building on Linux

Reviewed-by: jvos, kcr

! buildSrc/linux.gradle

From kcr at openjdk.java.net  Wed Dec 18 17:28:17 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 18 Dec 2019 17:28:17 GMT
Subject: [Rev 02] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <1fpPz0revVBK7SKsGQh9T7hkoXSFc2xXLBlDtsYW8f4=.863e828b-17d3-40e8-93c0-d6c99830573d@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
 <1fpPz0revVBK7SKsGQh9T7hkoXSFc2xXLBlDtsYW8f4=.863e828b-17d3-40e8-93c0-d6c99830573d@github.com>
Message-ID: <ofRv0xP31AD-z4L5FGQVQHYI5KMltSpbla_JwvCClPc=.032fad2b-eac9-45af-aa12-25c576c98c44@github.com>

On Tue, 17 Dec 2019 21:43:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> The fix looks good (with a minor formatting comment). The test needs a couple of changes.

@arapte - can you be the second reviewer on this?

-------------

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

From kcr at openjdk.java.net  Wed Dec 18 17:32:15 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 18 Dec 2019 17:32:15 GMT
Subject: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <RsFqcFBdBoq1U0sLXZ-RcYRYf8WUQsYS3z-oCJHw6Eg=.68d90bde-3473-4d09-8bc7-3e48d61d86e9@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>
 <RsFqcFBdBoq1U0sLXZ-RcYRYf8WUQsYS3z-oCJHw6Eg=.68d90bde-3473-4d09-8bc7-3e48d61d86e9@github.com>
Message-ID: <UapkyA-v4efgAzWO_mfIoLJGp0IV7BObuzhN2qouIgo=.aee541ed-e266-4d50-9f1a-d46917d49429@github.com>

On Mon, 16 Dec 2019 21:32:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> Looks good.
> 
> Once the CSR is approved, this can be integrated.

@Maxoudela the CSR has been approved. Go ahead and `/integrate` this and I will sponsor it.

-------------

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

From shadzic at openjdk.java.net  Wed Dec 18 18:31:25 2019
From: shadzic at openjdk.java.net (Hadzic Samir)
Date: Wed, 18 Dec 2019 18:31:25 GMT
Subject: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <UapkyA-v4efgAzWO_mfIoLJGp0IV7BObuzhN2qouIgo=.aee541ed-e266-4d50-9f1a-d46917d49429@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>
 <RsFqcFBdBoq1U0sLXZ-RcYRYf8WUQsYS3z-oCJHw6Eg=.68d90bde-3473-4d09-8bc7-3e48d61d86e9@github.com>
 <UapkyA-v4efgAzWO_mfIoLJGp0IV7BObuzhN2qouIgo=.aee541ed-e266-4d50-9f1a-d46917d49429@github.com>
Message-ID: <fgEbmjdtm79zSiuKPc5SoXCW1acvDXBg0TRj_yuNM3A=.d424aa79-f70d-4911-92bc-3c341b2b8b7b@github.com>

On Wed, 18 Dec 2019 17:32:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Looks good.
>> 
>> Once the CSR is approved, this can be integrated.
> 
> @Maxoudela the CSR has been approved. Go ahead and `/integrate` this and I will sponsor it.

`/integrate`

-------------

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

From kcr at openjdk.java.net  Wed Dec 18 18:32:59 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 18 Dec 2019 18:32:59 GMT
Subject: [Rev 07] RFR: 8207957: TableSkinUtils should not contain actual
 code implementation
In-Reply-To: <fgEbmjdtm79zSiuKPc5SoXCW1acvDXBg0TRj_yuNM3A=.d424aa79-f70d-4911-92bc-3c341b2b8b7b@github.com>
References: <WaR0m56w4Cg_r2xwzfGYpbsAMqav-coTgUzdGed1DbQ=.55b4313c-1f86-4e5f-951c-7680d07eca1f@github.com>
 <6WoZb2QgBV06OPbC1QXokvYK3z9GSzALQXYFpM6SAcE=.3e676ae6-1d38-4791-8d4a-2964c338aa1b@github.com>
 <RsFqcFBdBoq1U0sLXZ-RcYRYf8WUQsYS3z-oCJHw6Eg=.68d90bde-3473-4d09-8bc7-3e48d61d86e9@github.com>
 <UapkyA-v4efgAzWO_mfIoLJGp0IV7BObuzhN2qouIgo=.aee541ed-e266-4d50-9f1a-d46917d49429@github.com>
 <fgEbmjdtm79zSiuKPc5SoXCW1acvDXBg0TRj_yuNM3A=.d424aa79-f70d-4911-92bc-3c341b2b8b7b@github.com>
Message-ID: <OhWSRjLYLmCAj9KzYpHsyWkohBlq3Ap3lNuhJ5m_TTk=.cfda22b7-19f9-4fd3-990b-fa9bcf5ba7f0@github.com>

On Wed, 18 Dec 2019 18:29:59 GMT, Hadzic Samir <shadzic at openjdk.org> wrote:

>> @Maxoudela the CSR has been approved. Go ahead and `/integrate` this and I will sponsor it.
> 
> `/integrate`

I think you need to enter the integrate command "as-is" without the back-quotes. the `/` needs to be the first character.

-------------

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

From nlisker at gmail.com  Wed Dec 18 18:36:12 2019
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 18 Dec 2019 20:36:12 +0200
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <5DF98923.4070409@oracle.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
 <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
 <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
 <5DF98923.4070409@oracle.com>
Message-ID: <CA+0ynh8uB6tg_dF3eqdvM7Bs=o5XhL6tDuXw-VsTjZ88wUueTw@mail.gmail.com>

>
> The client libraries in the OpenJDK do as a default rule, excusing simple
> fixes.
>

Then maybe it would be helpful to have a "/reviewers n" command that will
tell the bot how many reviewers are needed. It's less convoluted than the
CSR tracking and basically replaces the comment a reviewer would make
anyway to inform the PR author how many reviewers they should wait for.
Extending the bot to look for n reviewers instead of the current 1 should
not be far fetched.



>
>
On Wed, Dec 18, 2019 at 4:02 AM Philip Race <philip.race at oracle.com> wrote:

>
>
> On 12/16/19, 4:14 PM, Nir Lisker wrote:
> > Do other projects also have multi-reviewers requirements?
>
> The client libraries in the OpenJDK do as a default rule, excusing
> simple fixes.
>
> >
> > I would think that at least for a CSR, which is OpenJDK-wide, a request
> > could be put in with the Skara to track it. A Reviewer (or Committer?)
> > could invoke a /csr command which will require the PR author to provide a
> > link to the CSR, and check that it was approved as part of the patch
> > approval process.
>
> I think that if there is a CSR sub-task in JBS skara can key off whether
> that is approved.
> This does mean skara needs to probe JBS but SFAIK its doing that a
> hundred times
> a minute anyway.
>
> -phil.
>
> >
> > Not sure how complicated it would be to implement.
> >
> > - Nir
> >
> > On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth<
> kevin.rushforth at oracle.com>
> > wrote:
> >
> >> That's a good question about whether we can ask for a slight rewording
> >> of the Skara bot message to indicate that there might be other things to
> >> check before "/integrate". I'll raise that question with the Skara team.
> >>
> >> As an aside, I noticed the other day that you typed "/integrate" after a
> >> single review, but in that case, there was no clear indication from Ajit
> >> (the first reviewer and the sponsor) that a second review was required,
> >> so I didn't comment on it.
> >>
> >> -- Kevin
> >>
> >>
> >> On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
> >>> Kevin,
> >>>
> >>> thanks for the clarification :) My bad that I didn't re-read the
> >>> contrib.md. But then, who does? The lazy like myself do it
> >>> occasionally only (down to once and then forget about it<g>)
> >>>
> >>> Maybe the bot message can be improved? With some indication that its
> >>> (the bot's) knowledge about review requirements is limited, so would
> >>> require a careful check by the contributor before actually post the
> >>> /integrate comment? Actually, I think I goofed the other day, was
> >>> safed only by Ajit who waited for the 2nd review before his /sponsor.
> >>>
> >>> -- Jeanette
> >>>
> >>> Zitat von Kevin Rushforth<kevin.rushforth at oracle.com>:
> >>>
> >>>> I added a comment to the two PRs in question, but it bears discussion
> >>>> here.
> >>>>
> >>>> The Skara bot can't know whether all criteria have been met. It
> >>>> can't, for example, know whether there are outstanding comments from
> >>>> some reviewers that need to be addressed. Nor does it know which PRs
> >>>> need two reviewers (or sometimes a third if there is a specific
> >>>> person we would like to review it), which ones need a CSR, etc.
> >>>>
> >>>> So having it state authoritatively that the PR is ready to integrate
> >>>> is a bit misleading. This is documented in the Code Review section of
> >>>> the CONTRIBUTING [1] doc:
> >>>>
> >>>>> NOTE: while the Skara tooling will indicate that the PR is ready to
> >>>>> integrate once the first reviewer with a "Reviewer" role in the
> >>>>> project has approved it, this may or may not be sufficient depending
> >>>>> on the type of fix. For example, you must wait for a second approval
> >>>>> for enhancements or high-impact bug fixes.
> >>>> If anyone can think of a way to improve this and make it more clear,
> >>>> that would be helpful.
> >>>>
> >>>> -- Kevin
> >>>>
> >>>> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
> >>>>
> >>>>
> >>>> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
> >>>>> Looks like it assumes a pull request as properly reviewed as soon as
> >>>>> it gets a single approve - independent on how many reviewers are
> >>>>> required, see f.i.
> >>>>>
> >>>>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
> >>>>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
> >>>>>
> >>>>> -- Jeanette
> >>>>>
> >>>
> >>>
> >>
>

From kevin.rushforth at oracle.com  Wed Dec 18 19:31:15 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 18 Dec 2019 11:31:15 -0800
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <CA+0ynh8uB6tg_dF3eqdvM7Bs=o5XhL6tDuXw-VsTjZ88wUueTw@mail.gmail.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
 <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
 <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
 <5DF98923.4070409@oracle.com>
 <CA+0ynh8uB6tg_dF3eqdvM7Bs=o5XhL6tDuXw-VsTjZ88wUueTw@mail.gmail.com>
Message-ID: <a4405c66-542b-f2b0-7a1a-800300f59bab@oracle.com>

That's an interesting idea. It would, of course, need to disallow 
reducing the number below the minimum specified in .jcheck/conf (e.g., 
we wouldn't allow "/reviewers 0").

-- Kevin


On 12/18/2019 10:36 AM, Nir Lisker wrote:
>
>     The client libraries in the OpenJDK do as a default rule,
>     excusing?simple fixes.
>
>
> Then maybe it would be helpful to have a "/reviewers n" command that 
> will tell the bot how many reviewers are needed. It's less convoluted 
> than the CSR tracking and basically replaces the comment a reviewer 
> would make anyway to inform the PR author how many reviewers they 
> should wait for. Extending the bot to look for n reviewers instead of 
> the current 1 should not be far fetched.
>
>
>
> On Wed, Dec 18, 2019 at 4:02 AM Philip Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>> wrote:
>
>
>
>     On 12/16/19, 4:14 PM, Nir Lisker wrote:
>     > Do other projects also have multi-reviewers requirements?
>
>     The client libraries in the OpenJDK do as a default rule, excusing
>     simple fixes.
>
>     >
>     > I would think that at least for a CSR, which is OpenJDK-wide, a
>     request
>     > could be put in with the Skara to track it. A Reviewer (or
>     Committer?)
>     > could invoke a /csr command which will require the PR author to
>     provide a
>     > link to the CSR, and check that it was approved as part of the patch
>     > approval process.
>
>     I think that if there is a CSR sub-task in JBS skara can key off
>     whether
>     that is approved.
>     This does mean skara needs to probe JBS but SFAIK its doing that a
>     hundred times
>     a minute anyway.
>
>     -phil.
>
>     >
>     > Not sure how complicated it would be to implement.
>     >
>     > - Nir
>     >
>     > On Mon, Dec 16, 2019 at 5:39 PM Kevin
>     Rushforth<kevin.rushforth at oracle.com
>     <mailto:kevin.rushforth at oracle.com>>
>     > wrote:
>     >
>     >> That's a good question about whether we can ask for a slight
>     rewording
>     >> of the Skara bot message to indicate that there might be other
>     things to
>     >> check before "/integrate". I'll raise that question with the
>     Skara team.
>     >>
>     >> As an aside, I noticed the other day that you typed
>     "/integrate" after a
>     >> single review, but in that case, there was no clear indication
>     from Ajit
>     >> (the first reviewer and the sponsor) that a second review was
>     required,
>     >> so I didn't comment on it.
>     >>
>     >> -- Kevin
>     >>
>     >>
>     >> On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>     >>> Kevin,
>     >>>
>     >>> thanks for the clarification :) My bad that I didn't re-read the
>     >>> contrib.md. But then, who does? The lazy like myself do it
>     >>> occasionally only (down to once and then forget about it<g>)
>     >>>
>     >>> Maybe the bot message can be improved? With some indication
>     that its
>     >>> (the bot's) knowledge about review requirements is limited, so
>     would
>     >>> require a careful check by the contributor before actually
>     post the
>     >>> /integrate comment? Actually, I think I goofed the other day, was
>     >>> safed only by Ajit who waited for the 2nd review before his
>     /sponsor.
>     >>>
>     >>> -- Jeanette
>     >>>
>     >>> Zitat von Kevin Rushforth<kevin.rushforth at oracle.com
>     <mailto:kevin.rushforth at oracle.com>>:
>     >>>
>     >>>> I added a comment to the two PRs in question, but it bears
>     discussion
>     >>>> here.
>     >>>>
>     >>>> The Skara bot can't know whether all criteria have been met. It
>     >>>> can't, for example, know whether there are outstanding
>     comments from
>     >>>> some reviewers that need to be addressed. Nor does it know
>     which PRs
>     >>>> need two reviewers (or sometimes a third if there is a specific
>     >>>> person we would like to review it), which ones need a CSR, etc.
>     >>>>
>     >>>> So having it state authoritatively that the PR is ready to
>     integrate
>     >>>> is a bit misleading. This is documented in the Code Review
>     section of
>     >>>> the CONTRIBUTING [1] doc:
>     >>>>
>     >>>>> NOTE: while the Skara tooling will indicate that the PR is
>     ready to
>     >>>>> integrate once the first reviewer with a "Reviewer" role in the
>     >>>>> project has approved it, this may or may not be sufficient
>     depending
>     >>>>> on the type of fix. For example, you must wait for a second
>     approval
>     >>>>> for enhancements or high-impact bug fixes.
>     >>>> If anyone can think of a way to improve this and make it more
>     clear,
>     >>>> that would be helpful.
>     >>>>
>     >>>> -- Kevin
>     >>>>
>     >>>> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>     >>>>
>     >>>>
>     >>>> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>     >>>>> Looks like it assumes a pull request as properly reviewed as
>     soon as
>     >>>>> it gets a single approve - independent on how many reviewers are
>     >>>>> required, see f.i.
>     >>>>>
>     >>>>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>     >>>>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>     >>>>>
>     >>>>> -- Jeanette
>     >>>>>
>     >>>
>     >>>
>     >>
>


From philip.race at oracle.com  Thu Dec 19 03:17:31 2019
From: philip.race at oracle.com (Phil Race)
Date: Wed, 18 Dec 2019 19:17:31 -0800
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <a4405c66-542b-f2b0-7a1a-800300f59bab@oracle.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
 <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
 <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
 <5DF98923.4070409@oracle.com>
 <CA+0ynh8uB6tg_dF3eqdvM7Bs=o5XhL6tDuXw-VsTjZ88wUueTw@mail.gmail.com>
 <a4405c66-542b-f2b0-7a1a-800300f59bab@oracle.com>
Message-ID: <CD81E1E3-B95F-4931-ADAC-3B3D07531726@oracle.com>

It would have to allow anyone who has reviewer status to add that comment.
Not just the author since if they knew we would have less need for it.

-Phil.

> On Dec 18, 2019, at 11:31 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> That's an interesting idea. It would, of course, need to disallow reducing the number below the minimum specified in .jcheck/conf (e.g., we wouldn't allow "/reviewers 0").
> 
> -- Kevin
> 
> 
>> On 12/18/2019 10:36 AM, Nir Lisker wrote:
>>> The client libraries in the OpenJDK do as a default rule, excusing simple fixes.
>> 
>> Then maybe it would be helpful to have a "/reviewers n" command that will tell the bot how many reviewers are needed. It's less convoluted than the CSR tracking and basically replaces the comment a reviewer would make anyway to inform the PR author how many reviewers they should wait for. Extending the bot to look for n reviewers instead of the current 1 should not be far fetched.
>> 
>>  
>>> 
>> 
>>> On Wed, Dec 18, 2019 at 4:02 AM Philip Race <philip.race at oracle.com> wrote:
>>> 
>>> 
>>> On 12/16/19, 4:14 PM, Nir Lisker wrote:
>>> > Do other projects also have multi-reviewers requirements?
>>> 
>>> The client libraries in the OpenJDK do as a default rule, excusing 
>>> simple fixes.
>>> 
>>> >
>>> > I would think that at least for a CSR, which is OpenJDK-wide, a request
>>> > could be put in with the Skara to track it. A Reviewer (or Committer?)
>>> > could invoke a /csr command which will require the PR author to provide a
>>> > link to the CSR, and check that it was approved as part of the patch
>>> > approval process.
>>> 
>>> I think that if there is a CSR sub-task in JBS skara can key off whether 
>>> that is approved.
>>> This does mean skara needs to probe JBS but SFAIK its doing that a 
>>> hundred times
>>> a minute anyway.
>>> 
>>> -phil.
>>> 
>>> >
>>> > Not sure how complicated it would be to implement.
>>> >
>>> > - Nir
>>> >
>>> > On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth<kevin.rushforth at oracle.com>
>>> > wrote:
>>> >
>>> >> That's a good question about whether we can ask for a slight rewording
>>> >> of the Skara bot message to indicate that there might be other things to
>>> >> check before "/integrate". I'll raise that question with the Skara team.
>>> >>
>>> >> As an aside, I noticed the other day that you typed "/integrate" after a
>>> >> single review, but in that case, there was no clear indication from Ajit
>>> >> (the first reviewer and the sponsor) that a second review was required,
>>> >> so I didn't comment on it.
>>> >>
>>> >> -- Kevin
>>> >>
>>> >>
>>> >> On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>>> >>> Kevin,
>>> >>>
>>> >>> thanks for the clarification :) My bad that I didn't re-read the
>>> >>> contrib.md. But then, who does? The lazy like myself do it
>>> >>> occasionally only (down to once and then forget about it<g>)
>>> >>>
>>> >>> Maybe the bot message can be improved? With some indication that its
>>> >>> (the bot's) knowledge about review requirements is limited, so would
>>> >>> require a careful check by the contributor before actually post the
>>> >>> /integrate comment? Actually, I think I goofed the other day, was
>>> >>> safed only by Ajit who waited for the 2nd review before his /sponsor.
>>> >>>
>>> >>> -- Jeanette
>>> >>>
>>> >>> Zitat von Kevin Rushforth<kevin.rushforth at oracle.com>:
>>> >>>
>>> >>>> I added a comment to the two PRs in question, but it bears discussion
>>> >>>> here.
>>> >>>>
>>> >>>> The Skara bot can't know whether all criteria have been met. It
>>> >>>> can't, for example, know whether there are outstanding comments from
>>> >>>> some reviewers that need to be addressed. Nor does it know which PRs
>>> >>>> need two reviewers (or sometimes a third if there is a specific
>>> >>>> person we would like to review it), which ones need a CSR, etc.
>>> >>>>
>>> >>>> So having it state authoritatively that the PR is ready to integrate
>>> >>>> is a bit misleading. This is documented in the Code Review section of
>>> >>>> the CONTRIBUTING [1] doc:
>>> >>>>
>>> >>>>> NOTE: while the Skara tooling will indicate that the PR is ready to
>>> >>>>> integrate once the first reviewer with a "Reviewer" role in the
>>> >>>>> project has approved it, this may or may not be sufficient depending
>>> >>>>> on the type of fix. For example, you must wait for a second approval
>>> >>>>> for enhancements or high-impact bug fixes.
>>> >>>> If anyone can think of a way to improve this and make it more clear,
>>> >>>> that would be helpful.
>>> >>>>
>>> >>>> -- Kevin
>>> >>>>
>>> >>>> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>>> >>>>
>>> >>>>
>>> >>>> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>>> >>>>> Looks like it assumes a pull request as properly reviewed as soon as
>>> >>>>> it gets a single approve - independent on how many reviewers are
>>> >>>>> required, see f.i.
>>> >>>>>
>>> >>>>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>>> >>>>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>> >>>>>
>>> >>>>> -- Jeanette
>>> >>>>>
>>> >>>
>>> >>>
>>> >>
> 

From florian.kirmaier at gmail.com  Thu Dec 19 12:37:41 2019
From: florian.kirmaier at gmail.com (Florian Kirmaier)
Date: Thu, 19 Dec 2019 13:37:41 +0100
Subject: RFR: JDK-8236259: MemoryLeak in ProgressIndicator -
 DeterminateIndicator doesn't get collected
Message-ID: <CA+4mSqZpLA5XpqcskzHjAOXZm3sd+2Yc3N6wW8YxeiJRzjdQxg@mail.gmail.com>

Hi everyone,

Here is my PR for the memory-leak I've reported some minutes ago.
PR: https://github.com/openjdk/jfx/pull/71
Ticket: https://bugs.openjdk.java.net/browse/JDK-8236259
The fix itself is quite straight forward.
It basically just removed the listener which causes the leak.

The unit-test for the fix is a bit more complicated.

I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy
(written by myself), which simplifies testing for memory leaks.
I think there are many places in the JavaFX-codebase that could highly
benefit from this library.
It could also simplify many of the already existing unit tests.
It makes testing for memory-leaks readable and reliable.
It would also be possible to just copy the code of the library into the
JavaFX-codebase.
It only contains a single class.

I also had to make a method public, to write the test. I'm open to ideas,
how I could solve it differently.

Florian Kirmaier

From fkirmaier at openjdk.java.net  Thu Dec 19 12:39:07 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 19 Dec 2019 12:39:07 GMT
Subject: RFR: 8236259: MemoryLeak in ProgressIndicator
Message-ID: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>

Hi everyone,

ticket: https://bugs.openjdk.java.net/browse/JDK-8236259

The fix itself is quite straight forward.
It basically just removed the listener which causes the leak.

The unit-test for the fix is a bit more complicated.

I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks.
I think there are many places in the JavaFX-codebase that could highly benefit from this library.
It could also simplify many of the already existing unit tests.
It makes testing for memory-leaks readably and reliable. 
It would also be possible to just copy the code of the library into the JavaFX-codebase. 
It only contains a single class.

I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently.

-------------

Commits:
 - c4da2e7b: JDK-8236259: MemoryLeak in ProgressIndicator - DeterminateIndicator doesn't get collected

Changes: https://git.openjdk.java.net/jfx/pull/71/files
 Webrev: https://webrevs.openjdk.java.net/jfx/71/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236259
  Stats: 45 lines in 4 files changed: 41 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/71.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/71/head:pull/71

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

From fastegal at openjdk.java.net  Thu Dec 19 13:28:27 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 19 Dec 2019 13:28:27 GMT
Subject: RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
Message-ID: <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>

On Thu, 19 Dec 2019 12:35:56 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Hi everyone,
> 
> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259
> 
> The fix itself is quite straight forward.
> It basically just removed the listener which causes the leak.
> 
> The unit-test for the fix is a bit more complicated.
> 
> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks.
> I think there are many places in the JavaFX-codebase that could highly benefit from this library.
> It could also simplify many of the already existing unit tests.
> It makes testing for memory-leaks readably and reliable. 
> It would also be possible to just copy the code of the library into the JavaFX-codebase. 
> It only contains a single class.
> 
> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 521:

> 520:             registerChangeListener(text.fontProperty(), (Consumer<ObservableValue<?>>) fontListener);
> 521: 
> 522:             // The circular background for the progress pie piece

wondering why you add a (strong) field reference here? 

Thought that registerChangeListener(observableValue, consumer) takes care of handling storage/cleanup - provided its counter-method unregisterChangeListener(observableValue) is called, which is missing, so seems to be the only part that has to be added. Or not?

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 555:

> 554:         }
> 555: 
> 556:         private void setFillOverride(Paint fillOverride) {

just a side-note: this will remove the whole chain of listeners to that property. Not a problem here, because the indicator seems to be the only participant listening. A bit strange using the skin's LambdaMultiplePropertyChangeListenerHandler ...

-------------

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

From fkirmaier at openjdk.java.net  Thu Dec 19 13:35:47 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 19 Dec 2019 13:35:47 GMT
Subject: RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
Message-ID: <UMjA4HlmFLc9qvtkl4eN2U0DfhKT-xJ99w0ygeYVAuA=.250407dc-b368-45f3-86df-699302d2c964@github.com>

On Thu, 19 Dec 2019 13:23:25 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Hi everyone,
>> 
>> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259
>> 
>> The fix itself is quite straight forward.
>> It basically just removed the listener which causes the leak.
>> 
>> The unit-test for the fix is a bit more complicated.
>> 
>> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks.
>> I think there are many places in the JavaFX-codebase that could highly benefit from this library.
>> It could also simplify many of the already existing unit tests.
>> It makes testing for memory-leaks readably and reliable. 
>> It would also be possible to just copy the code of the library into the JavaFX-codebase. 
>> It only contains a single class.
>> 
>> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently.
> 
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 521:
> 
>> 520:             registerChangeListener(text.fontProperty(), (Consumer<ObservableValue<?>>) fontListener);
>> 521: 
>> 522:             // The circular background for the progress pie piece
> 
> wondering why you add a (strong) field reference here? 
> 
> Thought that registerChangeListener(observableValue, consumer) takes care of handling storage/cleanup - provided its counter-method unregisterChangeListener(observableValue) is called, which is missing, so seems to be the only part that has to be added. Or not?

Yes, that doesn't make a lot of sense. It's probably an artifact because I expected a different API do unregister the listener. I'm gonna change it back!

-------------

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

From fkirmaier at openjdk.java.net  Thu Dec 19 13:36:03 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 19 Dec 2019 13:36:03 GMT
Subject: RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
Message-ID: <bvrfTehxRLi8rCCzTYiaR1HzZt95b32W3F3r-S3UDAo=.e9403dea-b5c2-4a00-ba79-9ba999d1b139@github.com>

On Thu, 19 Dec 2019 13:28:07 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Hi everyone,
>> 
>> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259
>> 
>> The fix itself is quite straight forward.
>> It basically just removed the listener which causes the leak.
>> 
>> The unit-test for the fix is a bit more complicated.
>> 
>> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks.
>> I think there are many places in the JavaFX-codebase that could highly benefit from this library.
>> It could also simplify many of the already existing unit tests.
>> It makes testing for memory-leaks readably and reliable. 
>> It would also be possible to just copy the code of the library into the JavaFX-codebase. 
>> It only contains a single class.
>> 
>> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently.
> 
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 555:
> 
>> 554:         }
>> 555: 
>> 556:         private void setFillOverride(Paint fillOverride) {
> 
> just a side-note: this will remove the whole chain of listeners to that property. Not a problem here, because the indicator seems to be the only participant listening. A bit strange using the skin's LambdaMultiplePropertyChangeListenerHandler ...

Yes, do you know an API for registerChangeListener which allows me to only remove a specific listener?

-------------

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

From fastegal at openjdk.java.net  Thu Dec 19 13:39:23 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 19 Dec 2019 13:39:23 GMT
Subject: RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <bvrfTehxRLi8rCCzTYiaR1HzZt95b32W3F3r-S3UDAo=.e9403dea-b5c2-4a00-ba79-9ba999d1b139@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
 <bvrfTehxRLi8rCCzTYiaR1HzZt95b32W3F3r-S3UDAo=.e9403dea-b5c2-4a00-ba79-9ba999d1b139@github.com>
Message-ID: <6126ZbZJAQnIkjbSLBEHMokret4fi4266QMA9AWkrQo=.bd490049-dc1a-48b9-add5-bbe32da45873@github.com>

On Thu, 19 Dec 2019 13:35:51 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 555:
>> 
>>> 554:         }
>>> 555: 
>>> 556:         private void setFillOverride(Paint fillOverride) {
>> 
>> just a side-note: this will remove the whole chain of listeners to that property. Not a problem here, because the indicator seems to be the only participant listening. A bit strange using the skin's LambdaMultiplePropertyChangeListenerHandler ...
> 
> Yes, do you know an API for registerChangeListener which allows me to only remove a specific listener?

no way, afaik - there had been debates when the api was added somewhere in jbs, don't recall exactly where

-------------

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

From fastegal at openjdk.java.net  Thu Dec 19 13:47:22 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 19 Dec 2019 13:47:22 GMT
Subject: RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <6126ZbZJAQnIkjbSLBEHMokret4fi4266QMA9AWkrQo=.bd490049-dc1a-48b9-add5-bbe32da45873@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
 <bvrfTehxRLi8rCCzTYiaR1HzZt95b32W3F3r-S3UDAo=.e9403dea-b5c2-4a00-ba79-9ba999d1b139@github.com>
 <6126ZbZJAQnIkjbSLBEHMokret4fi4266QMA9AWkrQo=.bd490049-dc1a-48b9-add5-bbe32da45873@github.com>
Message-ID: <9NZtsyDeTXHfn2oFJyWffHzj4JdzGvHYN2MBmSmegFg=.26f69f11-52c6-49d5-995b-0cf85607073b@github.com>

On Thu, 19 Dec 2019 13:39:07 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Yes, do you know an API for registerChangeListener which allows me to only remove a specific listener?
> 
> no way, afaik - there had been debates when the api was added somewhere in jbs, don't recall exactly where

here's where it was added: https://bugs.openjdk.java.net/browse/JDK-8151617

-------------

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

From swpalmer at openjdk.java.net  Thu Dec 19 13:48:27 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Thu, 19 Dec 2019 13:48:27 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
Message-ID: <xgODDca7_fUTwoCuCtUg8GyweKSXSlWxmJSwwkCJ0XU=.411c1cc3-6e7f-49d1-b758-97626985d3a2@github.com>

On Thu, 12 Dec 2019 21:51:56 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> 

I was thinking of deferring the `apps/toys` demo to avoid any delays in getting the new API into JavaFX 14.  I have something for it, I just don't want any feedback on it to hold up the review of this issue. Is there anything else I need to do?  Is the CSR in good shape?

-------------

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

From fkirmaier at openjdk.java.net  Thu Dec 19 13:54:00 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 19 Dec 2019 13:54:00 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
Message-ID: <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>

> Hi everyone,
> 
> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259
> 
> The fix itself is quite straight forward.
> It basically just removed the listener which causes the leak.
> 
> The unit-test for the fix is a bit more complicated.
> 
> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks.
> I think there are many places in the JavaFX-codebase that could highly benefit from this library.
> It could also simplify many of the already existing unit tests.
> It makes testing for memory-leaks readably and reliable. 
> It would also be possible to just copy the code of the library into the JavaFX-codebase. 
> It only contains a single class.
> 
> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - e9ea4d8e: JDK-8236259: MemoryLeak in ProgressIndicator - DeterminateIndicator doesn't get collected

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/71/files
  - new: https://git.openjdk.java.net/jfx/pull/71/files/c4da2e7b..e9ea4d8e

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

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

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

From fkirmaier at openjdk.java.net  Thu Dec 19 13:56:53 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 19 Dec 2019 13:56:53 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <9NZtsyDeTXHfn2oFJyWffHzj4JdzGvHYN2MBmSmegFg=.26f69f11-52c6-49d5-995b-0cf85607073b@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
 <bvrfTehxRLi8rCCzTYiaR1HzZt95b32W3F3r-S3UDAo=.e9403dea-b5c2-4a00-ba79-9ba999d1b139@github.com>
 <6126ZbZJAQnIkjbSLBEHMokret4fi4266QMA9AWkrQo=.bd490049-dc1a-48b9-add5-bbe32da45873@github.com>
 <9NZtsyDeTXHfn2oFJyWffHzj4JdzGvHYN2MBmSmegFg=.26f69f11-52c6-49d5-995b-0cf85607073b@github.com>
Message-ID: <bdKiTEOxkBH4mpiWrBKuozwrbZ4xYCfVu9C1ngqTgg4=.fb9bf9ef-2f72-4f29-9f70-1f9e1b525a53@github.com>

On Thu, 19 Dec 2019 13:47:14 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> no way, afaik - there had been debates when the api was added somewhere in jbs, don't recall exactly where
> 
> here's where it was added: https://bugs.openjdk.java.net/browse/JDK-8151617

I don't see an API in the discussion, on how to remove a specific listener. Did i miss something? It seems to me, that the API is written to support only a single listener per property.

-------------

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

From fastegal at openjdk.java.net  Thu Dec 19 14:01:24 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 19 Dec 2019 14:01:24 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <UMjA4HlmFLc9qvtkl4eN2U0DfhKT-xJ99w0ygeYVAuA=.250407dc-b368-45f3-86df-699302d2c964@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
 <UMjA4HlmFLc9qvtkl4eN2U0DfhKT-xJ99w0ygeYVAuA=.250407dc-b368-45f3-86df-699302d2c964@github.com>
Message-ID: <wSd15uHy148NnKpWuQZzN6tuzPykhCdmBQZb-A1DTn8=.0d258304-e7e4-4e0b-9e17-e754bc681056@github.com>

On Thu, 19 Dec 2019 13:35:27 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressIndicatorSkin.java line 521:
>> 
>>> 520:             registerChangeListener(text.fontProperty(), (Consumer<ObservableValue<?>>) fontListener);
>>> 521: 
>>> 522:             // The circular background for the progress pie piece
>> 
>> wondering why you add a (strong) field reference here? 
>> 
>> Thought that registerChangeListener(observableValue, consumer) takes care of handling storage/cleanup - provided its counter-method unregisterChangeListener(observableValue) is called, which is missing, so seems to be the only part that has to be added. Or not?
> 
> Yes, that doesn't make a lot of sense. It's probably an artifact because I expected a different API do unregister the listener. I'm gonna change it back!

just thinking aloud: actually, it's rather whacky that the indicator (mis-)uses the skin's multiplePropertyListener - it's api isn't meant for frequent register/unregisters (the unregisters is quite a heavy measure). Maybe it should have its own? Or the other way round: skin listening to the property and indicator having a method to update based on font which is invoked by skin's listener?

-------------

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

From fkirmaier at openjdk.java.net  Thu Dec 19 14:20:13 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 19 Dec 2019 14:20:13 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <wSd15uHy148NnKpWuQZzN6tuzPykhCdmBQZb-A1DTn8=.0d258304-e7e4-4e0b-9e17-e754bc681056@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
 <UMjA4HlmFLc9qvtkl4eN2U0DfhKT-xJ99w0ygeYVAuA=.250407dc-b368-45f3-86df-699302d2c964@github.com>
 <wSd15uHy148NnKpWuQZzN6tuzPykhCdmBQZb-A1DTn8=.0d258304-e7e4-4e0b-9e17-e754bc681056@github.com>
Message-ID: <inqwH3N8Ix-n1Q3U0SQbRUK3eB5Geug-X3u9jCEFdho=.f2b5af03-d071-4829-a4a1-e291d68784a6@github.com>

On Thu, 19 Dec 2019 14:01:08 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Yes, that doesn't make a lot of sense. It's probably an artifact because I expected a different API do unregister the listener. I'm gonna change it back!
> 
> just thinking aloud: actually, it's rather whacky that the indicator (mis-)uses the skin's multiplePropertyListener - it's api isn't meant for frequent register/unregisters (the unregisters is quite a heavy measure). Maybe it should have its own? Or the other way round: skin listening to the property and indicator having a method to update based on font which is invoked by skin's listener?

Yes, that would be reasonable.

I would rewrite the fix, add an method "updateFont" to the skin, which also updates the DeterminationIndicator.

When I look into the code, I'm a little bit confused. The fontListeners doesn't get called without a font-change. In this case, the variable doneTextWidth and doneTextHeight never get's initialized. Do I miss something or is the current code wrong?

-------------

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

From arapte at openjdk.java.net  Thu Dec 19 14:32:35 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 19 Dec 2019 14:32:35 GMT
Subject: [Rev 02] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
Message-ID: <VgrHtRd1w5OiKYqfDjeBk8Wh1GlWXsvGnhQkID3WHos=.3ca0973b-87ff-45b9-98cd-d84d18b14b27@github.com>

On Thu, 19 Dec 2019 14:32:32 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8232811
>> 
>> This one was hard to tackle.
>> 
>> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest
> 
> The pull request has been updated with 1 additional commit.

The fix itself looks good. suggested some changes in test and a query.
Please take a look.

tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 34:

> 33: import javafx.scene.control.Dialog;
> 34: import javafx.scene.control.DialogEvent;
> 35: import javafx.scene.robot.Robot;

DialogEvent is not used in program, please remove the import.

tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 50:

> 49: 
> 50: //see JDK8193502
> 51: public class DialogWithOwnerSizingTest {

Please change to JDK-8193502

tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 64:

> 63:     public void dialogWithOwnerSizingTest() throws Exception {
> 64:         Thread.sleep(500);
> 65:         clickButton();

This `sleep()` can be removed.

tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 87:

> 86:         });
> 87:         Thread.sleep(600);
> 88:         waitForLatch(dialogHideLatch, 10, "Failed to hide Dialog");

This `sleep()` can be removed too. anyway `dailogHideLatch` will synchronize.

tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 77:

> 76: 
> 77:         Thread.sleep(400);
> 78:         waitForLatch(dialogShownLatch, 10, "Failed to show Dialog");

This sleep() can be removed too. anyway `dailogShowLatch `will synchronize.

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1062:

> 1061:         geometry.final_height.type = BOUNDSTYPE_CONTENT;
> 1062:     }
> 1063: 

So now `geometry.final_width.value` and `geometry.final_height.value` will be set after the `Dialog `is displayed on screen.
Does this mean that, the `Dialog` will be resized after it is displayed ? I did not observe any size change visually.

An observation unrelated to this change: `Dialog` changes it's position after being displayed. It can not be observed always, but is very frequent. Should be easy to observe it on a slow machine.
On the same machine, I did not observe any size change though.

-------------

Changes requested by arapte (Reviewer).

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

From fastegal at openjdk.java.net  Thu Dec 19 14:43:43 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 19 Dec 2019 14:43:43 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <bdKiTEOxkBH4mpiWrBKuozwrbZ4xYCfVu9C1ngqTgg4=.fb9bf9ef-2f72-4f29-9f70-1f9e1b525a53@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
 <bvrfTehxRLi8rCCzTYiaR1HzZt95b32W3F3r-S3UDAo=.e9403dea-b5c2-4a00-ba79-9ba999d1b139@github.com>
 <6126ZbZJAQnIkjbSLBEHMokret4fi4266QMA9AWkrQo=.bd490049-dc1a-48b9-add5-bbe32da45873@github.com>
 <9NZtsyDeTXHfn2oFJyWffHzj4JdzGvHYN2MBmSmegFg=.26f69f11-52c6-49d5-995b-0cf85607073b@github.com>
 <bdKiTEOxkBH4mpiWrBKuozwrbZ4xYCfVu9C1ngqTgg4=.fb9bf9ef-2f72-4f29-9f70-1f9e1b525a53@github.com>
Message-ID: <aZuAOpmwiENzIFZuwzYsDAm0lNsQGBqTdg9YJTuw0e0=.6b85930c-ab89-43fc-b1c6-361511f30bfd@github.com>

On Thu, 19 Dec 2019 13:56:39 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> here's where it was added: https://bugs.openjdk.java.net/browse/JDK-8151617
> 
> I don't see an API in the discussion, on how to remove a specific listener. Did i miss something? It seems to me, that the API is written to support only a single listener per property.

the api is in a related issue (should be noted in the issue above). The use-cases mentioned in the isssue: it's a do-once scenario with the skin (and its subclasses) as the only user: multiple listeners can be registered, typically by a skin and/or its subclasses, each can be pre/postpended (or replaced) in the chain for that property and all are unregistered at dispose time. So I think it's really bad to use it in another collaborator like the indicator, particularly if that is re-created often and each of the instances need to remove the listener.

-------------

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

From fastegal at openjdk.java.net  Thu Dec 19 14:56:32 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 19 Dec 2019 14:56:32 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <inqwH3N8Ix-n1Q3U0SQbRUK3eB5Geug-X3u9jCEFdho=.f2b5af03-d071-4829-a4a1-e291d68784a6@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <B6WoT0XgtrDFCMvrSMtqyRathwNuClSw9UBA-sk38Eg=.2a6c9226-d6d5-4bd9-8bea-bb6e18ddb745@github.com>
 <UMjA4HlmFLc9qvtkl4eN2U0DfhKT-xJ99w0ygeYVAuA=.250407dc-b368-45f3-86df-699302d2c964@github.com>
 <wSd15uHy148NnKpWuQZzN6tuzPykhCdmBQZb-A1DTn8=.0d258304-e7e4-4e0b-9e17-e754bc681056@github.com>
 <inqwH3N8Ix-n1Q3U0SQbRUK3eB5Geug-X3u9jCEFdho=.f2b5af03-d071-4829-a4a1-e291d68784a6@github.com>
Message-ID: <Apq3KRYBavATssotqLUQCJDv37LZ0bYD5ubQvkwxXrc=.dcaceb2d-3e28-4cfd-89ff-df72728b37d4@github.com>

On Thu, 19 Dec 2019 14:19:57 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> just thinking aloud: actually, it's rather whacky that the indicator (mis-)uses the skin's multiplePropertyListener - it's api isn't meant for frequent register/unregisters (the unregisters is quite a heavy measure). Maybe it should have its own? Or the other way round: skin listening to the property and indicator having a method to update based on font which is invoked by skin's listener?
> 
> Yes, that would be reasonable.
> 
> I would rewrite the fix, add an method "updateFont" to the skin, which also updates the DeterminationIndicator.
> 
> When I look into the code, I'm a little bit confused. The fontListeners doesn't get called without a font-change. In this case, the variable doneTextWidth and doneTextHeight never get's initialized. Do I miss something or is the current code wrong?

welcome to the jungle :) looks like the code can't really work (and probably is untested) or is not important ..

-------------

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

From kcr at openjdk.java.net  Thu Dec 19 15:12:14 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 19 Dec 2019 15:12:14 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
Message-ID: <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>

On Thu, 19 Dec 2019 15:12:12 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Hi everyone,
>> 
>> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259
>> 
>> The fix itself is quite straight forward.
>> It basically just removed the listener which causes the leak.
>> 
>> The unit-test for the fix is a bit more complicated.
>> 
>> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks.
>> I think there are many places in the JavaFX-codebase that could highly benefit from this library.
>> It could also simplify many of the already existing unit tests.
>> It makes testing for memory-leaks readably and reliable. 
>> It would also be possible to just copy the code of the library into the JavaFX-codebase. 
>> It only contains a single class.
>> 
>> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently.
> 
> The pull request has been updated with 1 additional commit.

I haven't looked at the fix itself, but there are two things that _must_ be fixed before this PR can be considered:
1. You need to remove the additional 3rd-party test library dependency.
2. You need to revert the change that makes a test method public API.

build.gradle line 2514:

> 2513:         compile project(':graphics')
> 2514:         testCompile "de.sandec:JMemoryBuddy:0.1.3"
> 2515:     }

This is a new third-party dependency, which would need legal approval. You need to remove this.

modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 1929:

> 1928:      */
> 1929:     public List<Node> test_getRemoved() {
> 1930:         return removed;

This is not an acceptable change. We do not add public API to support tests. Take a look at the Shim classes for an example of how to handle this.

-------------

Changes requested by kcr (Lead).

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

From swpalmer at gmail.com  Thu Dec 19 13:42:07 2019
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 19 Dec 2019 08:42:07 -0500
Subject: apps/toys HelloTextFlow renders incorrectly on macOS 10.15
Message-ID: <D50BF7A2-2F0E-40F3-9E7B-772E1C8DDEC8@gmail.com>

As follow up to JDK-8130738 I was thinking about adding a new panel to HelloTextFlow to show adjusting the tabSize rather than making a new ?toy?.  However I noticed rendering issues right away.  When you select text, parts of the text seem to paint white-on-white .. proportional to the amount selected.  Try it on macOS 10.15 and hopefully you will see what I mean. I?ve attached a couple screenshots if they make it through to the list?

Is this a known issue?

Scott


From fkirmaier at openjdk.java.net  Thu Dec 19 15:25:07 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 19 Dec 2019 15:25:07 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
Message-ID: <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>

On Thu, 19 Dec 2019 15:12:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> I haven't looked at the fix itself, but there are two things that _must_ be fixed before this PR can be considered:
> 1. You need to remove the additional 3rd-party test library dependency.
> 2. You need to revert the change that makes a test method public API.

As mentioned, I could copy the class of the library into the JavaFX-Project. Alternatively, I could remove the unit-test entirely. 

But to be honest, the current state related to memory-leaks in the JavaFX project is a bit questionable. JavaFX is filled with leaks and code which could have leaks.
I would like to add many more tests like this into the JavaFX-CodeBase. But without the class/library I can only write unreadable code filled with sleeps, Weakreferences etc., which would be sad because now I know how to do it better.

-------------

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

From fastegal at openjdk.java.net  Thu Dec 19 15:28:20 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 19 Dec 2019 15:28:20 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
Message-ID: <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>

On Thu, 19 Dec 2019 15:24:48 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> I haven't looked at the fix itself, but there are two things that _must_ be fixed before this PR can be considered:
>> 1. You need to remove the additional 3rd-party test library dependency.
>> 2. You need to revert the change that makes a test method public API.
> 
> As mentioned, I could copy the class of the library into the JavaFX-Project. Alternatively, I could remove the unit-test entirely. 
> 
> But to be honest, the current state related to memory-leaks in the JavaFX project is a bit questionable. JavaFX is filled with leaks and code which could have leaks.
> I would like to add many more tests like this into the JavaFX-CodeBase. But without the class/library I can only write unreadable code filled with sleeps, Weakreferences etc., which would be sad because now I know how to do it better.

Florian, basically it's a single class isn't it? If so, it might be acceptable to add that class to the test.xx.infrastructure package (don't know if doing so would require a jbs issue)

-------------

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

From fastegal at openjdk.java.net  Thu Dec 19 15:33:23 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 19 Dec 2019 15:33:23 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
Message-ID: <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>

On Thu, 19 Dec 2019 15:27:59 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> As mentioned, I could copy the class of the library into the JavaFX-Project. Alternatively, I could remove the unit-test entirely. 
>> 
>> But to be honest, the current state related to memory-leaks in the JavaFX project is a bit questionable. JavaFX is filled with leaks and code which could have leaks.
>> I would like to add many more tests like this into the JavaFX-CodeBase. But without the class/library I can only write unreadable code filled with sleeps, Weakreferences etc., which would be sad because now I know how to do it better.
> 
> Florian, basically it's a single class isn't it? If so, it might be acceptable to add that class to the test.xx.infrastructure package (don't know if doing so would require a jbs issue)

for now, you could have a look at ProgressIndicatorTest (or ProgressSkinTest) attemptGC - might not be optimal (don't know enough about the dirty details of gc :) but gets the test failing/passing before/after fixing a memory leak

-------------

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

From fkirmaier at openjdk.java.net  Thu Dec 19 15:44:53 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 19 Dec 2019 15:44:53 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
Message-ID: <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>

On Thu, 19 Dec 2019 15:33:09 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Florian, basically it's a single class isn't it? If so, it might be acceptable to add that class to the test.xx.infrastructure package (don't know if doing so would require a jbs issue)
> 
> for now, you could have a look at ProgressIndicatorTest (or ProgressSkinTest) attemptGC - might not be optimal (don't know enough about the dirty details of gc :) but gets the test failing/passing before/after fixing a memory leak

The point of having this GC-magic in a library is, that it's verified by the library that it's implementation is stable for all common JavaVersions. The attemptGC is basically bad practice. I think in the JavaFX-Codebase this kind of GC-Tests are invented about 10 times. No one knows which of these implementations are stable and their code is usually unreadable. I know it, I have done it multiple times.

Copying to Infrastructure would be fine for me. It removes some benefits, like easy upgrades, Travis-verified implementation etc. But it's probably the best short-term solution.

-------------

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

From fastegal at openjdk.java.net  Thu Dec 19 15:48:33 2019
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 19 Dec 2019 15:48:33 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
 <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
Message-ID: <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>

On Thu, 19 Dec 2019 15:44:37 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> for now, you could have a look at ProgressIndicatorTest (or ProgressSkinTest) attemptGC - might not be optimal (don't know enough about the dirty details of gc :) but gets the test failing/passing before/after fixing a memory leak
> 
> The point of having this GC-magic in a library is, that it's verified by the library that it's implementation is stable for all common JavaVersions. The attemptGC is basically bad practice. I think in the JavaFX-Codebase this kind of GC-Tests are invented about 10 times. No one knows which of these implementations are stable and their code is usually unreadable. I know it, I have done it multiple times.
> 
> Copying to Infrastructure would be fine for me. It removes some benefits, like easy upgrades, Travis-verified implementation etc. But it's probably the best short-term solution.

probably not  invented so often - just c&p'd from searches of occurances of System.gc ;-)

-------------

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

From kcr at openjdk.java.net  Thu Dec 19 16:16:43 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 19 Dec 2019 16:16:43 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
 <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
 <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>
Message-ID: <BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com>

On Thu, 19 Dec 2019 15:48:17 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> The point of having this GC-magic in a library is, that it's verified by the library that it's implementation is stable for all common JavaVersions. The attemptGC is basically bad practice. I think in the JavaFX-Codebase this kind of GC-Tests are invented about 10 times. No one knows which of these implementations are stable and their code is usually unreadable. I know it, I have done it multiple times.
>> 
>> Copying to Infrastructure would be fine for me. It removes some benefits, like easy upgrades, Travis-verified implementation etc. But it's probably the best short-term solution.
> 
> probably not  invented so often - just c&p'd from searches of occurances of System.gc ;-)

Yes, exactly.

@FlorianKirmaier Proposing to add test class to the test infrastructure would be a reasonable alternative to pulling it in as a third-party dependency. I recommend separating it out into its own enhancement, with a separate JBS issue. I see that it has a dependency on the `jdk.management` module. As long as that dependency only surfaces as a test dependency, that won't be a problem. It would be nice if it were available to all modules, meaning that putting it somewhere in `javafx.base` would be good.

-------------

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

From kevin.rushforth at oracle.com  Thu Dec 19 16:23:57 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Dec 2019 08:23:57 -0800
Subject: Skara - bot sending can-be-integrated message prematurely?
In-Reply-To: <CD81E1E3-B95F-4931-ADAC-3B3D07531726@oracle.com>
References: <20191216132355.Horde.6zrrRoo2wZbW4oyHrdTvLA1@webmail.df.eu>
 <97111c6f-d2c6-0d64-4467-b08aa69c72a6@oracle.com>
 <20191216154149.Horde.vV41KBIOtMzUVIGHz1bUkQ4@webmail.df.eu>
 <3f5e7f38-c9c2-e345-3e64-7336113fa0d2@oracle.com>
 <CA+0ynh8BUmnxOWcb_dm7k+mZOye=P3c-1HnEDT2E5zT5QKmDXQ@mail.gmail.com>
 <5DF98923.4070409@oracle.com>
 <CA+0ynh8uB6tg_dF3eqdvM7Bs=o5XhL6tDuXw-VsTjZ88wUueTw@mail.gmail.com>
 <a4405c66-542b-f2b0-7a1a-800300f59bab@oracle.com>
 <CD81E1E3-B95F-4931-ADAC-3B3D07531726@oracle.com>
Message-ID: <72e4e84c-873e-6857-cf4a-5c71638d1fa3@oracle.com>

FYI, for anyone interested, the Skara team submitted the following PR to 
modify the "ready for integration" message:

https://github.com/openjdk/skara/pull/343

We can file a follow-up RFE to have them consider adding "/reviewers" 
and "/csr" commands.

-- Kevin


On 12/18/2019 7:17 PM, Phil Race wrote:
> It would have to allow anyone who has reviewer status to add that 
> comment.
> Not just the author since if they knew we would have less need for it.
>
> -Phil.
>
> On Dec 18, 2019, at 11:31 AM, Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>> That's an interesting idea. It would, of course, need to disallow 
>> reducing the number below the minimum specified in .jcheck/conf 
>> (e.g., we wouldn't allow "/reviewers 0").
>>
>> -- Kevin
>>
>>
>> On 12/18/2019 10:36 AM, Nir Lisker wrote:
>>>
>>>     The client libraries in the OpenJDK do as a default rule,
>>>     excusing?simple fixes.
>>>
>>>
>>> Then maybe it would be helpful to have a "/reviewers n" command that 
>>> will tell the bot how many reviewers are needed. It's less 
>>> convoluted than the CSR tracking and basically replaces the comment 
>>> a reviewer would make anyway to inform the PR author how many 
>>> reviewers they should wait for. Extending the bot to look for n 
>>> reviewers instead of the current 1 should not be far fetched.
>>>
>>>
>>>
>>> On Wed, Dec 18, 2019 at 4:02 AM Philip Race <philip.race at oracle.com 
>>> <mailto:philip.race at oracle.com>> wrote:
>>>
>>>
>>>
>>>     On 12/16/19, 4:14 PM, Nir Lisker wrote:
>>>     > Do other projects also have multi-reviewers requirements?
>>>
>>>     The client libraries in the OpenJDK do as a default rule, excusing
>>>     simple fixes.
>>>
>>>     >
>>>     > I would think that at least for a CSR, which is OpenJDK-wide,
>>>     a request
>>>     > could be put in with the Skara to track it. A Reviewer (or
>>>     Committer?)
>>>     > could invoke a /csr command which will require the PR author
>>>     to provide a
>>>     > link to the CSR, and check that it was approved as part of the
>>>     patch
>>>     > approval process.
>>>
>>>     I think that if there is a CSR sub-task in JBS skara can key off
>>>     whether
>>>     that is approved.
>>>     This does mean skara needs to probe JBS but SFAIK its doing that a
>>>     hundred times
>>>     a minute anyway.
>>>
>>>     -phil.
>>>
>>>     >
>>>     > Not sure how complicated it would be to implement.
>>>     >
>>>     > - Nir
>>>     >
>>>     > On Mon, Dec 16, 2019 at 5:39 PM Kevin
>>>     Rushforth<kevin.rushforth at oracle.com
>>>     <mailto:kevin.rushforth at oracle.com>>
>>>     > wrote:
>>>     >
>>>     >> That's a good question about whether we can ask for a slight
>>>     rewording
>>>     >> of the Skara bot message to indicate that there might be
>>>     other things to
>>>     >> check before "/integrate". I'll raise that question with the
>>>     Skara team.
>>>     >>
>>>     >> As an aside, I noticed the other day that you typed
>>>     "/integrate" after a
>>>     >> single review, but in that case, there was no clear
>>>     indication from Ajit
>>>     >> (the first reviewer and the sponsor) that a second review was
>>>     required,
>>>     >> so I didn't comment on it.
>>>     >>
>>>     >> -- Kevin
>>>     >>
>>>     >>
>>>     >> On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>>>     >>> Kevin,
>>>     >>>
>>>     >>> thanks for the clarification :) My bad that I didn't re-read the
>>>     >>> contrib.md. But then, who does? The lazy like myself do it
>>>     >>> occasionally only (down to once and then forget about it<g>)
>>>     >>>
>>>     >>> Maybe the bot message can be improved? With some indication
>>>     that its
>>>     >>> (the bot's) knowledge about review requirements is limited,
>>>     so would
>>>     >>> require a careful check by the contributor before actually
>>>     post the
>>>     >>> /integrate comment? Actually, I think I goofed the other
>>>     day, was
>>>     >>> safed only by Ajit who waited for the 2nd review before his
>>>     /sponsor.
>>>     >>>
>>>     >>> -- Jeanette
>>>     >>>
>>>     >>> Zitat von Kevin Rushforth<kevin.rushforth at oracle.com
>>>     <mailto:kevin.rushforth at oracle.com>>:
>>>     >>>
>>>     >>>> I added a comment to the two PRs in question, but it bears
>>>     discussion
>>>     >>>> here.
>>>     >>>>
>>>     >>>> The Skara bot can't know whether all criteria have been met. It
>>>     >>>> can't, for example, know whether there are outstanding
>>>     comments from
>>>     >>>> some reviewers that need to be addressed. Nor does it know
>>>     which PRs
>>>     >>>> need two reviewers (or sometimes a third if there is a specific
>>>     >>>> person we would like to review it), which ones need a CSR, etc.
>>>     >>>>
>>>     >>>> So having it state authoritatively that the PR is ready to
>>>     integrate
>>>     >>>> is a bit misleading. This is documented in the Code Review
>>>     section of
>>>     >>>> the CONTRIBUTING [1] doc:
>>>     >>>>
>>>     >>>>> NOTE: while the Skara tooling will indicate that the PR is
>>>     ready to
>>>     >>>>> integrate once the first reviewer with a "Reviewer" role
>>>     in the
>>>     >>>>> project has approved it, this may or may not be sufficient
>>>     depending
>>>     >>>>> on the type of fix. For example, you must wait for a
>>>     second approval
>>>     >>>>> for enhancements or high-impact bug fixes.
>>>     >>>> If anyone can think of a way to improve this and make it
>>>     more clear,
>>>     >>>> that would be helpful.
>>>     >>>>
>>>     >>>> -- Kevin
>>>     >>>>
>>>     >>>> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>>>     >>>>
>>>     >>>>
>>>     >>>> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>>>     >>>>> Looks like it assumes a pull request as properly reviewed
>>>     as soon as
>>>     >>>>> it gets a single approve - independent on how many
>>>     reviewers are
>>>     >>>>> required, see f.i.
>>>     >>>>>
>>>     >>>>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>>>     >>>>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>>     >>>>>
>>>     >>>>> -- Jeanette
>>>     >>>>>
>>>     >>>
>>>     >>>
>>>     >>
>>>
>>


From David.Grieve at microsoft.com  Thu Dec 19 18:24:49 2019
From: David.Grieve at microsoft.com (David Grieve)
Date: Thu, 19 Dec 2019 18:24:49 +0000
Subject: apps/toys HelloTextFlow renders incorrectly on macOS 10.15
Message-ID: <BN8PR21MB128132CDF7886D71F832F07E9B520@BN8PR21MB1281.namprd21.prod.outlook.com>

Because the toy itself handles the highlighting, I believe this is a problem in the toy, not in the library.

From kcr at openjdk.java.net  Thu Dec 19 18:58:27 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 19 Dec 2019 18:58:27 GMT
Subject: RFR: 8234474: [macos 10.15] Crash in file dialog in sandbox mode
Message-ID: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>

This PR is a fix for [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474), a crash in the code that shows a file open or save dialog.

In order to provide additional support for Copy (CMD-C), Cut (CMD-X), and Paste (CMD-V), the Glass implementation for displaying a file open or save dialog subclasses NSSavePanel or NSOpenPanel to add this support. When the application is running in sandboxed mode, the dialogs are shown out-of-process by the "powerbox". In this mode, attempting to use our subclass results in a security exception. Previously, we added code to detect whether we were running in a sandbox as a fix for [JDK-8092977](https://bugs.openjdk.java.net/browse/JDK-8092977); we now use NSSavePanel or NSOpenPanel directly when in sandboxed mode.

Starting with macOS 10.15 (Catalina) Apple always displays file dialogs out-of-process via powerbox, so our use of a subclass is ineffective. Further, we have reports of some cases where we crash even though our sandbox detection code doesn't indicate that we are running in a sandbox.

Since there is no point in trying to use our subclasses on macOS 10.15 or later, I propose to fix this bug by changing the logic so that we use NSSavePanel or NSOpenPanel directly in either of the following conditions:

1) the app is running in sandbox mode
OR
2) The platform is macOS 10.15 or later

-------------

Commits:
 - dca394e6: 8234474: [macos 10.15] Crash in file dialog in sandbox mode on macOS Catalina

Changes: https://git.openjdk.java.net/jfx/pull/70/files
 Webrev: https://webrevs.openjdk.java.net/jfx/70/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234474
  Stats: 22 lines in 1 file changed: 18 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/70.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/70/head:pull/70

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

From kcr at openjdk.java.net  Thu Dec 19 19:00:56 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 19 Dec 2019 19:00:56 GMT
Subject: RFR: 8234474: [macos 10.15] Crash in file dialog in sandbox mode
In-Reply-To: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
References: <EVQvT9DIMHzAdLwtEWrtUdr4TdfZIbodfsqZb0hH77o=.e888686d-4e00-4e14-b0b1-a94559ab7ad0@github.com>
Message-ID: <iz890WfnpJaYY0CNtHsnMYV8M1bg7EFxHgifZqS4TnI=.ff3698ad-579f-46bb-b4b7-811a14a14ee1@github.com>

On Thu, 19 Dec 2019 00:08:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR is a fix for [JDK-8234474](https://bugs.openjdk.java.net/browse/JDK-8234474), a crash in the code that shows a file open or save dialog.
> 
> In order to provide additional support for Copy (CMD-C), Cut (CMD-X), and Paste (CMD-V), the Glass implementation for displaying a file open or save dialog subclasses NSSavePanel or NSOpenPanel to add this support. When the application is running in sandboxed mode, the dialogs are shown out-of-process by the "powerbox". In this mode, attempting to use our subclass results in a security exception. Previously, we added code to detect whether we were running in a sandbox as a fix for [JDK-8092977](https://bugs.openjdk.java.net/browse/JDK-8092977); we now use NSSavePanel or NSOpenPanel directly when in sandboxed mode.
> 
> Starting with macOS 10.15 (Catalina) Apple always displays file dialogs out-of-process via powerbox, so our use of a subclass is ineffective. Further, we have reports of some cases where we crash even though our sandbox detection code doesn't indicate that we are running in a sandbox.
> 
> Since there is no point in trying to use our subclasses on macOS 10.15 or later, I propose to fix this bug by changing the logic so that we use NSSavePanel or NSOpenPanel directly in either of the following conditions:
> 
> 1) the app is running in sandbox mode
> OR
> 2) The platform is macOS 10.15 or later

This will need two reviewers.

@arapte I'd like you to be one of the reviewers.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Thu Dec 19 19:02:32 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 19 Dec 2019 19:02:32 GMT
Subject: RFR: 8235627: Fixed blank stage when running in macOS guest VM
Message-ID: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>

https://bugs.openjdk.java.net/browse/JDK-8235627

-------------

Commits:
 - 73523680: 8235627: Fixed blank stage when running in macOS guest VM

Changes: https://git.openjdk.java.net/jfx/pull/65/files
 Webrev: https://webrevs.openjdk.java.net/jfx/65/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8235627
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/65.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/65/head:pull/65

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

From kcr at openjdk.java.net  Thu Dec 19 19:17:43 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 19 Dec 2019 19:17:43 GMT
Subject: RFR: 8235627: Fixed blank stage when running in macOS guest VM
In-Reply-To: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
Message-ID: <QiyVoBJK_GQy44J3Xe5m-GSq64D_zLlEX8vxaC9sWW0=.222d0a59-78bf-4321-8439-44f171b4c2e8@github.com>

On Tue, 10 Dec 2019 13:12:37 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8235627

While this looks simple enough, I will also request @arapte to review this, in addition to reviewing it myself.

-------------

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

From kcr at openjdk.java.net  Thu Dec 19 19:24:03 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 19 Dec 2019 19:24:03 GMT
Subject: RFR: 8235627: Fixed blank stage when running in macOS guest VM
In-Reply-To: <QiyVoBJK_GQy44J3Xe5m-GSq64D_zLlEX8vxaC9sWW0=.222d0a59-78bf-4321-8439-44f171b4c2e8@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <QiyVoBJK_GQy44J3Xe5m-GSq64D_zLlEX8vxaC9sWW0=.222d0a59-78bf-4321-8439-44f171b4c2e8@github.com>
Message-ID: <oPJrC6zRWrLUbAJeIMld7fBym0fTUEHY05gimjMHizE=.c590b1b9-a420-4f33-91b3-5613b4946875@github.com>

On Thu, 19 Dec 2019 19:17:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8235627
> 
> While this looks simple enough, I will also request @arapte to review this, in addition to reviewing it myself.

The fix looks fine to me, but I want to run a couple quick tests.

@fthevenet Please change the title of this PR to exactly match the title of the JBS bug (meaning that you should remove the word "Fixed").

-------------

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

From dgrieve at openjdk.java.net  Thu Dec 19 19:28:34 2019
From: dgrieve at openjdk.java.net (David Grieve)
Date: Thu, 19 Dec 2019 19:28:34 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
Message-ID: <OtCpicgZS8WfcpxFV8LWaP8lWr1PEaYnlrguXKXQOQA=.d49797db-89c9-41d3-875a-ae6ed7b5ccae@github.com>

On Thu, 19 Dec 2019 19:28:34 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Hi everyone,
>> 
>> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259
>> 
>> The fix itself is quite straight forward.
>> It basically just removed the listener which causes the leak.
>> 
>> The unit-test for the fix is a bit more complicated.
>> 
>> I added a library JMemoryBuddy https://github.com/Sandec/JMemoryBuddy (written by myself), which simplifies testing for memory leaks.
>> I think there are many places in the JavaFX-codebase that could highly benefit from this library.
>> It could also simplify many of the already existing unit tests.
>> It makes testing for memory-leaks readably and reliable. 
>> It would also be possible to just copy the code of the library into the JavaFX-codebase. 
>> It only contains a single class.
>> 
>> I also had to make a method public, to write the test. I'm open to ideas, how I could solve it differently.
> 
> The pull request has been updated with 1 additional commit.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ProgressIndicatorSkinTest.java line 106:

> 105:             Node detIndicator = indicator.getChildrenUnmodifiable().get(0);
> 106:             System.out.println(detIndicator.getClass().getSimpleName());
> 107:             checker.assertCollectable(detIndicator);

remove

-------------

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

From David.Grieve at microsoft.com  Thu Dec 19 19:47:19 2019
From: David.Grieve at microsoft.com (David Grieve)
Date: Thu, 19 Dec 2019 19:47:19 +0000
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
Message-ID: <BN8PR21MB12816A3CC51530E199823F609B520@BN8PR21MB1281.namprd21.prod.outlook.com>

Github failed me. My 'remove' comment was applied to the System.out.println, not the assert. 

> -----Original Message-----
> From: openjfx-dev <openjfx-dev-bounces at openjdk.java.net> On Behalf Of
> David Grieve
> Sent: Thursday, December 19, 2019 2:29 PM
> To: openjfx-dev at openjdk.java.net
> Subject: [EXTERNAL] Re: [Rev 01] RFR: 8236259: MemoryLeak in
> ProgressIndicator
> 
> On Thu, 19 Dec 2019 19:28:34 GMT, Florian Kirmaier
> <fkirmaier at openjdk.org> wrote:
> 
> >> Hi everyone,
> >>
> >> ticket:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
> .openjdk.java.net%2Fbrowse%2FJDK-
> 8236259&amp;data=02%7C01%7CDavid.Grieve%40microsoft.com%7C856e05
> 0ee1bf484a7a7008d784b9dde4%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C0%7C637123806135627853&amp;sdata=yMuZMaBg7UmJEWzn8AGI6K8f5
> aRmFclOi4nov%2BLas%2BM%3D&amp;reserved=0
> >>
> >> The fix itself is quite straight forward.
> >> It basically just removed the listener which causes the leak.
> >>
> >> The unit-test for the fix is a bit more complicated.
> >>
> >> I added a library JMemoryBuddy
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FSandec%2FJMemoryBuddy&amp;data=02%7C01%7CDavid.Griev
> e%40microsoft.com%7C856e050ee1bf484a7a7008d784b9dde4%7C72f988bf8
> 6f141af91ab2d7cd011db47%7C1%7C0%7C637123806135627853&amp;sdata=6
> a1cOZEa9Ah%2F47NyvrRetz9YZyTgXhoJ1b13re8SZw8%3D&amp;reserved=0
> (written by myself), which simplifies testing for memory leaks.
> >> I think there are many places in the JavaFX-codebase that could highly
> benefit from this library.
> >> It could also simplify many of the already existing unit tests.
> >> It makes testing for memory-leaks readably and reliable.
> >> It would also be possible to just copy the code of the library into the
> JavaFX-codebase.
> >> It only contains a single class.
> >>
> >> I also had to make a method public, to write the test. I'm open to ideas,
> how I could solve it differently.
> >
> > The pull request has been updated with 1 additional commit.
> 
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/Progr
> essIndicatorSkinTest.java line 106:
> 
> > 105:             Node detIndicator = indicator.getChildrenUnmodifiable().get(0);
> > 106:             System.out.println(detIndicator.getClass().getSimpleName());
> > 107:             checker.assertCollectable(detIndicator);
> 
> remove
> 
> -------------
> 
> PR:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.o
> penjdk.java.net%2Fjfx%2Fpull%2F71&amp;data=02%7C01%7CDavid.Grieve%
> 40microsoft.com%7C856e050ee1bf484a7a7008d784b9dde4%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637123806135627853&amp;sdata=ATF
> nmAXAw0x0ENGrqp%2Fde8fEuIg7mrQrYZmXn4gLnug%3D&amp;reserved=0

From dgrieve at openjdk.java.net  Thu Dec 19 19:59:26 2019
From: dgrieve at openjdk.java.net (David Grieve)
Date: Thu, 19 Dec 2019 19:59:26 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
 <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
 <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>
 <BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com>
Message-ID: <CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com>

On Thu, 19 Dec 2019 16:16:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> probably not  invented so often - just c&p'd from searches of occurances of System.gc ;-)
> 
> Yes, exactly.
> 
> @FlorianKirmaier Proposing to add test class to the test infrastructure would be a reasonable alternative to pulling it in as a third-party dependency. I recommend separating it out into its own enhancement, with a separate JBS issue. I see that it has a dependency on the `jdk.management` module. As long as that dependency only surfaces as a test dependency, that won't be a problem. It would be nice if it were available to all modules, meaning that putting it somewhere in `javafx.base` would be good.

I would urge caution about incorporating JMemoryBuddy without seeking out advice from GC experts. I have my doubts that it will work reliably given its reliance on System.gc(). (Opinion is my own, not my employer's).

-------------

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

From tsayao at openjdk.java.net  Thu Dec 19 20:24:37 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 19 Dec 2019 20:24:37 GMT
Subject: [Rev 02] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <VgrHtRd1w5OiKYqfDjeBk8Wh1GlWXsvGnhQkID3WHos=.3ca0973b-87ff-45b9-98cd-d84d18b14b27@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
 <VgrHtRd1w5OiKYqfDjeBk8Wh1GlWXsvGnhQkID3WHos=.3ca0973b-87ff-45b9-98cd-d84d18b14b27@github.com>
Message-ID: <jJ479Db8jF0DVcqALIN_6fHIwEXx4CQ5wSQedmC9R7I=.3046f98c-5674-4c65-9929-a3a825c12ce6@github.com>

On Thu, 19 Dec 2019 14:29:39 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1062:
> 
>> 1061:         geometry.final_height.type = BOUNDSTYPE_CONTENT;
>> 1062:     }
>> 1063: 
> 
> So now `geometry.final_width.value` and `geometry.final_height.value` will be set after the `Dialog `is displayed on screen.
> Does this mean that, the `Dialog` will be resized after it is displayed ? I did not observe any size change visually.
> 
> An observation unrelated to this change: `Dialog` changes it's position after being displayed. It can not be observed always, but is very frequent. Should be easy to observe it on a slow machine.
> On the same machine, I did not observe any size change though.

No, it will be set on set_bounds(). This will just update de final value after show() / map.

-------------

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

From tsayao at openjdk.java.net  Thu Dec 19 20:34:10 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 19 Dec 2019 20:34:10 GMT
Subject: [Rev 03] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
Message-ID: <Tbq2LkhQdqOAxjklFu3gRF3-HAdCOHSOvfRwWRTzDmo=.965a915c-310f-4c25-855a-4fbdc34f41e1@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8232811
> 
> This one was hard to tackle.
> 
> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest

The pull request has been updated with 2 additional commits.

-------------

Added commits:
 - 1d40aa9f: Merge remote-tracking branch 'origin/fix_jdk_8232811' into fix_jdk_8232811
 - f97833db: Did requested changes.

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/63/files
  - new: https://git.openjdk.java.net/jfx/pull/63/files/7b723c3b..1d40aa9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/63/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/63/webrev.02-03

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

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

From tsayao at openjdk.java.net  Thu Dec 19 20:34:25 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 19 Dec 2019 20:34:25 GMT
Subject: [Rev 02] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <zumT4t2DP62BXmKXtvE5r697Hb5gQt12STEUS-iFkXY=.e403c4be-8ffd-4dfb-bfbf-984463643ab4@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
 <zumT4t2DP62BXmKXtvE5r697Hb5gQt12STEUS-iFkXY=.e403c4be-8ffd-4dfb-bfbf-984463643ab4@github.com>
Message-ID: <Q5uSIhBuwcMrcGUPhQNm5t6HYrC4g78JXBYkPsKrROM=.a1302d8b-8efe-4d4b-81bf-b7f2ee973ed1@github.com>

On Tue, 17 Dec 2019 23:01:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 124:
> 
>> 123: 
>> 124:             stage.initStyle(StageStyle.UNDECORATED);
>> 125:             stage.setOnShown(e -> Platform.runLater(startupLatch::countDown));
> 
> Since this is a Robot test that relies on the Stage being in front of other windows, can you add the following?
> 
>     stage.setAlwaysOnTop(true);

ok

-------------

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

From tsayao at openjdk.java.net  Thu Dec 19 20:34:54 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 19 Dec 2019 20:34:54 GMT
Subject: [Rev 02] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <VgrHtRd1w5OiKYqfDjeBk8Wh1GlWXsvGnhQkID3WHos=.3ca0973b-87ff-45b9-98cd-d84d18b14b27@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
 <VgrHtRd1w5OiKYqfDjeBk8Wh1GlWXsvGnhQkID3WHos=.3ca0973b-87ff-45b9-98cd-d84d18b14b27@github.com>
Message-ID: <-AXwSJsqO8pf0P4_qUcGqtfKJqcBd1lqbfxjxKXMiSE=.776b89b5-5bf3-4528-80b1-f3a1f0ff6828@github.com>

On Thu, 19 Dec 2019 14:13:47 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 64:
> 
>> 63:     public void dialogWithOwnerSizingTest() throws Exception {
>> 64:         Thread.sleep(500);
>> 65:         clickButton();
> 
> This `sleep()` can be removed.

Removed it, but the test failed.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Thu Dec 19 20:35:35 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Thu, 19 Dec 2019 20:35:35 GMT
Subject: RFR: 8088198: Exception thrown from snapshot if dimensions are larger
 than max texture size
Message-ID: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>

This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size

In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
Other than that, the logic used to do the actual snapshot is unchanged.

Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"

-------------

Commits:
 - 4bc44173: 8088198: Exception thrown from snapshot if dimensions are larger than max texture size

Changes: https://git.openjdk.java.net/jfx/pull/68/files
 Webrev: https://webrevs.openjdk.java.net/jfx/68/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8088198
  Stats: 142 lines in 2 files changed: 111 ins; 11 del; 20 mod
  Patch: https://git.openjdk.java.net/jfx/pull/68.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/68/head:pull/68

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

From tsayao at openjdk.java.net  Thu Dec 19 20:36:15 2019
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Thu, 19 Dec 2019 20:36:15 GMT
Subject: [Rev 02] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <1fpPz0revVBK7SKsGQh9T7hkoXSFc2xXLBlDtsYW8f4=.863e828b-17d3-40e8-93c0-d6c99830573d@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <T1DWYG3V20aR8_VSe0bQph5QNxKcGn9Er-6EO45BIwg=.2490bebd-e2c9-4f94-aaf1-f3a99cb95d6c@github.com>
 <1fpPz0revVBK7SKsGQh9T7hkoXSFc2xXLBlDtsYW8f4=.863e828b-17d3-40e8-93c0-d6c99830573d@github.com>
Message-ID: <uSLZukPfBYcgpAqvJ0JlAfrVAr51WQjy-L3hVEMXDV4=.3e9cb31c-cc4e-4d65-8e4d-5d741e2e0f1c@github.com>

On Tue, 17 Dec 2019 21:37:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> tests/system/src/test/java/test/robot/javafx/scene/dialog/DialogWithOwnerSizingTest.java line 63:
> 
>> 62:     @Test(timeout = 15000)
>> 63:     public void dialogWithOwnerSizingTest() throws Exception {
>> 64:         Thread.sleep(500);
> 
> This test fails on Windows 10 with 125% screen scaling. The size of the two dialogs are not exactly the same: 181.6 vs 180.0. I recommend either excluding the test or else adding a 2 pixel tolerance if the DPI scaling factor is non-integral.

Added 2 pixels tolerance.

-------------

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

From kevin.rushforth at oracle.com  Thu Dec 19 22:09:12 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 19 Dec 2019 14:09:12 -0800
Subject: Difference in CSS styling / rendering.
In-Reply-To: <998C7A66-E1CD-4EB1-B6B0-7AF65E291D3E@gmail.com>
References: <998C7A66-E1CD-4EB1-B6B0-7AF65E291D3E@gmail.com>
Message-ID: <6b6497ea-f98c-9b86-254e-344a36fab595@oracle.com>

Hi Dirk,

Any update on this? We'd love to take a look at it if you have a test case.

Thanks.

-- Kevin


On 12/9/2019 1:13 PM, Dirk Lemmermann wrote:
> Hi,
>
> I just noticed that the timeline in FlexGanttFX does not get rendered correctly anymore after updating to 14-ea+4. The borders around the date cells disappeared.
>
> I assume that this must be somehow related to the CSS fix that made it into this version.
>
> This is just a heads-up. If possible I will try to create a standalone example for this issue, but considering the complexity of this control it might be difficult to do so.
>
> Dirk
>
>


From fkirmaier at openjdk.java.net  Thu Dec 19 22:23:14 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 19 Dec 2019 22:23:14 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
 <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
 <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>
 <BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com>
 <CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com>
Message-ID: <iZcprNjnyi8ygmRJ2GnIKr33hu7ngVQMGyOQx2czDKU=.7fd85466-633c-4f56-a8e5-82096ce43563@github.com>

On Thu, 19 Dec 2019 19:59:07 GMT, David Grieve <dgrieve at openjdk.org> wrote:

>> Yes, exactly.
>> 
>> @FlorianKirmaier Proposing to add test class to the test infrastructure would be a reasonable alternative to pulling it in as a third-party dependency. I recommend separating it out into its own enhancement, with a separate JBS issue. I see that it has a dependency on the `jdk.management` module. As long as that dependency only surfaces as a test dependency, that won't be a problem. It would be nice if it were available to all modules, meaning that putting it somewhere in `javafx.base` would be good.
> 
> I would urge caution about incorporating JMemoryBuddy without seeking out advice from GC experts. I have my doubts that it will work reliably given its reliance on System.gc(). (Opinion is my own, not my employer's).

@dsgrieve 
It's worth mentioning that JavaFX already has many tests based on System.gc().
An advantage of having a testsuit as an library (or copyied from an library) is, that its stability is regulary verified by the travis builds for different JVMs.
The alternative would be to not test for memory-leaks at all which is much worse than having slightly unstable tests.
Maybe it can make sense to seperate these tests for leaks in an own testgroup.

I'm introducing this library in more and more projects. I never had problems with unstable tests. 
I only had this kind of problem when I wrote the WeakReference/System.gc/sleep-logic for every single test.

-------------

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

From kcr at openjdk.java.net  Thu Dec 19 22:48:29 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 19 Dec 2019 22:48:29 GMT
Subject: RFR: 8235364: Update copyright header for files modified in 2019
Message-ID: <g7pTcpYr4XPTLDCx4GmuDh3rBi-uq5865I9UHqzZNiI=.045081aa-9a71-4307-9d3c-ef4f225e5986@github.com>

Update the last-modified year in the copyright header to 2019 for files that were modified this year without updating the year in the copyright header.

-------------

Commits:
 - 9c6e0a64: 8235364: Update copyright header for files modified in 2019

Changes: https://git.openjdk.java.net/jfx/pull/72/files
 Webrev: https://webrevs.openjdk.java.net/jfx/72/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8235364
  Stats: 73 lines in 73 files changed: 0 ins; 0 del; 73 mod
  Patch: https://git.openjdk.java.net/jfx/pull/72.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/72/head:pull/72

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

From kcr at openjdk.java.net  Thu Dec 19 22:48:29 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 19 Dec 2019 22:48:29 GMT
Subject: RFR: 8235364: Update copyright header for files modified in 2019
In-Reply-To: <g7pTcpYr4XPTLDCx4GmuDh3rBi-uq5865I9UHqzZNiI=.045081aa-9a71-4307-9d3c-ef4f225e5986@github.com>
References: <g7pTcpYr4XPTLDCx4GmuDh3rBi-uq5865I9UHqzZNiI=.045081aa-9a71-4307-9d3c-ef4f225e5986@github.com>
Message-ID: <auoAC3l5j5k2VDj-t8yPkcn0uysPFTr_SDvK2m7_3Y8=.2abcff5d-559e-4ee2-bebb-1c17c9808aa9@github.com>

On Thu, 19 Dec 2019 22:47:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Update the last-modified year in the copyright header to 2019 for files that were modified this year without updating the year in the copyright header.

Reviewer: @arapte

(this only needs a single reviewer)

-------------

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

From kcr at openjdk.java.net  Fri Dec 20 00:19:54 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 00:19:54 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <xgODDca7_fUTwoCuCtUg8GyweKSXSlWxmJSwwkCJ0XU=.411c1cc3-6e7f-49d1-b758-97626985d3a2@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
 <xgODDca7_fUTwoCuCtUg8GyweKSXSlWxmJSwwkCJ0XU=.411c1cc3-6e7f-49d1-b758-97626985d3a2@github.com>
Message-ID: <QuWhUkchaPYKRpQuMZBloLgKvu5_ZE0TUOQzXwAL8Vc=.094fe714-503f-48cd-be44-4e5d30fc40da@github.com>

On Thu, 19 Dec 2019 13:48:11 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>>
> 
> I was thinking of deferring the `apps/toys` demo to avoid any delays in getting the new API into JavaFX 14.  I have something for it, I just don't want any feedback on it to hold up the review of this issue. Is there anything else I need to do?  Is the CSR in good shape?

I agree that that addition of a demo program in `apps/toys` can be decoupled from this. Please file a follow-up issue for this.

I reviewed the CSR. It looks ready to go.

In addition to an approved CSR, both @prrace and I will need to review this PR.

-------------

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

From ebresiedev at gmail.com  Fri Dec 20 03:44:45 2019
From: ebresiedev at gmail.com (Eric Bresie)
Date: Thu, 19 Dec 2019 21:44:45 -0600
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: iZcprNjnyi8ygmRJ2GnIKr33hu7ngVQMGyOQx2czDKU=.7fd85466-633c-4f56-a8e5-82096ce43563@github.com
References: 4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com
 mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com
 ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com
 qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com
 O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com
 OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com
 pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com
 4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com
 BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com
 CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com
 CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com
Message-ID: <895c1f67-df85-4a5c-b772-c7c67c050ef4@Erics-iPhone-X>

Would it just be better to run some code analysis tools on the code base to hunt for these? Like maybe sonarqube integratedas part of CI build analysis?

Eric Bresie
Ebresie at gmail.com
> On December 19, 2019 at 4:23:14 PM CST, Florian Kirmaier <fkirmaier at openjdk.java.net> wrote:
> On Thu, 19 Dec 2019 19:59:07 GMT, David Grieve <dgrieve at openjdk.org> wrote:
>
> > > Yes, exactly.
> > >
> > > @FlorianKirmaier Proposing to add test class to the test infrastructure would be a reasonable alternative to pulling it in as a third-party dependency. I recommend separating it out into its own enhancement, with a separate JBS issue. I see that it has a dependency on the `jdk.management` module. As long as that dependency only surfaces as a test dependency, that won't be a problem. It would be nice if it were available to all modules, meaning that putting it somewhere in `javafx.base` would be good.
> >
> > I would urge caution about incorporating JMemoryBuddy without seeking out advice from GC experts. I have my doubts that it will work reliably given its reliance on System.gc(). (Opinion is my own, not my employer's).
>
> @dsgrieve
> It's worth mentioning that JavaFX already has many tests based on System.gc().
> An advantage of having a testsuit as an library (or copyied from an library) is, that its stability is regulary verified by the travis builds for different JVMs.
> The alternative would be to not test for memory-leaks at all which is much worse than having slightly unstable tests.
> Maybe it can make sense to seperate these tests for leaks in an own testgroup.
>
> I'm introducing this library in more and more projects. I never had problems with unstable tests.
> I only had this kind of problem when I wrote the WeakReference/System.gc/sleep-logic for every single test.
>
> -------------
>
> PR: https://git.openjdk.java.net/jfx/pull/71

From fkirmaier at openjdk.java.net  Fri Dec 20 09:54:09 2019
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Fri, 20 Dec 2019 09:54:09 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <iZcprNjnyi8ygmRJ2GnIKr33hu7ngVQMGyOQx2czDKU=.7fd85466-633c-4f56-a8e5-82096ce43563@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
 <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
 <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>
 <BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com>
 <CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com>
 <iZcprNjnyi8ygmRJ2GnIKr33hu7ngVQMGyO
 Qx2czDKU=.7fd85466-633c-4f56-a8e5-82096ce43563@github.com>
Message-ID: <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com>

On Thu, 19 Dec 2019 22:22:55 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> I would urge caution about incorporating JMemoryBuddy without seeking out advice from GC experts. I have my doubts that it will work reliably given its reliance on System.gc(). (Opinion is my own, not my employer's).
> 
> @dsgrieve 
> It's worth mentioning that JavaFX already has many tests based on System.gc().
> An advantage of having a testsuit as an library (or copyied from an library) is, that its stability is regulary verified by the travis builds for different JVMs.
> The alternative would be to not test for memory-leaks at all which is much worse than having slightly unstable tests.
> Maybe it can make sense to seperate these tests for leaks in an own testgroup.
> 
> I'm introducing this library in more and more projects. I never had problems with unstable tests. 
> I only had this kind of problem when I wrote the WeakReference/System.gc/sleep-logic for every single test.

I highly doubt that a code analysis tool will find such memoryleaks.

-------------

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

From arapte at openjdk.java.net  Fri Dec 20 10:02:26 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 20 Dec 2019 10:02:26 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
Message-ID: <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>

On Tue, 10 Dec 2019 13:12:37 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8235627

As mentioned in the description of [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627), following error is printed 
CGLChoosePixelFormat error: 10002

According to the documentation at [CGL Error Codes](http://mirror.informatimago.com/next/developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL/chap5/chapter_5_section_41.html#//apple_ref/doc/uid/TP30000136/BDJHHIDE)

10002 is kCGLBadPixelFormat, which means Invalid pixel format object.
This does not seem to be an error code that should be returned by `CGLChoosePixelFormat`.
However the doc is very old, last updated on 2002-08-01.

Irrelevant to this doc the idea of this fix looks good.

modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m line 97:

> 96:         if (pix == NULL)
> 97:         {
> 98:             const CGLPixelFormatAttribute attributes2[] =

The change looks good.
I would suggest to print a message inside the if block, mentioning that the first attempt to create a pixel format object has failed and second attempt is being made with minimal attributes.
Also please use `CGLErrorString(err)`  when printing the error message.

-------------

Changes requested by arapte (Reviewer).

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

From arapte at openjdk.java.net  Fri Dec 20 10:02:27 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 20 Dec 2019 10:02:27 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
Message-ID: <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>

On Fri, 20 Dec 2019 09:50:35 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8235627
> 
> modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m line 97:
> 
>> 96:         if (pix == NULL)
>> 97:         {
>> 98:             const CGLPixelFormatAttribute attributes2[] =
> 
> The change looks good.
> I would suggest to print a message inside the if block, mentioning that the first attempt to create a pixel format object has failed and second attempt is being made with minimal attributes.
> Also please use `CGLErrorString(err)`  when printing the error message.

Additionally the if condition at line 105 can be changed to match with the change. as,
`if (pix == NULL || err != kCGLNoError)`

-------------

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

From arapte at openjdk.java.net  Fri Dec 20 10:06:06 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 20 Dec 2019 10:06:06 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
Message-ID: <aqoIiTh7PEFyU12IH-hgrAOxoTBozP3iKnwzZHsF6Ew=.83429135-d51d-4362-ad81-e8d84fc2665f@github.com>

On Fri, 20 Dec 2019 10:02:16 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8235627
> 
> As mentioned in the description of [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627), following error is printed 
> CGLChoosePixelFormat error: 10002
> 
> According to the documentation at [CGL Error Codes](http://mirror.informatimago.com/next/developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL/chap5/chapter_5_section_41.html#//apple_ref/doc/uid/TP30000136/BDJHHIDE)
> 
> 10002 is kCGLBadPixelFormat, which means Invalid pixel format object.
> This does not seem to be an error code that should be returned by `CGLChoosePixelFormat`.
> However the doc is very old, last updated on 2002-08-01.
> 
> Irrelevant to this doc the idea of this fix looks good.

Hi fthevenet,
The basic idea of fix looks good to me. You have reported this bug with a very good detailed description. Can you please update the PR description also with same or sufficient information.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Dec 20 10:23:47 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 20 Dec 2019 10:23:47 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>
Message-ID: <IRyZ6qdFsE7q1o6sX9zCJvq-dbzoBR4kvCPXaeHtLFM=.6ce8a194-7679-4745-9e90-b0e0e46f7bd6@github.com>

On Fri, 20 Dec 2019 09:55:18 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m line 97:
>> 
>>> 96:         if (pix == NULL)
>>> 97:         {
>>> 98:             const CGLPixelFormatAttribute attributes2[] =
>> 
>> The change looks good.
>> I would suggest to print a message inside the if block, mentioning that the first attempt to create a pixel format object has failed and second attempt is being made with minimal attributes.
>> Also please use `CGLErrorString(err)`  when printing the error message.
> 
> Additionally the if condition at line 105 can be changed to match with the change. as,
> `if (pix == NULL || err != kCGLNoError)`

Could you please be more specific on why you suggest the check be expended with  `|| err != kCGLNoError`?
I see no harm in adding it but it feels like an unnecessary condition to me; my understanding of the current [documentation](https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html) (though the use of the API itself is deprecated by Apple) has me understand than `pix == NULL` is both a necessary and sufficient test.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Dec 20 10:31:45 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 20 Dec 2019 10:31:45 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <aqoIiTh7PEFyU12IH-hgrAOxoTBozP3iKnwzZHsF6Ew=.83429135-d51d-4362-ad81-e8d84fc2665f@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <aqoIiTh7PEFyU12IH-hgrAOxoTBozP3iKnwzZHsF6Ew=.83429135-d51d-4362-ad81-e8d84fc2665f@github.com>
Message-ID: <JGGx-ZS28d9zJEoDSu1NfHFVlTSmjI7eZNcvSd6CosI=.d07e087f-db16-4ed9-a6ca-01f57321ab86@github.com>

On Fri, 20 Dec 2019 10:05:48 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> As mentioned in the description of [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627), following error is printed 
>> CGLChoosePixelFormat error: 10002
>> 
>> According to the documentation at [CGL Error Codes](http://mirror.informatimago.com/next/developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL/chap5/chapter_5_section_41.html#//apple_ref/doc/uid/TP30000136/BDJHHIDE)
>> 
>> 10002 is kCGLBadPixelFormat, which means Invalid pixel format object.
>> This does not seem to be an error code that should be returned by `CGLChoosePixelFormat`.
>> However the doc is very old, last updated on 2002-08-01.
>> 
>> Irrelevant to this doc the idea of this fix looks good.
> 
> Hi fthevenet,
> The basic idea of fix looks good to me. You have reported this bug with a very good detailed description. Can you please update the PR description also with same or sufficient information.

> Can you please update the PR description also with same or sufficient information.

I'm trying to do that but it seems the PR despcription gets reverted to its original from after I've edited it?
Any idea on what I'm doing wrong?

-------------

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

From thevenet.fred at free.fr  Fri Dec 20 10:39:35 2019
From: thevenet.fred at free.fr (thevenet.fred at free.fr)
Date: Fri, 20 Dec 2019 11:39:35 +0100 (CET)
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <JGGx-ZS28d9zJEoDSu1NfHFVlTSmjI7eZNcvSd6CosI=.d07e087f-db16-4ed9-a6ca-01f57321ab86@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <aqoIiTh7PEFyU12IH-hgrAOxoTBozP3iKnwzZHsF6Ew=.83429135-d51d-4362-ad81-e8d84fc2665f@github.com>
 <JGGx-ZS28d9zJEoDSu1NfHFVlTSmjI7eZNcvSd6CosI=.d07e087f-db16-4ed9-a6ca-01f57321ab86@github.com>
Message-ID: <683346774.1715506363.1576838375962.JavaMail.zimbra@free.fr>

Please ignore that; I just RTFM, its all good now ;)

----- Mail original -----
De: "Frederic Thevenet" <github.com+7450507+fthevenet at openjdk.java.net>
?: "openjfx-dev" <openjfx-dev at openjdk.java.net>
Envoy?: Vendredi 20 D?cembre 2019 11:31:45
Objet: Re: RFR: 8235627: Blank stages when running JavaFX app in a macOS virtual machine

On Fri, 20 Dec 2019 10:05:48 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> As mentioned in the description of [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627), following error is printed 
>> CGLChoosePixelFormat error: 10002
>> 
>> According to the documentation at [CGL Error Codes](http://mirror.informatimago.com/next/developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL/chap5/chapter_5_section_41.html#//apple_ref/doc/uid/TP30000136/BDJHHIDE)
>> 
>> 10002 is kCGLBadPixelFormat, which means Invalid pixel format object.
>> This does not seem to be an error code that should be returned by `CGLChoosePixelFormat`.
>> However the doc is very old, last updated on 2002-08-01.
>> 
>> Irrelevant to this doc the idea of this fix looks good.
> 
> Hi fthevenet,
> The basic idea of fix looks good to me. You have reported this bug with a very good detailed description. Can you please update the PR description also with same or sufficient information.

> Can you please update the PR description also with same or sufficient information.

I'm trying to do that but it seems the PR despcription gets reverted to its original from after I've edited it?
Any idea on what I'm doing wrong?

-------------

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

From arapte at openjdk.java.net  Fri Dec 20 13:13:55 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 20 Dec 2019 13:13:55 GMT
Subject: [Rev 03] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <Tbq2LkhQdqOAxjklFu3gRF3-HAdCOHSOvfRwWRTzDmo=.965a915c-310f-4c25-855a-4fbdc34f41e1@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <Tbq2LkhQdqOAxjklFu3gRF3-HAdCOHSOvfRwWRTzDmo=.965a915c-310f-4c25-855a-4fbdc34f41e1@github.com>
Message-ID: <TgOUsb9VjHHc4At1SqMmRkRY6E_CbhDBUAsiYsVqA0E=.c522b703-632f-4043-87f6-9ce878dfd7a5@github.com>

On Fri, 20 Dec 2019 13:13:55 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8232811
>> 
>> This one was hard to tackle.
>> 
>> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest
> 
> The pull request has been updated with 2 additional commits.

Looks good to me. Test passes on all three platforms.

-------------

Marked as reviewed by arapte (Reviewer).

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

From kcr at openjdk.java.net  Fri Dec 20 13:26:16 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 13:26:16 GMT
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
In-Reply-To: <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
 <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
 <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>
 <BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com>
 <CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com>
 <iZcprNjnyi8ygmRJ2GnIKr33hu7ngVQMGyO
 Qx2czDKU=.7fd85466-633c-4f56-a8e5-82096ce43563@github.com>
 <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com>
Message-ID: <xFY1R-O53_xFrJnVfvJdRFvMSTo7e3XxP02zZjGFvvM=.78597514-fb80-454b-a7ce-4e336e7bcc1f@github.com>

On Fri, 20 Dec 2019 09:53:56 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> @dsgrieve 
>> It's worth mentioning that JavaFX already has many tests based on System.gc().
>> An advantage of having a testsuit as an library (or copyied from an library) is, that its stability is regulary verified by the travis builds for different JVMs.
>> The alternative would be to not test for memory-leaks at all which is much worse than having slightly unstable tests.
>> Maybe it can make sense to seperate these tests for leaks in an own testgroup.
>> 
>> I'm introducing this library in more and more projects. I never had problems with unstable tests. 
>> I only had this kind of problem when I wrote the WeakReference/System.gc/sleep-logic for every single test.
> 
> I highly doubt that a code analysis tool will find such memoryleaks.

I agree. Static analysis tools are quite limited in this regard, and are in now way a substitute for regression testing.

So the question is how best to test fixes for memory leaks at runtime. Our current approach can be best characterized as "ad hoc", and is not all that robust (although works well enough in most cases and is still much better than doing no testing at all). I would welcome discussion of a more robust approach for testing, but it should be decoupled from this bug fix, and discussed as a separate JBS Enhancement request.

-------------

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

From arapte at openjdk.java.net  Fri Dec 20 13:36:24 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 20 Dec 2019 13:36:24 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <IRyZ6qdFsE7q1o6sX9zCJvq-dbzoBR4kvCPXaeHtLFM=.6ce8a194-7679-4745-9e90-b0e0e46f7bd6@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>
 <IRyZ6qdFsE7q1o6sX9zCJvq-dbzoBR4kvCPXaeHtLFM=.6ce8a194-7679-4745-9e90-b0e0e46f7bd6@github.com>
Message-ID: <gFlaKrGYE0N3HtEqRw4s0pxm63E54FZQ96jOylXq8eM=.3691aa48-5217-4e4b-9e64-441631380fc3@github.com>

On Fri, 20 Dec 2019 10:23:36 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> Additionally the if condition at line 105 can be changed to match with the change. as,
>> `if (pix == NULL || err != kCGLNoError)`
> 
> Could you please be more specific on why you suggest the check be expended with  `|| err != kCGLNoError`?
> I see no harm in adding it but it feels like an unnecessary condition to me; my understanding of the current [documentation](https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html) (though the use of the API itself is deprecated by Apple) has me understand than `pix == NULL` is both a necessary and sufficient test.

>From the documentation, the check `pix == NULL` seems sufficient, but the `err != kCGLNoError` was used before, so I just want to keep it safe. If the issue occurs without error getting printed it will be difficult to trace. As you observed the OpenGL is deprecated, so suspecting documentation may not be up to date. Also this [doc](https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/CGL_OpenGL/#//apple_ref/c/func/CGLChoosePixelFormat) was referred for fixing  [JDK-8154148](https://bugs.openjdk.java.net/browse/JDK-8154148), and is no longer available.
However I can't find any documentation to support this `err != kCGLNoError` check.

-------------

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

From kcr at openjdk.java.net  Fri Dec 20 13:50:25 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 13:50:25 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <gFlaKrGYE0N3HtEqRw4s0pxm63E54FZQ96jOylXq8eM=.3691aa48-5217-4e4b-9e64-441631380fc3@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>
 <IRyZ6qdFsE7q1o6sX9zCJvq-dbzoBR4kvCPXaeHtLFM=.6ce8a194-7679-4745-9e90-b0e0e46f7bd6@github.com>
 <gFlaKrGYE0N3HtEqRw4s0pxm63E54FZQ96jOylXq8eM=.3691aa48-5217-4e4b-9e64-441631380fc3@github.com>
Message-ID: <PnGjpC9I4JJoDmsFk9eWrBdJYXY5fWY_X6I-QCo8iw0=.4f67dad5-eb48-49d5-9a18-7fff2e61ba77@github.com>

On Fri, 20 Dec 2019 13:36:16 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Could you please be more specific on why you suggest the check be expended with  `|| err != kCGLNoError`?
>> I see no harm in adding it but it feels like an unnecessary condition to me; my understanding of the current [documentation](https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html) (though the use of the API itself is deprecated by Apple) has me understand than `pix == NULL` is both a necessary and sufficient test.
> 
> From the documentation, the check `pix == NULL` seems sufficient, but the `err != kCGLNoError` was used before, so I just want to keep it safe. If the issue occurs without error getting printed it will be difficult to trace. As you observed the OpenGL is deprecated, so suspecting documentation may not be up to date. Also this [doc](https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/CGL_OpenGL/#//apple_ref/c/func/CGLChoosePixelFormat) was referred for fixing  [JDK-8154148](https://bugs.openjdk.java.net/browse/JDK-8154148), and is no longer available.
> However I can't find any documentation to support this `err != kCGLNoError` check.

Actually, the existing check uses `err == kCGLNoError` which seems backwards (and likely is a big part of why this bug is happening). My recommendation is to not add in the check for `err != kCGLNoError`, and just use `if (pix == NULL)`.

The suggestion to add the print statement is a good one.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Dec 20 13:53:55 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 20 Dec 2019 13:53:55 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <PnGjpC9I4JJoDmsFk9eWrBdJYXY5fWY_X6I-QCo8iw0=.4f67dad5-eb48-49d5-9a18-7fff2e61ba77@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>
 <IRyZ6qdFsE7q1o6sX9zCJvq-dbzoBR4kvCPXaeHtLFM=.6ce8a194-7679-4745-9e90-b0e0e46f7bd6@github.com>
 <gFlaKrGYE0N3HtEqRw4s0pxm63E54FZQ96jOylXq8eM=.3691aa48-5217-4e4b-9e64-441631380fc3@github.com>
 <PnGjpC9I4JJoDmsFk9eWrBdJYXY5fWY_X6I-QCo8iw0=.4f67dad5-eb48-49d5-9a18-7fff2e61ba77@github.com>
Message-ID: <oHKgFrwUgGil11-BPLE4lON5aEm8and1s3MPek0Ifao=.7d2cdc47-34e1-4c5d-80df-48b77fcee8e9@github.com>

On Fri, 20 Dec 2019 13:50:16 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> From the documentation, the check `pix == NULL` seems sufficient, but the `err != kCGLNoError` was used before, so I just want to keep it safe. If the issue occurs without error getting printed it will be difficult to trace. As you observed the OpenGL is deprecated, so suspecting documentation may not be up to date. Also this [doc](https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/CGL_OpenGL/#//apple_ref/c/func/CGLChoosePixelFormat) was referred for fixing  [JDK-8154148](https://bugs.openjdk.java.net/browse/JDK-8154148), and is no longer available.
>> However I can't find any documentation to support this `err != kCGLNoError` check.
> 
> Actually, the existing check uses `err == kCGLNoError` which seems backwards (and likely is a big part of why this bug is happening). My recommendation is to not add in the check for `err != kCGLNoError`, and just use `if (pix == NULL)`.
> 
> The suggestion to add the print statement is a good one.

Actually, `err == kCGLNoError` was used before and not `err != kCGLNoError`  (i.e. equals and not different) and that is in fact the reason for the bug (in conjunction with the AND).
As you note, it's unfortunate that the link you mentioned is no longer valid as it would be very useful to understand the motivation behind the original fix in JDK-8154148, because it is indeed quite puzzling.

Please note that in any case a check on `err != kCGLNoError` is done just before the function returns and the error is logged if true.

-------------

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

From kcr at openjdk.java.net  Fri Dec 20 13:54:14 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 13:54:14 GMT
Subject: [Rev 03] RFR: 8232811: Dialog's preferred size no longer
 accommodates multi-line strings
In-Reply-To: <Tbq2LkhQdqOAxjklFu3gRF3-HAdCOHSOvfRwWRTzDmo=.965a915c-310f-4c25-855a-4fbdc34f41e1@github.com>
References: <eej1Za5d6c3kDlCi8Obx39tuAMg-hy5fh018hKfX07I=.db5f3bdb-d7a2-4940-a9fb-6e02a5eb20e6@github.com>
 <Tbq2LkhQdqOAxjklFu3gRF3-HAdCOHSOvfRwWRTzDmo=.965a915c-310f-4c25-855a-4fbdc34f41e1@github.com>
Message-ID: <6A7EJnUHKCuLh4m2zY5YoOTHsAfNpJfTss1K8_JBELE=.34aca62b-f58f-49c4-ba11-14dbec1e1b86@github.com>

On Fri, 20 Dec 2019 13:54:14 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8232811
>> 
>> This one was hard to tackle.
>> 
>> ./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.scene.dialog.DialogWithOwnerSizingTest
> 
> The pull request has been updated with 2 additional commits.

Looks good.

I can sponsor this fix.

-------------

Marked as reviewed by kcr (Lead).

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

From arapte at openjdk.java.net  Fri Dec 20 13:54:25 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 20 Dec 2019 13:54:25 GMT
Subject: RFR: 8235364: Update copyright header for files modified in 2019
In-Reply-To: <g7pTcpYr4XPTLDCx4GmuDh3rBi-uq5865I9UHqzZNiI=.045081aa-9a71-4307-9d3c-ef4f225e5986@github.com>
References: <g7pTcpYr4XPTLDCx4GmuDh3rBi-uq5865I9UHqzZNiI=.045081aa-9a71-4307-9d3c-ef4f225e5986@github.com>
Message-ID: <ENXTibwNRkb8G6HYlMe-2eahFrfltpUChF1PYJu-zY0=.dee4c8a3-4815-42e7-a9b1-847213a989e1@github.com>

On Thu, 19 Dec 2019 22:47:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Update the last-modified year in the copyright header to 2019 for files that were modified this year without updating the year in the copyright header.

The change looks good.

-------------

Marked as reviewed by arapte (Reviewer).

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

From kcr at openjdk.java.net  Fri Dec 20 14:01:55 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 14:01:55 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <oHKgFrwUgGil11-BPLE4lON5aEm8and1s3MPek0Ifao=.7d2cdc47-34e1-4c5d-80df-48b77fcee8e9@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>
 <IRyZ6qdFsE7q1o6sX9zCJvq-dbzoBR4kvCPXaeHtLFM=.6ce8a194-7679-4745-9e90-b0e0e46f7bd6@github.com>
 <gFlaKrGYE0N3HtEqRw4s0pxm63E54FZQ96jOylXq8eM=.3691aa48-5217-4e4b-9e64-441631380fc3@github.com>
 <PnGjpC9I4JJoDmsFk9eWrBdJYXY5fWY_X6I-QCo8iw0=.4f67dad5-eb48-49d5-9a18-7fff2e61ba77@github.com>
 <oHKgFrwUgGil11-BPLE4lON5aEm8and1s3MPek0Ifao=.7d2cdc47-34e1-4c5d-80df-48b77fcee8e9@github.com>
Message-ID: <rooFcydu1RzoEntQ3dU1lkcnqcVUXdenvWgyQtGRDtM=.9d9d55d2-11c7-419c-a478-a967bb8c4301@github.com>

On Fri, 20 Dec 2019 13:53:38 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> Actually, the existing check uses `err == kCGLNoError` which seems backwards (and likely is a big part of why this bug is happening). My recommendation is to not add in the check for `err != kCGLNoError`, and just use `if (pix == NULL)`.
>> 
>> The suggestion to add the print statement is a good one.
> 
> Actually, `err == kCGLNoError` was used before and not `err != kCGLNoError`  (i.e. equals and not different) and that is in fact the reason for the bug (in conjunction with the AND).
> As you note, it's unfortunate that the link you mentioned is no longer valid as it would be very useful to understand the motivation behind the original fix in JDK-8154148, because it is indeed quite puzzling.
> 
> Please note that in any case a check on `err != kCGLNoError` is done just before the function returns and the error is logged if true.

OK, so we're in agreement on the fix itself. Good.

The existing logging done right before the function returns will indeed log a complete failure to find a valid pixel format. It won't, however, log the fact that the initial attempt failed and we then try to use a fallback. It was this that @arapte asked to be logged. I agree with his request.

-------------

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

From arapte at openjdk.java.net  Fri Dec 20 14:03:16 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 20 Dec 2019 14:03:16 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <rooFcydu1RzoEntQ3dU1lkcnqcVUXdenvWgyQtGRDtM=.9d9d55d2-11c7-419c-a478-a967bb8c4301@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>
 <IRyZ6qdFsE7q1o6sX9zCJvq-dbzoBR4kvCPXaeHtLFM=.6ce8a194-7679-4745-9e90-b0e0e46f7bd6@github.com>
 <gFlaKrGYE0N3HtEqRw4s0pxm63E54FZQ96jOylXq8eM=.3691aa48-5217-4e4b-9e64-441631380fc3@github.com>
 <PnGjpC9I4JJoDmsFk9eWrBdJYXY5fWY_X6I-QCo8iw0=.4f67dad5-eb48-49d5-9a18-7fff2e61ba77@github.com>
 <oHKgFrwUgGil11-BPLE4lON5aEm8and1s3MPek0Ifao=.7d2cdc47-34e1-4c5d-80df-48b77fcee8e9@github.com>
 <rooFcydu1RzoEntQ3dU1lkcnqcVUXdenvWgyQtGRDtM=.9d9d55d2-11c7-419c-a478-a967bb8c4301@github.com>
Message-ID: <VoNew1_b0YL8P-Y1KwY878Du1KaAAn1Kc87EutcQjXo=.08a518c2-d0d9-49c0-8b20-0f7ac322cc9a@github.com>

On Fri, 20 Dec 2019 14:01:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Actually, `err == kCGLNoError` was used before and not `err != kCGLNoError`  (i.e. equals and not different) and that is in fact the reason for the bug (in conjunction with the AND).
>> As you note, it's unfortunate that the link you mentioned is no longer valid as it would be very useful to understand the motivation behind the original fix in JDK-8154148, because it is indeed quite puzzling.
>> 
>> Please note that in any case a check on `err != kCGLNoError` is done just before the function returns and the error is logged if true.
> 
> OK, so we're in agreement on the fix itself. Good.
> 
> The existing logging done right before the function returns will indeed log a complete failure to find a valid pixel format. It won't, however, log the fact that the initial attempt failed and we then try to use a fallback. It was this that @arapte asked to be logged. I agree with his request.

It looks good then, please update PR without `err != kCGLNoError`

-------------

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

From kcr at openjdk.java.net  Fri Dec 20 14:06:46 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 14:06:46 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <VoNew1_b0YL8P-Y1KwY878Du1KaAAn1Kc87EutcQjXo=.08a518c2-d0d9-49c0-8b20-0f7ac322cc9a@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>
 <IRyZ6qdFsE7q1o6sX9zCJvq-dbzoBR4kvCPXaeHtLFM=.6ce8a194-7679-4745-9e90-b0e0e46f7bd6@github.com>
 <gFlaKrGYE0N3HtEqRw4s0pxm63E54FZQ96jOylXq8eM=.3691aa48-5217-4e4b-9e64-441631380fc3@github.com>
 <PnGjpC9I4JJoDmsFk9eWrBdJYXY5fWY_X6I-QCo8iw0=.4f67dad5-eb48-49d5-9a18-7fff2e61ba77@github.com>
 <oHKgFrwUgGil11-BPLE4lON5aEm8and1s3MPek0Ifao=.7d2cdc47-34e1-4c5d-80df-48b77fcee8e9@github.com>
 <rooFcydu1RzoEntQ3dU1lkcnqcVUXdenvWgyQtGRDtM=.9d9d55d2-11c7-419c-a478-a967bb8c4301@github.com>
 <VoNew1_b0YL8P-Y1KwY878Du1KaAAn1Kc87EutcQjXo=.08a518c2-d0d9-49c0-8b20-0f7ac322cc9a@github.com>
Message-ID: <NwuuhxAJ9DcCDSuzOe___wgiz5ujel5-FS2OCKAa5ys=.10653e61-4c8d-4126-8c27-5f0ddfe6eac6@github.com>

On Fri, 20 Dec 2019 14:03:02 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> OK, so we're in agreement on the fix itself. Good.
>> 
>> The existing logging done right before the function returns will indeed log a complete failure to find a valid pixel format. It won't, however, log the fact that the initial attempt failed and we then try to use a fallback. It was this that @arapte asked to be logged. I agree with his request.
> 
> It looks good then, please update PR without `err != kCGLNoError`

Something like this, maybe?

    if (pix == NULL) {
        NSLog(@"CGLChoosePixelFormat: unable to find a pixel format, trying again with reduced capabilities");

The message could perhaps be improved, but something indicating we are using a fallback would be helpful.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Dec 20 14:15:25 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 20 Dec 2019 14:15:25 GMT
Subject: RFR: 8235627: Blank stages when running JavaFX app in a macOS
 virtual machine
In-Reply-To: <NwuuhxAJ9DcCDSuzOe___wgiz5ujel5-FS2OCKAa5ys=.10653e61-4c8d-4126-8c27-5f0ddfe6eac6@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <DiZVP52cdhHelxMQB0ED7c-0M06u226zEYF9qac0fA4=.88492741-64e5-4f66-8a8d-e8f17f820ad6@github.com>
 <IRyZ6qdFsE7q1o6sX9zCJvq-dbzoBR4kvCPXaeHtLFM=.6ce8a194-7679-4745-9e90-b0e0e46f7bd6@github.com>
 <gFlaKrGYE0N3HtEqRw4s0pxm63E54FZQ96jOylXq8eM=.3691aa48-5217-4e4b-9e64-441631380fc3@github.com>
 <PnGjpC9I4JJoDmsFk9eWrBdJYXY5fWY_X6I-QCo8iw0=.4f67dad5-eb48-49d5-9a18-7fff2e61ba77@github.com>
 <oHKgFrwUgGil11-BPLE4lON5aEm8and1s3MPek0Ifao=.7d2cdc47-34e1-4c5d-80df-48b77fcee8e9@github.com>
 <rooFcydu1RzoEntQ3dU1lkcnqcVUXdenvWgyQtGRDtM=.9d9d55d2-11c7-419c-a478-a967bb8c4301@github.com>
 <VoNew1_b0YL8P-Y1KwY878Du1KaAAn1Kc87EutcQjXo=.08a518c2-d0d9-49c0-8b20-0f7ac322cc9a@github.com>
 <NwuuhxAJ9DcCDSuzOe___wgiz5ujel5-FS2OCKAa5ys=.10653e61-4c8d-4126-8c27-5f0ddfe6eac6@github.com>
Message-ID: <SNjc3CNbINEehjDgJyvX3DSrpglFDAb6uLyQpc7vxFA=.625006d3-26bd-4dcb-97ab-5df977d5a5fc@github.com>

On Fri, 20 Dec 2019 14:06:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> It looks good then, please update PR without `err != kCGLNoError`
> 
> Something like this, maybe?
> 
>     if (pix == NULL) {
>         NSLog(@"CGLChoosePixelFormat: unable to find a pixel format, trying again with reduced capabilities");
> 
> The message could perhaps be improved, but something indicating we are using a fallback would be helpful.

> The existing logging done right before the function returns will indeed log a complete failure to find a valid pixel format. It won't, however, log the fact that the initial attempt failed and we then try to use a fallback. It was this that @arapte asked to be logged. I agree with his request.

Agreed. 
I suggest the printout only explains that we failed to get a pixel format object and we're about to try again but doesn't mention the returned error; since we don't check on its value, we could end up printing something like "Failed to do something very important[..] (Error: No error)", which would just be confusing IMO.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Dec 20 15:07:16 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 20 Dec 2019 15:07:16 GMT
Subject: [Rev 01] RFR: 8235627: Blank stages when running JavaFX app in a
 macOS virtual machine
In-Reply-To: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
Message-ID: <v1-a3LLq3KFO1UkvMqtabaUUgCNVbHYvDg-CPLvSlbM=.5f3e1209-766f-488b-b31d-32a345061f35@github.com>

> This is a PR for [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627).
> 
> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
> 
> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
> 
> The problematic code is located at #96 in GlassView3D.m:
> 
> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
> 096: if ((err == kCGLNoError) && (npix == 0))
> 097: {
> 098: const CGLPixelFormatAttribute attributes2[] =
> 099: {
> 100: kCGLPFAAllowOfflineRenderers,
> 101: (CGLPixelFormatAttribute)0
> 102: };
> 103: err = CGLChoosePixelFormat(attributes2, &pix, &npix);
> 104: }
> 
> 
> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
> 
> From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 8c7d3591: Log the fact that fist call to CGLChoosePixelFormat failed

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/65/files
  - new: https://git.openjdk.java.net/jfx/pull/65/files/73523680..8c7d3591

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/65.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/65/head:pull/65

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

From swpalmer at openjdk.java.net  Fri Dec 20 16:15:56 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Fri, 20 Dec 2019 16:15:56 GMT
Subject: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <QuWhUkchaPYKRpQuMZBloLgKvu5_ZE0TUOQzXwAL8Vc=.094fe714-503f-48cd-be44-4e5d30fc40da@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <6eAJ-X1FJJqK2-pQbv2fvfMGFrH01wAB-ZnNU0zm6F0=.279b9c26-b0f5-4006-ae37-cdae6271735f@github.com>
 <DfI8GSEg92LsAONgpaCwBqHzV2-mRAYJjrtbI7dppvo=.0a503f15-5d94-49b8-acdb-bca1c620ec19@github.com>
 <xgODDca7_fUTwoCuCtUg8GyweKSXSlWxmJSwwkCJ0XU=.411c1cc3-6e7f-49d1-b758-97626985d3a2@github.com>
 <QuWhUkchaPYKRpQuMZBloLgKvu5_ZE0TUOQzXwAL8Vc=.094fe714-503f-48cd-be44-4e5d30fc40da@github.com>
Message-ID: <dfBoyPTPZLasngS42rHA_R4BZpJLqnt2fTvms1t-0LE=.d12cab4f-1b56-4c7d-899a-0f80f262e96d@github.com>

On Fri, 20 Dec 2019 00:19:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I was thinking of deferring the `apps/toys` demo to avoid any delays in getting the new API into JavaFX 14.  I have something for it, I just don't want any feedback on it to hold up the review of this issue. Is there anything else I need to do?  Is the CSR in good shape?
> 
> I agree that that addition of a demo program in `apps/toys` can be decoupled from this. Please file a follow-up issue for this.
> 
> I reviewed the CSR. It looks ready to go.
> 
> In addition to an approved CSR, both @prrace and I will need to review this PR.

I have created https://bugs.openjdk.java.net/browse/JDK-8236438 to track the creation of a demo program.

-------------

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

From kcr at openjdk.java.net  Fri Dec 20 16:58:16 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 16:58:16 GMT
Subject: [Rev 01] RFR: 8235627: Blank stages when running JavaFX app in a
 macOS virtual machine
In-Reply-To: <aqoIiTh7PEFyU12IH-hgrAOxoTBozP3iKnwzZHsF6Ew=.83429135-d51d-4362-ad81-e8d84fc2665f@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <HVvaTgOgICzhAH9iLiqCuaU4UHXzAPyy1od0PGEhZak=.3aa34f29-efa1-4197-a430-70cbe6445af9@github.com>
 <aqoIiTh7PEFyU12IH-hgrAOxoTBozP3iKnwzZHsF6Ew=.83429135-d51d-4362-ad81-e8d84fc2665f@github.com>
Message-ID: <5tkH1ABX36_6gv4xkk5UEoK0V62AFfBkGjars1Pmt5g=.7b3217ee-8f92-4208-8e03-3c33f1b35f41@github.com>

On Fri, 20 Dec 2019 10:05:48 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> As mentioned in the description of [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627), following error is printed 
>> CGLChoosePixelFormat error: 10002
>> 
>> According to the documentation at [CGL Error Codes](http://mirror.informatimago.com/next/developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL/chap5/chapter_5_section_41.html#//apple_ref/doc/uid/TP30000136/BDJHHIDE)
>> 
>> 10002 is kCGLBadPixelFormat, which means Invalid pixel format object.
>> This does not seem to be an error code that should be returned by `CGLChoosePixelFormat`.
>> However the doc is very old, last updated on 2002-08-01.
>> 
>> Irrelevant to this doc the idea of this fix looks good.
> 
> Hi fthevenet,
> The basic idea of fix looks good to me. You have reported this bug with a very good detailed description. Can you please update the PR description also with same or sufficient information.

This looks good now. One last request: please update the last-modified year in the copyright header to 2019 as follows:

 * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved.

I've already submitted a PR with the last changes for the year, so this will save me the trouble of a follow-on fix after the new year.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Dec 20 17:02:45 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 20 Dec 2019 17:02:45 GMT
Subject: [Rev 02] RFR: 8235627: Blank stages when running JavaFX app in a
 macOS virtual machine
In-Reply-To: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
Message-ID: <SRN4sUEuMFo-bYiN7f56RZqh8Lt53YZVjfXdxE7bwPI=.16ac99cf-fe98-46fa-8a85-c189398cc87c@github.com>

> This is a PR for [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627).
> 
> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
> 
> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
> 
> The problematic code is located at #96 in GlassView3D.m:
> 
> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
> 096: if ((err == kCGLNoError) && (npix == 0))
> 097: {
> 098: const CGLPixelFormatAttribute attributes2[] =
> 099: {
> 100: kCGLPFAAllowOfflineRenderers,
> 101: (CGLPixelFormatAttribute)0
> 102: };
> 103: err = CGLChoosePixelFormat(attributes2, &pix, &npix);
> 104: }
> 
> 
> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
> 
> From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - f0f4651b: Updated the last-modified year in the copyright header to 2019

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/65/files
  - new: https://git.openjdk.java.net/jfx/pull/65/files/8c7d3591..f0f4651b

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/65/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/65/webrev.01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/65.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/65/head:pull/65

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

From kcr at openjdk.java.net  Fri Dec 20 17:37:45 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 17:37:45 GMT
Subject: RFR: 8088198: Exception thrown from snapshot if dimensions are
 larger than max texture size
In-Reply-To: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
Message-ID: <UvYm56uK2GPnS7P8YP4nV34mc5pPmOW9ljPcqO5BI4E=.e6998e56-3307-4b0f-aa12-ef1093c88e24@github.com>

On Tue, 17 Dec 2019 13:47:50 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
> 
> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
> Other than that, the logic used to do the actual snapshot is unchanged.
> 
> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"

This will need two reviewers. I want to review it, and I request @arapte to also review.

I won't have time to do a detailed review until the new year. One quick comment: in addition to the new tests you have provided, there are 4 `@Ignore`d tests in [Snapshot2Test.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java) that can likely be re-enabled. Look for `TODO: Re-enable this test when RT-22073 is fixed` (RT-22073 was mapped to JDK-8088198).

-------------

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

From kcr at openjdk.java.net  Fri Dec 20 17:41:00 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 17:41:00 GMT
Subject: [Rev 02] RFR: 8235627: Blank stages when running JavaFX app in a
 macOS virtual machine
In-Reply-To: <SRN4sUEuMFo-bYiN7f56RZqh8Lt53YZVjfXdxE7bwPI=.16ac99cf-fe98-46fa-8a85-c189398cc87c@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <SRN4sUEuMFo-bYiN7f56RZqh8Lt53YZVjfXdxE7bwPI=.16ac99cf-fe98-46fa-8a85-c189398cc87c@github.com>
Message-ID: <n7Gi9W0bJaUf12SucPIc3ftD5cuziRQTR6-T99wW1xQ=.6d7aeab3-f0b9-457d-8adc-49a418087748@github.com>

On Fri, 20 Dec 2019 17:41:00 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> This is a PR for [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627).
>> 
>> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
>> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
>> 
>> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
>> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
>> 
>> The problematic code is located at #96 in GlassView3D.m:
>> 
>> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
>> 096: if ((err == kCGLNoError) && (npix == 0))
>> 097: {
>> 098: const CGLPixelFormatAttribute attributes2[] =
>> 099: {
>> 100: kCGLPFAAllowOfflineRenderers,
>> 101: (CGLPixelFormatAttribute)0
>> 102: };
>> 103: err = CGLChoosePixelFormat(attributes2, &pix, &npix);
>> 104: }
>> 
>> 
>> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>> 
>> From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
>> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
>> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
> 
> The pull request has been updated with 1 additional commit.

Looks good.

Once @arapte approves,you can /integrate this change, and then he can sponsor it.

-------------

Marked as reviewed by kcr (Lead).

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

From github.com+7450507+fthevenet at openjdk.java.net  Fri Dec 20 17:55:18 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Fri, 20 Dec 2019 17:55:18 GMT
Subject: RFR: 8088198: Exception thrown from snapshot if dimensions are
 larger than max texture size
In-Reply-To: <UvYm56uK2GPnS7P8YP4nV34mc5pPmOW9ljPcqO5BI4E=.e6998e56-3307-4b0f-aa12-ef1093c88e24@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <UvYm56uK2GPnS7P8YP4nV34mc5pPmOW9ljPcqO5BI4E=.e6998e56-3307-4b0f-aa12-ef1093c88e24@github.com>
Message-ID: <D3PcM6rOssmYOtZa2qZ6_cfiitUunHAyJIPlmkKcCzM=.cca99693-140c-4575-b784-dee37fd098cf@github.com>

On Fri, 20 Dec 2019 17:37:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
>> 
>> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
>> Other than that, the logic used to do the actual snapshot is unchanged.
>> 
>> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
>> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"
> 
> This will need two reviewers. I want to review it, and I request @arapte to also review.
> 
> I won't have time to do a detailed review until the new year. One quick comment: in addition to the new tests you have provided, there are 4 `@Ignore`d tests in [Snapshot2Test.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java) that can likely be re-enabled. Look for `TODO: Re-enable this test when RT-22073 is fixed` (RT-22073 was mapped to JDK-8088198).

> 
> 
> This will need two reviewers. I want to review it, and I request @arapte to also review.
> 
> I won't have time to do a detailed review until the new year. One quick comment: in addition to the new tests you have provided, there are 4 `@Ignore`d tests in [Snapshot2Test.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java) that can likely be re-enabled. Look for `TODO: Re-enable this test when RT-22073 is fixed` (RT-22073 was mapped to JDK-8088198).

I hadn't noticed these tests before, but at a glance it does indeed look like they make the ones I added redundant.

-------------

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

From kcr at openjdk.java.net  Fri Dec 20 19:09:08 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 19:09:08 GMT
Subject: [Integrated] RFR: 8235364: Update copyright header for files
 modified in 2019
In-Reply-To: <g7pTcpYr4XPTLDCx4GmuDh3rBi-uq5865I9UHqzZNiI=.045081aa-9a71-4307-9d3c-ef4f225e5986@github.com>
References: <g7pTcpYr4XPTLDCx4GmuDh3rBi-uq5865I9UHqzZNiI=.045081aa-9a71-4307-9d3c-ef4f225e5986@github.com>
Message-ID: <6a393ae1-ca08-47d2-9fcb-be08d15662a8@openjdk.org>

Changeset: 5e0fb91c
Author:    Kevin Rushforth <kcr at openjdk.org>
Date:      2019-12-20 19:08:27 +0000
URL:       https://git.openjdk.java.net/jfx/commit/5e0fb91c

8235364: Update copyright header for files modified in 2019

Reviewed-by: arapte

! modules/javafx.base/src/main/java/com/sun/javafx/binding/SelectBinding.java
! modules/javafx.base/src/main/java/com/sun/javafx/event/CompositeEventHandler.java
! modules/javafx.base/src/main/java/com/sun/javafx/event/EventHandlerManager.java
! modules/javafx.base/src/main/java/javafx/beans/binding/package.html
! modules/javafx.base/src/main/java/javafx/beans/property/package.html
! modules/javafx.base/src/main/java/javafx/beans/value/package.html
! modules/javafx.base/src/main/java/javafx/collections/FXCollections.java
! modules/javafx.base/src/test/java/test/com/sun/javafx/event/CompositeEventHandlerTest.java
! modules/javafx.base/src/test/java/test/com/sun/javafx/event/EventHandlerManagerTest.java
! modules/javafx.base/src/test/java/test/javafx/collections/FXCollectionsTest.java
! modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java
! modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java
! modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java
! modules/javafx.controls/src/main/java/javafx/scene/control/ButtonBar.java
! modules/javafx.controls/src/main/java/javafx/scene/control/Cell.java
! modules/javafx.controls/src/main/java/javafx/scene/control/skin/ComboBoxPopupControl.java
! modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java
! modules/javafx.controls/src/main/java/javafx/scene/control/skin/NestedTableColumnHeader.java
! modules/javafx.controls/src/main/java/javafx/scene/control/skin/ProgressBarSkin.java
! modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableSkinUtils.java
! modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkin.java
! modules/javafx.controls/src/shims/java/javafx/scene/control/skin/TableColumnHeaderShim.java
! modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/KeyEventFirer.java
! modules/javafx.controls/src/test/java/test/javafx/scene/control/TextFieldTest.java
! modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ProgressBarSkinTest.java
! modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html
! modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html
! modules/javafx.graphics/src/main/java/com/sun/glass/ui/ios/IosApplication.java
! modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java
! modules/javafx.graphics/src/main/java/com/sun/prism/impl/GlyphCache.java
! modules/javafx.graphics/src/main/java/javafx/application/Platform.java
! modules/javafx.graphics/src/main/java/javafx/scene/input/DragEvent.java
! modules/javafx.graphics/src/main/java/javafx/scene/input/MouseEvent.java
! modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java
! modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderPane.java
! modules/javafx.graphics/src/main/java/javafx/scene/layout/FlowPane.java
! modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java
! modules/javafx.graphics/src/main/java/javafx/scene/layout/Pane.java
! modules/javafx.graphics/src/main/java/javafx/scene/layout/TilePane.java
! modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java
! modules/javafx.graphics/src/main/java/javafx/scene/layout/package.html
! modules/javafx.graphics/src/main/java/javafx/scene/package.html
! modules/javafx.graphics/src/main/java/javafx/scene/shape/Shape.java
! modules/javafx.graphics/src/main/native-font/coretext.c
! modules/javafx.graphics/src/main/native-glass/ios/GlassApplication.m
! modules/javafx.graphics/src/main/native-glass/ios/GlassHelper.h
! modules/javafx.graphics/src/main/native-glass/ios/GlassHelper.m
! modules/javafx.graphics/src/main/native-glass/ios/GlassViewDelegate.m
! modules/javafx.graphics/src/main/native-prism-sw/JNIUtil.c
! modules/javafx.graphics/src/main/native-prism-sw/JNIUtil.h
! modules/javafx.graphics/src/main/native-prism-sw/JPiscesRenderer.c
! modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/RenderRootTest.java
! modules/javafx.graphics/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java
! modules/javafx.graphics/src/test/java/test/javafx/concurrent/ServiceWithSecurityManagerTest.java
! modules/javafx.graphics/src/test/java/test/javafx/css/CssMetaDataTest.java
! modules/javafx.graphics/src/test/java/test/javafx/css/Node_cssStateTransition_Test.java
! modules/javafx.graphics/src/test/java/test/javafx/css/RuleTest.java
! modules/javafx.graphics/src/test/java/test/javafx/scene/Node_effectiveOrientation_Css_Test.java
! modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderPaneTest.java
! modules/javafx.graphics/src/test/java/test/javafx/scene/layout/ResizabilityTest.java
! modules/javafx.graphics/src/test/java/test/javafx/stage/PopupTest.java
! modules/javafx.graphics/src/test/java/test/javafx/stage/Popup_parentWindow_Test.java
! modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java
! modules/javafx.web/src/main/java/com/sun/webkit/network/ByteBufferPool.java
! modules/javafx.web/src/main/java/com/sun/webkit/network/NetworkContext.java
! modules/javafx.web/src/main/java/com/sun/webkit/network/URLLoader.java
! modules/javafx.web/src/main/java/com/sun/webkit/network/URLLoaderBase.java
! modules/javafx.web/src/main/java/javafx/scene/web/HTMLEditorSkin.java
! modules/javafx.web/src/main/java/module-info.java
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/java/ResourceHandleJava.cpp
! modules/javafx.web/src/main/native/Source/WebCore/platform/network/java/URLLoader.h
! tests/system/src/test/java/test/javafx/embed/swing/SwingFXUtilsTest.java
! tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java

From arapte at openjdk.java.net  Fri Dec 20 19:20:56 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 20 Dec 2019 19:20:56 GMT
Subject: [Rev 02] RFR: 8235627: Blank stages when running JavaFX app in a
 macOS virtual machine
In-Reply-To: <SRN4sUEuMFo-bYiN7f56RZqh8Lt53YZVjfXdxE7bwPI=.16ac99cf-fe98-46fa-8a85-c189398cc87c@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
 <SRN4sUEuMFo-bYiN7f56RZqh8Lt53YZVjfXdxE7bwPI=.16ac99cf-fe98-46fa-8a85-c189398cc87c@github.com>
Message-ID: <96kichj7x413xUydoPg075wgc7AjbM2Izblx7fO6UKc=.c05f47e1-548b-4053-8115-e788cdc62bac@github.com>

On Fri, 20 Dec 2019 19:20:56 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> This is a PR for [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627).
>> 
>> When running a JavaFX application in macOS guest VM, the main stage is completely blank, with the following errors: CGLChoosePixelFormat error: 10002, CGLCreateContext error: 10002
>> This behavior was observed with a macOS 10.15 guest OS on both VMWare player and VirtualBox, on a Windows 10 host.
>> 
>> This is an old issue that has already been reported several times (notably as JDK-8154852) but is claimed to have been fixed by JDK-8154148.
>> However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM crash, it doesn't prevent an incorrect pixel format to be retrieved, which is the root cause for the stage being empty.
>> 
>> The problematic code is located at #96 in GlassView3D.m:
>> 
>> 095: CGLError err = CGLChoosePixelFormat(attributes, &pix, &npix);
>> 096: if ((err == kCGLNoError) && (npix == 0))
>> 097: {
>> 098: const CGLPixelFormatAttribute attributes2[] =
>> 099: {
>> 100: kCGLPFAAllowOfflineRenderers,
>> 101: (CGLPixelFormatAttribute)0
>> 102: };
>> 103: err = CGLChoosePixelFormat(attributes2, &pix, &npix);
>> 104: }
>> 
>> 
>> In a comment in JDK-8154148, the following claim is made: "[...] an error happens is when something bad or invalid has occurred. An unsatisfied pixel format request is indicated by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a different format when npix is 0 and err is kCGLNoError." (https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)
>> 
>> From what I could observe, this is not necessarily true; in this case where a pixel format satisfying the initial conditions could not be found, the return code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel format with less restrictive condition.
>> This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be "if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
>> This is further supported by a sample in Apple developer's documentation on how to choose a pixel format: https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html
> 
> The pull request has been updated with 1 additional commit.

Looks good to me too.

-------------

Marked as reviewed by arapte (Reviewer).

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

From kcr at openjdk.java.net  Fri Dec 20 20:20:05 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 20:20:05 GMT
Subject: [Integrated] RFR: 8235627: Fixed blank stage when running in
 macOS guest VM
In-Reply-To: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
References: <H1zq_eV459a0QjPwZaEAFNHQ0aaiknX54sywHFkKg7Y=.28b1ddbc-8b5f-4450-8040-abc9eab8e06e@github.com>
Message-ID: <f479512d-d1f5-4cc9-a580-2f1aab6a57da@openjdk.org>

Changeset: 69e4ef35
Author:    Frederic Thevenet <thevenet.fred at free.fr>
Committer: Kevin Rushforth <kcr at openjdk.org>
Date:      2019-12-20 20:19:25 +0000
URL:       https://git.openjdk.java.net/jfx/commit/69e4ef35

8235627: Blank stages when running JavaFX app in a macOS virtual machine

Reviewed-by: arapte, kcr

! modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m

From kcr at openjdk.java.net  Fri Dec 20 21:56:45 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 21:56:45 GMT
Subject: RFR: 8217472: Add attenuation for PointLight
In-Reply-To: <8rYgugRQG-zrAZsJc8I2KCABvRgf6yJ7F-AOMgUvKV8=.267cc5a7-c8b5-4b6e-87ed-3cbdab895020@github.com>
References: <ykxcJ1ygFkSapBtap4VknPQ71U5MgIJn6CCMPkwIaG0=.2f5a3a6c-144f-4a99-bc3a-9b710d9d6964@github.com>
 <deq05FjcDNT3m6beVoiK7XX9x_E6X_0NJAX-SqNQlpo=.93bb488a-f5dc-43b4-8a74-689c6f16aed5@github.com>
 <8rYgugRQG-zrAZsJc8I2KCABvRgf6yJ7F-AOMgUvKV8=.267cc5a7-c8b5-4b6e-87ed-3cbdab895020@github.com>
Message-ID: <DpuJJPsI7LyNn9X5jsgwEoVmhPPCAGMWXmtiY4af4HU=.aefb6cdb-28b8-4d2c-9ca6-d8ca2ae5c518@github.com>

On Wed, 20 Nov 2019 00:32:36 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Kevin, Ambarish,
>> 
>> You can start the review, especially the API. I will hunt that specific values bug this week.
>> 
>> I'll need to know what kind of tests are needed in terms of functionality and performance.
> 
> The bug I mentioned above is not a bug actually. There are large changes over a small distance that make it looks like a jump in the lighting values, but when working with a finer scale the lighting dynamics seem correct.

I think this is on the right track. The API looks like it is in good shape.

This will need a fair bit of testing to ensure that there are no regressions either in functionality or (especially) performance, in addition to tests for the new functionality. On the performance aspect, the inner loop of the lighting calculation now has an additional if test for the max range and additional arithmetic calculations for the attenuation. What we will need is a test program that we can run on Mac and Windows to measure the performance of rendering in a fill-rate-limited case. Ideally, we would not pay much of a performance hit in the default case where `ca == 1, la == 0, qa == 0`, but we first need to be able to measure the drop in performance before we can say whether it is acceptable.

Speaking of testing, I took the current patch for a test drive on Mac and Windows. I get the following system test failures on Mac, and also the same failure using fx83dfeatures/LightMotion in toys.


Shader compile log: ERROR: 0:308: Use of undeclared identifier 'range'
ERROR: 0:316: Regular non-array variable 'dist' may not be redeclared

test.robot.test3d.MeshCompareTest > testSnapshot3D[3] STANDARD_ERROR
    java.lang.RuntimeException: Error creating fragment shader
    	at javafx.graphics/com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:141)
    	at javafx.graphics/com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:177)
        ...
test.robot.test3d.MeshCompareTest > testSnapshot3D[3] FAILED
    java.lang.IllegalArgumentException: Unrecognized image loader: null
        at javafx.graphics/javafx.scene.image.WritableImage.loadTkImage(WritableImage.java:278)
        at javafx.graphics/javafx.scene.image.WritableImage$1.loadTkImage(WritableImage.java:53)
        at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1340)
        at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1372)
        at javafx.graphics/javafx.scene.Scene.snapshot(Scene.java:1462)
        at test.robot.test3d.MeshCompareTest.lambda$testSnapshot3D$0(MeshCompareTest.java:315)


test.robot.test3d.Snapshot3DTest > testSnapshot3D[3] FAILED
(same failure as above)


test.robot.test3d.Snapshot3DTest > testSnapshot3D[7] FAILED
(same failure as above)

-------------

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

From prr at openjdk.java.net  Fri Dec 20 22:18:30 2019
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 20 Dec 2019 22:18:30 GMT
Subject: [Rev 05] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <-EQiBrSkLEbmDIE2fwRic4XLsKmRuk9f7MTNnRKvgzA=.591b8ad4-0598-47a1-b721-86203f2adbab@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <-EQiBrSkLEbmDIE2fwRic4XLsKmRuk9f7MTNnRKvgzA=.591b8ad4-0598-47a1-b721-86203f2adbab@github.com>
Message-ID: <XRnIlu9ED8CYTdBAlPnt2DRBVzVODbaIQTKzC31Wo2k=.bf4cb5eb-6346-498e-983b-3553189fb0ba@github.com>

On Fri, 20 Dec 2019 22:18:29 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both.  TextFlow's tab size overrides that of contained Text nodes.
> 
> The pull request has been updated with 1 additional commit.



-------------

Marked as reviewed by prr (Reviewer).

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

From kcr at openjdk.java.net  Fri Dec 20 22:37:35 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 22:37:35 GMT
Subject: RFR: 8232589: Remove CoreAudio Utility Classes
In-Reply-To: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
References: <WzbFQy-Hsgp7pOGyloeI42hQmyhe7ZqTewQ3woNFTBM=.c51094eb-e92c-46e6-b1ae-52d2df0a370c@github.com>
Message-ID: <xk3WU784qz017EsNSXpBbdSw58ThhpWN_Pc7rxLsgbY=.5986ff3b-112a-4758-a639-30de360469ee@github.com>

On Wed, 18 Dec 2019 01:04:42 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8232589
> 
> - Removed CoreAudio Utility classes.
> - Spectrum which was depended on CoreAudio Utility classes for doing computations will now run GStreamer spectrum element to do spectrum. Element will be run without pipeline and will be used as utility library to do spectrum calculation. I added extra APIs to bypass proper element initialization.
> - Equalizer and audio unit (volume and balance) where modified, so we can run then directly without CoreAudio pipeline.

All my testing looks good. The code changes look fine, although I have a couple questions.

modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/spectrum/gstspectrum.c line 915:

> 914:   bpf = GST_AUDIO_FILTER_BPF (spectrum);
> 915: #ifdef OSX
> 916:   if (spectrum->bps_user != 0 && spectrum->bpf_user != 0) {

Should this also be qualified with `GSTREAMER_LITE` since it represents changes specific to our port?

modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioEqualizer.cpp line 422:

> 421:             mEQBufferA = (double*)calloc(mEQBufferSize, sizeof(double));
> 422:             mEQBufferB = (double*)calloc(mEQBufferSize, sizeof(double));
> 423:         }

This is allocating 8 times (i.e., `sizeof(double)`) as much memory as before. I presume this is intentional?

-------------



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

From kcr at openjdk.java.net  Fri Dec 20 23:44:07 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 20 Dec 2019 23:44:07 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
Message-ID: <hCpM6d-VogKWvd66yibDiPAOn6VWlyWVLCJcwcMJ7yo=.3785aa05-221c-4d06-996d-3544bb47e000@github.com>

On Fri, 20 Dec 2019 23:44:07 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both.  TextFlow's tab size overrides that of contained Text nodes.
> 
> The pull request has been updated with 1 additional commit.

The fix looks good now. There is one problem in the test (in `StubTextLayout`) that needs to be fixed.

modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubTextLayout.java line 50:

> 49:     private int tabSize = DEFAULT_TAB_SIZE;
> 50:     private int nullFontSize = 10;
> 51: 

Setting `nullFontSize` to 10 by default has broken one of the existing unit tests (a rather fragile test it seems). I now see the following failure:

test.javafx.scene.chart.StackedBarChartTest > testSeriesAdd FAILED
    org.junit.ComparisonFailure: expected:<10 4[78 234 37 254 432 234 83 499 375 234 140] > but was:<10 4[60 218 35 238 415 218 80 465 360 218 135] >
        at org.junit.Assert.assertEquals(Assert.java:123)
        at org.junit.Assert.assertEquals(Assert.java:145)
        at test.javafx.scene.chart.StackedBarChartTest.testSeriesAdd(StackedBarChartTest.java:110)

If you change this to 0, which restores the previous default, leaving in place the setting to 10 in ` setContent(TextSpan[])`, then all tests pass.

-------------



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

From swpalmer at openjdk.java.net  Sat Dec 21 02:51:08 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Sat, 21 Dec 2019 02:51:08 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <hCpM6d-VogKWvd66yibDiPAOn6VWlyWVLCJcwcMJ7yo=.3785aa05-221c-4d06-996d-3544bb47e000@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
 <hCpM6d-VogKWvd66yibDiPAOn6VWlyWVLCJcwcMJ7yo=.3785aa05-221c-4d06-996d-3544bb47e000@github.com>
Message-ID: <uG7wl2m0GL1XMZ9cMChw8PNQ8Asqyub9eAbyBdlATEA=.a42638f4-280f-4e50-9e84-d9d30acf7d9a@github.com>

On Fri, 20 Dec 2019 23:43:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The pull request has been updated with 1 additional commit.
> 
> The fix looks good now. There is one problem in the test (in `StubTextLayout`) that needs to be fixed.

Interesting.  I was only running the tests in graphics (gradle :graphics:test) as when I run all the tests I always get this failure (unrelated to anything I've changed):

> Task :base:test

test.javafx.util.converter.LocalDateTimeStringConverterTest > toString_to_fromString_testRoundtrip[0] FAILED
    java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' could not be parsed, unparsed text found at index 19
        at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052)
        at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1877)
        at javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208)
        at javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159)
        at test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131)

5222 tests completed, 1 failed, 27 skipped

-------------

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

From swpalmer at openjdk.java.net  Sat Dec 21 02:55:32 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Sat, 21 Dec 2019 02:55:32 GMT
Subject: [Rev 06] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
Message-ID: <gJs-Uck7cEjSEPemDTEbM42AhemZNlFzQ6zzt1P_gzQ=.6b7abac9-4cab-4906-91eb-80625fe48182@github.com>

> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both.  TextFlow's tab size overrides that of contained Text nodes.

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 78ddf12e: 8130738: Fixed test issue with StubTextLayout

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/32/files
  - new: https://git.openjdk.java.net/jfx/pull/32/files/f846ad6d..78ddf12e

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/32/webrev.06
 - incr: https://webrevs.openjdk.java.net/jfx/32/webrev.05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32

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

From swpalmer at openjdk.java.net  Sat Dec 21 03:04:17 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Sat, 21 Dec 2019 03:04:17 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <uG7wl2m0GL1XMZ9cMChw8PNQ8Asqyub9eAbyBdlATEA=.a42638f4-280f-4e50-9e84-d9d30acf7d9a@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
 <hCpM6d-VogKWvd66yibDiPAOn6VWlyWVLCJcwcMJ7yo=.3785aa05-221c-4d06-996d-3544bb47e000@github.com>
 <uG7wl2m0GL1XMZ9cMChw8PNQ8Asqyub9eAbyBdlATEA=.a42638f4-280f-4e50-9e84-d9d30acf7d9a@github.com>
Message-ID: <_tElrFJfsMSasOUFuTi2aegqQtkwxLtocLOhmVEFoDQ=.2316a5d2-dd40-4fd1-86b7-53fd7c13be1c@github.com>

On Sat, 21 Dec 2019 02:50:54 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> The fix looks good now. There is one problem in the test (in `StubTextLayout`) that needs to be fixed.
> 
> Interesting.  I was only running the tests in graphics (gradle :graphics:test) as when I run all the tests I always get this failure (unrelated to anything I've changed):
> 
>> Task :base:test
> 
> test.javafx.util.converter.LocalDateTimeStringConverterTest > toString_to_fromString_testRoundtrip[0] FAILED
>     java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' could not be parsed, unparsed text found at index 19
>         at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052)
>         at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1877)
>         at javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208)
>         at javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159)
>         at test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131)
> 
> 5222 tests completed, 1 failed, 27 skipped

I'm not sure if I'me supposed to try to integrate now that I've made that 10 -> 0 change, or if the new change resets the need for review... Also, note that the link in the bot msg for "project specific requirements" is giving me a 404 error.

-------------

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

From philip.race at oracle.com  Sat Dec 21 03:22:42 2019
From: philip.race at oracle.com (Philip Race)
Date: Fri, 20 Dec 2019 19:22:42 -0800
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <_tElrFJfsMSasOUFuTi2aegqQtkwxLtocLOhmVEFoDQ=.2316a5d2-dd40-4fd1-86b7-53fd7c13be1c@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
 <hCpM6d-VogKWvd66yibDiPAOn6VWlyWVLCJcwcMJ7yo=.3785aa05-221c-4d06-996d-3544bb47e000@github.com>
 <uG7wl2m0GL1XMZ9cMChw8PNQ8Asqyub9eAbyBdlATEA=.a42638f4-280f-4e50-9e84-d9d30acf7d9a@github.com>
 <_tElrFJfsMSasOUFuTi2aegqQtkwxLtocLOhmVEFoDQ=.2316a5d2-dd40-4fd1-86b7-53fd7c13be1c@github.com>
Message-ID: <5DFD9002.1070500@oracle.com>



On 12/20/19, 7:04 PM, Scott Palmer wrote:
> I'm not sure if I'me supposed to try to integrate now that I've made that 10 ->  0 change, or if the new change resets the need for review...

It shows ready, which surprises me.
Still learning skara .. I'd expect any change to reset as how can it 
know if it is
a  good or insignificant change or not no matter how the commenter 
characterised the issue ?


>   Also, note that the link in the bot msg for "project specific requirements" is giving me a 404 error.
I see that too https://github.com/openjdk/jfx/blob/masterCONTRIBUTING.md


I don't know how the change here : 
https://github.com/openjdk/skara/pull/343/files

+ automated pre-integration checks. When the change also ");
+       message.append("fulfills all [project specific 
requirements](https://github.com/");

maps to the project, but it seems like there's a config bug somewhere 
that may be just being
exposed

-phil

From ebresie at gmail.com  Sat Dec 21 17:13:07 2019
From: ebresie at gmail.com (Eric Bresie)
Date: Sat, 21 Dec 2019 11:13:07 -0600
Subject: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator (Code
 Analysis Discussion)
In-Reply-To: <xFY1R-O53_xFrJnVfvJdRFvMSTo7e3XxP02zZjGFvvM=.78597514-fb80-454b-a7ce-4e336e7bcc1f@github.com>
References: <4AOkSv1WjFvlW91fwfyuscb_BJpaAmzCZrYwAFMg_w8=.cb41dacd-8f6a-4ce3-bf6e-c9f3ed389232@github.com>
 <mWq3bcNLAsijr9rSexk5JBZI6Fon6fKPgx7nqpwCOvc=.b4e6c0ad-9cd1-47a1-b0e1-6774ad4c9f3a@github.com>
 <ItKD7SRIrN-oJiQaOgEt_fCaRcE3DVjgqZkxanFNOGc=.d8dc674d-a117-4f2f-9fa7-d0582076abf4@github.com>
 <qqv0zb9Y4jtStMr_JipVW4gsARbKuj5rsbKwkLvIRCU=.9d211c8e-4743-4d95-8d4c-46d1e3732d5e@github.com>
 <O6EAGZkA8oaYdFzW6sYq-fdrrX1QNN0c26z9U2ZaBo0=.32d5ef98-97fe-4216-8bc7-07bca6707a29@github.com>
 <OJQ1Sg2x73VHRRRfPjni2zFD0qedDh5ak-753XeuO5Q=.89b0cfac-8968-40e7-b554-a76ce40b01fa@github.com>
 <pNM9QJd1C_eudoW8kQejgdIxURnZGlqEbrbhfzLSyrk=.8cdd20b7-5847-456d-8ae8-06261011bbe9@github.com>
 <4ZgDMHtyYvvEyjNbrSqYtImrVggXwYRjOWtYm4giLVk=.ca2a5e57-5d0f-4508-ad03-41598f1f1be8@github.com>
 <BCC35I2fOs4dCOEu-DSFzFohy0n5wiyTe0GH3XhGp44=.9b70d988-8728-4285-b162-d32813f709b3@github.com>
 <CLRbCmKAGW7YaFrID3K-uTY65MC7wuiwfXkCMeegq4Q=.ff00f530-4adb-4e6f-8992-cd1f6c811763@github.com>
 <46MzoLjJGQldWFkSMjgZLc4d9pCkAeI8gjQWAzqiSO0=.9424ff3f-e054-4842-a56b-7edfc1eb6761@github.com>
 <xFY1R-O53_xFrJnVfvJdRFvMSTo7e3XxP02zZjGFvvM=.78597514-fb80-454b-a7ce-4e336e7bcc1f@github.com>
Message-ID: <CAHw6w1Qq+xF=PJvXwN2uDK_FCv3isBSGQC_pdvqAjXTPc4uJeA@mail.gmail.com>

Accepting that static analysis tools are not best at finding memory
leaks...however they can find some easy to find ones.  I was just wondering
if some of these can be run across the code base to find these "easy to
find" ones to help in the process.

Additionally, if there are certain checks that want to be flowed out across
the code base (i.e. checks for initialization, then having the analysis run
as part of a CI build jobs which could be periodically run and reported on
to might help maintain some level of code quality over time.  I know this
can potentially find a lot of false failures but just thought it might be
worth considering at some point.

Eric Bresie
ebresie at gmail.com


On Fri, Dec 20, 2019 at 7:30 AM Kevin Rushforth <kcr at openjdk.java.net>
wrote:

> On Fri, 20 Dec 2019 09:53:56 GMT, Florian Kirmaier <fkirmaier at openjdk.org>
> wrote:
>
> >> @dsgrieve
> >> It's worth mentioning that JavaFX already has many tests based on
> System.gc().
> >> An advantage of having a testsuit as an library (or copyied from an
> library) is, that its stability is regulary verified by the travis builds
> for different JVMs.
> >> The alternative would be to not test for memory-leaks at all which is
> much worse than having slightly unstable tests.
> >> Maybe it can make sense to seperate these tests for leaks in an own
> testgroup.
> >>
> >> I'm introducing this library in more and more projects. I never had
> problems with unstable tests.
> >> I only had this kind of problem when I wrote the
> WeakReference/System.gc/sleep-logic for every single test.
> >
> > I highly doubt that a code analysis tool will find such memoryleaks.
>
> I agree. Static analysis tools are quite limited in this regard, and are
> in now way a substitute for regression testing.
>
> So the question is how best to test fixes for memory leaks at runtime. Our
> current approach can be best characterized as "ad hoc", and is not all that
> robust (although works well enough in most cases and is still much better
> than doing no testing at all). I would welcome discussion of a more robust
> approach for testing, but it should be decoupled from this bug fix, and
> discussed as a separate JBS Enhancement request.
>
> -------------
>
> PR: https://git.openjdk.java.net/jfx/pull/71
>

From jvos at openjdk.java.net  Sat Dec 21 18:13:10 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Sat, 21 Dec 2019 18:13:10 GMT
Subject: RFR: 8236484: Compile error in monocle dispman
Message-ID: <apzKeEAtPEmQqIyv0Whr0wX9VWGsUdFngRvCdhCHnhQ=.e753f03e-9c5a-4a2e-bfe7-28e910b39861@github.com>

Trivial fix for a compiler error where a void function returns a long

-------------

Commits:
 - 5c066016: Trivial fix for a compiler error where a void function returns a long

Changes: https://git.openjdk.java.net/jfx/pull/74/files
 Webrev: https://webrevs.openjdk.java.net/jfx/74/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236484
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/74.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/74/head:pull/74

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

From jvos at openjdk.java.net  Sat Dec 21 18:22:55 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Sat, 21 Dec 2019 18:22:55 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <LAVvWfJ57Y7a2gFvc1FF8IeTFc91TROv6qnNnY4M97k=.39ebda86-18f3-46e1-af69-9e60e954f5cf@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
 <FTLU9msATCFecKkKSMDbRIfoti3oHeNByOX3RMv9xwg=.831b1744-1059-40a3-a64b-b0cce08e4540@github.com>
 <LAVvWfJ57Y7a2gFvc1FF8IeTFc91TROv6qnNnY4M97k=.39ebda86-18f3-46e1-af69-9e60e954f5cf@github.com>
Message-ID: <dJY6uX8R7fbRyiftmCyh3TuqdUGGy63zll2Qqv3vDnQ=.6dbcd745-a5fd-483c-aa46-16c5b36434b3@github.com>

On Wed, 18 Dec 2019 16:55:30 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 63:
>> 
>>> 62:     }
>>> 63: }
>>> 64: 
>> 
>> there are no checks on memory errors as used to be in the finalize implementation. Are those not needed anymore?
> 
> Hi Johan,
> The `readAndClearMemErrorFlag()` method checks if the variable `mem_Error_Flag` is `JNI_TRUE`.
> A call should be made to `setMemErrorFlag()` to set `mem_Error_Flag` to `JNI_TRUE`.
> 
> The methods used to dispose Surface and renderer only `free()` the allocated memory and 
> do not result in making a call to `setMemErrorFlag().`
> So we do not need to check for `readAndClearMemErrorFlag()`
> And I think it was not required before this change too.

The dispose methods indeed won't set the `mem_Error_Flag` but this flag might have been set by other methods. Isn't there a probability that the flag has been set, and that `readAndClearMemErrorFlag()` is not yet called since the flag has been set?

-------------

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

From swpalmer at openjdk.java.net  Sat Dec 21 18:35:41 2019
From: swpalmer at openjdk.java.net (Scott Palmer)
Date: Sat, 21 Dec 2019 18:35:41 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <_tElrFJfsMSasOUFuTi2aegqQtkwxLtocLOhmVEFoDQ=.2316a5d2-dd40-4fd1-86b7-53fd7c13be1c@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
 <hCpM6d-VogKWvd66yibDiPAOn6VWlyWVLCJcwcMJ7yo=.3785aa05-221c-4d06-996d-3544bb47e000@github.com>
 <uG7wl2m0GL1XMZ9cMChw8PNQ8Asqyub9eAbyBdlATEA=.a42638f4-280f-4e50-9e84-d9d30acf7d9a@github.com>
 <_tElrFJfsMSasOUFuTi2aegqQtkwxLtocLOhmVEFoDQ=.2316a5d2-dd40-4fd1-86b7-53fd7c13be1c@github.com>
Message-ID: <odTtdt4wlSe2RMA-XAFHgPUD0FYN_j37G_51cGPfJ5A=.3e65560b-d336-4d10-adfc-9c082c8c3ffd@github.com>

On Sat, 21 Dec 2019 03:03:57 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> Interesting.  I was only running the tests in graphics (gradle :graphics:test) as when I run all the tests I always get this failure (unrelated to anything I've changed):
>> 
>>> Task :base:test
>> 
>> test.javafx.util.converter.LocalDateTimeStringConverterTest > toString_to_fromString_testRoundtrip[0] FAILED
>>     java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' could not be parsed, unparsed text found at index 19
>>         at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052)
>>         at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1877)
>>         at javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208)
>>         at javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159)
>>         at test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131)
>> 
>> 5222 tests completed, 1 failed, 27 skipped
> 
> I'm not sure if I'me supposed to try to integrate now that I've made that 10 -> 0 change, or if the new change resets the need for review... Also, note that the link in the bot msg for "project specific requirements" is giving me a 404 error.

Link problem appears to just be a missing slash: https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md

-------------

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

From prr at openjdk.java.net  Sat Dec 21 20:35:28 2019
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 21 Dec 2019 20:35:28 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <odTtdt4wlSe2RMA-XAFHgPUD0FYN_j37G_51cGPfJ5A=.3e65560b-d336-4d10-adfc-9c082c8c3ffd@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
 <hCpM6d-VogKWvd66yibDiPAOn6VWlyWVLCJcwcMJ7yo=.3785aa05-221c-4d06-996d-3544bb47e000@github.com>
 <uG7wl2m0GL1XMZ9cMChw8PNQ8Asqyub9eAbyBdlATEA=.a42638f4-280f-4e50-9e84-d9d30acf7d9a@github.com>
 <_tElrFJfsMSasOUFuTi2aegqQtkwxLtocLOhmVEFoDQ=.2316a5d2-dd40-4fd1-86b7-53fd7c13be1c@github.com>
 <odTtdt4wlSe2RMA-XAFHgPUD0FYN_j37G_51cGPfJ5A=.3e65560b-d336-4d10-adfc-9c082c8c3ffd@github.com>
Message-ID: <3cbQ0VzO46Fsy_lCMaktyATqNMxKtreXXQ7CWhdORmA=.e089b35b-a3a9-4d1e-b147-9002a60849a0@github.com>

On Sat, 21 Dec 2019 18:35:26 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> I'm not sure if I'me supposed to try to integrate now that I've made that 10 -> 0 change, or if the new change resets the need for review... Also, note that the link in the bot msg for "project specific requirements" is giving me a 404 error.
> 
> Link problem appears to just be a missing slash: https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md

> Link problem appears to just be a missing slash: https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md

Seems this was fixed yesterday : https://github.com/openjdk/skara/pull/344

-------------

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

From arapte at openjdk.java.net  Tue Dec 24 06:37:20 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 24 Dec 2019 06:37:20 GMT
Subject: RFR: 8235772: Remove use of deprecated finalize method from
 PiscesRenderer and AbstractSurface
In-Reply-To: <dJY6uX8R7fbRyiftmCyh3TuqdUGGy63zll2Qqv3vDnQ=.6dbcd745-a5fd-483c-aa46-16c5b36434b3@github.com>
References: <asR0dpLaEHyVJh7MgqKHa3UHhGTjM9FSaLYn4_daXdU=.d902ff1a-b825-4971-aa52-a008efdef779@github.com>
 <FTLU9msATCFecKkKSMDbRIfoti3oHeNByOX3RMv9xwg=.831b1744-1059-40a3-a64b-b0cce08e4540@github.com>
 <LAVvWfJ57Y7a2gFvc1FF8IeTFc91TROv6qnNnY4M97k=.39ebda86-18f3-46e1-af69-9e60e954f5cf@github.com>
 <dJY6uX8R7fbRyiftmCyh3TuqdUGGy63zll2Qqv3vDnQ=.6dbcd745-a5fd-483c-aa46-16c5b36434b3@github.com>
Message-ID: <yyD8hlcbDx35EajGmbiPkrynBIsHvjC4HX8AbFBmVmA=.cdeac3c5-a77e-4379-bbf1-be10ab4bcbde@github.com>

On Sat, 21 Dec 2019 18:22:44 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Hi Johan,
>> The `readAndClearMemErrorFlag()` method checks if the variable `mem_Error_Flag` is `JNI_TRUE`.
>> A call should be made to `setMemErrorFlag()` to set `mem_Error_Flag` to `JNI_TRUE`.
>> 
>> The methods used to dispose Surface and renderer only `free()` the allocated memory and 
>> do not result in making a call to `setMemErrorFlag().`
>> So we do not need to check for `readAndClearMemErrorFlag()`
>> And I think it was not required before this change too.
> 
> The dispose methods indeed won't set the `mem_Error_Flag` but this flag might have been set by other methods. Isn't there a probability that the flag has been set, and that `readAndClearMemErrorFlag()` is not yet called since the flag has been set?

Hi Johan, I did miss to verify this angle.
But have checked the code now and can confirm that, in a given function for all possible calls to `setMemErrorFlag()` there exists a call to `readAndClearMemErrorFlag()` in the same function. So it looks safe to remove the memory checks from `dispose()`

-------------

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

From arapte at openjdk.java.net  Tue Dec 24 08:12:16 2019
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 24 Dec 2019 08:12:16 GMT
Subject: RFR: 8088198: Exception thrown from snapshot if dimensions are
 larger than max texture size
In-Reply-To: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
Message-ID: <vGfNX2Nqj36iNEg2FV3lKiIGKvnnbMhfr1R-xFowzdg=.688a7f7e-dc82-4a09-a8af-27325a2d9ad9@github.com>

On Tue, 17 Dec 2019 13:47:50 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
> 
> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
> Other than that, the logic used to do the actual snapshot is unchanged.
> 
> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1286:

> 1285:                                     Node root, BaseTransform transform, boolean depthBuffer,
> 1286:                                     Paint fill, Camera camera, WritableImage wimg) {
> 1287: 

Generally we avoid only formatting changes. It will be acceptable to change formatting of the code which is getting modified for the fix. Please do not include only formatting changes, which are not required for the fix.

-------------

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

From github.com+7450507+fthevenet at openjdk.java.net  Tue Dec 24 10:14:06 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Tue, 24 Dec 2019 10:14:06 GMT
Subject: [Rev 01] RFR: 8088198: Exception thrown from snapshot if
 dimensions are larger than max texture size
In-Reply-To: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
Message-ID: <J8DrHueBIA88__j5zIlfqCWZyyJ6DhabHjCZPukpmA4=.a0323fd5-5484-4e6e-8065-3c1bde53785c@github.com>

> This PR aims to address the following issue: JDK-8088198 Exception thrown from snapshot if dimensions are larger than max texture size
> 
> In order to do that, it simply captures snapshots in multiple tiles of maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the tiles into a a single image.
> Other than that, the logic used to do the actual snapshot is unchanged.
> 
> Tests using the existing SnapshotCommon class have been added in a new file named Snapshot3Test under SystemTest/test/javafx/scene.
> These tests pass with the proposed fix, and fail without, throwing " java.lang.IllegalArgumentException: Unrecognized image loader: null"

The pull request has been updated with 1 additional commit.

-------------

Added commits:
 - 9986809d: Revert formatting changes

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/68/files
  - new: https://git.openjdk.java.net/jfx/pull/68/files/4bc44173..9986809d

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

  Stats: 17 lines in 1 file changed: 0 ins; 2 del; 15 mod
  Patch: https://git.openjdk.java.net/jfx/pull/68.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/68/head:pull/68

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

From github.com+7450507+fthevenet at openjdk.java.net  Tue Dec 24 13:53:29 2019
From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet)
Date: Tue, 24 Dec 2019 13:53:29 GMT
Subject: RFR: 8088198: Exception thrown from snapshot if dimensions are
 larger than max texture size
In-Reply-To: <D3PcM6rOssmYOtZa2qZ6_cfiitUunHAyJIPlmkKcCzM=.cca99693-140c-4575-b784-dee37fd098cf@github.com>
References: <HQ3pjlS0flV3vW7YaAoS6EKQipTAUodbtlxzNXdp8YM=.3941a030-d229-40bb-82e1-aed50065f5da@github.com>
 <UvYm56uK2GPnS7P8YP4nV34mc5pPmOW9ljPcqO5BI4E=.e6998e56-3307-4b0f-aa12-ef1093c88e24@github.com>
 <D3PcM6rOssmYOtZa2qZ6_cfiitUunHAyJIPlmkKcCzM=.cca99693-140c-4575-b784-dee37fd098cf@github.com>
Message-ID: <Lf4kvrZxf0FBzXezG5n7AuvagrT0l0GhtA8A4VfvkhM=.d0e5b6b2-8c9a-41b6-8d09-7b28c5495b2c@github.com>

On Fri, 20 Dec 2019 17:55:04 GMT, Frederic Thevenet <github.com+7450507+fthevenet at openjdk.org> wrote:

>> This will need two reviewers. I want to review it, and I request @arapte to also review.
>> 
>> I won't have time to do a detailed review until the new year. One quick comment: in addition to the new tests you have provided, there are 4 `@Ignore`d tests in [Snapshot2Test.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java) that can likely be re-enabled. Look for `TODO: Re-enable this test when RT-22073 is fixed` (RT-22073 was mapped to JDK-8088198).
> 
>> 
>> 
>> This will need two reviewers. I want to review it, and I request @arapte to also review.
>> 
>> I won't have time to do a detailed review until the new year. One quick comment: in addition to the new tests you have provided, there are 4 `@Ignore`d tests in [Snapshot2Test.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java) that can likely be re-enabled. Look for `TODO: Re-enable this test when RT-22073 is fixed` (RT-22073 was mapped to JDK-8088198).
> 
> I hadn't noticed these tests before, but at a glance it does indeed look like they make the ones I added redundant.

Upon closer inspection, I believe that the tests I added in Snapshot3Test are indeed redundant and less complete than the 4 ignored test in Snapshot2Test.
I therefore propose to remove Snapshot3Test.java entirely and to re-enable the 4 testSnapshotBig* test instead.

-------------

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

From david_green at use.startmail.com  Thu Dec 26 20:24:08 2019
From: david_green at use.startmail.com (David Green)
Date: Thu, 26 Dec 2019 20:24:08 -0000
Subject: error in tutorial
Message-ID: <157739184797.6495.9172254440030590749@startmail.com>

This step fails:  

  

3\. Create a library  

Go to File -&gt; Project Structure -&gt; Libraries and add the JavaFX 13 SDK
as a library to the project. Point to the lib folder of the JavaFX SDK.  

  

The src.zip located in this package lib will cause the build in IJ to fail. I
don't know why, since it is source, albeit zipped.  

  

To get the project to build, I had to remove it. I placed it in a new src
folder I created at the same level as lib in the sdk.  

  


From youngty1997 at gmail.com  Fri Dec 27 06:59:20 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Thu, 26 Dec 2019 22:59:20 -0800
Subject: error in tutorial
In-Reply-To: <157739184797.6495.9172254440030590749@startmail.com>
References: <157739184797.6495.9172254440030590749@startmail.com>
Message-ID: <5e053b49.1c69fb81.58538.20c1@mx.google.com>



Told them about this over a(2?) year ago. Java 9 Modules do not accept unsupported file formats such as ZIP files(nor have they ever) and will throw an error if a module folder contains them. 

Not only does this cause this issue, but it violates standards: in no OS will you find zip files containing source code mixed in with the libraries themselves. Take a look in /usr/lib, you won?t find any.


Fixing this issue on the build side literally only requires a one line Gradle build file change so that the output of the src.zip is the root of the SDK build and not the libs folder. It would take less than a minute to fix, literally. 

The excuse for not fixing this at the time was: ?it?s the way we?ve always done it?. Maybe Oracle/Gluon have stopped smoking shrooms and are willing to fix this now.


From: David Green
Sent: Thursday, December 26, 2019 12:24 PM
To: openjfx-dev at openjdk.java.net
Subject: error in tutorial

This step fails:  

  

3\. Create a library  

Go to File -&gt; Project Structure -&gt; Libraries and add the JavaFX 13 SDK
as a library to the project. Point to the lib folder of the JavaFX SDK.  

  

The src.zip located in this package lib will cause the build in IJ to fail. I
don't know why, since it is source, albeit zipped.  

  

To get the project to build, I had to remove it. I placed it in a new src
folder I created at the same level as lib in the sdk.  

  



From johan.vos at gluonhq.com  Fri Dec 27 10:19:08 2019
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 27 Dec 2019 11:19:08 +0100
Subject: error in tutorial
In-Reply-To: <157739184797.6495.9172254440030590749@startmail.com>
References: <157739184797.6495.9172254440030590749@startmail.com>
Message-ID: <CABxFH2EJUkx_tHbQn_o2-d1jP-OOYjYR-nWoyLfQeG-55nUUKA@mail.gmail.com>

Hi David,

What tutorial are you talking about? If you refer to https://openjfx.io,
that is a community-initiative, developed at
https://github.com/openjfx/openjfx-docs .
So if you have issues and PR's, that is the place to submit and discuss
with the other contributors to that site.

Thanks,

- Johan

On Thu, Dec 26, 2019 at 9:26 PM David Green <david_green at use.startmail.com>
wrote:

> This step fails:
>
>
>
> 3\. Create a library
>
> Go to File -&gt; Project Structure -&gt; Libraries and add the JavaFX 13
> SDK
> as a library to the project. Point to the lib folder of the JavaFX SDK.
>
>
>
> The src.zip located in this package lib will cause the build in IJ to
> fail. I
> don't know why, since it is source, albeit zipped.
>
>
>
> To get the project to build, I had to remove it. I placed it in a new src
> folder I created at the same level as lib in the sdk.
>
>
>
>

From youngty1997 at gmail.com  Fri Dec 27 22:06:31 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 27 Dec 2019 16:06:31 -0600
Subject: error in tutorial
In-Reply-To: <CABxFH2EJUkx_tHbQn_o2-d1jP-OOYjYR-nWoyLfQeG-55nUUKA@mail.gmail.com>
References: <157739184797.6495.9172254440030590749@startmail.com>
 <CABxFH2EJUkx_tHbQn_o2-d1jP-OOYjYR-nWoyLfQeG-55nUUKA@mail.gmail.com>
Message-ID: <89d58181-5556-a270-48ce-6e11820ddf60@gmail.com>


On 12/27/19 4:19 AM, Johan Vos wrote:
> Hi David,
>
> What tutorial are you talking about? If you refer to https://openjfx.io,
> that is a community-initiative, developed at
> https://github.com/openjfx/openjfx-docs .
> So if you have issues and PR's, that is the place to submit and discuss
> with the other contributors to that site.


Only the Netbeans section has a warning telling you to delete src.zip. 
Neither Intellij nor Eclipse do.


A user shouldn't have to do that anyway though! This could be easily 
fixed. Literally all you need to do is in this section:


// Zip module sources for standalone SDK
 ??? //
 ??? // NOTE: the input is taken from the modular-sdk/modules_src dir
 ??? // so that we don't have to duplicate the logic and create another
 ??? // temporary directory. This is somewhat inelegant, since the 
bundled sdk
 ??? // and the standalone sdk should be independent of one another, but 
seems
 ??? // better than the alternatives.
 ??? def zipSourceFilesTask = 
project.task("zipSourceFilesStandalone$t.capital", type: Zip, dependsOn: 
buildModulesTask) {
 ??????? destinationDir = file("${standaloneLibDir}")
 ??????? archiveName = standaloneSrcZipName
 ??????? includeEmptyDirs = false
 ??????? from modulesSrcDir
 ??????? include "**/*.java"
 ??? }


change:


destinationDir = file("${standaloneLibDir}")


to:


destinationDir = file("${standaloneSdkDir}")


That's it. Literally less than a minute, like I said. You can put zip 
files in zip files, it doesn't matter. This is a really stupid thing to 
be stubborn about.


>
> Thanks,
>
> - Johan
>
> On Thu, Dec 26, 2019 at 9:26 PM David Green <david_green at use.startmail.com>
> wrote:
>
>> This step fails:
>>
>>
>>
>> 3\. Create a library
>>
>> Go to File -&gt; Project Structure -&gt; Libraries and add the JavaFX 13
>> SDK
>> as a library to the project. Point to the lib folder of the JavaFX SDK.
>>
>>
>>
>> The src.zip located in this package lib will cause the build in IJ to
>> fail. I
>> don't know why, since it is source, albeit zipped.
>>
>>
>>
>> To get the project to build, I had to remove it. I placed it in a new src
>> folder I created at the same level as lib in the sdk.
>>
>>
>>
>>

From johnvalrose at gmail.com  Fri Dec 27 22:40:50 2019
From: johnvalrose at gmail.com (John-Val Rose)
Date: Sat, 28 Dec 2019 09:40:50 +1100
Subject: error in tutorial
In-Reply-To: <89d58181-5556-a270-48ce-6e11820ddf60@gmail.com>
References: <89d58181-5556-a270-48ce-6e11820ddf60@gmail.com>
Message-ID: <A1196427-C994-4B9E-B536-51FED53178AA@gmail.com>

Ty,

If it?s so easy to fix then why don?t you just fix it?

John-Val

> On 28 Dec 2019, at 09:14, Ty Young <youngty1997 at gmail.com> wrote:
> 
> ?
>> On 12/27/19 4:19 AM, Johan Vos wrote:
>> Hi David,
>> 
>> What tutorial are you talking about? If you refer to https://openjfx.io,
>> that is a community-initiative, developed at
>> https://github.com/openjfx/openjfx-docs .
>> So if you have issues and PR's, that is the place to submit and discuss
>> with the other contributors to that site.
> 
> 
> Only the Netbeans section has a warning telling you to delete src.zip. Neither Intellij nor Eclipse do.
> 
> 
> A user shouldn't have to do that anyway though! This could be easily fixed. Literally all you need to do is in this section:
> 
> 
> // Zip module sources for standalone SDK
>     //
>     // NOTE: the input is taken from the modular-sdk/modules_src dir
>     // so that we don't have to duplicate the logic and create another
>     // temporary directory. This is somewhat inelegant, since the bundled sdk
>     // and the standalone sdk should be independent of one another, but seems
>     // better than the alternatives.
>     def zipSourceFilesTask = project.task("zipSourceFilesStandalone$t.capital", type: Zip, dependsOn: buildModulesTask) {
>         destinationDir = file("${standaloneLibDir}")
>         archiveName = standaloneSrcZipName
>         includeEmptyDirs = false
>         from modulesSrcDir
>         include "**/*.java"
>     }
> 
> 
> change:

From youngty1997 at gmail.com  Fri Dec 27 23:09:18 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 27 Dec 2019 17:09:18 -0600
Subject: error in tutorial
In-Reply-To: <A1196427-C994-4B9E-B536-51FED53178AA@gmail.com>
References: <89d58181-5556-a270-48ce-6e11820ddf60@gmail.com>
 <A1196427-C994-4B9E-B536-51FED53178AA@gmail.com>
Message-ID: <35603fc2-8dea-7e67-1eb3-109032e86a6a@gmail.com>


On 12/27/19 4:40 PM, John-Val Rose wrote:
> Ty,
>
> If it?s so easy to fix then why don?t you just fix it?


I don't exactly have the ability to directly push changes to the repo...


>
> John-Val
>
>> On 28 Dec 2019, at 09:14, Ty Young <youngty1997 at gmail.com> wrote:
>>
>> ?
>>> On 12/27/19 4:19 AM, Johan Vos wrote:
>>> Hi David,
>>>
>>> What tutorial are you talking about? If you refer to https://openjfx.io,
>>> that is a community-initiative, developed at
>>> https://github.com/openjfx/openjfx-docs .
>>> So if you have issues and PR's, that is the place to submit and discuss
>>> with the other contributors to that site.
>>
>> Only the Netbeans section has a warning telling you to delete src.zip. Neither Intellij nor Eclipse do.
>>
>>
>> A user shouldn't have to do that anyway though! This could be easily fixed. Literally all you need to do is in this section:
>>
>>
>> // Zip module sources for standalone SDK
>>      //
>>      // NOTE: the input is taken from the modular-sdk/modules_src dir
>>      // so that we don't have to duplicate the logic and create another
>>      // temporary directory. This is somewhat inelegant, since the bundled sdk
>>      // and the standalone sdk should be independent of one another, but seems
>>      // better than the alternatives.
>>      def zipSourceFilesTask = project.task("zipSourceFilesStandalone$t.capital", type: Zip, dependsOn: buildModulesTask) {
>>          destinationDir = file("${standaloneLibDir}")
>>          archiveName = standaloneSrcZipName
>>          includeEmptyDirs = false
>>          from modulesSrcDir
>>          include "**/*.java"
>>      }
>>
>>
>> change:

From johan.vos at gluonhq.com  Sat Dec 28 10:53:29 2019
From: johan.vos at gluonhq.com (Johan Vos)
Date: Sat, 28 Dec 2019 11:53:29 +0100
Subject: error in tutorial
In-Reply-To: <35603fc2-8dea-7e67-1eb3-109032e86a6a@gmail.com>
References: <89d58181-5556-a270-48ce-6e11820ddf60@gmail.com>
 <A1196427-C994-4B9E-B536-51FED53178AA@gmail.com>
 <35603fc2-8dea-7e67-1eb3-109032e86a6a@gmail.com>
Message-ID: <CABxFH2E1ALKy3x75SAM3rX8OWq7Nkm=z+5oow_1NS8AcnJ5HNw@mail.gmail.com>

Hi Ty,

Since I have absolutely no idea what you are talking about, I have a few
questions:

1. "... push changes to the repo..."? -> It would help giving a bit context
instead of talking about "the repo". Since this is the openjfx-dev list,
chances are high you're talking about the JavaFX repository at
https://github.com/openjdk/jfx. In that case, please read the README and
CONTRIBUTING files there for advice on how to propose/make changes (note
that this will probably take longer than 1 minute, as we have strong
quality checks in place). If you talk about a different "repo", please
follow the explicit or implicit rules on that repo(sitory). For example, if
you talk about https://github.com/openjfx/openjfx-docs , please create an
issue and file a PR, and work with the community to get it accepted. (note
that in this case, this should not be discussed on the openjfx-dev list
(note the *dev*)).

2. You refer to informal or formal talks you had, but it is totally unclear
to me who you talked to about what. Frankly, we spent lots of time moving
all code and as much as possible the documentation to github, so we can
easily track discussions. (for JavaFX bugs, we use JBS, so that can be
discussed there) If someone said "it?s the way we?ve always done it?"
please refer to the issue where your request has been made and subsequently
rejected, so I can have a look at the context,

3. Can you write a few words about what the word "Community" means to you?
Many people in the JavaFX Ecosystem spent tons of spare time in making the
JavaFX "Community" a friendly place. I'm interested in your opinion about
that word. To give a few options, does it mean
A: I insult people and companies, use words like "smoking shrooms" and
"stubborn" and I expect everything I think about to be fixed magically
(since I suppose the volunteers have no life apart from doing what I want
them to do)
B: I friendly discuss issues and opportunities with fellow community
members, where I respect other opinions, keep discussions polite and
technical.
C: somewhere between A and B?

- Johan


On Sat, Dec 28, 2019 at 12:11 AM Ty Young <youngty1997 at gmail.com> wrote:

>
> On 12/27/19 4:40 PM, John-Val Rose wrote:
> > Ty,
> >
> > If it?s so easy to fix then why don?t you just fix it?
>
>
> I don't exactly have the ability to directly push changes to the repo...
>
>
> >
> > John-Val
> >
> >> On 28 Dec 2019, at 09:14, Ty Young <youngty1997 at gmail.com> wrote:
> >>
> >> ?
> >>> On 12/27/19 4:19 AM, Johan Vos wrote:
> >>> Hi David,
> >>>
> >>> What tutorial are you talking about? If you refer to
> https://openjfx.io,
> >>> that is a community-initiative, developed at
> >>> https://github.com/openjfx/openjfx-docs .
> >>> So if you have issues and PR's, that is the place to submit and discuss
> >>> with the other contributors to that site.
> >>
> >> Only the Netbeans section has a warning telling you to delete src.zip.
> Neither Intellij nor Eclipse do.
> >>
> >>
> >> A user shouldn't have to do that anyway though! This could be easily
> fixed. Literally all you need to do is in this section:
> >>
> >>
> >> // Zip module sources for standalone SDK
> >>      //
> >>      // NOTE: the input is taken from the modular-sdk/modules_src dir
> >>      // so that we don't have to duplicate the logic and create another
> >>      // temporary directory. This is somewhat inelegant, since the
> bundled sdk
> >>      // and the standalone sdk should be independent of one another,
> but seems
> >>      // better than the alternatives.
> >>      def zipSourceFilesTask =
> project.task("zipSourceFilesStandalone$t.capital", type: Zip, dependsOn:
> buildModulesTask) {
> >>          destinationDir = file("${standaloneLibDir}")
> >>          archiveName = standaloneSrcZipName
> >>          includeEmptyDirs = false
> >>          from modulesSrcDir
> >>          include "**/*.java"
> >>      }
> >>
> >>
> >> change:
>

From youngty1997 at gmail.com  Sat Dec 28 19:01:03 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Sat, 28 Dec 2019 13:01:03 -0600
Subject: error in tutorial
In-Reply-To: <CABxFH2E1ALKy3x75SAM3rX8OWq7Nkm=z+5oow_1NS8AcnJ5HNw@mail.gmail.com>
References: <89d58181-5556-a270-48ce-6e11820ddf60@gmail.com>
 <A1196427-C994-4B9E-B536-51FED53178AA@gmail.com>
 <35603fc2-8dea-7e67-1eb3-109032e86a6a@gmail.com>
 <CABxFH2E1ALKy3x75SAM3rX8OWq7Nkm=z+5oow_1NS8AcnJ5HNw@mail.gmail.com>
Message-ID: <139431be-42f5-50db-9249-6e78fa83fc25@gmail.com>

3. "community" is a funny word to describe JavaFX given it is 100% owned 
by Oracle and which no one can contribute to without signing away their 
rights to their own code.





On 12/28/19 4:53 AM, Johan Vos wrote:
> Hi Ty,
>
> Since I have absolutely no idea what you are talking about, I have a 
> few questions:
>
> 1. "... push changes to the repo..."? -> It would help giving a bit 
> context instead of talking about "the repo". Since this is the 
> openjfx-dev list, chances are high you're talking about the JavaFX 
> repository at https://github.com/openjdk/jfx. In that case, please 
> read the README and CONTRIBUTING files there for advice on how to 
> propose/make changes (note that this will probably take longer than 1 
> minute, as we have strong quality checks in place). If you talk about 
> a different "repo", please follow the explicit or implicit rules on 
> that repo(sitory). For example, if you talk about 
> https://github.com/openjfx/openjfx-docs?, please create an issue and 
> file a PR, and work with the community to get it accepted. (note that 
> in this case, this should not be discussed on the openjfx-dev list 
> (note the *dev*)).


This is not an issue of documentation. IDEs can and do provide the 
ability to designate an entire folder as a location of project 
libraries. You can specify a directory manually via command line in 
which contains Java 9 modules. To continue to entertain the idea that 
this is an issue of documentation is simply crazy. It's an easily 
fixable technical error.


>
> 2. You refer to informal or formal talks you had, but it is totally 
> unclear to me who you talked to about what. Frankly, we spent lots of 
> time moving all code and as much as possible the documentation to 
> github, so we can easily track discussions. (for JavaFX bugs, we use 
> JBS, so that can be discussed there) If someone said "it?s the way 
> we?ve always done it?" please refer to the issue where your request 
> has been made and subsequently rejected, so I can have a look at the 
> context,


It was an email a very long time ago on this list. Too lazy to dig it 
up, but I'm pretty sure it was from Kevin Rushforth. Again, very long 
time ago at this point.


>
> 3. Can you write a few words about what the word "Community" means to 
> you? Many people in the JavaFX Ecosystem spent tons of spare time in 
> making the JavaFX "Community" a friendly place. I'm interested in your 
> opinion about that word. To give a few options, does it mean
> A: I insult people and companies, use words like "smoking shrooms" and 
> "stubborn" and I expect everything I think about to be fixed magically 
> (since I suppose the volunteers have no life apart from doing what I 
> want them to do)


"community" is a funny word to describe JavaFX given it is 100% owned by 
Oracle and which no one(AFAIK) can contribute to without signing away 
their rights to their own code.


If this was a feature request I'd understand this nonsense but that's 
not at all what this is. This is a self created, self perpetuated, and 
needlessly self harming *technical* error defended using the worst 
possible defense against very real issues(the creation of this thread is 
proof). Source files(or zips containing such) are not libraries(AKA 
"libs") and it causes IDE issues(among other things). The fix is 
*really* simple.


and the whole (in essence) "everyone who works on JavaFX is a someone 
doing it in their free time is BS. Oracle developers are payed to work 
on JavaFX and are the ones who originally made JavaFX(AFAIK) and 
(presumably) the Gradle script. If someone with basically no knowledge 
of Gradle such as myself can scan through a file or use ctrl + f and 
read variable names then I'd hope someone with actual experience could 
do better. Maybe I'm wrong and am the one in actuality that is smoking 
shrooms.


> B: I friendly discuss issues and opportunities with fellow community 
> members, where I respect other opinions, keep discussions polite and 
> technical.


That's funny because I seem to remember during a JDK(or maybe it was 
exclusively JavaFX?) event that a presenter made a rather rude joke 
about my multi-threading issue I brought up on this list a long time 
ago. I don't remember specifically who made the joke but I do know as 
someone who watches said events on YouTube that those events are very 
incestuous. I guess because it was the other way around that it was OK 
though.


TL;DR: People in glass houses shouldn't throw stones.


> C: somewhere between A and B?
>
> - Johan
>
>
> On Sat, Dec 28, 2019 at 12:11 AM Ty Young <youngty1997 at gmail.com 
> <mailto:youngty1997 at gmail.com>> wrote:
>
>
>     On 12/27/19 4:40 PM, John-Val Rose wrote:
>     > Ty,
>     >
>     > If it?s so easy to fix then why don?t you just fix it?
>
>
>     I don't exactly have the ability to directly push changes to the
>     repo...
>
>
>     >
>     > John-Val
>     >
>     >> On 28 Dec 2019, at 09:14, Ty Young <youngty1997 at gmail.com
>     <mailto:youngty1997 at gmail.com>> wrote:
>     >>
>     >> ?
>     >>> On 12/27/19 4:19 AM, Johan Vos wrote:
>     >>> Hi David,
>     >>>
>     >>> What tutorial are you talking about? If you refer to
>     https://openjfx.io,
>     >>> that is a community-initiative, developed at
>     >>> https://github.com/openjfx/openjfx-docs .
>     >>> So if you have issues and PR's, that is the place to submit
>     and discuss
>     >>> with the other contributors to that site.
>     >>
>     >> Only the Netbeans section has a warning telling you to delete
>     src.zip. Neither Intellij nor Eclipse do.
>     >>
>     >>
>     >> A user shouldn't have to do that anyway though! This could be
>     easily fixed. Literally all you need to do is in this section:
>     >>
>     >>
>     >> // Zip module sources for standalone SDK
>     >>? ? ? //
>     >>? ? ? // NOTE: the input is taken from the
>     modular-sdk/modules_src dir
>     >>? ? ? // so that we don't have to duplicate the logic and create
>     another
>     >>? ? ? // temporary directory. This is somewhat inelegant, since
>     the bundled sdk
>     >>? ? ? // and the standalone sdk should be independent of one
>     another, but seems
>     >>? ? ? // better than the alternatives.
>     >>? ? ? def zipSourceFilesTask =
>     project.task("zipSourceFilesStandalone$t.capital", type: Zip,
>     dependsOn: buildModulesTask) {
>     >>? ? ? ? ? destinationDir = file("${standaloneLibDir}")
>     >>? ? ? ? ? archiveName = standaloneSrcZipName
>     >>? ? ? ? ? includeEmptyDirs = false
>     >>? ? ? ? ? from modulesSrcDir
>     >>? ? ? ? ? include "**/*.java"
>     >>? ? ? }
>     >>
>     >>
>     >> change:
>

From youngty1997 at gmail.com  Sat Dec 28 19:11:04 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Sat, 28 Dec 2019 13:11:04 -0600
Subject: error in tutorial
In-Reply-To: <139431be-42f5-50db-9249-6e78fa83fc25@gmail.com>
References: <139431be-42f5-50db-9249-6e78fa83fc25@gmail.com>
Message-ID: <7b61f40c-efc2-92e9-1218-66d552c05fac@gmail.com>






On 12/28/19 4:53 AM, Johan Vos wrote:
> Hi Ty,
>
> Since I have absolutely no idea what you are talking about, I have a 
> few questions:
>
> 1. "... push changes to the repo..."? -> It would help giving a bit 
> context instead of talking about "the repo". Since this is the 
> openjfx-dev list, chances are high you're talking about the JavaFX 
> repository at https://github.com/openjdk/jfx. In that case, please 
> read the README and CONTRIBUTING files there for advice on how to 
> propose/make changes (note that this will probably take longer than 1 
> minute, as we have strong quality checks in place). If you talk about 
> a different "repo", please follow the explicit or implicit rules on 
> that repo(sitory). For example, if you talk about 
> https://github.com/openjfx/openjfx-docs?, please create an issue and 
> file a PR, and work with the community to get it accepted. (note that 
> in this case, this should not be discussed on the openjfx-dev list 
> (note the *dev*)).


This is not an issue of documentation. IDEs can and do provide the 
ability to designate an entire folder as a location of project 
libraries. You can specify a directory manually via command line in 
which contains Java 9 modules. To continue to entertain the idea that 
this is an issue of documentation is simply crazy. It's an easily 
fixable technical error.


>
> 2. You refer to informal or formal talks you had, but it is totally 
> unclear to me who you talked to about what. Frankly, we spent lots of 
> time moving all code and as much as possible the documentation to 
> github, so we can easily track discussions. (for JavaFX bugs, we use 
> JBS, so that can be discussed there) If someone said "it?s the way 
> we?ve always done it?" please refer to the issue where your request 
> has been made and subsequently rejected, so I can have a look at the 
> context,


It was an email a very long time ago on this list. Too lazy to dig it 
up, but I'm pretty sure it was from Kevin Rushforth. Again, very long 
time ago at this point.


>
> 3. Can you write a few words about what the word "Community" means to 
> you? Many people in the JavaFX Ecosystem spent tons of spare time in 
> making the JavaFX "Community" a friendly place. I'm interested in your 
> opinion about that word. To give a few options, does it mean
> A: I insult people and companies, use words like "smoking shrooms" and 
> "stubborn" and I expect everything I think about to be fixed magically 
> (since I suppose the volunteers have no life apart from doing what I 
> want them to do)


"community" is a funny word to describe JavaFX given it is 100% owned by 
Oracle and which no one(AFAIK) can contribute to without signing away 
their rights to their own code.


If this was a feature request I'd understand this nonsense but that's 
not at all what this is. This is a self created, self perpetuated, and 
needlessly self harming *technical* error defended using the worst 
possible defense against very real issues(the creation of this thread is 
proof). Source files(or zips containing such) are not libraries(AKA 
"libs") and it causes IDE issues(among other things). The fix is 
*really* simple.


and the whole (in essence) "everyone who works on JavaFX is a someone 
doing it in their free time is BS. Oracle developers are payed to work 
on JavaFX and are the ones who originally made JavaFX(AFAIK) and 
(presumably) the Gradle script. If someone with basically no knowledge 
of Gradle such as myself can scan through a file or use ctrl + f and 
read variable names then I'd hope someone with actual experience could 
do better. Maybe I'm wrong and am the one in actuality that is smoking 
shrooms.


> B: I friendly discuss issues and opportunities with fellow community 
> members, where I respect other opinions, keep discussions polite and 
> technical.


That's funny because I seem to remember during a JDK(or maybe it was 
exclusively JavaFX?) event that a presenter made a rather rude joke 
about my multi-threading issue I brought up on this list a long time 
ago. I don't remember specifically who made the joke but I do know as 
someone who watches said events on YouTube that those events are very 
incestuous. I guess because it was the other way around that it was OK 
though.


TL;DR: People in glass houses shouldn't throw stones.


> C: somewhere between A and B?
>
> - Johan
>
>
> On Sat, Dec 28, 2019 at 12:11 AM Ty Young <youngty1997 at gmail.com 
> <mailto:youngty1997 at gmail.com>> wrote:
>
>
>     On 12/27/19 4:40 PM, John-Val Rose wrote:
>     > Ty,
>     >
>     > If it?s so easy to fix then why don?t you just fix it?
>
>
>     I don't exactly have the ability to directly push changes to the
>     repo...
>
>
>     >
>     > John-Val
>     >
>     >> On 28 Dec 2019, at 09:14, Ty Young <youngty1997 at gmail.com
>     <mailto:youngty1997 at gmail.com>> wrote:
>     >>
>     >> ?
>     >>> On 12/27/19 4:19 AM, Johan Vos wrote:
>     >>> Hi David,
>     >>>
>     >>> What tutorial are you talking about? If you refer to
>     https://openjfx.io,
>     >>> that is a community-initiative, developed at
>     >>> https://github.com/openjfx/openjfx-docs .
>     >>> So if you have issues and PR's, that is the place to submit
>     and discuss
>     >>> with the other contributors to that site.
>     >>
>     >> Only the Netbeans section has a warning telling you to delete
>     src.zip. Neither Intellij nor Eclipse do.
>     >>
>     >>
>     >> A user shouldn't have to do that anyway though! This could be
>     easily fixed. Literally all you need to do is in this section:
>     >>
>     >>
>     >> // Zip module sources for standalone SDK
>     >>? ? ? //
>     >>? ? ? // NOTE: the input is taken from the
>     modular-sdk/modules_src dir
>     >>? ? ? // so that we don't have to duplicate the logic and create
>     another
>     >>? ? ? // temporary directory. This is somewhat inelegant, since
>     the bundled sdk
>     >>? ? ? // and the standalone sdk should be independent of one
>     another, but seems
>     >>? ? ? // better than the alternatives.
>     >>? ? ? def zipSourceFilesTask =
>     project.task("zipSourceFilesStandalone$t.capital", type: Zip,
>     dependsOn: buildModulesTask) {
>     >>? ? ? ? ? destinationDir = file("${standaloneLibDir}")
>     >>? ? ? ? ? archiveName = standaloneSrcZipName
>     >>? ? ? ? ? includeEmptyDirs = false
>     >>? ? ? ? ? from modulesSrcDir
>     >>? ? ? ? ? include "**/*.java"
>     >>? ? ? }
>     >>
>     >>
>     >> change:
>

From jvos at openjdk.java.net  Mon Dec 30 11:10:30 2019
From: jvos at openjdk.java.net (Johan Vos)
Date: Mon, 30 Dec 2019 11:10:30 GMT
Subject: RFR: 8236448: Remove unused and repair broken Android/Dalvik code
Message-ID: <LSlNWMVTtEDd4jvveWlxDpstkDurdf-DBKkJVe5wvQo=.a94d92a2-3df1-4eb3-bf2d-74b708a810f8@github.com>

This allows to build the JavaFX jars and native libraries for Android devices

-------------

Commits:
 - 504a2440: fix trailing whitespace
 - 97a3f14f: Fix for #8236448

Changes: https://git.openjdk.java.net/jfx/pull/75/files
 Webrev: https://webrevs.openjdk.java.net/jfx/75/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236448
  Stats: 1039 lines in 14 files changed: 315 ins; 615 del; 109 mod
  Patch: https://git.openjdk.java.net/jfx/pull/75.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/75/head:pull/75

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

From anthonyv.be at outlook.com  Mon Dec 30 16:55:52 2019
From: anthonyv.be at outlook.com (Anthony Vanelverdinghe)
Date: Mon, 30 Dec 2019 17:55:52 +0100
Subject: error in tutorial
In-Reply-To: <7b61f40c-efc2-92e9-1218-66d552c05fac@gmail.com>
References: <139431be-42f5-50db-9249-6e78fa83fc25@gmail.com>
 <7b61f40c-efc2-92e9-1218-66d552c05fac@gmail.com>
Message-ID: <AM0PR07MB6372B7859BFDAD0C7D920333E8270@AM0PR07MB6372.eurprd07.prod.outlook.com>

Hi

Some observations:
This is the mentioned e-mail: 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022497.html
The lib folder contains a src.zip file, both in JDK 13.0.1 and in JavaFX 
SDK 13.0.1, so this is consistent.
For NetBeans and IntelliJ IDEA (I didn't check Eclipse):
- neither supports jmod files in libraries (see [1])
- both support selecting individual jar files, after which things work 
as expected
- neither constructs an optimal modulepath, even if the application is 
modular

So I believe that this is mostly just a documentation issue: rather than 
saying "add the lib folder of the SDK" it should say "add all jar files 
in the lib folder of the SDK". Additionally, IDEs should be improved to 
support jmod files in libraries, and to construct optimal modulepaths 
for modular applications.

Kind regards,
Anthony

[1] https://youtrack.jetbrains.com/issue/IDEA-171448

On 28/12/2019 20:11, Ty Young wrote:
>
>
>
>
>
> On 12/28/19 4:53 AM, Johan Vos wrote:
>> Hi Ty,
>>
>> Since I have absolutely no idea what you are talking about, I have a 
>> few questions:
>>
>> 1. "... push changes to the repo..."? -> It would help giving a bit 
>> context instead of talking about "the repo". Since this is the 
>> openjfx-dev list, chances are high you're talking about the JavaFX 
>> repository at https://github.com/openjdk/jfx. In that case, please 
>> read the README and CONTRIBUTING files there for advice on how to 
>> propose/make changes (note that this will probably take longer than 1 
>> minute, as we have strong quality checks in place). If you talk about 
>> a different "repo", please follow the explicit or implicit rules on 
>> that repo(sitory). For example, if you talk about 
>> https://github.com/openjfx/openjfx-docs?, please create an issue and 
>> file a PR, and work with the community to get it accepted. (note that 
>> in this case, this should not be discussed on the openjfx-dev list 
>> (note the *dev*)).
>
>
> This is not an issue of documentation. IDEs can and do provide the 
> ability to designate an entire folder as a location of project 
> libraries. You can specify a directory manually via command line in 
> which contains Java 9 modules. To continue to entertain the idea that 
> this is an issue of documentation is simply crazy. It's an easily 
> fixable technical error.
>
>
>>
>> 2. You refer to informal or formal talks you had, but it is totally 
>> unclear to me who you talked to about what. Frankly, we spent lots of 
>> time moving all code and as much as possible the documentation to 
>> github, so we can easily track discussions. (for JavaFX bugs, we use 
>> JBS, so that can be discussed there) If someone said "it?s the way 
>> we?ve always done it?" please refer to the issue where your request 
>> has been made and subsequently rejected, so I can have a look at the 
>> context,
>
>
> It was an email a very long time ago on this list. Too lazy to dig it 
> up, but I'm pretty sure it was from Kevin Rushforth. Again, very long 
> time ago at this point.
>
>
>>
>> 3. Can you write a few words about what the word "Community" means to 
>> you? Many people in the JavaFX Ecosystem spent tons of spare time in 
>> making the JavaFX "Community" a friendly place. I'm interested in 
>> your opinion about that word. To give a few options, does it mean
>> A: I insult people and companies, use words like "smoking shrooms" 
>> and "stubborn" and I expect everything I think about to be fixed 
>> magically (since I suppose the volunteers have no life apart from 
>> doing what I want them to do)
>
>
> "community" is a funny word to describe JavaFX given it is 100% owned 
> by Oracle and which no one(AFAIK) can contribute to without signing 
> away their rights to their own code.
>
>
> If this was a feature request I'd understand this nonsense but that's 
> not at all what this is. This is a self created, self perpetuated, and 
> needlessly self harming *technical* error defended using the worst 
> possible defense against very real issues(the creation of this thread 
> is proof). Source files(or zips containing such) are not libraries(AKA 
> "libs") and it causes IDE issues(among other things). The fix is 
> *really* simple.
>
>
> and the whole (in essence) "everyone who works on JavaFX is a someone 
> doing it in their free time is BS. Oracle developers are payed to work 
> on JavaFX and are the ones who originally made JavaFX(AFAIK) and 
> (presumably) the Gradle script. If someone with basically no knowledge 
> of Gradle such as myself can scan through a file or use ctrl + f and 
> read variable names then I'd hope someone with actual experience could 
> do better. Maybe I'm wrong and am the one in actuality that is smoking 
> shrooms.
>
>
>> B: I friendly discuss issues and opportunities with fellow community 
>> members, where I respect other opinions, keep discussions polite and 
>> technical.
>
>
> That's funny because I seem to remember during a JDK(or maybe it was 
> exclusively JavaFX?) event that a presenter made a rather rude joke 
> about my multi-threading issue I brought up on this list a long time 
> ago. I don't remember specifically who made the joke but I do know as 
> someone who watches said events on YouTube that those events are very 
> incestuous. I guess because it was the other way around that it was OK 
> though.
>
>
> TL;DR: People in glass houses shouldn't throw stones.
>
>
>> C: somewhere between A and B?
>>
>> - Johan
>>
>>
>> On Sat, Dec 28, 2019 at 12:11 AM Ty Young <youngty1997 at gmail.com 
>> <mailto:youngty1997 at gmail.com>> wrote:
>>
>>
>> ??? On 12/27/19 4:40 PM, John-Val Rose wrote:
>> ??? > Ty,
>> ??? >
>> ??? > If it?s so easy to fix then why don?t you just fix it?
>>
>>
>> ??? I don't exactly have the ability to directly push changes to the
>> ??? repo...
>>
>>
>> ??? >
>> ??? > John-Val
>> ??? >
>> ??? >> On 28 Dec 2019, at 09:14, Ty Young <youngty1997 at gmail.com
>> ??? <mailto:youngty1997 at gmail.com>> wrote:
>> ??? >>
>> ??? >> ?
>> ??? >>> On 12/27/19 4:19 AM, Johan Vos wrote:
>> ??? >>> Hi David,
>> ??? >>>
>> ??? >>> What tutorial are you talking about? If you refer to
>> ??? https://openjfx.io,
>> ??? >>> that is a community-initiative, developed at
>> ??? >>> https://github.com/openjfx/openjfx-docs .
>> ??? >>> So if you have issues and PR's, that is the place to submit
>> ??? and discuss
>> ??? >>> with the other contributors to that site.
>> ??? >>
>> ??? >> Only the Netbeans section has a warning telling you to delete
>> ??? src.zip. Neither Intellij nor Eclipse do.
>> ??? >>
>> ??? >>
>> ??? >> A user shouldn't have to do that anyway though! This could be
>> ??? easily fixed. Literally all you need to do is in this section:
>> ??? >>
>> ??? >>
>> ??? >> // Zip module sources for standalone SDK
>> ??? >>? ? ? //
>> ??? >>? ? ? // NOTE: the input is taken from the
>> ??? modular-sdk/modules_src dir
>> ??? >>? ? ? // so that we don't have to duplicate the logic and create
>> ??? another
>> ??? >>? ? ? // temporary directory. This is somewhat inelegant, since
>> ??? the bundled sdk
>> ??? >>? ? ? // and the standalone sdk should be independent of one
>> ??? another, but seems
>> ??? >>? ? ? // better than the alternatives.
>> ??? >>? ? ? def zipSourceFilesTask =
>> ??? project.task("zipSourceFilesStandalone$t.capital", type: Zip,
>> ??? dependsOn: buildModulesTask) {
>> ??? >>? ? ? ? ? destinationDir = file("${standaloneLibDir}")
>> ??? >>? ? ? ? ? archiveName = standaloneSrcZipName
>> ??? >>? ? ? ? ? includeEmptyDirs = false
>> ??? >>? ? ? ? ? from modulesSrcDir
>> ??? >>? ? ? ? ? include "**/*.java"
>> ??? >>? ? ? }
>> ??? >>
>> ??? >>
>> ??? >> change:
>>

From youngty1997 at gmail.com  Mon Dec 30 23:41:45 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Mon, 30 Dec 2019 17:41:45 -0600
Subject: error in tutorial
In-Reply-To: <AM0PR07MB6372B7859BFDAD0C7D920333E8270@AM0PR07MB6372.eurprd07.prod.outlook.com>
References: <139431be-42f5-50db-9249-6e78fa83fc25@gmail.com>
 <7b61f40c-efc2-92e9-1218-66d552c05fac@gmail.com>
 <AM0PR07MB6372B7859BFDAD0C7D920333E8270@AM0PR07MB6372.eurprd07.prod.outlook.com>
Message-ID: <2caa7551-aa43-d64a-d9e0-ba9510a5b106@gmail.com>


On 12/30/19 10:55 AM, Anthony Vanelverdinghe wrote:
> Hi
>
> Some observations:
> This is the mentioned e-mail: 
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022497.html


Thanks for finding it.


> The lib folder contains a src.zip file, both in JDK 13.0.1 and in 
> JavaFX SDK 13.0.1, so this is consistent.


Consistent but irrelevant. The only jar in jdk/lib is jrt-fs by default. 
Everything else is binary .so and properties files basically.


JavaFX on the other hand has about a dozen jars and you're supposed to 
include all the Jars at once and/or make them a "library"(same thing, in 
effect).


> For NetBeans and IntelliJ IDEA (I didn't check Eclipse):
> - neither supports jmod files in libraries (see [1])


Yep. Build system and IDE support is still lacking despite Java 9 being 
released like 2 years ago now.


> - both support selecting individual jar files, after which things work 
> as expected
> - neither constructs an optimal modulepath, even if the application is 
> modular
>
> So I believe that this is mostly just a documentation issue: rather 
> than saying "add the lib folder of the SDK" it should say "add all jar 
> files in the lib folder of the SDK". 


JavaFX isn't intended to be used piecemeal. Besides, if you individually 
just include the jar files then the native libraries bundles with JavaFX 
won't be included.


> Additionally, IDEs should be improved to support jmod files in 
> libraries, and to construct optimal modulepaths for modular applications.


Good luck doing that. Netbeans still spits out a pre java 9 command line 
string that is *supposed* to be able to launch the application from the 
command line. It doesn't.


>
> Kind regards,
> Anthony
>
> [1] https://youtrack.jetbrains.com/issue/IDEA-171448
>
> On 28/12/2019 20:11, Ty Young wrote:
>>
>>
>>
>>
>>
>> On 12/28/19 4:53 AM, Johan Vos wrote:
>>> Hi Ty,
>>>
>>> Since I have absolutely no idea what you are talking about, I have a 
>>> few questions:
>>>
>>> 1. "... push changes to the repo..."? -> It would help giving a bit 
>>> context instead of talking about "the repo". Since this is the 
>>> openjfx-dev list, chances are high you're talking about the JavaFX 
>>> repository at https://github.com/openjdk/jfx. In that case, please 
>>> read the README and CONTRIBUTING files there for advice on how to 
>>> propose/make changes (note that this will probably take longer than 
>>> 1 minute, as we have strong quality checks in place). If you talk 
>>> about a different "repo", please follow the explicit or implicit 
>>> rules on that repo(sitory). For example, if you talk about 
>>> https://github.com/openjfx/openjfx-docs?, please create an issue and 
>>> file a PR, and work with the community to get it accepted. (note 
>>> that in this case, this should not be discussed on the openjfx-dev 
>>> list (note the *dev*)).
>>
>>
>> This is not an issue of documentation. IDEs can and do provide the 
>> ability to designate an entire folder as a location of project 
>> libraries. You can specify a directory manually via command line in 
>> which contains Java 9 modules. To continue to entertain the idea that 
>> this is an issue of documentation is simply crazy. It's an easily 
>> fixable technical error.
>>
>>
>>>
>>> 2. You refer to informal or formal talks you had, but it is totally 
>>> unclear to me who you talked to about what. Frankly, we spent lots 
>>> of time moving all code and as much as possible the documentation to 
>>> github, so we can easily track discussions. (for JavaFX bugs, we use 
>>> JBS, so that can be discussed there) If someone said "it?s the way 
>>> we?ve always done it?" please refer to the issue where your request 
>>> has been made and subsequently rejected, so I can have a look at the 
>>> context,
>>
>>
>> It was an email a very long time ago on this list. Too lazy to dig it 
>> up, but I'm pretty sure it was from Kevin Rushforth. Again, very long 
>> time ago at this point.
>>
>>
>>>
>>> 3. Can you write a few words about what the word "Community" means 
>>> to you? Many people in the JavaFX Ecosystem spent tons of spare time 
>>> in making the JavaFX "Community" a friendly place. I'm interested in 
>>> your opinion about that word. To give a few options, does it mean
>>> A: I insult people and companies, use words like "smoking shrooms" 
>>> and "stubborn" and I expect everything I think about to be fixed 
>>> magically (since I suppose the volunteers have no life apart from 
>>> doing what I want them to do)
>>
>>
>> "community" is a funny word to describe JavaFX given it is 100% owned 
>> by Oracle and which no one(AFAIK) can contribute to without signing 
>> away their rights to their own code.
>>
>>
>> If this was a feature request I'd understand this nonsense but that's 
>> not at all what this is. This is a self created, self perpetuated, 
>> and needlessly self harming *technical* error defended using the 
>> worst possible defense against very real issues(the creation of this 
>> thread is proof). Source files(or zips containing such) are not 
>> libraries(AKA "libs") and it causes IDE issues(among other things). 
>> The fix is *really* simple.
>>
>>
>> and the whole (in essence) "everyone who works on JavaFX is a someone 
>> doing it in their free time is BS. Oracle developers are payed to 
>> work on JavaFX and are the ones who originally made JavaFX(AFAIK) and 
>> (presumably) the Gradle script. If someone with basically no 
>> knowledge of Gradle such as myself can scan through a file or use 
>> ctrl + f and read variable names then I'd hope someone with actual 
>> experience could do better. Maybe I'm wrong and am the one in 
>> actuality that is smoking shrooms.
>>
>>
>>> B: I friendly discuss issues and opportunities with fellow community 
>>> members, where I respect other opinions, keep discussions polite and 
>>> technical.
>>
>>
>> That's funny because I seem to remember during a JDK(or maybe it was 
>> exclusively JavaFX?) event that a presenter made a rather rude joke 
>> about my multi-threading issue I brought up on this list a long time 
>> ago. I don't remember specifically who made the joke but I do know as 
>> someone who watches said events on YouTube that those events are very 
>> incestuous. I guess because it was the other way around that it was 
>> OK though.
>>
>>
>> TL;DR: People in glass houses shouldn't throw stones.
>>
>>
>>> C: somewhere between A and B?
>>>
>>> - Johan
>>>
>>>
>>> On Sat, Dec 28, 2019 at 12:11 AM Ty Young <youngty1997 at gmail.com 
>>> <mailto:youngty1997 at gmail.com>> wrote:
>>>
>>>
>>> ??? On 12/27/19 4:40 PM, John-Val Rose wrote:
>>> ??? > Ty,
>>> ??? >
>>> ??? > If it?s so easy to fix then why don?t you just fix it?
>>>
>>>
>>> ??? I don't exactly have the ability to directly push changes to the
>>> ??? repo...
>>>
>>>
>>> ??? >
>>> ??? > John-Val
>>> ??? >
>>> ??? >> On 28 Dec 2019, at 09:14, Ty Young <youngty1997 at gmail.com
>>> ??? <mailto:youngty1997 at gmail.com>> wrote:
>>> ??? >>
>>> ??? >> ?
>>> ??? >>> On 12/27/19 4:19 AM, Johan Vos wrote:
>>> ??? >>> Hi David,
>>> ??? >>>
>>> ??? >>> What tutorial are you talking about? If you refer to
>>> ??? https://openjfx.io,
>>> ??? >>> that is a community-initiative, developed at
>>> ??? >>> https://github.com/openjfx/openjfx-docs .
>>> ??? >>> So if you have issues and PR's, that is the place to submit
>>> ??? and discuss
>>> ??? >>> with the other contributors to that site.
>>> ??? >>
>>> ??? >> Only the Netbeans section has a warning telling you to delete
>>> ??? src.zip. Neither Intellij nor Eclipse do.
>>> ??? >>
>>> ??? >>
>>> ??? >> A user shouldn't have to do that anyway though! This could be
>>> ??? easily fixed. Literally all you need to do is in this section:
>>> ??? >>
>>> ??? >>
>>> ??? >> // Zip module sources for standalone SDK
>>> ??? >>? ? ? //
>>> ??? >>? ? ? // NOTE: the input is taken from the
>>> ??? modular-sdk/modules_src dir
>>> ??? >>? ? ? // so that we don't have to duplicate the logic and create
>>> ??? another
>>> ??? >>? ? ? // temporary directory. This is somewhat inelegant, since
>>> ??? the bundled sdk
>>> ??? >>? ? ? // and the standalone sdk should be independent of one
>>> ??? another, but seems
>>> ??? >>? ? ? // better than the alternatives.
>>> ??? >>? ? ? def zipSourceFilesTask =
>>> ??? project.task("zipSourceFilesStandalone$t.capital", type: Zip,
>>> ??? dependsOn: buildModulesTask) {
>>> ??? >>? ? ? ? ? destinationDir = file("${standaloneLibDir}")
>>> ??? >>? ? ? ? ? archiveName = standaloneSrcZipName
>>> ??? >>? ? ? ? ? includeEmptyDirs = false
>>> ??? >>? ? ? ? ? from modulesSrcDir
>>> ??? >>? ? ? ? ? include "**/*.java"
>>> ??? >>? ? ? }
>>> ??? >>
>>> ??? >>
>>> ??? >> change:
>>>

From kcr at openjdk.java.net  Tue Dec 31 14:31:33 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 31 Dec 2019 14:31:33 GMT
Subject: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <3cbQ0VzO46Fsy_lCMaktyATqNMxKtreXXQ7CWhdORmA=.e089b35b-a3a9-4d1e-b147-9002a60849a0@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <4-1M42tYCNITil8q1YQEIagSbePyDfZglET1OZTJMlc=.6e0fb043-a534-415c-9637-dbb85622e39d@github.com>
 <hCpM6d-VogKWvd66yibDiPAOn6VWlyWVLCJcwcMJ7yo=.3785aa05-221c-4d06-996d-3544bb47e000@github.com>
 <uG7wl2m0GL1XMZ9cMChw8PNQ8Asqyub9eAbyBdlATEA=.a42638f4-280f-4e50-9e84-d9d30acf7d9a@github.com>
 <_tElrFJfsMSasOUFuTi2aegqQtkwxLtocLOhmVEFoDQ=.2316a5d2-dd40-4fd1-86b7-53fd7c13be1c@github.com>
 <odTtdt4wlSe2RMA-XAFHgPUD0FYN_j37G_51cGPfJ5A=.3e65560b-d336-4d10-adfc-9c082c8c3ffd@github.com>
 <3cbQ0VzO46Fsy_lCMaktyATqNMxKtreXXQ7CWhdORmA=.e089b35b-a3a9-4d1e-b147-9002a60849a0@github.com>
Message-ID: <GTKvXhXajvUfuWyj6rKmoU9jrO-Xbc3GQ9HV_WMQlKg=.bd9a8b02-5cde-48ab-b827-b579270466c4@github.com>

On Sat, 21 Dec 2019 20:35:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> Link problem appears to just be a missing slash: https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
> 
>> Link problem appears to just be a missing slash: https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
> 
> Seems this was fixed yesterday : https://github.com/openjdk/skara/pull/344

@swpalmer The change still needs my completed review -- note that there is currently only one reviewer listed in the __Approvers__ section above. Once I approve, which I will do soon, I will sponsor it.

I'm still looking for ways to make the CONTRIBUTING guidelines more clear as to when it is OK to integrate. I'll take a stab at it in the new year...

-------------

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

From kcr at openjdk.java.net  Tue Dec 31 16:15:25 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 31 Dec 2019 16:15:25 GMT
Subject: RFR: 8236484: Compile error in monocle dispman
In-Reply-To: <apzKeEAtPEmQqIyv0Whr0wX9VWGsUdFngRvCdhCHnhQ=.e753f03e-9c5a-4a2e-bfe7-28e910b39861@github.com>
References: <apzKeEAtPEmQqIyv0Whr0wX9VWGsUdFngRvCdhCHnhQ=.e753f03e-9c5a-4a2e-bfe7-28e910b39861@github.com>
Message-ID: <kjDkZqTpbu_3QgAvP9qGLUc4B-7CQK7sTGgRJpnTpyA=.69ddb762-cbd5-4a96-bd0d-e2ce0b8e40d2@github.com>

On Sat, 21 Dec 2019 18:10:37 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Trivial fix for a compiler error where a void function returns a long



-------------

Marked as reviewed by kcr (Lead).

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

From kevin.rushforth at oracle.com  Tue Dec 31 17:45:16 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 31 Dec 2019 09:45:16 -0800
Subject: Should Skara tooling invalidate approvals when new commits are
 pushed? [was: RFR: 8130738: Add tabSize property to Text and TextFlow]
Message-ID: <c8c7a4fe-faca-1afc-d8ff-a59dda0a5497@oracle.com>

Since this isn't directly related to the PR in question, I'm starting a 
new thread.

On 12/20/2019 7:22 PM, Philip Race wrote:
> On 12/20/19, 7:04 PM, Scott Palmer wrote:
>> I'm not sure if I'me supposed to try to integrate now that I've made 
>> that 10 ->? 0 change, or if the new change resets the need for review...
>
> It shows ready, which surprises me.
> Still learning skara .. I'd expect any change to reset as how can it 
> know if it is
> a? good or insignificant change or not no matter how the commenter 
> characterised the issue ?

Pushing a new commit doesn't automatically invalidate existing 
approvals, although it is highlighted in the "Approvers" section that 
the approval was for a prior commit:

 ??? Approvers
 ??????? Phil Race (prr - Reviewer) Note! Review applies to f846ad6

I remember bringing this up with the Skara team during my initial 
testing, since I also had wondered whether pushing a new commit should 
invalidate approvals. The current policy allows for doing trivial fixes 
brought up when approving a review (e.g., a change in a comment or 
formatting) without requiring all reviewers to re-approve. It matches 
current practice for email-based reviews, so I think the current 
behavior is a reasonable default.

They did say that they could implement an optional feature (i.e., a 
project would need to opt-in to this behavior, probably via a 
.jcheck/conf property) to invalidate all approvals upon pushing a new 
commit, but I don't think an RFE was filed to track it.

This seems like it could be a valuable feature, although it does come 
with a slight cost in terms of timing and flexibility. What do others think?

-- Kevin


From kevin.rushforth at oracle.com  Tue Dec 31 18:17:09 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 31 Dec 2019 10:17:09 -0800
Subject: error in tutorial
In-Reply-To: <AM0PR07MB6372B7859BFDAD0C7D920333E8270@AM0PR07MB6372.eurprd07.prod.outlook.com>
References: <139431be-42f5-50db-9249-6e78fa83fc25@gmail.com>
 <7b61f40c-efc2-92e9-1218-66d552c05fac@gmail.com>
 <AM0PR07MB6372B7859BFDAD0C7D920333E8270@AM0PR07MB6372.eurprd07.prod.outlook.com>
Message-ID: <52b87213-2e8b-7f64-75fc-281c9a93a940@oracle.com>

Ignoring jmods for a moment, since those are only intended to be used by 
jlink to produce an image that includes the modules (jmods are not a 
runtime format)...

The issue being caused by the src.zip in the lib directory of the JavaFX 
SDK seems more like a problem with the IDE(s) in question than with the 
JavaFX SDK. Both javac and java are perfectly happy with a module path 
that points to the lib directory, and will only consider the .jar files 
in that directory, ignoring other files. I note that in addition to 
src.zip, the lib directory contains several native libraries on Linux 
(*.so) and Mac (*.dylib).

While we could relocate just the src.zip file, as a workaround for what 
looks like an IDE problem, it isn't as trivial as Ty's post suggests. 
For one thing, this would be an incompatible change (although a minor 
one), and would require a CSR. I am not in favor of this change, but we 
can discuss it on this list if others feel differently. Also, as Johan 
pointed out, we will need a bug in JBS to track this.

-- Kevin


On 12/30/2019 8:55 AM, Anthony Vanelverdinghe wrote:
> Hi
>
> Some observations:
> This is the mentioned e-mail: 
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022497.html
> The lib folder contains a src.zip file, both in JDK 13.0.1 and in 
> JavaFX SDK 13.0.1, so this is consistent.
> For NetBeans and IntelliJ IDEA (I didn't check Eclipse):
> - neither supports jmod files in libraries (see [1])
> - both support selecting individual jar files, after which things work 
> as expected
> - neither constructs an optimal modulepath, even if the application is 
> modular
>
> So I believe that this is mostly just a documentation issue: rather 
> than saying "add the lib folder of the SDK" it should say "add all jar 
> files in the lib folder of the SDK". Additionally, IDEs should be 
> improved to support jmod files in libraries, and to construct optimal 
> modulepaths for modular applications.
>
> Kind regards,
> Anthony
>
> [1] https://youtrack.jetbrains.com/issue/IDEA-171448
>
> On 28/12/2019 20:11, Ty Young wrote:
>>
>>
>>
>>
>>
>> On 12/28/19 4:53 AM, Johan Vos wrote:
>>> Hi Ty,
>>>
>>> Since I have absolutely no idea what you are talking about, I have a 
>>> few questions:
>>>
>>> 1. "... push changes to the repo..."? -> It would help giving a bit 
>>> context instead of talking about "the repo". Since this is the 
>>> openjfx-dev list, chances are high you're talking about the JavaFX 
>>> repository at https://github.com/openjdk/jfx. In that case, please 
>>> read the README and CONTRIBUTING files there for advice on how to 
>>> propose/make changes (note that this will probably take longer than 
>>> 1 minute, as we have strong quality checks in place). If you talk 
>>> about a different "repo", please follow the explicit or implicit 
>>> rules on that repo(sitory). For example, if you talk about 
>>> https://github.com/openjfx/openjfx-docs?, please create an issue and 
>>> file a PR, and work with the community to get it accepted. (note 
>>> that in this case, this should not be discussed on the openjfx-dev 
>>> list (note the *dev*)).
>>
>>
>> This is not an issue of documentation. IDEs can and do provide the 
>> ability to designate an entire folder as a location of project 
>> libraries. You can specify a directory manually via command line in 
>> which contains Java 9 modules. To continue to entertain the idea that 
>> this is an issue of documentation is simply crazy. It's an easily 
>> fixable technical error.
>>
>>
>>>
>>> 2. You refer to informal or formal talks you had, but it is totally 
>>> unclear to me who you talked to about what. Frankly, we spent lots 
>>> of time moving all code and as much as possible the documentation to 
>>> github, so we can easily track discussions. (for JavaFX bugs, we use 
>>> JBS, so that can be discussed there) If someone said "it?s the way 
>>> we?ve always done it?" please refer to the issue where your request 
>>> has been made and subsequently rejected, so I can have a look at the 
>>> context,
>>
>>
>> It was an email a very long time ago on this list. Too lazy to dig it 
>> up, but I'm pretty sure it was from Kevin Rushforth. Again, very long 
>> time ago at this point.
>>
>>
>>>
>>> 3. Can you write a few words about what the word "Community" means 
>>> to you? Many people in the JavaFX Ecosystem spent tons of spare time 
>>> in making the JavaFX "Community" a friendly place. I'm interested in 
>>> your opinion about that word. To give a few options, does it mean
>>> A: I insult people and companies, use words like "smoking shrooms" 
>>> and "stubborn" and I expect everything I think about to be fixed 
>>> magically (since I suppose the volunteers have no life apart from 
>>> doing what I want them to do)
>>
>>
>> "community" is a funny word to describe JavaFX given it is 100% owned 
>> by Oracle and which no one(AFAIK) can contribute to without signing 
>> away their rights to their own code.
>>
>>
>> If this was a feature request I'd understand this nonsense but that's 
>> not at all what this is. This is a self created, self perpetuated, 
>> and needlessly self harming *technical* error defended using the 
>> worst possible defense against very real issues(the creation of this 
>> thread is proof). Source files(or zips containing such) are not 
>> libraries(AKA "libs") and it causes IDE issues(among other things). 
>> The fix is *really* simple.
>>
>>
>> and the whole (in essence) "everyone who works on JavaFX is a someone 
>> doing it in their free time is BS. Oracle developers are payed to 
>> work on JavaFX and are the ones who originally made JavaFX(AFAIK) and 
>> (presumably) the Gradle script. If someone with basically no 
>> knowledge of Gradle such as myself can scan through a file or use 
>> ctrl + f and read variable names then I'd hope someone with actual 
>> experience could do better. Maybe I'm wrong and am the one in 
>> actuality that is smoking shrooms.
>>
>>
>>> B: I friendly discuss issues and opportunities with fellow community 
>>> members, where I respect other opinions, keep discussions polite and 
>>> technical.
>>
>>
>> That's funny because I seem to remember during a JDK(or maybe it was 
>> exclusively JavaFX?) event that a presenter made a rather rude joke 
>> about my multi-threading issue I brought up on this list a long time 
>> ago. I don't remember specifically who made the joke but I do know as 
>> someone who watches said events on YouTube that those events are very 
>> incestuous. I guess because it was the other way around that it was 
>> OK though.
>>
>>
>> TL;DR: People in glass houses shouldn't throw stones.
>>
>>
>>> C: somewhere between A and B?
>>>
>>> - Johan
>>>
>>>
>>> On Sat, Dec 28, 2019 at 12:11 AM Ty Young <youngty1997 at gmail.com 
>>> <mailto:youngty1997 at gmail.com>> wrote:
>>>
>>>
>>> ??? On 12/27/19 4:40 PM, John-Val Rose wrote:
>>> ??? > Ty,
>>> ??? >
>>> ??? > If it?s so easy to fix then why don?t you just fix it?
>>>
>>>
>>> ??? I don't exactly have the ability to directly push changes to the
>>> ??? repo...
>>>
>>>
>>> ??? >
>>> ??? > John-Val
>>> ??? >
>>> ??? >> On 28 Dec 2019, at 09:14, Ty Young <youngty1997 at gmail.com
>>> ??? <mailto:youngty1997 at gmail.com>> wrote:
>>> ??? >>
>>> ??? >> ?
>>> ??? >>> On 12/27/19 4:19 AM, Johan Vos wrote:
>>> ??? >>> Hi David,
>>> ??? >>>
>>> ??? >>> What tutorial are you talking about? If you refer to
>>> ??? https://openjfx.io,
>>> ??? >>> that is a community-initiative, developed at
>>> ??? >>> https://github.com/openjfx/openjfx-docs .
>>> ??? >>> So if you have issues and PR's, that is the place to submit
>>> ??? and discuss
>>> ??? >>> with the other contributors to that site.
>>> ??? >>
>>> ??? >> Only the Netbeans section has a warning telling you to delete
>>> ??? src.zip. Neither Intellij nor Eclipse do.
>>> ??? >>
>>> ??? >>
>>> ??? >> A user shouldn't have to do that anyway though! This could be
>>> ??? easily fixed. Literally all you need to do is in this section:
>>> ??? >>
>>> ??? >>
>>> ??? >> // Zip module sources for standalone SDK
>>> ??? >>? ? ? //
>>> ??? >>? ? ? // NOTE: the input is taken from the
>>> ??? modular-sdk/modules_src dir
>>> ??? >>? ? ? // so that we don't have to duplicate the logic and create
>>> ??? another
>>> ??? >>? ? ? // temporary directory. This is somewhat inelegant, since
>>> ??? the bundled sdk
>>> ??? >>? ? ? // and the standalone sdk should be independent of one
>>> ??? another, but seems
>>> ??? >>? ? ? // better than the alternatives.
>>> ??? >>? ? ? def zipSourceFilesTask =
>>> ??? project.task("zipSourceFilesStandalone$t.capital", type: Zip,
>>> ??? dependsOn: buildModulesTask) {
>>> ??? >>? ? ? ? ? destinationDir = file("${standaloneLibDir}")
>>> ??? >>? ? ? ? ? archiveName = standaloneSrcZipName
>>> ??? >>? ? ? ? ? includeEmptyDirs = false
>>> ??? >>? ? ? ? ? from modulesSrcDir
>>> ??? >>? ? ? ? ? include "**/*.java"
>>> ??? >>? ? ? }
>>> ??? >>
>>> ??? >>
>>> ??? >> change:
>>>


From kcr at openjdk.java.net  Tue Dec 31 18:19:30 2019
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 31 Dec 2019 18:19:30 GMT
Subject: [Rev 06] RFR: 8130738: Add tabSize property to Text and TextFlow
In-Reply-To: <gJs-Uck7cEjSEPemDTEbM42AhemZNlFzQ6zzt1P_gzQ=.6b7abac9-4cab-4906-91eb-80625fe48182@github.com>
References: <ywVG73kXeVHzJHmieQs7x4A5laNppG9ZrSvs2x3CxaU=.08f52093-ab93-4648-85ee-1ed553e3c032@github.com>
 <gJs-Uck7cEjSEPemDTEbM42AhemZNlFzQ6zzt1P_gzQ=.6b7abac9-4cab-4906-91eb-80625fe48182@github.com>
Message-ID: <Jj9NZVVr_vwZ1GCwltTPRM3WCba06ldZIXMecbGMJy4=.6292e4b3-ba9a-439c-9051-854c95475601@github.com>

On Tue, 31 Dec 2019 18:19:29 GMT, Scott Palmer <swpalmer at openjdk.org> wrote:

>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to both.  TextFlow's tab size overrides that of contained Text nodes.
> 
> The pull request has been updated with 1 additional commit.

Looks good now.

-------------

Marked as reviewed by kcr (Lead).

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

From thiago.sayao at clamed.com.br  Tue Dec 31 19:50:53 2019
From: thiago.sayao at clamed.com.br (Thiago Milczarek Sayao)
Date: Tue, 31 Dec 2019 19:50:53 +0000
Subject: Linux Glass - WindowContextChild and WindowContextPlug
Message-ID: <CP2P15201MB222861932AFEAE636E35F464DE260@CP2P15201MB2228.LAMP152.PROD.OUTLOOK.COM>


Does anyone knows the context of use of WindowContextChild and WindowContextPlug on the linux glass implementation?

File: glass_window.cpp

They seem to be never called.

Thanks.