From jvos at openjdk.java.net Sat May 1 20:15:55 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 1 May 2021 20:15:55 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v5] In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: <672NFM-VT4yePnDjSR79E2tREcfH0Yg61uoPkn_bgrg=.17fe213f-af04-4f13-81ca-5f4d156467dd@github.com> On Thu, 29 Apr 2021 23:52:30 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure Gradle checksum verification >> * [JDK-8263204][2]: Add Gradle Wrapper Validation Action >> * [JDK-8264010][3]: Add Gradle dependency verification >> >> "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: >> >> * [C?dric Champeau at Devoxx][6] in November 2019 >> * [Louis Jacomet at Jfokus][7] in February 2020 >> >> "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 >> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 >> >> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html >> [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf >> [6]: https://youtu.be/GWGNp3a3hpk >> [7]: https://youtu.be/bwiafNatsf0 > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Add more details to the instructions in the README > > Add more details to the file 'gradle/README.txt' on how to create and > update the dependency verification file for Linux, macOS, Windows, and > the internal Oracle builds. > - Remove older unused Oracle internal dependencies > - Add two more Oracle internal dependencies > - Merge branch 'master' into dependency-verification > - Add dependencies for internal builds at Oracle > - Add dependencies for media and WebKit libraries > - Merge branch 'master' into dependency-verification > - Add a README file and update 'UPDATING-lucene.txt' > - 8264010: Add Gradle dependency verification Looks good, I'll do a deeper inspection tomorrow. ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From jvos at openjdk.java.net Mon May 3 06:18:00 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 3 May 2021 06:18:00 GMT Subject: RFR: 8264010: Add Gradle dependency verification [v5] In-Reply-To: References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: On Thu, 29 Apr 2021 23:52:30 GMT, John Neffenger wrote: >> This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: >> >> * [JDK-8262236][1]: Configure Gradle checksum verification >> * [JDK-8263204][2]: Add Gradle Wrapper Validation Action >> * [JDK-8264010][3]: Add Gradle dependency verification >> >> "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: >> >> * [C?dric Champeau at Devoxx][6] in November 2019 >> * [Louis Jacomet at Jfokus][7] in February 2020 >> >> "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 >> [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 >> >> [4]: https://docs.gradle.org/current/userguide/dependency_verification.html >> [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf >> [6]: https://youtu.be/GWGNp3a3hpk >> [7]: https://youtu.be/bwiafNatsf0 > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Add more details to the instructions in the README > > Add more details to the file 'gradle/README.txt' on how to create and > update the dependency verification file for Linux, macOS, Windows, and > the internal Oracle builds. > - Remove older unused Oracle internal dependencies > - Add two more Oracle internal dependencies > - Merge branch 'master' into dependency-verification > - Add dependencies for internal builds at Oracle > - Add dependencies for media and WebKit libraries > - Merge branch 'master' into dependency-verification > - Add a README file and update 'UPDATING-lucene.txt' > - 8264010: Add Gradle dependency verification Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From arapte at openjdk.java.net Mon May 3 10:12:03 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 3 May 2021 10:12:03 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v8] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 19:18:59 GMT, mstr2 wrote: >> This PR fixes the implementation of `ControlUtils.reducingChange`, which incorrectly computed adjacent removed indices, thus resulting in incorrect removal notifications. >> >> Since there were no unit tests for this method, I also added a bunch of tests. >> >> After applying this fix, I can no longer reproduce [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228). > > mstr2 has updated the pull request incrementally with one additional commit since the last revision: > > Use MockListObserver The fix looks good to me. Performed a regressive testing on TreeTableView and TreeView. Though there is an existing issue that SelectionModel.getSelectedItems() and SelectionModel.getSelectedIndices() are incorrect when some intermediate change events are received. Also, I agree with Jeanette on that the two issues in discussion seem different. The AIOOB Exception is not reproducible with TreeView. But I found another NPE with TreeView which gets fixed by this PR. Steps: 1. Run the test program attached to [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228) 2. Select/Click any child of root for instance 4 Item 1 3. Ctrl click the same item to deselect it -> Observe the NPE This gets fixed by this PR. The issues that are currently listed in the bug [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228) are not reproducible, so it can be closed as cannot reproduce or May be we should update the description of [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228) to include this NPE and add that bug to this PR ? modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 6654: > 6652: root.setExpanded(true); > 6653: > 6654: TreeTableView treeView = new TreeTableView<>(root); rename variable as `treeTableView` modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeViewTest.java line 3704: > 3702: observer.check1(); > 3703: observer.checkAddRemove(0, treeView.getSelectionModel().getSelectedItems(), List.of(c1, c2, c3), 1, 1); > 3704: } These test validate the getRemoved() list. I think we should also have a test for exception. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/480 From kcr at openjdk.java.net Mon May 3 12:24:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 3 May 2021 12:24:55 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v8] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 19:18:59 GMT, mstr2 wrote: >> This PR fixes the implementation of `ControlUtils.reducingChange`, which incorrectly computed adjacent removed indices, thus resulting in incorrect removal notifications. >> >> Since there were no unit tests for this method, I also added a bunch of tests. >> >> After applying this fix, I can no longer reproduce [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228). > > mstr2 has updated the pull request incrementally with one additional commit since the last revision: > > Use MockListObserver I'm a bit confused about the various issues. > The issues that are currently listed in the bug JDK-8189228 are not reproducible, so it can be closed as cannot reproduce If any are reproducible before this fix, then closing as "cannot reproduce" is incorrect. Either close as a duplicate, or list that issue in this PR. But... I thought based on the earlier discussion that one or more NPEs in TreeView multi-selection remain even after this which, which focuses on fixing IOOBE. Is this not the case? ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From jgneff at openjdk.java.net Mon May 3 16:30:59 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 3 May 2021 16:30:59 GMT Subject: Integrated: 8264010: Add Gradle dependency verification In-Reply-To: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> References: <_heRdkcJJX8Tq5rDzuIDG60ggXFfAFNVMNXWITFCCXk=.1bce244d-e251-44b7-94ac-54e16d6b6f22@github.com> Message-ID: On Tue, 23 Mar 2021 05:32:04 GMT, John Neffenger wrote: > This pull request adds dependency verification to the Gradle builds of JavaFX on Linux, macOS, and Windows. It is the third of three changes that close the gaps in the JavaFX build security: > > * [JDK-8262236][1]: Configure Gradle checksum verification > * [JDK-8263204][2]: Add Gradle Wrapper Validation Action > * [JDK-8264010][3]: Add Gradle dependency verification > > "Without dependency verification it's easy for an attacker to compromise your supply chain," warns the [Gradle User Guide][4]. All three changes come from conference talks by members of the Gradle team, available as [PDF slides][5] or on YouTube in the following two videos: > > * [C?dric Champeau at Devoxx][6] in November 2019 > * [Louis Jacomet at Jfokus][7] in February 2020 > > "We all run in a crazy-unsafe environment, in a way," says Louis Jacomet at the end of his talk. These three changes make it just a little less crazy-unsafe for all of us building JavaFX, regardless of our system, network, or country. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8262236 > [2]: https://bugs.openjdk.java.net/browse/JDK-8263204 > [3]: https://bugs.openjdk.java.net/browse/JDK-8264010 > > [4]: https://docs.gradle.org/current/userguide/dependency_verification.html > [5]: https://www.jfokus.se/jfokus20-preso/Protecting-your-organization-against-attacks-via-the-build-system.pdf > [6]: https://youtu.be/GWGNp3a3hpk > [7]: https://youtu.be/bwiafNatsf0 This pull request has now been integrated. Changeset: a9f6035c Author: John Neffenger URL: https://git.openjdk.java.net/jfx/commit/a9f6035c9c1d4dc60aa960498d8dbb5e52827017 Stats: 325 lines in 3 files changed: 313 ins; 4 del; 8 mod 8264010: Add Gradle dependency verification Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/437 From github.com+3197675+abhinayagarwal at openjdk.java.net Mon May 3 19:24:55 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Mon, 3 May 2021 19:24:55 GMT Subject: Integrated: 8264998: Empty Jars shouldn't have Automatic-Module-Name In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 08:42:14 GMT, Abhinay Agarwal wrote: > 8264998: Empty Jars shouldn't have Automatic-Module-Name This pull request has now been integrated. Changeset: 02b078a8 Author: Abhinay Agarwal Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/02b078a8a00803e03f4d2b5f06552f88dd0d5c00 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod 8264998: Empty Jars shouldn't have Automatic-Module-Name Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/484 From github.com+43553916+mstr2 at openjdk.java.net Mon May 3 20:51:13 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Mon, 3 May 2021 20:51:13 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v9] In-Reply-To: References: Message-ID: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> > This PR fixes the implementation of `ControlUtils.reducingChange`, which incorrectly computed adjacent removed indices, thus resulting in incorrect removal notifications. > > Since there were no unit tests for this method, I also added a bunch of tests. > > After applying this fix, I can no longer reproduce [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228). mstr2 has updated the pull request incrementally with two additional commits since the last revision: - Rename local variable in test - Remove unrelated fix ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/480/files - new: https://git.openjdk.java.net/jfx/pull/480/files/b2057f4f..f0524116 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=480&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=480&range=07-08 Stats: 22 lines in 3 files changed: 0 ins; 14 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/480.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/480/head:pull/480 PR: https://git.openjdk.java.net/jfx/pull/480 From github.com+43553916+mstr2 at openjdk.java.net Mon May 3 21:09:51 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Mon, 3 May 2021 21:09:51 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v9] In-Reply-To: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> References: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> Message-ID: On Mon, 3 May 2021 20:51:13 GMT, mstr2 wrote: >> This PR fixes the implementation of `ControlUtils.reducingChange`, which incorrectly computed adjacent removed indices, thus resulting in incorrect removal notifications. >> >> Since there were no unit tests for this method, I also added a bunch of tests. >> >> After applying this fix, I can no longer reproduce [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228). > > mstr2 has updated the pull request incrementally with two additional commits since the last revision: > > - Rename local variable in test > - Remove unrelated fix I've removed the clearSelection fix, which can be addressed in another PR. What remains is a fix for the underlying issue that the list of removed selected indices is incorrect when a tree branch is collapsed. The IOOB exception is an artifact of the elaborate test setup in [8189354](https://bugs.openjdk.java.net/browse/JDK-8189354). I propose to change the title of the JBS issue to `List of removed selected indices is incorrect when a tree branch is collapsed` and have this PR be the fix for that. ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From frank at webtechie.be Tue May 4 12:08:55 2021 From: frank at webtechie.be (Frank Delporte) Date: Tue, 04 May 2021 14:08:55 +0200 Subject: Add method to save a JavaFX image to file without the use of =?utf-8?Q?SwingFXU?= =?utf-8?Q?tils=3F?= Message-ID: <1620130135740.27918.309712@webmail10> Hello My first contribution to this mailing list... ;-) During an experiment with FXGL on the Raspberry Pi + Gluon JavaFX 17-ea, it turned out there was a missing dependency to javafx.swing. (also mentioned here ) Turns out SwingFXUtils was used in the FXGL library only to be able to save a screenshot of the application to a file and we were able to rework it as you can see here: I researched this topic for a few hours, but didn't manage to find a good approach to save a JavaFX Image. Maybe I missed something? Or wouldn't it be a good idea to extend the JavaFX Image or BufferedImage with e.g. writeToFile(ImageFormat.PNG), writeToFile(ImageFormat.JPG)? Best regards Frank Delporte Want to have coding-fun? Check my blogand book "Getting started with Java on Raspberry Pi" on From kevin.rushforth at oracle.com Tue May 4 12:21:07 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 4 May 2021 05:21:07 -0700 Subject: Add method to save a JavaFX image to file without the use of SwingFXUtils? In-Reply-To: <1620130135740.27918.309712@webmail10> References: <1620130135740.27918.309712@webmail10> Message-ID: <3edbb218-28b7-67eb-704e-c6c9d5f5e162@oracle.com> Hi, We've discussed adding image reading and writing functionality in the past. Something on the order of Java2D's Image I/O. Doing it right would be a large project, and would be more than just adding a couple methods to JavaFX Image. Unless and until we do that, using the SwingFXUtils to produce a BufferedImage from a JavaFX Image is the recommended approach. -- Kevin On 5/4/2021 5:08 AM, Frank Delporte wrote: > Hello > > My first contribution to this mailing list... ;-) > > During an experiment with FXGL on the Raspberry Pi + Gluon JavaFX 17-ea, it turned out there was a missing dependency to javafx.swing. > (also mentioned here ) > > Turns out SwingFXUtils was used in the FXGL library only to be able to save a screenshot of the application to a file and we were able to rework it as you can see here: > > I researched this topic for a few hours, but didn't manage to find a good approach to save a JavaFX Image. Maybe I missed something? Or wouldn't it be a good idea to extend the JavaFX Image or BufferedImage with e.g. writeToFile(ImageFormat.PNG), writeToFile(ImageFormat.JPG)? > > Best regards > Frank Delporte > > Want to have coding-fun? > Check my blogand book "Getting started with Java on Raspberry Pi" on > > From arapte at openjdk.java.net Tue May 4 12:35:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 4 May 2021 12:35:10 GMT Subject: RFR: 8264157: Items of non-editable ComboBox cannot be selected using up/down keys Message-ID: This issue [JDK-8264157](https://bugs.openjdk.java.net/browse/JDK-8264157) is a regression of [JDK-8209788](https://bugs.openjdk.java.net/browse/JDK-8209788), which removed two KeyMappings from `ComboBoxListViewBehavior`. That removal was not required to fix [JDK-8209788](https://bugs.openjdk.java.net/browse/JDK-8209788). Reverting `ComboBoxListViewBehavior.java` fixes the regression. Fix includes a new test which fails before and pass with the fix. ------------- Commit messages: - revert partial fix and add test Changes: https://git.openjdk.java.net/jfx/pull/485/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=485&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264157 Stats: 69 lines in 2 files changed: 67 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/485/head:pull/485 PR: https://git.openjdk.java.net/jfx/pull/485 From arapte at openjdk.java.net Tue May 4 13:53:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 4 May 2021 13:53:56 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v8] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 12:22:16 GMT, Kevin Rushforth wrote: > If any are reproducible before this fix, then closing as "cannot reproduce" is incorrect. I was suggesting to close JDK-8189228 because the three issues that are currently listed in JDK-8189228 are not reproducible with or without this PR. We can file a new bug for the NPE that I noticed with TreeView. ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From kcr at openjdk.java.net Tue May 4 14:00:01 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 4 May 2021 14:00:01 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v8] In-Reply-To: References: Message-ID: <9DwiC5LJtRRVti9dPUbqcVgrUbarS6zAdntTVHf_M6Q=.192730dd-bf48-43b6-9b83-18d14438d958@github.com> On Tue, 4 May 2021 13:51:01 GMT, Ambarish Rapte wrote: > I was suggesting to close JDK-8189228 because the three issues that are currently listed in JDK-8189228 are not reproducible with or without this PR. > We can file a new bug for the NPE that I noticed with TreeView. Good idea. Can you close [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228) as "Cannot reproduce", and then file the new NPE issue? ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From github.com+43553916+mstr2 at openjdk.java.net Tue May 4 14:42:55 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Tue, 4 May 2021 14:42:55 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v8] In-Reply-To: References: Message-ID: On Mon, 3 May 2021 09:41:44 GMT, Ambarish Rapte wrote: >> mstr2 has updated the pull request incrementally with one additional commit since the last revision: >> >> Use MockListObserver > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeViewTest.java line 3704: > >> 3702: observer.check1(); >> 3703: observer.checkAddRemove(0, treeView.getSelectionModel().getSelectedItems(), List.of(c1, c2, c3), 1, 1); >> 3704: } > > These test validate the getRemoved() list. I think we should also have a test for exception. I think this is no longer part of this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From swpalmer at gmail.com Wed May 5 03:46:57 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 4 May 2021 23:46:57 -0400 Subject: Add method to save a JavaFX image to file without the use of SwingFXUtils? In-Reply-To: <3edbb218-28b7-67eb-704e-c6c9d5f5e162@oracle.com> References: <3edbb218-28b7-67eb-704e-c6c9d5f5e162@oracle.com> Message-ID: <06CA7182-5024-42FE-9F3A-E908CC2BB57F@gmail.com> An overhaul to ImageIO that isn?t dependent on any UI framework, but rather accesses raw image data via arrays or ByteBuffer (or even the new foreign MemoryAccess stuff?) would help. For specific UI framework types, BufferedImage and JavaFX Image, they just need the plumbing to get the raw data accessible to ImageIO v2. That way we don?t need to mix different UI modules to read and write images. There are already too many ways to read images in the JDK, it would help if they could all delegate to a single body of code. It also might help with some cases of server-side image generation, where a full UI toolkit isn?t needed... e.g. only the JavaFX graphics module (and base) is enough to generate images. Is anything like that every likely to happen? Scott > > On May 4, 2021, at 8:21 AM, Kevin Rushforth wrote: > > ?Hi, > > We've discussed adding image reading and writing functionality in the past. Something on the order of Java2D's Image I/O. Doing it right would be a large project, and would be more than just adding a couple methods to JavaFX Image. Unless and until we do that, using the SwingFXUtils to produce a BufferedImage from a JavaFX Image is the recommended approach. > > -- Kevin > > >> On 5/4/2021 5:08 AM, Frank Delporte wrote: >> Hello >> >> My first contribution to this mailing list... ;-) >> >> During an experiment with FXGL on the Raspberry Pi + Gluon JavaFX 17-ea, it turned out there was a missing dependency to javafx.swing. >> (also mentioned here ) >> >> Turns out SwingFXUtils was used in the FXGL library only to be able to save a screenshot of the application to a file and we were able to rework it as you can see here: >> >> I researched this topic for a few hours, but didn't manage to find a good approach to save a JavaFX Image. Maybe I missed something? Or wouldn't it be a good idea to extend the JavaFX Image or BufferedImage with e.g. writeToFile(ImageFormat.PNG), writeToFile(ImageFormat.JPG)? >> >> Best regards >> Frank Delporte >> >> Want to have coding-fun? >> Check my blogand book "Getting started with Java on Raspberry Pi" on >> >> > From john at status6.com Wed May 5 05:42:48 2021 From: john at status6.com (John Neffenger) Date: Tue, 4 May 2021 22:42:48 -0700 Subject: Add method to save a JavaFX image to file without the use of SwingFXUtils? In-Reply-To: <1620130135740.27918.309712@webmail10> References: <1620130135740.27918.309712@webmail10> Message-ID: <17320cbd-a754-4979-b9ae-153af37d850d@status6.com> On 5/4/21 5:08 AM, Frank Delporte wrote: > I researched this topic for a few hours, but didn't manage to find a good approach to save a JavaFX Image. For what it's worth, I ran 224 benchmarks to find the fastest method to go in the other direction: read in an image using AWT and convert it to a JavaFX image. The results are posted here: Benchmarks https://jgneff.github.io/tofximage/ I found that the methods in SwingFXUtils are general enough that you can almost always write them to be much, much faster for your specific case. The code of the benchmarks is here: AWT to JavaFX Image Conversion Benchmarks https://github.com/jgneff/tofximage If you don't care about the alpha channel, this method came out tops: public void setArgbAsArgbPre(SourceAwtImage, ...) https://github.com/jgneff/tofximage/blob/b40a1e01238f1431295716ca09e4c40b82ac95d9/src/main/java/org/status6/tofximage/Benchmarks.java#L475 That method is shown below in a real application: public void handle(long now) https://github.com/jgneff/epd-javafx/blob/master/src/org/status6/epd/javafx/ImageAnimation.java#L172 John From arapte at openjdk.java.net Wed May 5 06:38:19 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 5 May 2021 06:38:19 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v8] In-Reply-To: <9DwiC5LJtRRVti9dPUbqcVgrUbarS6zAdntTVHf_M6Q=.192730dd-bf48-43b6-9b83-18d14438d958@github.com> References: <9DwiC5LJtRRVti9dPUbqcVgrUbarS6zAdntTVHf_M6Q=.192730dd-bf48-43b6-9b83-18d14438d958@github.com> Message-ID: On Tue, 4 May 2021 13:57:08 GMT, Kevin Rushforth wrote: > Good idea. Can you close [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228) as "Cannot reproduce", and then file the new NPE issue? I have closed [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228) and reported a new one for NPE [JDK-8266539](https://bugs.openjdk.java.net/browse/JDK-8266539) ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From arapte at openjdk.java.net Wed May 5 07:41:50 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 5 May 2021 07:41:50 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v9] In-Reply-To: References: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> Message-ID: On Mon, 3 May 2021 21:06:48 GMT, mstr2 wrote: > The IOOB exception is an artifact of the elaborate test setup in [8189354](https://bugs.openjdk.java.net/browse/JDK-8189354). I propose to change the title of the JBS issue to `List of removed selected indices is incorrect when a tree branch is collapsed` and have this PR be the fix for that. True, we need to change the summary of this issue. I would suggest a little different rewording like, `Change.getRemoved() list contains incorrect selected items when a TreeItem is collapsed`. I will update the JBS then you can update the title of this PR ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From arapte at openjdk.java.net Wed May 5 09:34:55 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 5 May 2021 09:34:55 GMT Subject: RFR: 8189354: ArrayIndexOutOfBoundsException when listening to selection changes on TreeTableView [v9] In-Reply-To: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> References: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> Message-ID: On Mon, 3 May 2021 20:51:13 GMT, mstr2 wrote: >> This PR fixes the implementation of `ControlUtils.reducingChange`, which incorrectly computed adjacent removed indices, thus resulting in incorrect removal notifications. >> >> Since there were no unit tests for this method, I also added a bunch of tests. >> >> After applying this fix, I can no longer reproduce [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228). > > mstr2 has updated the pull request incrementally with two additional commits since the last revision: > > - Rename local variable in test > - Remove unrelated fix We couple more similar issues reported 1. [JDK-8255935](https://bugs.openjdk.java.net/browse/JDK-8255935) : MultipleSelectionModel provides incorrect 'removed' sub-list in change events 2. [JDK-8196065](https://bugs.openjdk.java.net/browse/JDK-8196065) : ListChangeListener getRemoved() returns items that were not removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From fastegal at openjdk.java.net Wed May 5 10:36:52 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 5 May 2021 10:36:52 GMT Subject: RFR: 8264157: Items of non-editable ComboBox cannot be selected using up/down keys In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:29:54 GMT, Ambarish Rapte wrote: > This issue [JDK-8264157](https://bugs.openjdk.java.net/browse/JDK-8264157) is a regression of [JDK-8209788](https://bugs.openjdk.java.net/browse/JDK-8209788), which removed two KeyMappings from `ComboBoxListViewBehavior`. That removal was not required to fix [JDK-8209788](https://bugs.openjdk.java.net/browse/JDK-8209788). > Reverting `ComboBoxListViewBehavior.java` fixes the regression. > Fix includes a new test which fails before and pass with the fix. fix looks good, verified test failing before and passing after - crossing fingers we got it completely right this time :) ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/485 From kcr at openjdk.java.net Wed May 5 12:04:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 May 2021 12:04:26 GMT Subject: [jfx11u] RFR: 8262366: Update glib to version 2.66.7 Message-ID: Backport glib / gstreamer update from jfx mainline to jfx11u. The backport applied cleanly, and I ran a sanity test on Windows (I'll test on other two platforms before integrating). ------------- Commit messages: - 8262366: Update glib to version 2.66.7 Changes: https://git.openjdk.java.net/jfx11u/pull/2/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=2&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262366 Stats: 39567 lines in 441 files changed: 23434 ins; 5427 del; 10706 mod Patch: https://git.openjdk.java.net/jfx11u/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/2/head:pull/2 PR: https://git.openjdk.java.net/jfx11u/pull/2 From kcr at openjdk.java.net Wed May 5 12:09:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 May 2021 12:09:10 GMT Subject: [jfx11u] RFR: 8260245: Update ICU4C to version 68.2 Message-ID: Backport ICU update from jfx mainline to jfx11u. The backport was clean except for a minor diff in the surrounding context in `build.gradle`. I ran a sanity test on Windows (I'll test on other two platforms before integrating). ------------- Commit messages: - 8260245: Update ICU4C to version 68.2 Changes: https://git.openjdk.java.net/jfx11u/pull/3/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=3&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260245 Stats: 45773 lines in 673 files changed: 24665 ins; 8082 del; 13026 mod Patch: https://git.openjdk.java.net/jfx11u/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/3/head:pull/3 PR: https://git.openjdk.java.net/jfx11u/pull/3 From kcr at openjdk.java.net Wed May 5 13:50:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 May 2021 13:50:02 GMT Subject: RFR: 8262396: Update Mesa 3-D Headers to version 21.0.3 Message-ID: Update OpenGL headers to latest versions from Mesa project. I ran a sanity test on all three platforms. I also checked the diffs against the Java2D patch in openjdk/jdk#3854 and they match, excluding the Java2D-specific ifdefs. ------------- Commit messages: - 8262396: Update Mesa 3-D Headers to version 21.0.3 Changes: https://git.openjdk.java.net/jfx/pull/486/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=486&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262396 Stats: 140 lines in 6 files changed: 100 ins; 18 del; 22 mod Patch: https://git.openjdk.java.net/jfx/pull/486.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/486/head:pull/486 PR: https://git.openjdk.java.net/jfx/pull/486 From jvos at openjdk.java.net Wed May 5 14:40:52 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 5 May 2021 14:40:52 GMT Subject: [jfx11u] RFR: 8262366: Update glib to version 2.66.7 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 11:57:06 GMT, Kevin Rushforth wrote: > Backport glib / gstreamer update from jfx mainline to jfx11u. The backport applied cleanly, and I ran a sanity test on Windows (I'll test on other two platforms before integrating). works on linux and mac ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx11u/pull/2 From kcr at openjdk.java.net Wed May 5 16:16:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 May 2021 16:16:54 GMT Subject: [jfx11u] Integrated: 8262366: Update glib to version 2.66.7 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 11:57:06 GMT, Kevin Rushforth wrote: > Backport glib / gstreamer update from jfx mainline to jfx11u. The backport applied cleanly, and I ran a sanity test on Windows (I'll test on other two platforms before integrating). This pull request has now been integrated. Changeset: 1c7d8dc4 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/1c7d8dc49764645efc7e4cccf5a0a56ac9b76db9 Stats: 39567 lines in 441 files changed: 23434 ins; 5427 del; 10706 mod 8262366: Update glib to version 2.66.7 8262365: Update GStreamer to version 1.18.3 Reviewed-by: jvos Backport-of: e63931e67b55e216f449d5cdddd01959a45d099d ------------- PR: https://git.openjdk.java.net/jfx11u/pull/2 From kcr at openjdk.java.net Wed May 5 16:18:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 May 2021 16:18:09 GMT Subject: [jfx11u] RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys Message-ID: This is the backport of a small enhancement to add a query for CAPS_LOCK and NUM_LOCK to jfx11u. The jfx mainline patch applied cleanly except for one conflict in an import statement which had to be manually resolved. I also needed to subsequently modify the `@since` tag in the new API method to reflect the change in release, as noted in the [CSR](https://bugs.openjdk.java.net/browse/JDK-8259868?focusedCommentId=14397008&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14397008). I've sanity tested it on Windows. I will sanity test on Linux and Mac before integrating. ------------- Commit messages: - Update @since tag to 11.0.12 - 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys Changes: https://git.openjdk.java.net/jfx11u/pull/4/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=4&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259680 Stats: 446 lines in 15 files changed: 445 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/4.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/4/head:pull/4 PR: https://git.openjdk.java.net/jfx11u/pull/4 From kcr at openjdk.java.net Wed May 5 17:54:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 May 2021 17:54:50 GMT Subject: [jfx11u] RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Wed, 5 May 2021 16:12:36 GMT, Kevin Rushforth wrote: > This is the backport of a small enhancement to add a query for CAPS_LOCK and NUM_LOCK to jfx11u. > > The jfx mainline patch applied cleanly except for one conflict in an import statement which had to be manually resolved. I also needed to subsequently modify the `@since` tag in the new API method to reflect the change in release, as noted in the [CSR](https://bugs.openjdk.java.net/browse/JDK-8259868?focusedCommentId=14397008&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14397008). > > I've sanity tested it on Windows. I will sanity test on Linux and Mac before integrating. Verified on Mac and Linux as well. ------------- PR: https://git.openjdk.java.net/jfx11u/pull/4 From jvos at openjdk.java.net Wed May 5 18:01:52 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 5 May 2021 18:01:52 GMT Subject: [jfx11u] RFR: 8260245: Update ICU4C to version 68.2 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 12:00:25 GMT, Kevin Rushforth wrote: > Backport ICU update from jfx mainline to jfx11u. The backport was clean except for a minor diff in the surrounding context in `build.gradle`. I ran a sanity test on Windows (I'll test on other two platforms before integrating). Works fine on Linux, still doing mac but no problems so far ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx11u/pull/3 From kcr at openjdk.java.net Wed May 5 19:32:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 May 2021 19:32:56 GMT Subject: [jfx11u] Integrated: 8260245: Update ICU4C to version 68.2 In-Reply-To: References: Message-ID: <7bi3C2s-FSzsvYBCxoix2CHNM2ozgSX5Dvb-mv0WWx4=.a0bb6012-9736-48c5-b3a9-847a772ec2dc@github.com> On Wed, 5 May 2021 12:00:25 GMT, Kevin Rushforth wrote: > Backport ICU update from jfx mainline to jfx11u. The backport was clean except for a minor diff in the surrounding context in `build.gradle`. I ran a sanity test on Windows (I'll test on other two platforms before integrating). This pull request has now been integrated. Changeset: 81feeb26 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/81feeb26c87f5a8535e5088006f9adbcaec3d3ea Stats: 45773 lines in 673 files changed: 24665 ins; 8082 del; 13026 mod 8260245: Update ICU4C to version 68.2 8232379: Need to remove large icudt64l.zip binary file from source repository Reviewed-by: jvos Backport-of: 808b1078f762a923bd5e74298daffeb88ed108c2 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/3 From jvos at openjdk.java.net Wed May 5 19:37:52 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 5 May 2021 19:37:52 GMT Subject: [jfx11u] RFR: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Wed, 5 May 2021 16:12:36 GMT, Kevin Rushforth wrote: > This is the backport of a small enhancement to add a query for CAPS_LOCK and NUM_LOCK to jfx11u. > > The jfx mainline patch applied cleanly except for one conflict in an import statement which had to be manually resolved. I also needed to subsequently modify the `@since` tag in the new API method to reflect the change in release, as noted in the [CSR](https://bugs.openjdk.java.net/browse/JDK-8259868?focusedCommentId=14397008&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14397008). > > I've sanity tested it on Windows. I will sanity test on Linux and Mac before integrating. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/4 From prr at openjdk.java.net Wed May 5 19:40:55 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 5 May 2021 19:40:55 GMT Subject: RFR: 8262396: Update Mesa 3-D Headers to version 21.0.3 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 13:45:39 GMT, Kevin Rushforth wrote: > Update OpenGL headers to latest versions from Mesa project. I ran a sanity test on all three platforms. I also checked the diffs against the Java2D patch in openjdk/jdk#3854 and they match, excluding the Java2D-specific ifdefs. Looks good. I also checked against the 2D version. This may be as close as it gets to reviewing your own changes :-) ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/486 From kcr at openjdk.java.net Wed May 5 19:53:53 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 May 2021 19:53:53 GMT Subject: [jfx11u] Integrated: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys In-Reply-To: References: Message-ID: On Wed, 5 May 2021 16:12:36 GMT, Kevin Rushforth wrote: > This is the backport of a small enhancement to add a query for CAPS_LOCK and NUM_LOCK to jfx11u. > > The jfx mainline patch applied cleanly except for one conflict in an import statement which had to be manually resolved. I also needed to subsequently modify the `@since` tag in the new API method to reflect the change in release, as noted in the [CSR](https://bugs.openjdk.java.net/browse/JDK-8259868?focusedCommentId=14397008&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14397008). > > I've sanity tested it on Windows. I will sanity test on Linux and Mac before integrating. This pull request has now been integrated. Changeset: ea4f8806 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/ea4f880600f747fc5334504d5ab71c019e45ba61 Stats: 446 lines in 15 files changed: 445 ins; 0 del; 1 mod 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys Reviewed-by: jvos Backport-of: 217a8cba5d68f6468fec8b33753b31430d3309da ------------- PR: https://git.openjdk.java.net/jfx11u/pull/4 From kcr at openjdk.java.net Wed May 5 21:07:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 5 May 2021 21:07:00 GMT Subject: [jfx11u] RFR: 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set Message-ID: Clean backport of macOS tabbed windows fix. Verified on Mac (the fix is macOS-specific). ------------- Commit messages: - 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set Changes: https://git.openjdk.java.net/jfx11u/pull/5/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=5&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263169 Stats: 174 lines in 2 files changed: 174 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/5/head:pull/5 PR: https://git.openjdk.java.net/jfx11u/pull/5 From aghaisas at openjdk.java.net Thu May 6 10:28:21 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 6 May 2021 10:28:21 GMT Subject: RFR: 8265277: =?UTF-8?B?U2tpbkJhc2U6OnJlZ2lzdGVyQ2hhbmdlTGlzdGVuZXLigIs=?= missing '@since 9' javadoc tag Message-ID: Please review a very simple fix that adds a missing javadoc tag. ------------- Commit messages: - add missing since tag Changes: https://git.openjdk.java.net/jfx/pull/487/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=487&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265277 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/487.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/487/head:pull/487 PR: https://git.openjdk.java.net/jfx/pull/487 From kcr at openjdk.java.net Thu May 6 11:57:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 May 2021 11:57:02 GMT Subject: RFR: 8265277: =?UTF-8?B?U2tpbkJhc2U6OnJlZ2lzdGVyQ2hhbmdlTGlzdGVuZXLigIs=?= missing '@since 9' javadoc tag In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:22:13 GMT, Ajit Ghaisas wrote: > Please review a very simple fix that adds a missing javadoc tag. Looks good. Unrelated to your change, I see the following failure in the GitHub Actions test run on Linux: 2021-05-06T10:27:19.6546656Z test.javafx.css.HonorDeveloperSettingsTest > testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle FAILED 2021-05-06T10:27:19.6549284Z java.lang.NullPointerException 2021-05-06T10:27:19.6550829Z at javafx.graphics/javafx.scene.Node.notifyParentsOfInvalidatedCSS(Node.java:9295) 2021-05-06T10:27:19.6552527Z at javafx.graphics/javafx.scene.Node.reapplyCSS(Node.java:9342) 2021-05-06T10:27:19.6553757Z at javafx.graphics/javafx.scene.Node$1.reapplyCSS(Node.java:588) 2021-05-06T10:27:19.6555253Z at javafx.graphics/com.sun.javafx.scene.NodeHelper.reapplyCSS(NodeHelper.java:283) 2021-05-06T10:27:19.6557553Z at javafx.graphics/com.sun.javafx.css.StyleManager.userAgentStylesheetsChanged(StyleManager.java:1514) 2021-05-06T10:27:19.6560309Z at javafx.graphics/com.sun.javafx.css.StyleManager.setDefaultUserAgentStylesheet(StyleManager.java:1365) 2021-05-06T10:27:19.6563106Z at javafx.graphics/com.sun.javafx.css.StyleManager.setDefaultUserAgentStylesheet(StyleManager.java:1347) 2021-05-06T10:27:19.6571692Z at test.javafx.css.HonorDeveloperSettingsTest.setUp(HonorDeveloperSettingsTest.java:89) Can you file a new bug for this intermittent failure? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/487 From pbansal at openjdk.java.net Thu May 6 12:01:54 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 6 May 2021 12:01:54 GMT Subject: RFR: 8265277: =?UTF-8?B?U2tpbkJhc2U6OnJlZ2lzdGVyQ2hhbmdlTGlzdGVuZXLigIs=?= missing '@since 9' javadoc tag In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:22:13 GMT, Ajit Ghaisas wrote: > Please review a very simple fix that adds a missing javadoc tag. Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/487 From kcr at openjdk.java.net Thu May 6 12:42:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 May 2021 12:42:56 GMT Subject: RFR: 8264157: Items of non-editable ComboBox cannot be selected using up/down keys In-Reply-To: References: Message-ID: On Tue, 4 May 2021 12:29:54 GMT, Ambarish Rapte wrote: > This issue [JDK-8264157](https://bugs.openjdk.java.net/browse/JDK-8264157) is a regression of [JDK-8209788](https://bugs.openjdk.java.net/browse/JDK-8209788), which removed two KeyMappings from `ComboBoxListViewBehavior`. That removal was not required to fix [JDK-8209788](https://bugs.openjdk.java.net/browse/JDK-8209788). > Reverting `ComboBoxListViewBehavior.java` fixes the regression. > Fix includes a new test which fails before and pass with the fix. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/485 From kcr at openjdk.java.net Thu May 6 12:43:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 May 2021 12:43:54 GMT Subject: [jfx11u] Integrated: 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set In-Reply-To: References: Message-ID: On Wed, 5 May 2021 21:01:26 GMT, Kevin Rushforth wrote: > Clean backport of macOS tabbed windows fix. Verified on Mac (the fix is macOS-specific). This pull request has now been integrated. Changeset: 2808769f Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/2808769f8533dc47adea1e5aa981ed08c0d729f8 Stats: 174 lines in 2 files changed: 174 ins; 0 del; 0 mod 8263169: [macos] JavaFX windows open as tabs when system preference for documents is set Backport-of: 58988582828beb4a41622ccda25cba813d69a93f ------------- PR: https://git.openjdk.java.net/jfx11u/pull/5 From aghaisas at openjdk.java.net Thu May 6 14:31:59 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 6 May 2021 14:31:59 GMT Subject: RFR: 8265277: =?UTF-8?B?U2tpbkJhc2U6OnJlZ2lzdGVyQ2hhbmdlTGlzdGVuZXLigIs=?= missing '@since 9' javadoc tag In-Reply-To: References: Message-ID: On Thu, 6 May 2021 11:53:38 GMT, Kevin Rushforth wrote: > > Can you file a new bug for this intermittent failure? I have filed JDK-8266643 for this. ------------- PR: https://git.openjdk.java.net/jfx/pull/487 From aghaisas at openjdk.java.net Thu May 6 14:31:59 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 6 May 2021 14:31:59 GMT Subject: Integrated: 8265277: =?UTF-8?B?U2tpbkJhc2U6OnJlZ2lzdGVyQ2hhbmdlTGlzdGVuZXLigIs=?= missing '@since 9' javadoc tag In-Reply-To: References: Message-ID: On Thu, 6 May 2021 10:22:13 GMT, Ajit Ghaisas wrote: > Please review a very simple fix that adds a missing javadoc tag. This pull request has now been integrated. Changeset: 599ca1e3 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/599ca1e3f4e8c8a369f3458071ca92a0a4265a78 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8265277: SkinBase::registerChangeListener? missing '@since 9' javadoc tag Reviewed-by: kcr, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/487 From arapte at openjdk.java.net Thu May 6 15:28:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 6 May 2021 15:28:56 GMT Subject: RFR: 8262396: Update Mesa 3-D Headers to version 21.0.3 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 13:45:39 GMT, Kevin Rushforth wrote: > Update OpenGL headers to latest versions from Mesa project. I ran a sanity test on all three platforms. I also checked the diffs against the Java2D patch in openjdk/jdk#3854 and they match, excluding the Java2D-specific ifdefs. lgtm... ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/486 From arapte at openjdk.java.net Thu May 6 15:30:56 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 6 May 2021 15:30:56 GMT Subject: Integrated: 8264157: Items of non-editable ComboBox cannot be selected using up/down keys In-Reply-To: References: Message-ID: <8GKNO3WAI4xv18qF3WuCMVF5b4aeSHwP0VlovMl_dnA=.4ac7b2fd-1c0d-4997-b41c-6963664471e3@github.com> On Tue, 4 May 2021 12:29:54 GMT, Ambarish Rapte wrote: > This issue [JDK-8264157](https://bugs.openjdk.java.net/browse/JDK-8264157) is a regression of [JDK-8209788](https://bugs.openjdk.java.net/browse/JDK-8209788), which removed two KeyMappings from `ComboBoxListViewBehavior`. That removal was not required to fix [JDK-8209788](https://bugs.openjdk.java.net/browse/JDK-8209788). > Reverting `ComboBoxListViewBehavior.java` fixes the regression. > Fix includes a new test which fails before and pass with the fix. This pull request has now been integrated. Changeset: 4b6c587f Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/4b6c587faacdc1f5f00df6e4bf5ad57c3a48723f Stats: 69 lines in 2 files changed: 67 ins; 0 del; 2 mod 8264157: Items of non-editable ComboBox cannot be selected using up/down keys Reviewed-by: fastegal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/485 From pbansal at openjdk.java.net Thu May 6 15:32:53 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 6 May 2021 15:32:53 GMT Subject: RFR: 8210199: [linux / macOS] fileChooser can't handle emojis In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:42:04 GMT, Jose Pereda wrote: > Both `GlassDialogs.m` for macOS and `GlassCommonDialogs.c` for Linux use UTF8 encoding for the file names selected via native FileChooser, and this will fail if there are emojis in the file name. > > This PR uses the same approach as in [JDK-8258381](https://bugs.openjdk.java.net/browse/JDK-8258381) for macOS, using UTF16 encoding. > > For Linux, the Java `String(byte[] bytes)` constructor with default charset is used instead, preventing the need of using UTF8 encoding. I ran this on both MacOS and Linux. The fix looks fine and solves the issue. I do not see the exception with the fix. I tested on MacOs 10.15.7 and Ubuntu 20.10 and Ubuntu 20.04. One thing I noticed is that on linux, the file does not actually open on selection and Java stops responding. I see this on both Ubuntu 20.04 and Ubuntu 20.10. But this happens without the current fix also and not just for the file containing emojis in the filename. It is happening for all the files. So I do not think it is related to the current changes and it may be a test case issue also. I am attaching a screenshot for reference. error ------------- PR: https://git.openjdk.java.net/jfx/pull/471 From kcr at openjdk.java.net Thu May 6 15:35:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 May 2021 15:35:54 GMT Subject: Integrated: 8262396: Update Mesa 3-D Headers to version 21.0.3 In-Reply-To: References: Message-ID: On Wed, 5 May 2021 13:45:39 GMT, Kevin Rushforth wrote: > Update OpenGL headers to latest versions from Mesa project. I ran a sanity test on all three platforms. I also checked the diffs against the Java2D patch in openjdk/jdk#3854 and they match, excluding the Java2D-specific ifdefs. This pull request has now been integrated. Changeset: ab7c1515 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/ab7c15159d840377e6ceb9a80dd62e074aa80301 Stats: 140 lines in 6 files changed: 100 ins; 18 del; 22 mod 8262396: Update Mesa 3-D Headers to version 21.0.3 Reviewed-by: prr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/486 From pbansal at openjdk.java.net Thu May 6 18:01:13 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 6 May 2021 18:01:13 GMT Subject: RFR: 8210199: [linux / macOS] fileChooser can't handle emojis In-Reply-To: References: Message-ID: <0pPmcHmzeICe0HDcubaguYVLU0jgSTBz1Y7rZ3EmuMc=.ed753e67-586a-4690-bfd4-8708e4fe0908@github.com> On Wed, 21 Apr 2021 10:42:04 GMT, Jose Pereda wrote: > Both `GlassDialogs.m` for macOS and `GlassCommonDialogs.c` for Linux use UTF8 encoding for the file names selected via native FileChooser, and this will fail if there are emojis in the file name. > > This PR uses the same approach as in [JDK-8258381](https://bugs.openjdk.java.net/browse/JDK-8258381) for macOS, using UTF16 encoding. > > For Linux, the Java `String(byte[] bytes)` constructor with default charset is used instead, preventing the need of using UTF8 encoding. Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/471 From jgneff at openjdk.java.net Thu May 6 20:44:05 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Thu, 6 May 2021 20:44:05 GMT Subject: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error Message-ID: The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. ### Before For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: $ gradle sdk Dependency verification is an incubating feature. FAILURE: Build failed with an exception. * Where: Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 * What went wrong: A problem occurred evaluating script. > FAIL: WINSDK_DIR not defined ? BUILD FAILED in 4s *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? ### After With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: $ gradle sdk Dependency verification is an incubating feature. > Configure project : 'reg' is not recognized as an internal or external command, operable program or batch file. 'reg' is not recognized as an internal or external command, operable program or batch file. 'reg' is not recognized as an internal or external command, operable program or batch file. ? 'powershell.exe' is not recognized as an internal or external command, operable program or batch file. FAILURE: Build failed with an exception. * Where: Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 * What went wrong: A problem occurred evaluating script. > FAIL: WINSDK_DIR not defined ? BUILD FAILED in 3s *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? ------------- Commit messages: - JDK-8266396: Add VSCMD_DEBUG to genVSproperties.bat environment Changes: https://git.openjdk.java.net/jfx/pull/488/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=488&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266396 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/488.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/488/head:pull/488 PR: https://git.openjdk.java.net/jfx/pull/488 From jgneff at openjdk.java.net Thu May 6 20:46:55 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Thu, 6 May 2021 20:46:55 GMT Subject: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error In-Reply-To: References: Message-ID: On Thu, 6 May 2021 20:39:11 GMT, John Neffenger wrote: > The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. > > This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. > > This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. > > ### Before > > For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: > > > $ gradle sdk > Dependency verification is an incubating feature. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 4s > > > *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? > > ### After > > With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: > > > $ gradle sdk > Dependency verification is an incubating feature. > >> Configure project : > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > > ? > > 'powershell.exe' is not recognized as an internal or external command, > operable program or batch file. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 3s > > > *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? ### Notes The sequence of nested calls to the batch files is shown below, where `C:/Program Files (x86)/Microsoft Visual Studio` is the root directory of the Visual Studio files: buildSrc/genVSproperties.bat ? "2019/Community/VC/Auxiliary/Build/vcvarsall.bat" ? "2019/Community/Common7/Tools/VsDevCmd.bat" ? "2019/Community/Common7/Tools/vsdevcmd/core/winsdk.bat" The file `VsDevCmd.bat` calls `powershell.exe` to send telemetry to Microsoft when `VSCMD_DEBUG` is defined. To avoid sending telemetry, define the environment variable `VSCMD_SKIP_SENDTELEMETRY`. For example, in Cygwin you can define: export VSCMD_SKIP_SENDTELEMETRY=1 This pull request sets `VSCMD_DEBUG` to the empty string (""). In batch files, setting a variable to the empty string is equivalent to leaving the variable undefined. Furthermore, setting the value in Gradle to the string "3" is the same as setting the value to the number 3. To verify, I replaced `genVSproperties.bat` with this batch file: @echo off if defined VSCMD_DEBUG ( echo VSCMD_DEBUG is defined 1>&2 ) else ( echo VSCMD_DEBUG is not defined 1>&2 ) if "%VSCMD_DEBUG%" NEQ "" ( echo VSCMD_DEBUG = "%VSCMD_DEBUG%" 1>&2 ) else ( echo VSCMD_DEBUG is the empty string "%VSCMD_DEBUG%" 1>&2 ) We could instead set the default value to "3". In that case, I get two error messages during the Windows build due to following registry query failing on my system: $ reg query "HKLM\SOFTWARE\Microsoft\VisualStudio\VSPerf" \ ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From john at status6.com Thu May 6 20:59:54 2021 From: john at status6.com (John Neffenger) Date: Thu, 6 May 2021 13:59:54 -0700 Subject: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error In-Reply-To: References: Message-ID: On 5/6/21 1:46 PM, John Neffenger wrote: > $ reg query "HKLM\SOFTWARE\Microsoft\VisualStudio\VSPerf" \ The last part of my comment was truncated by Skara when it tripped over the '/v' Windows command-line option. It's repeated below for the mailing list ... We could instead set the default value to "3". In that case, I get two error messages during the Windows build due to following registry query failing on my system: $ reg query "HKLM\SOFTWARE\Microsoft\VisualStudio\VSPerf" /v "CollectionToolsDir2019" ERROR: The system was unable to find the specified registry key or value. ### Wiki I suggest that we remove the "Missing paths issue" section from the Wiki, added on October 31, 2019. It only led me astray. If you get `WINSDK_DIR not defined`, it's an error, and you should find its source and fix it. This pull request can help. From jgneff at openjdk.java.net Fri May 7 03:29:59 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Fri, 7 May 2021 03:29:59 GMT Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3 In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 22:07:34 GMT, Alessadro Parisi wrote: >> This is a toolchain upgrade on Windows from the current Visual Studio 2017 (version 15.9.16) to Visual Studio 2019 (version 16.5.3). This will match a recent upgrade done for JDK 15 -- see [JDK-8244214](https://bugs.openjdk.java.net/browse/JDK-8244214). >> >> I have run a full build and test using this new compiler. >> >> NOTE: although this isn't strictly dependent on [JDK-8244487](https://bugs.openjdk.java.net/browse/JDK-8244487), which is out for review as PR #211 , I plan to wait until that one is approved. I will then integrate PR #211 followed by this PR. > > Can you also update the build script located in tools/scripts? > Build fails on my system with `FAIL: WINSDK_DIR not defined` > Also, it's not possible to install Windows SDK 7.1 on Windows 10, so that should be updated too @palexdev Please ignore my previous comment and see #488 if you're still getting the `WINSDK_DIR` error. ------------- PR: https://git.openjdk.java.net/jfx/pull/212 From jvos at openjdk.java.net Fri May 7 07:41:55 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 7 May 2021 07:41:55 GMT Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3 In-Reply-To: References: Message-ID: <4LiRMU3NPSF-MxSxFROS2zoXgezTS58sdqsBU1HYiDc=.4a67c360-de81-4ce0-a5f0-9d379db080cf@github.com> On Wed, 6 May 2020 20:37:10 GMT, Kevin Rushforth wrote: > This is a toolchain upgrade on Windows from the current Visual Studio 2017 (version 15.9.16) to Visual Studio 2019 (version 16.5.3). This will match a recent upgrade done for JDK 15 -- see [JDK-8244214](https://bugs.openjdk.java.net/browse/JDK-8244214). > > I have run a full build and test using this new compiler. > > NOTE: although this isn't strictly dependent on [JDK-8244487](https://bugs.openjdk.java.net/browse/JDK-8244487), which is out for review as PR #211 , I plan to wait until that one is approved. I will then integrate PR #211 followed by this PR. I am not a big fan of scripts in a source code repository, unless they are automatically tested with every commit. Scripts are good candidates for being outdated soon, and often contain bitrotten code. We strive towards excellent code quality in the repository, and towards a very high test coverage for this code. If we can't achieve the same quality for scripts (which I believe is extremely hard to do), I am in favor of splitting of those scripts -- and maybe have them in a separate repository, maintained by different people? ------------- PR: https://git.openjdk.java.net/jfx/pull/212 From arapte at openjdk.java.net Fri May 7 11:15:12 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 7 May 2021 11:15:12 GMT Subject: [jfx11u] RFR: 8204568: Relative CSS-Attributes don't work all time Message-ID: Backport had a minor merge conflict of copyright year in the file `Labeled.java`. Rest of the changes are clean backport ------------- Commit messages: - 8204568: Relative CSS-Attributes don't work all time Changes: https://git.openjdk.java.net/jfx11u/pull/6/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=6&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8204568 Stats: 700 lines in 5 files changed: 696 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx11u/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/6/head:pull/6 PR: https://git.openjdk.java.net/jfx11u/pull/6 From kcr at openjdk.java.net Fri May 7 13:46:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 May 2021 13:46:51 GMT Subject: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error In-Reply-To: References: Message-ID: On Thu, 6 May 2021 20:39:11 GMT, John Neffenger wrote: > The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. > > This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. > > This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. > > ### Before > > For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: > > > $ gradle sdk > Dependency verification is an incubating feature. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 4s > > > *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? > > ### After > > With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: > > > $ gradle sdk > Dependency verification is an incubating feature. > >> Configure project : > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > > ? > > 'powershell.exe' is not recognized as an internal or external command, > operable program or batch file. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 3s > > > *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? It would be more convenient to ask the developer set `VSCMD_DEBUG` via an env variable, rather than asking them to edit `win.gradle`. That way, the instructions would be: export VSCMD_DEBUG=3 export VSCMD_SKIP_SENDTELEMETRY=1 gradle ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From arapte at openjdk.java.net Fri May 7 14:45:22 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 7 May 2021 14:45:22 GMT Subject: [jfx11u] RFR: 8240539: Upgrade gradle to version 6.3 Message-ID: jfx11u uses gradle 5.3 for build, it needs to be upgraded to gradle 6.3 same as jfx mainline. This PR backports three fixes: 1. [JDK-8240539](https://bugs.openjdk.java.net/browse/JDK-8240539): Upgrade gradle to version 6.3 2. [JDK-8232063](https://bugs.openjdk.java.net/browse/JDK-8232063): Upgrade gradle to version 6.0 and 3. [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754): FX build fails using gradle 5.6+ or 6 All the changes backport cleanly. ------------- Commit messages: - 8240539: Upgrade gradle to version 6.3 - 8232063: Upgrade gradle to version 6.0 - 8226754: FX build fails using gradle 5.6+ or 6 Changes: https://git.openjdk.java.net/jfx11u/pull/7/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=7&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240539 Stats: 31 lines in 6 files changed: 17 ins; 4 del; 10 mod Patch: https://git.openjdk.java.net/jfx11u/pull/7.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/7/head:pull/7 PR: https://git.openjdk.java.net/jfx11u/pull/7 From jgneff at openjdk.java.net Fri May 7 16:03:02 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Fri, 7 May 2021 16:03:02 GMT Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3 In-Reply-To: References: Message-ID: On Wed, 6 May 2020 20:37:10 GMT, Kevin Rushforth wrote: > This is a toolchain upgrade on Windows from the current Visual Studio 2017 (version 15.9.16) to Visual Studio 2019 (version 16.5.3). This will match a recent upgrade done for JDK 15 -- see [JDK-8244214](https://bugs.openjdk.java.net/browse/JDK-8244214). > > I have run a full build and test using this new compiler. > > NOTE: although this isn't strictly dependent on [JDK-8244487](https://bugs.openjdk.java.net/browse/JDK-8244487), which is out for review as PR #211 , I plan to wait until that one is approved. I will then integrate PR #211 followed by this PR. I also think that we should remove it. If you read its history on the mailing list, it was added to the repository in part as a solution to the `WINSDK_DIR not defined` error. See the message ["Problems building openjfx"][1] on the mailing list. That discussion starts with `WINSDK_DIR`. My goal in #488 is to give developers a better chance at getting the official build under Cygwin working after hitting the error. [1]: https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-November/022858.html ------------- PR: https://git.openjdk.java.net/jfx/pull/212 From jgneff at openjdk.java.net Fri May 7 17:47:03 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Fri, 7 May 2021 17:47:03 GMT Subject: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error In-Reply-To: References: Message-ID: On Fri, 7 May 2021 13:42:49 GMT, Kevin Rushforth wrote: > It would be more convenient to ask the developer set `VSCMD_DEBUG` via an env variable, rather than asking them to edit `win.gradle`. Thanks, Kevin. That is the most direct approach. I didn't document it that way for the following reasons: 1. Using the `export` command under Cygwin sets the variable for the *entire* build. In the current commit, the variable, when defined, is set only for the duration of the `genVSproperties.bat` batch file and the batch files it calls. 2. I would like to see this documented in the code, even if just as comments, as opposed to the Wiki. When I got the error, the first thing I did was search through the code base for `WINSDK_DIR`. I would have found the lines added by this pull request right away. Don't let the name confused you. The variable is not a debugging variable; it doesn't enable debug trace logging. What it actually does is prevent the batch files from sending both standard output and standard error to "NUL", which they do by default. Defining it with `VSCMD_DEBUG=3` really means, "Please don't silently discard really important error messages!" You don't expect all error messages to be hidden from you when you invoke 3,985 Windows batch file statements, but that's exactly what's happening now: $ cloc trace.bat 1 text file. 1 unique file. 0 files ignored. github.com/AlDanial/cloc v 1.82 T=0.01 s (73.6 files/s, 438775.4 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- DOS Batch 1 1938 40 3985 ------------------------------------------------------------------------------- I'll up the ante and suggest that we set the value to "3" by default in the build file (and disable telemetry). Then the batch files will behave as one would expect. I tested all values of the variable (undefined, valid, and invalid), and the generated file `windows_tools.properties` was identical in all cases. Otherwise, where do you suggest we document this? If you disfavor the current options ("" and "3"), what do you think of making it three comment lines in the `win.gradle` file? ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From github.com+16880178+palexdev at openjdk.java.net Fri May 7 17:55:23 2021 From: github.com+16880178+palexdev at openjdk.java.net (Alessadro Parisi) Date: Fri, 7 May 2021 17:55:23 GMT Subject: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3 In-Reply-To: References: Message-ID: On Fri, 7 May 2021 16:00:31 GMT, John Neffenger wrote: > I also think that we should remove it. If you read its history on the mailing list, it was added to the repository in part as a solution to the `WINSDK_DIR not defined` error. See the message ["Problems building openjfx"][1] on the mailing list. That discussion starts with `WINSDK_DIR`. My goal in #488 is to give developers a better chance at getting the official build under Cygwin working after hitting the error. > > [1]: https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-November/022858.html > Directories configuration issues that by the way still persist. In fact what I did to build the project in the end was to manually set the dir in the gradle config files and that was the only solution that would make the project compilable on my PC ------------- PR: https://git.openjdk.java.net/jfx/pull/212 From kcr at openjdk.java.net Fri May 7 23:02:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 May 2021 23:02:16 GMT Subject: RFR: 8266757: Add entry for jdk-12_doc-all.zip to gradle/verification-metadata.xml Message-ID: As indicated in JBS this PR adds a missing entry for the JDK 12 API docs zip bundle for javadoc offline processing. This missing entry is causing a build failure on my system (which will soon propagate to our CI builds). ------------- Commit messages: - 8266757: Add entry for jdk-12_doc-all.zip to gradle/verification-metadata.xml Changes: https://git.openjdk.java.net/jfx/pull/489/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=489&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266757 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/489.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/489/head:pull/489 PR: https://git.openjdk.java.net/jfx/pull/489 From kcr at openjdk.java.net Fri May 7 23:02:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 May 2021 23:02:17 GMT Subject: RFR: 8266757: Add entry for jdk-12_doc-all.zip to gradle/verification-metadata.xml In-Reply-To: References: Message-ID: On Fri, 7 May 2021 17:30:37 GMT, Kevin Rushforth wrote: > As indicated in JBS this PR adds a missing entry for the JDK 12 API docs zip bundle for javadoc offline processing. This missing entry is causing a build failure on my system (which will soon propagate to our CI builds). One of the Linux unit tests failed due to and unrelated issue, [JDK-8266643](https://bugs.openjdk.java.net/browse/JDK-8266643). ------------- PR: https://git.openjdk.java.net/jfx/pull/489 From kcr at openjdk.java.net Fri May 7 23:57:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 May 2021 23:57:36 GMT Subject: [jfx11u] RFR: 8240539: Upgrade gradle to version 6.3 In-Reply-To: References: Message-ID: On Fri, 7 May 2021 14:35:48 GMT, Ambarish Rapte wrote: > jfx11u uses gradle 5.3 for build, it needs to be upgraded to gradle 6.3 same as jfx mainline. > This PR backports three fixes: > > 1. [JDK-8240539](https://bugs.openjdk.java.net/browse/JDK-8240539): Upgrade gradle to version 6.3 > 2. [JDK-8232063](https://bugs.openjdk.java.net/browse/JDK-8232063): Upgrade gradle to version 6.0 and > 3. [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754): FX build fails using gradle 5.6+ or 6 > > All the changes backport cleanly. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx11u/pull/7 From kcr at openjdk.java.net Sat May 8 14:19:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 May 2021 14:19:05 GMT Subject: RFR: 8264219: tools/scripts/build.ps1 is out of date and no longer works Message-ID: As noted in PR #212 the unused `tools/scripts/build.ps1` script no longer works. This script was added in support of the Appveyor builds in the old `javafxports/openjdk-jfx` sandbox repo, which haven't been used in nearly two years. In its current state, it is more harmful to leave it in, as it is a source of confusion. Since the script is unused, this PR will simply delete it. ------------- Commit messages: - 8264219: tools/scripts/build.ps1 is out of date and no longer works Changes: https://git.openjdk.java.net/jfx/pull/490/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=490&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264219 Stats: 72 lines in 1 file changed: 0 ins; 72 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/490.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/490/head:pull/490 PR: https://git.openjdk.java.net/jfx/pull/490 From kcr at openjdk.java.net Sat May 8 15:47:23 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 May 2021 15:47:23 GMT Subject: [jfx11u] RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop Message-ID: <6RwspC-Zw1rSF7lBz1vw0auze-63R6HoYz6j39m4zXA=.aea5d6cc-f745-493f-959b-75da818788d7@github.com> This is a mostly-clean backport to jfx11u. The only merge conflicts I had to fix were in `D3DPipeline.cc` to ignore two hunks from the patch, since the static library support is not present in 11 (this is the exact same thing I had to do for the FX 8u backport). Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. Additional testing: verified on a remote desktop connection that disconnecting and reconnecting now works. ------------- Commit messages: - 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop Changes: https://git.openjdk.java.net/jfx11u/pull/8/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=8&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239589 Stats: 844 lines in 47 files changed: 724 ins; 36 del; 84 mod Patch: https://git.openjdk.java.net/jfx11u/pull/8.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/8/head:pull/8 PR: https://git.openjdk.java.net/jfx11u/pull/8 From kcr at openjdk.java.net Sat May 8 15:49:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 May 2021 15:49:44 GMT Subject: [jfx11u] RFR: 8259356: MediaPlayer's seek freezes video Message-ID: Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. ------------- Commit messages: - 8259356: MediaPlayer's seek freezes video Changes: https://git.openjdk.java.net/jfx11u/pull/10/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=10&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259356 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/10.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/10/head:pull/10 PR: https://git.openjdk.java.net/jfx11u/pull/10 From kcr at openjdk.java.net Sat May 8 15:49:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 May 2021 15:49:50 GMT Subject: [jfx11u] RFR: 8259555: Webkit crashes on Apple Silicon Message-ID: Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. ------------- Commit messages: - 8259555: Webkit crashes on Apple Silicon Changes: https://git.openjdk.java.net/jfx11u/pull/9/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=9&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259555 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/9/head:pull/9 PR: https://git.openjdk.java.net/jfx11u/pull/9 From kcr at openjdk.java.net Sat May 8 15:50:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 May 2021 15:50:03 GMT Subject: [jfx11u] RFR: 8262276: Debug build of WebKit fails Message-ID: Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. ------------- Commit messages: - 8262276: Debug build of WebKit fails Changes: https://git.openjdk.java.net/jfx11u/pull/13/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=13&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262276 Stats: 34 lines in 6 files changed: 21 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jfx11u/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/13/head:pull/13 PR: https://git.openjdk.java.net/jfx11u/pull/13 From kcr at openjdk.java.net Sat May 8 15:50:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 May 2021 15:50:26 GMT Subject: [jfx11u] RFR: 8263788: JavaFX application freezes completely after some time when using the WebView Message-ID: <9woqEHXAF3RmOuSpSGYdHdVtyor1HhJOGojs5er4WwI=.d2cf8cc0-1772-4861-924c-410a0c349ea0@github.com> Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. ------------- Commit messages: - 8263788: JavaFX application freezes completely after some time when using the WebView Changes: https://git.openjdk.java.net/jfx11u/pull/12/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=12&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263788 Stats: 38 lines in 3 files changed: 15 ins; 18 del; 5 mod Patch: https://git.openjdk.java.net/jfx11u/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/12/head:pull/12 PR: https://git.openjdk.java.net/jfx11u/pull/12 From kcr at openjdk.java.net Sat May 8 15:50:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 May 2021 15:50:30 GMT Subject: [jfx11u] RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader Message-ID: Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. ------------- Commit messages: - 8264990: WebEngine crashes with segfault when not loaded through system classloader Changes: https://git.openjdk.java.net/jfx11u/pull/11/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=11&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264990 Stats: 342 lines in 7 files changed: 315 ins; 7 del; 20 mod Patch: https://git.openjdk.java.net/jfx11u/pull/11.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/11/head:pull/11 PR: https://git.openjdk.java.net/jfx11u/pull/11 From kcr at openjdk.java.net Sat May 8 15:55:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 May 2021 15:55:11 GMT Subject: [jfx11u] RFR: 8264928: Update to Xcode 12.4 Message-ID: Almost clean backport to jfx11u (clean except for surrounding context in `build.properties`). Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. ------------- Commit messages: - 8264928: Update to Xcode 12.4 Changes: https://git.openjdk.java.net/jfx11u/pull/14/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=14&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264928 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/14.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/14/head:pull/14 PR: https://git.openjdk.java.net/jfx11u/pull/14 From kcr at openjdk.java.net Sat May 8 16:24:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 8 May 2021 16:24:06 GMT Subject: [jfx11u] RFR: 8204568: Relative CSS-Attributes don't work all time In-Reply-To: References: Message-ID: On Fri, 7 May 2021 11:10:41 GMT, Ambarish Rapte wrote: > Backport had a minor merge conflict of copyright year in the file `Labeled.java`. > Rest of the changes are clean backport Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/6 From jgneff at openjdk.java.net Mon May 10 05:54:51 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 10 May 2021 05:54:51 GMT Subject: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error [v2] In-Reply-To: References: Message-ID: > The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. > > This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. > > This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. > > ### Before > > For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: > > > $ gradle sdk > Dependency verification is an incubating feature. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 4s > > > *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? > > ### After > > With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: > > > $ gradle sdk > Dependency verification is an incubating feature. > >> Configure project : > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > > ? > > 'powershell.exe' is not recognized as an internal or external command, > operable program or batch file. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 3s > > > *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - JDK-8266396: Allow VSCMD_DEBUG to work as intended - Merge branch 'master' into vscmd-debug - JDK-8266396: Add VSCMD_DEBUG to genVSproperties.bat environment ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/488/files - new: https://git.openjdk.java.net/jfx/pull/488/files/248d0f72..6f6f4932 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=488&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=488&range=00-01 Stats: 227 lines in 11 files changed: 179 ins; 21 del; 27 mod Patch: https://git.openjdk.java.net/jfx/pull/488.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/488/head:pull/488 PR: https://git.openjdk.java.net/jfx/pull/488 From jgneff at openjdk.java.net Mon May 10 06:05:00 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 10 May 2021 06:05:00 GMT Subject: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error [v2] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 05:54:51 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - JDK-8266396: Allow VSCMD_DEBUG to work as intended > - Merge branch 'master' into vscmd-debug > - JDK-8266396: Add VSCMD_DEBUG to genVSproperties.bat environment I committed a better proposal, thanks to Kevin's suggestion, and after seeing what it takes to create the `trace.bat` file in my previous comment. Unfortunately, it's not enough to define `VSCMD_DEBUG` externally. The `cmd /q` option (in `win.gradle`) and the redirection of output to `NUL` (in `genVSproperties.bat`) conspire to suppress the requested information, regardless of the variable's value. So this commit adds the minimum changes for `VSCMD_DEBUG` to work. Instead of redirecting output to `NUL`, it redirects output to a new log file called `vcvarsall.log`. Because the trace-level debugging of `VSCMD_DEBUG=3` depends on `echo` being enabled, it adds `echo off` and `echo on` commands selectively in the OpenJFX batch file instead of using the global `cmd /q` option in the Gradle build file. The table below shows the number of debugging lines that are logged for each value of `VSCMD_DEBUG`, both before this pull request (on the `master` branch) and after the latest commit (on the pull request branch): | VSCMD_DEBUG | Level | Before | After | |:-----------:|:---------|-------:|------:| | undefined | none | 0 | 10 | | 1 | basic | 0 | 93 | | 2 | detailed | 0 | 615 | | 3 | trace | 2 | 5,832 | With this change, `VSCMD_DEBUG` actually works as intended. When the build is successful, there's just an extra 10-line log file in the build directory. If something goes wrong, though, developers can set the environment variable and run `gradle help`. The log file will then contain all the information needed to fix the error. If they're having trouble figuring it out, they can post the log file and ask for help on the mailing list. ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From arapte at openjdk.java.net Mon May 10 07:51:15 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 10 May 2021 07:51:15 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 15:20:41 GMT, mstr2 wrote: > The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). > > However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. > > ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). > > The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. > > This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. > > I've filed a bug report with the same title. looks all good to me ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/454 From arapte at openjdk.java.net Mon May 10 09:11:04 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 10 May 2021 09:11:04 GMT Subject: RFR: 8189354: Change.getRemoved() list contains incorrect selected items when a TreeItem is collapsed [v9] In-Reply-To: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> References: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> Message-ID: On Mon, 3 May 2021 20:51:13 GMT, mstr2 wrote: >> This PR fixes the implementation of `ControlUtils.reducingChange`, which incorrectly computed adjacent removed indices, thus resulting in incorrect removal notifications. >> >> Since there were no unit tests for this method, I also added a bunch of tests. >> >> After applying this fix, I can no longer reproduce [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228). > > mstr2 has updated the pull request incrementally with two additional commits since the last revision: > > - Rename local variable in test > - Remove unrelated fix looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/480 From arapte at openjdk.java.net Mon May 10 09:11:05 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 10 May 2021 09:11:05 GMT Subject: RFR: 8189354: Change.getRemoved() list contains incorrect selected items when a TreeItem is collapsed [v9] In-Reply-To: References: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> Message-ID: On Wed, 5 May 2021 09:32:30 GMT, Ambarish Rapte wrote: > We have couple more similar issues reported > > 1. [JDK-8255935](https://bugs.openjdk.java.net/browse/JDK-8255935) : MultipleSelectionModel provides incorrect 'removed' sub-list in change events > 2. [JDK-8196065](https://bugs.openjdk.java.net/browse/JDK-8196065) : ListChangeListener getRemoved() returns items that were not removed. Both these above issues do not get fixed by this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From arapte at openjdk.java.net Mon May 10 09:17:14 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 10 May 2021 09:17:14 GMT Subject: [jfx11u] Integrated: 8204568: Relative CSS-Attributes don't work all time In-Reply-To: References: Message-ID: On Fri, 7 May 2021 11:10:41 GMT, Ambarish Rapte wrote: > Backport had a minor merge conflict of copyright year in the file `Labeled.java`. > Rest of the changes are clean backport This pull request has now been integrated. Changeset: fdd0fa09 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/fdd0fa0942e6397bb2edfd73cc0c0911e8e4395a Stats: 700 lines in 5 files changed: 696 ins; 0 del; 4 mod 8204568: Relative CSS-Attributes don't work all time Reviewed-by: kcr Backport-of: 9c7cf172791c48ad419868045dd886968a2c4be8 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/6 From arapte at openjdk.java.net Mon May 10 09:18:54 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 10 May 2021 09:18:54 GMT Subject: [jfx11u] Integrated: 8240539: Upgrade gradle to version 6.3 In-Reply-To: References: Message-ID: On Fri, 7 May 2021 14:35:48 GMT, Ambarish Rapte wrote: > jfx11u uses gradle 5.3 for build, it needs to be upgraded to gradle 6.3 same as jfx mainline. > This PR backports three fixes: > > 1. [JDK-8240539](https://bugs.openjdk.java.net/browse/JDK-8240539): Upgrade gradle to version 6.3 > 2. [JDK-8232063](https://bugs.openjdk.java.net/browse/JDK-8232063): Upgrade gradle to version 6.0 and > 3. [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754): FX build fails using gradle 5.6+ or 6 > > All the changes backport cleanly. This pull request has now been integrated. Changeset: 6ff7384f Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/6ff7384f63b5e1767d97db9dbfde0db661423ee9 Stats: 31 lines in 6 files changed: 17 ins; 4 del; 10 mod 8240539: Upgrade gradle to version 6.3 8232063: Upgrade gradle to version 6.0 8226754: FX build fails using gradle 5.6+ or 6 Reviewed-by: kcr Backport-of: 9ecc10793d0e8b6fdba4e169166389f99334f820 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/7 From fastegal at openjdk.java.net Mon May 10 11:04:58 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 10 May 2021 11:04:58 GMT Subject: RFR: 8189354: Change.getRemoved() list contains incorrect selected items when a TreeItem is collapsed [v9] In-Reply-To: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> References: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> Message-ID: <_0XrVH2x6WsX9Q29S_Nd8qHILQyq5EeCYPf1LWHyKko=.782ec9f0-3916-4fc0-9ea6-e52db4d36e26@github.com> On Mon, 3 May 2021 20:51:13 GMT, mstr2 wrote: >> This PR fixes the implementation of `ControlUtils.reducingChange`, which incorrectly computed adjacent removed indices, thus resulting in incorrect removal notifications. >> >> Since there were no unit tests for this method, I also added a bunch of tests. >> >> After applying this fix, I can no longer reproduce [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228). > > mstr2 has updated the pull request incrementally with two additional commits since the last revision: > > - Rename local variable in test > - Remove unrelated fix Looks good :) Verified tests failing/passing before/after fix, verified example in bug report working correctly ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/480 From fastegal at openjdk.java.net Mon May 10 11:26:49 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 10 May 2021 11:26:49 GMT Subject: RFR: 8189354: Change.getRemoved() list contains incorrect selected items when a TreeItem is collapsed [v9] In-Reply-To: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> References: <3CB0mBAm9lvHKLHJsgCyxLd2vYfDjKgaRiAdAQ4LHjY=.6f726463-fc0e-4a41-8a31-4e7aa5e1bb2d@github.com> Message-ID: On Mon, 3 May 2021 20:51:13 GMT, mstr2 wrote: >> This PR fixes the implementation of `ControlUtils.reducingChange`, which incorrectly computed adjacent removed indices, thus resulting in incorrect removal notifications. >> >> Since there were no unit tests for this method, I also added a bunch of tests. >> >> After applying this fix, I can no longer reproduce [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228). > > mstr2 has updated the pull request incrementally with two additional commits since the last revision: > > - Rename local variable in test > - Remove unrelated fix fyi: filed [JDK-8266811](https://bugs.openjdk.java.net/browse/JDK-8266811) for the eclipse classpath issue introduced with this (by using MockListObserver) - will fix when this is integrated :) ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From jvos at openjdk.java.net Mon May 10 12:10:41 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 May 2021 12:10:41 GMT Subject: [jfx11u] RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: <6RwspC-Zw1rSF7lBz1vw0auze-63R6HoYz6j39m4zXA=.aea5d6cc-f745-493f-959b-75da818788d7@github.com> References: <6RwspC-Zw1rSF7lBz1vw0auze-63R6HoYz6j39m4zXA=.aea5d6cc-f745-493f-959b-75da818788d7@github.com> Message-ID: <8inyKTJCrGu1zDwcaO3yOW5qIYZu_QkW59H1aYDrWSw=.9d21cdc9-37eb-4ad9-b4b5-879647a70049@github.com> On Sat, 8 May 2021 15:41:06 GMT, Kevin Rushforth wrote: > This is a mostly-clean backport to jfx11u. The only merge conflicts I had to fix were in `D3DPipeline.cc` to ignore two hunks from the patch, since the static library support is not present in 11 (this is the exact same thing I had to do for the FX 8u backport). > > Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. > > Additional testing: verified on a remote desktop connection that disconnecting and reconnecting now works. looks good ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx11u/pull/8 From kcr at openjdk.java.net Mon May 10 12:26:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 May 2021 12:26:55 GMT Subject: [jfx11u] Integrated: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop In-Reply-To: <6RwspC-Zw1rSF7lBz1vw0auze-63R6HoYz6j39m4zXA=.aea5d6cc-f745-493f-959b-75da818788d7@github.com> References: <6RwspC-Zw1rSF7lBz1vw0auze-63R6HoYz6j39m4zXA=.aea5d6cc-f745-493f-959b-75da818788d7@github.com> Message-ID: <2YfijUKYWXyDtXX39kibmZM8c4mLqRKXG-DL6vqE6vk=.fe8ee142-5c77-4cd3-b860-d98b72e8ec80@github.com> On Sat, 8 May 2021 15:41:06 GMT, Kevin Rushforth wrote: > This is a mostly-clean backport to jfx11u. The only merge conflicts I had to fix were in `D3DPipeline.cc` to ignore two hunks from the patch, since the static library support is not present in 11 (this is the exact same thing I had to do for the FX 8u backport). > > Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. > > Additional testing: verified on a remote desktop connection that disconnecting and reconnecting now works. This pull request has now been integrated. Changeset: 26b5960b Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/26b5960b24fa41681a6598bbfed4acaf209e1f03 Stats: 844 lines in 47 files changed: 724 ins; 36 del; 84 mod 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop Reviewed-by: jvos Backport-of: 73e70fe978dda9fc821061dfc12bfb742dd7dc25 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/8 From aghaisas at openjdk.java.net Mon May 10 13:14:23 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 10 May 2021 13:14:23 GMT Subject: RFR: 8264138: Replace uses of Class.newInstance Message-ID: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> This PR replaces Class.newInstance() deprecated method with Contructor.newinstance(). ------------- Commit messages: - remove blankline - replace deprecated Class.newInstance Changes: https://git.openjdk.java.net/jfx/pull/491/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=491&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264138 Stats: 32 lines in 8 files changed: 0 ins; 6 del; 26 mod Patch: https://git.openjdk.java.net/jfx/pull/491.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/491/head:pull/491 PR: https://git.openjdk.java.net/jfx/pull/491 From jvos at openjdk.java.net Mon May 10 13:14:52 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 May 2021 13:14:52 GMT Subject: [jfx11u] RFR: 8258381: [macos] Exception when input emoji using Chinese input method Message-ID: Clean backport. This only touches the macos platform, build and basic tests work fine. ------------- Commit messages: - 8258381: [macos] Exception when input emoji using Chinese input method Changes: https://git.openjdk.java.net/jfx11u/pull/15/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=15&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258381 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/15.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/15/head:pull/15 PR: https://git.openjdk.java.net/jfx11u/pull/15 From github.com+43553916+mstr2 at openjdk.java.net Mon May 10 13:21:05 2021 From: github.com+43553916+mstr2 at openjdk.java.net (mstr2) Date: Mon, 10 May 2021 13:21:05 GMT Subject: Integrated: 8189354: Change.getRemoved() list contains incorrect selected items when a TreeItem is collapsed In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 04:11:28 GMT, mstr2 wrote: > This PR fixes the implementation of `ControlUtils.reducingChange`, which incorrectly computed adjacent removed indices, thus resulting in incorrect removal notifications. > > Since there were no unit tests for this method, I also added a bunch of tests. > > After applying this fix, I can no longer reproduce [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228). This pull request has now been integrated. Changeset: eb913cb7 Author: mstr2 <43553916+mstr2 at users.noreply.github.com> Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/eb913cb78bbc7a4973d1dfab3b02335edeff72aa Stats: 77 lines in 5 files changed: 46 ins; 26 del; 5 mod 8189354: Change.getRemoved() list contains incorrect selected items when a TreeItem is collapsed Reviewed-by: arapte, fastegal ------------- PR: https://git.openjdk.java.net/jfx/pull/480 From jvos at openjdk.java.net Mon May 10 16:33:00 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 May 2021 16:33:00 GMT Subject: [jfx11u] Integrated: 8258381: [macos] Exception when input emoji using Chinese input method In-Reply-To: References: Message-ID: On Mon, 10 May 2021 10:19:04 GMT, Johan Vos wrote: > Clean backport. > This only touches the macos platform, build and basic tests work fine. This pull request has now been integrated. Changeset: debddf79 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/debddf794f6c026fb860ca214c2fb6127de6e6b1 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8258381: [macos] Exception when input emoji using Chinese input method Backport-of: 052e9f7d30ddbbb06e6c7ba51bc1af8c3adc4568 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/15 From jvos at openjdk.java.net Mon May 10 16:45:16 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 May 2021 16:45:16 GMT Subject: [jfx11u] RFR: 8211294: ScrollPane content is blurry with 125% scaling Message-ID: Clean backport for jfx11u . Builds and tests are green. ------------- Commit messages: - 8211294: ScrollPane content is blurry with 125% scaling Changes: https://git.openjdk.java.net/jfx11u/pull/16/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=16&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8211294 Stats: 161 lines in 3 files changed: 136 ins; 12 del; 13 mod Patch: https://git.openjdk.java.net/jfx11u/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/16/head:pull/16 PR: https://git.openjdk.java.net/jfx11u/pull/16 From mstrauss at openjdk.java.net Mon May 10 17:33:22 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 10 May 2021 17:33:22 GMT Subject: RFR: 8266539: [TreeView]: Change.getRemoved() contains null item when deselecting a TreeItem Message-ID: This PR contains a fix that was de-scoped from #480 and solves an issue where an incorrect index is used in `MultipleSelectionModelBase.SelectedIndicesList.clear(int)`. ------------- Commit messages: - Fixed incorrect index - Failing test Changes: https://git.openjdk.java.net/jfx/pull/492/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=492&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266539 Stats: 17 lines in 2 files changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/492.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/492/head:pull/492 PR: https://git.openjdk.java.net/jfx/pull/492 From jvos at openjdk.java.net Mon May 10 19:26:15 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 10 May 2021 19:26:15 GMT Subject: [jfx11u] Integrated: 8211294: ScrollPane content is blurry with 125% scaling In-Reply-To: References: Message-ID: <01gLYsp2pisBZXGX9LvXRQ_w7D1oJ5BcGBRI-QW30F4=.dfc9bb92-e2f6-4c69-846e-dce0a86d5c17@github.com> On Mon, 10 May 2021 16:36:53 GMT, Johan Vos wrote: > Clean backport for jfx11u . Builds and tests are green. This pull request has now been integrated. Changeset: 32fda115 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/32fda11550c1e2c7b19ef681082e03fb52552cfd Stats: 161 lines in 3 files changed: 136 ins; 12 del; 13 mod 8211294: ScrollPane content is blurry with 125% scaling Backport-of: 9c84c77b6db546801cbd1a10563092bf84d026f7 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/16 From kcr at openjdk.java.net Mon May 10 21:33:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 May 2021 21:33:57 GMT Subject: [jfx11u] Integrated: 8259555: Webkit crashes on Apple Silicon In-Reply-To: References: Message-ID: On Sat, 8 May 2021 15:42:09 GMT, Kevin Rushforth wrote: > Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. This pull request has now been integrated. Changeset: 5ab6c406 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/5ab6c4062704b6368a8a5d805a90e658d72c554e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8259555: Webkit crashes on Apple Silicon Backport-of: b2f842de4d3db096f510fa3ef00936827bc85686 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/9 From kcr at openjdk.java.net Mon May 10 21:35:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 May 2021 21:35:03 GMT Subject: [jfx11u] Integrated: 8259356: MediaPlayer's seek freezes video In-Reply-To: References: Message-ID: On Sat, 8 May 2021 15:42:42 GMT, Kevin Rushforth wrote: > Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. This pull request has now been integrated. Changeset: 5b2b9f92 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/5b2b9f921a14db18c0ef71d1c27deab87118f0a8 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8259356: MediaPlayer's seek freezes video Backport-of: a68355803c5d05eea046ad07aca2e9e7d8b99dfc ------------- PR: https://git.openjdk.java.net/jfx11u/pull/10 From kcr at openjdk.java.net Mon May 10 21:37:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 May 2021 21:37:00 GMT Subject: [jfx11u] Integrated: 8264990: WebEngine crashes with segfault when not loaded through system classloader In-Reply-To: References: Message-ID: On Sat, 8 May 2021 15:43:36 GMT, Kevin Rushforth wrote: > Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. This pull request has now been integrated. Changeset: 346cf7d0 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/346cf7d04a60f5d8c02e20d9031c87fbe356280c Stats: 342 lines in 7 files changed: 315 ins; 7 del; 20 mod 8264990: WebEngine crashes with segfault when not loaded through system classloader Backport-of: e02cee966780f5e3056db80851ef59929ab76ab0 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/11 From kcr at openjdk.java.net Mon May 10 21:38:20 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 May 2021 21:38:20 GMT Subject: [jfx11u] Integrated: 8263788: JavaFX application freezes completely after some time when using the WebView In-Reply-To: <9woqEHXAF3RmOuSpSGYdHdVtyor1HhJOGojs5er4WwI=.d2cf8cc0-1772-4861-924c-410a0c349ea0@github.com> References: <9woqEHXAF3RmOuSpSGYdHdVtyor1HhJOGojs5er4WwI=.d2cf8cc0-1772-4861-924c-410a0c349ea0@github.com> Message-ID: On Sat, 8 May 2021 15:44:16 GMT, Kevin Rushforth wrote: > Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. This pull request has now been integrated. Changeset: 724dae39 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/724dae39b4e1af4ae4c76d16b140503c791041d7 Stats: 38 lines in 3 files changed: 15 ins; 18 del; 5 mod 8263788: JavaFX application freezes completely after some time when using the WebView Backport-of: 49d2126e26a32ac7f83525ba3340a4b069b346a2 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/12 From kcr at openjdk.java.net Mon May 10 21:40:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 May 2021 21:40:15 GMT Subject: [jfx11u] Integrated: 8262276: Debug build of WebKit fails In-Reply-To: References: Message-ID: On Sat, 8 May 2021 15:44:46 GMT, Kevin Rushforth wrote: > Clean backport to jfx11u. Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. This pull request has now been integrated. Changeset: 63f96315 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/63f963156fc493f181382141a4894144edd09a01 Stats: 34 lines in 6 files changed: 21 ins; 0 del; 13 mod 8262276: Debug build of WebKit fails Backport-of: ed080c82427b3a0b2e0091670ca97cb4dd38c761 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/13 From kcr at openjdk.java.net Mon May 10 21:42:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 10 May 2021 21:42:15 GMT Subject: [jfx11u] Integrated: 8264928: Update to Xcode 12.4 In-Reply-To: References: Message-ID: On Sat, 8 May 2021 15:47:44 GMT, Kevin Rushforth wrote: > Almost clean backport to jfx11u (clean except for surrounding context in `build.properties`). Tested on all three platforms, along with my other in-progress backports, all of which are aggregated in my [`kevinrushforth:test-kcr-11.0.12`](https://github.com/kevinrushforth/jfx11u/commits/test-kcr-11.0.12) branch. This pull request has now been integrated. Changeset: dfe89099 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/dfe89099d04576d7bd8630b610b7a1fde5a42730 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8264928: Update to Xcode 12.4 Backport-of: c8384a1b544fa322b359ceca8bd3df21aae92c56 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/14 From jgneff at openjdk.java.net Mon May 10 22:19:03 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 10 May 2021 22:19:03 GMT Subject: RFR: JDK-8266396: Allow VSCMD_DEBUG to work as intended [v2] In-Reply-To: References: Message-ID: On Mon, 10 May 2021 05:54:51 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - JDK-8266396: Allow VSCMD_DEBUG to work as intended > - Merge branch 'master' into vscmd-debug > - JDK-8266396: Add VSCMD_DEBUG to genVSproperties.bat environment To understand the build error that occurred with my last commit, you need to know three things: 1. by default, the JavaFX build on Windows always sends telemetry to Microsoft each time it runs the `vcvarsall.bat` batch file, 2. by default, the process that sends the telemetry is asynchronous, and 3. the Windows build runs that batch file twice, once for `x86` (via `vcvars32.bat`) and again for `x64`. The actual build error is way back at [Line 182][1] with the message "The process cannot access the file because it is being used by another process." It's a timing problem that occurs only when both `VSCMD_SKIP_SENDTELEMETRY` and `VSCMD_DEBUG` are undefined (or set to the empty string). In that case, the Visual Studio batch files start an asynchronous PowerShell script to send telemetry to Microsoft. Because the asynchronous process will continue to use the same standard error file descriptor as the batch file that started it, we hit the error when we try to run the batch file a second time before the PowerShell script has completed. If the PowerShell script completes before we run the batch file again, the error does not occur. I didn't hit the error because `powershell.exe` was not found on my `PATH`, essentially disabling the telemetry. The fix is simple: skip sending the telemetry. We should probably be doing that, anyway. An alternative, and perhaps safer, fix is not to redirect standard error when calling the `vcvarsall.bat` batch file. In that case, the trace messages would go to the log file but the error messages would go to the console, making it difficult to associate any errors with the commands that caused them. [1]: https://github.com/jgneff/jfx/runs/2542639912#step:8:182 ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From jgneff at openjdk.java.net Tue May 11 01:17:32 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 11 May 2021 01:17:32 GMT Subject: RFR: JDK-8266396: Allow VSCMD_DEBUG to work as intended [v3] In-Reply-To: References: Message-ID: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> > The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. > > This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. > > This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. > > ### Before > > For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: > > > $ gradle sdk > Dependency verification is an incubating feature. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 4s > > > *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? > > ### After > > With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: > > > $ gradle sdk > Dependency verification is an incubating feature. > >> Configure project : > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > 'reg' is not recognized as an internal or external command, > operable program or batch file. > > ? > > 'powershell.exe' is not recognized as an internal or external command, > operable program or batch file. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What went wrong: > A problem occurred evaluating script. >> FAIL: WINSDK_DIR not defined > > ? > > BUILD FAILED in 3s > > > *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Skip sending telemetry to fix "file in use" error ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/488/files - new: https://git.openjdk.java.net/jfx/pull/488/files/6f6f4932..c58bbdd9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=488&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=488&range=01-02 Stats: 8 lines in 2 files changed: 3 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/488.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/488/head:pull/488 PR: https://git.openjdk.java.net/jfx/pull/488 From mstrauss at openjdk.java.net Tue May 11 01:47:26 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 11 May 2021 01:47:26 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v4] In-Reply-To: References: Message-ID: > The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. > > `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - Fixed clear-and-select change notification - Add failing tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/478/files - new: https://git.openjdk.java.net/jfx/pull/478/files/d739a993..1219b6af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=02-03 Stats: 121 lines in 6 files changed: 87 ins; 10 del; 24 mod Patch: https://git.openjdk.java.net/jfx/pull/478.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/478/head:pull/478 PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Tue May 11 01:50:17 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 11 May 2021 01:50:17 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v5] In-Reply-To: References: Message-ID: > The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. > > `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into fixes/JDK-8196065 # Conflicts: # modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java - Cleanup - Fixed clear-and-select change notification - Add failing tests - Cleanup - Added tests - Fix incorrect index when multiple remove changes are handled in SelectedItemsReadOnlyObservableList - Add failing test ------------- Changes: https://git.openjdk.java.net/jfx/pull/478/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=04 Stats: 353 lines in 8 files changed: 329 ins; 2 del; 22 mod Patch: https://git.openjdk.java.net/jfx/pull/478.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/478/head:pull/478 PR: https://git.openjdk.java.net/jfx/pull/478 From jgneff at openjdk.java.net Tue May 11 01:52:58 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 11 May 2021 01:52:58 GMT Subject: RFR: JDK-8266396: Allow VSCMD_DEBUG to work as intended [v3] In-Reply-To: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Skip sending telemetry to fix "file in use" error With today's fix, the table in my prior comment is the same. In the "Before" column, the messages are printed with the normal Gradle output. In the "After" column, they're found in the new `vcvarsall.log` file. The table is included again below, showing the number of lines logged: | VSCMD_DEBUG | Level | Before | After | |:-----------:|:---------|-------:|------:| | undefined | none | 0 | 10 | | 1 | basic | 0 | 93 | | 2 | detailed | 0 | 615 | | 3 | trace | 2 | 5,832 | No more "black box" Windows batch files. ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From mstrauss at openjdk.java.net Tue May 11 02:14:01 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 11 May 2021 02:14:01 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v5] In-Reply-To: References: Message-ID: On Tue, 11 May 2021 01:50:17 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into fixes/JDK-8196065 > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java > - Cleanup > - Fixed clear-and-select change notification > - Add failing tests > - Cleanup > - Added tests > - Fix incorrect index when multiple remove changes are handled in SelectedItemsReadOnlyObservableList > - Add failing test I fixed another issue with `ControlUtils.buildClearAndSelectChange`, which led to incorrect change notifications for selected indices. This PR now fixes 1. [8196065](https://bugs.openjdk.java.net/browse/JDK-8196065) ListChangeListener getRemoved() returns items that were not removed. 2. [8255935](https://bugs.openjdk.java.net/browse/JDK-8255935) MultipleSelectionModel provides incorrect 'removed' sub-list in change events 3. The additional scenarios mentioned by @arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From fastegal at swingempire.de Tue May 11 09:28:55 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 11 May 2021 11:28:55 +0200 Subject: Build error with gradle (command line) Message-ID: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> Just sync'ed my local repository with upstream .. now can't build with gradle, the error: * Where: Build file 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' line: 4249 * What went wrong: A problem occurred evaluating root project 'jfx-fork'. > Dependency verification failed for configuration ':apps:lucene' 8 artifacts failed verification: - apache-13.pom (org.apache:apache:13) from repository MavenRepo - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) from repository MavenRepo - lucene-grouping-7.7.3.pom (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo - lucene-parent-7.7.3.pom (org.apache.lucene:lucene-parent:7.7.3) from repository MavenRepo - lucene-queries-7.7.3.pom (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo - lucene-queryparser-7.7.3.pom (org.apache.lucene:lucene-queryparser:7.7.3) from repository MavenRepo - lucene-sandbox-7.7.3.pom (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo - lucene-solr-grandparent-7.7.3.pom (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository MavenRepo This can indicate that a dependency has been compromised. Please carefully verify the checksums. Looks like I have to update some local files, shouldn't that happen automagically? -- Jeanette From ajit.ghaisas at oracle.com Tue May 11 09:46:12 2021 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 11 May 2021 15:16:12 +0530 Subject: Build error with gradle (command line) In-Reply-To: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> Message-ID: Hi Jeanette, I had faced this on my local system last week. Although the root cause is unknown - "gradle --refresh-dependencies? command had helped to get rid of this error. I did not pursue it as this error is not seen in our CI builds. Regards, Ajit > On 11-May-2021, at 2:58 PM, Jeanette Winzenburg wrote: > > > Just sync'ed my local repository with upstream .. now can't build with gradle, the error: > > * Where: > Build file 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' line: 4249 > > * What went wrong: > A problem occurred evaluating root project 'jfx-fork'. >> Dependency verification failed for configuration ':apps:lucene' > 8 artifacts failed verification: > - apache-13.pom (org.apache:apache:13) from repository MavenRepo > - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) from repository MavenRepo > - lucene-grouping-7.7.3.pom (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo > - lucene-parent-7.7.3.pom (org.apache.lucene:lucene-parent:7.7.3) from repository MavenRepo > - lucene-queries-7.7.3.pom (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo > - lucene-queryparser-7.7.3.pom (org.apache.lucene:lucene-queryparser:7.7.3) from repository MavenRepo > - lucene-sandbox-7.7.3.pom (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo > - lucene-solr-grandparent-7.7.3.pom (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository MavenRepo > This can indicate that a dependency has been compromised. Please carefully verify the checksums. > > Looks like I have to update some local files, shouldn't that happen automagically? > > -- Jeanette > > From fastegal at swingempire.de Tue May 11 10:43:53 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 11 May 2021 12:43:53 +0200 Subject: Build error with gradle (command line) In-Reply-To: References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> Message-ID: <20210511124353.Horde.Dik7tUKfsYEvNQQuLBHRZw8@webmail.df.eu> Thanks Johan, Ajit --refresh-dependencies did it .. nearly ;) now the error is down to: * What went wrong: Execution failed for task ':base:compileTestJava'. Dependency verification failed for configuration ':base:testCompileClasspath' One artifact failed verification: junit-4.8.2.pom (junit:junit:4.8.2) from repository MavenRepo This can indicate that a dependency has been compromised. Please carefully verify the checksums. .. will cleanup the gradle cache and see what happens (all these complete builds take some time, my machine is not the fastest, to put it mildly) Zitat von Ajit Ghaisas : > Hi Jeanette, > > I had faced this on my local system last week. > Although the root cause is unknown - "gradle > --refresh-dependencies? command had helped to get rid of this error. > > I did not pursue it as this error is not seen in our CI builds. > > Regards, > Ajit > >> On 11-May-2021, at 2:58 PM, Jeanette Winzenburg >> wrote: >> >> >> Just sync'ed my local repository with upstream .. now can't build >> with gradle, the error: >> >> * Where: >> Build file >> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' line: >> 4249 >> >> * What went wrong: >> A problem occurred evaluating root project 'jfx-fork'. >>> Dependency verification failed for configuration ':apps:lucene' >> 8 artifacts failed verification: >> - apache-13.pom (org.apache:apache:13) from repository MavenRepo >> - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) >> from repository MavenRepo >> - lucene-grouping-7.7.3.pom >> (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo >> - lucene-parent-7.7.3.pom >> (org.apache.lucene:lucene-parent:7.7.3) from repository MavenRepo >> - lucene-queries-7.7.3.pom >> (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo >> - lucene-queryparser-7.7.3.pom >> (org.apache.lucene:lucene-queryparser:7.7.3) from repository >> MavenRepo >> - lucene-sandbox-7.7.3.pom >> (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo >> - lucene-solr-grandparent-7.7.3.pom >> (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository >> MavenRepo >> This can indicate that a dependency has been compromised. Please >> carefully verify the checksums. >> >> Looks like I have to update some local files, shouldn't that happen >> automagically? >> >> -- Jeanette >> >> From kevin.rushforth at oracle.com Tue May 11 11:36:28 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 May 2021 04:36:28 -0700 Subject: Build error with gradle (command line) In-Reply-To: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> Message-ID: <1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com> We've had a couple other reports about this. The solutions that you can try (should only be needed one time) are: 1. gradle --refresh-dependencies ... 2. Remove the gradle cache before building: ? ? cd $USERPROFILE/.gradle ??? rm -rf caches native ??? gradle ... If this doesn't work, I will propose that we disable checking of the pom files in verification.xml. -- Kevin On 5/11/2021 2:28 AM, Jeanette Winzenburg wrote: > > Just sync'ed my local repository with upstream .. now can't build with > gradle, the error: > > * Where: > Build file > 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > line: 4249 > > * What went wrong: > A problem occurred evaluating root project 'jfx-fork'. >> Dependency verification failed for configuration ':apps:lucene' > ? 8 artifacts failed verification: > ??? - apache-13.pom (org.apache:apache:13) from repository MavenRepo > ??? - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) from > repository MavenRepo > ??? - lucene-grouping-7.7.3.pom > (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo > ??? - lucene-parent-7.7.3.pom (org.apache.lucene:lucene-parent:7.7.3) > from repository MavenRepo > ??? - lucene-queries-7.7.3.pom > (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo > ??? - lucene-queryparser-7.7.3.pom > (org.apache.lucene:lucene-queryparser:7.7.3) from repository MavenRepo > ??? - lucene-sandbox-7.7.3.pom > (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo > ??? - lucene-solr-grandparent-7.7.3.pom > (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository > MavenRepo > ? This can indicate that a dependency has been compromised. Please > carefully verify the checksums. > > Looks like I have to update some local files, shouldn't that happen > automagically? > > -- Jeanette > > From kevin.rushforth at oracle.com Tue May 11 11:41:05 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 May 2021 04:41:05 -0700 Subject: Build error with gradle (command line) In-Reply-To: <1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com> References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> <1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com> Message-ID: <0747f5a6-07e7-f25e-696a-c2d71bcccdc0@oracle.com> I see that Ajit answered already with option #1 and that you are going to try option #2. We might want to document this on the "Building JavaFX" Wiki page. To expand on this a bit, what I think must have happened is that the contents of the pom files changed some time in the not-too-distant-past so that the current checksums don't match those previously cached pom files. -- Kevin On 5/11/2021 4:36 AM, Kevin Rushforth wrote: > We've had a couple other reports about this. The solutions that you > can try (should only be needed one time) are: > > 1. gradle --refresh-dependencies ... > > 2. Remove the gradle cache before building: > ? ? cd $USERPROFILE/.gradle > ??? rm -rf caches native > ??? gradle ... > > If this doesn't work, I will propose that we disable checking of the > pom files in verification.xml. > > -- Kevin > > > On 5/11/2021 2:28 AM, Jeanette Winzenburg wrote: >> >> Just sync'ed my local repository with upstream .. now can't build >> with gradle, the error: >> >> * Where: >> Build file >> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' >> line: 4249 >> >> * What went wrong: >> A problem occurred evaluating root project 'jfx-fork'. >>> Dependency verification failed for configuration ':apps:lucene' >> ? 8 artifacts failed verification: >> ??? - apache-13.pom (org.apache:apache:13) from repository MavenRepo >> ??? - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) >> from repository MavenRepo >> ??? - lucene-grouping-7.7.3.pom >> (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo >> ??? - lucene-parent-7.7.3.pom (org.apache.lucene:lucene-parent:7.7.3) >> from repository MavenRepo >> ??? - lucene-queries-7.7.3.pom >> (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo >> ??? - lucene-queryparser-7.7.3.pom >> (org.apache.lucene:lucene-queryparser:7.7.3) from repository MavenRepo >> ??? - lucene-sandbox-7.7.3.pom >> (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo >> ??? - lucene-solr-grandparent-7.7.3.pom >> (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository >> MavenRepo >> ? This can indicate that a dependency has been compromised. Please >> carefully verify the checksums. >> >> Looks like I have to update some local files, shouldn't that happen >> automagically? >> >> -- Jeanette >> >> > From ebresie at gmail.com Tue May 11 11:58:06 2021 From: ebresie at gmail.com (Eric Bresie) Date: Tue, 11 May 2021 06:58:06 -0500 Subject: Build error with gradle (command line) In-Reply-To: 0747f5a6-07e7-f25e-696a-c2d71bcccdc0@oracle.com References: 20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu 1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com 1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com Message-ID: Assume it has to do with some of this.. https://docs.gradle.org/current/userguide/dependency_verification.html Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On May 11, 2021 at 6:41:05 AM CDT, Kevin Rushforth wrote: > I see that Ajit answered already with option #1 and that you are going > to try option #2. We might want to document this on the "Building > JavaFX" Wiki page. > > To expand on this a bit, what I think must have happened is that the > contents of the pom files changed some time in the not-too-distant-past > so that the current checksums don't match those previously cached pom files. > > -- Kevin > > > On 5/11/2021 4:36 AM, Kevin Rushforth wrote: > > We've had a couple other reports about this. The solutions that you > > can try (should only be needed one time) are: > > > > 1. gradle --refresh-dependencies ... > > > > 2. Remove the gradle cache before building: > > cd $USERPROFILE/.gradle > > rm -rf caches native > > gradle ... > > > > If this doesn't work, I will propose that we disable checking of the > > pom files in verification.xml. > > > > -- Kevin > > > > > > On 5/11/2021 2:28 AM, Jeanette Winzenburg wrote: > > > > > > Just sync'ed my local repository with upstream .. now can't build > > > with gradle, the error: > > > > > > * Where: > > > Build file > > > 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > > > line: 4249 > > > > > > * What went wrong: > > > A problem occurred evaluating root project 'jfx-fork'. > > > > Dependency verification failed for configuration ':apps:lucene' > > > 8 artifacts failed verification: > > > - apache-13.pom (org.apache:apache:13) from repository MavenRepo > > > - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) > > > from repository MavenRepo > > > - lucene-grouping-7.7.3.pom > > > (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo > > > - lucene-parent-7.7.3.pom (org.apache.lucene:lucene-parent:7.7.3) > > > from repository MavenRepo > > > - lucene-queries-7.7.3.pom > > > (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo > > > - lucene-queryparser-7.7.3.pom > > > (org.apache.lucene:lucene-queryparser:7.7.3) from repository MavenRepo > > > - lucene-sandbox-7.7.3.pom > > > (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo > > > - lucene-solr-grandparent-7.7.3.pom > > > (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository > > > MavenRepo > > > This can indicate that a dependency has been compromised. Please > > > carefully verify the checksums. > > > > > > Looks like I have to update some local files, shouldn't that happen > > > automagically? > > > > > > -- Jeanette > > > > > > > > > From johan.vos at gluonhq.com Tue May 11 12:00:42 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 11 May 2021 14:00:42 +0200 Subject: Build error with gradle (command line) In-Reply-To: <0747f5a6-07e7-f25e-696a-c2d71bcccdc0@oracle.com> References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> <1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com> <0747f5a6-07e7-f25e-696a-c2d71bcccdc0@oracle.com> Message-ID: On Tue, May 11, 2021 at 1:41 PM Kevin Rushforth wrote: > I see that Ajit answered already with option #1 and that you are going > to try option #2. We might want to document this on the "Building > JavaFX" Wiki page. > > To expand on this a bit, what I think must have happened is that the > contents of the pom files changed some time in the not-too-distant-past > so that the current checksums don't match those previously cached pom > files. > In my case, it seemed to be that the pom file was stored in a different location than the expected one. There must be a difference between "jars-X, modules-Y, artifacts-Z" but I fail to understand it (and I would assume we don't have to know it). - Johan From johan.vos at gluonhq.com Tue May 11 12:03:20 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 11 May 2021 14:03:20 +0200 Subject: Build error with gradle (command line) In-Reply-To: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> Message-ID: (I did a reply instead of a reply-all) Hi, I had that on one of my Linux systems too, after the fix for JDK-8264010. My first system went fine after I ran with ./gradlew --refresh-dependencies and I understood this worked for others as well. On the second system, that didn't work and I ended up removing the whole gradle cache (rm -rf ~/.gradle) (which my HD liked very much). I believe there has been some changes related to where gradle stores downloaded poms, as the lucene-core pom was stored in a different directory than the jar, while gradle searched only in the directory that contains the jar or so. This is pure unscientific speculation from my side, but with a fresh Gradle install, it worked fine. My initial enthusiasm for gradle is mainly gone because of the maintenance cost (i.e. upgrade gradle for every single major update of Java) but at least, in most cases there are (annoying) workarounds. On Tue, May 11, 2021 at 11:29 AM Jeanette Winzenburg < fastegal at swingempire.de> wrote: > > Just sync'ed my local repository with upstream .. now can't build with > gradle, the error: > > * Where: > Build file > 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > line: 4249 > > * What went wrong: > A problem occurred evaluating root project 'jfx-fork'. > > Dependency verification failed for configuration ':apps:lucene' > 8 artifacts failed verification: > - apache-13.pom (org.apache:apache:13) from repository MavenRepo > - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) > from repository MavenRepo > - lucene-grouping-7.7.3.pom > (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo > - lucene-parent-7.7.3.pom (org.apache.lucene:lucene-parent:7.7.3) > from repository MavenRepo > - lucene-queries-7.7.3.pom > (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo > - lucene-queryparser-7.7.3.pom > (org.apache.lucene:lucene-queryparser:7.7.3) from repository MavenRepo > - lucene-sandbox-7.7.3.pom > (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo > - lucene-solr-grandparent-7.7.3.pom > (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository > MavenRepo > This can indicate that a dependency has been compromised. Please > carefully verify the checksums. > > Looks like I have to update some local files, shouldn't that happen > automagically? > > -- Jeanette > > > From fastegal at swingempire.de Tue May 11 12:24:22 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 11 May 2021 14:24:22 +0200 Subject: Build error with gradle (command line) In-Reply-To: <1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com> References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> <1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com> Message-ID: <20210511142422.Horde.Sj4XXtEQLb908t-I3j_JtQ3@webmail.df.eu> deleting the caches did work, at last ;) To summarize: ./gradlew --refresh-dependencies got rid of the initial error (problems with dependencies around lucene libs), but then barked about junit cd MyProfile/.gradle rm -rf caches native made it work gain (hopefully permanent ;) Thanks everybody for the quick help, -- Jeanette Zitat von Kevin Rushforth : > We've had a couple other reports about this. The solutions that you > can try (should only be needed one time) are: > > 1. gradle --refresh-dependencies ... > > 2. Remove the gradle cache before building: > ? ? cd $USERPROFILE/.gradle > ??? rm -rf caches native > ??? gradle ... > > If this doesn't work, I will propose that we disable checking of the > pom files in verification.xml. > > -- Kevin > > > On 5/11/2021 2:28 AM, Jeanette Winzenburg wrote: >> >> Just sync'ed my local repository with upstream .. now can't build >> with gradle, the error: >> >> * Where: >> Build file >> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' line: >> 4249 >> >> * What went wrong: >> A problem occurred evaluating root project 'jfx-fork'. >>> Dependency verification failed for configuration ':apps:lucene' >> ? 8 artifacts failed verification: >> ??? - apache-13.pom (org.apache:apache:13) from repository MavenRepo >> ??? - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) >> from repository MavenRepo >> ??? - lucene-grouping-7.7.3.pom >> (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo >> ??? - lucene-parent-7.7.3.pom >> (org.apache.lucene:lucene-parent:7.7.3) from repository MavenRepo >> ??? - lucene-queries-7.7.3.pom >> (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo >> ??? - lucene-queryparser-7.7.3.pom >> (org.apache.lucene:lucene-queryparser:7.7.3) from repository >> MavenRepo >> ??? - lucene-sandbox-7.7.3.pom >> (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo >> ??? - lucene-solr-grandparent-7.7.3.pom >> (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository >> MavenRepo >> ? This can indicate that a dependency has been compromised. Please >> carefully verify the checksums. >> >> Looks like I have to update some local files, shouldn't that happen >> automagically? >> >> -- Jeanette >> >> From sykora at openjdk.java.net Tue May 11 14:35:17 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Tue, 11 May 2021 14:35:17 GMT Subject: RFR: 8266919: Gradle verification fails on windows x86 Message-ID: This pull request fixes gradle verification failures when building JavaFX with a Windows 32-bit JDK. ------------- Commit messages: - fix gradle verification for windows x86 Changes: https://git.openjdk.java.net/jfx/pull/494/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=494&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266919 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/494.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/494/head:pull/494 PR: https://git.openjdk.java.net/jfx/pull/494 From kcr at openjdk.java.net Tue May 11 14:43:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 11 May 2021 14:43:03 GMT Subject: RFR: 8266919: Gradle verification fails on windows x86 In-Reply-To: References: Message-ID: On Tue, 11 May 2021 14:30:08 GMT, Joeri Sykora wrote: > This pull request fixes gradle verification failures when building JavaFX with a Windows 32-bit JDK. Marked as reviewed by kcr (Lead). That's up to you. If you think it would help, go ahead. ------------- PR: https://git.openjdk.java.net/jfx/pull/494 From sykora at openjdk.java.net Tue May 11 14:43:03 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Tue, 11 May 2021 14:43:03 GMT Subject: RFR: 8266919: Gradle verification fails on windows x86 In-Reply-To: References: Message-ID: On Tue, 11 May 2021 14:30:08 GMT, Joeri Sykora wrote: > This pull request fixes gradle verification failures when building JavaFX with a Windows 32-bit JDK. I was wondering if the [README](https://github.com/openjdk/jfx/blob/master/gradle/README.txt) should be updated to include windows 32-bit in the steps to rebuild the verification XML file. ------------- PR: https://git.openjdk.java.net/jfx/pull/494 From john at status6.com Tue May 11 15:04:16 2021 From: john at status6.com (John Neffenger) Date: Tue, 11 May 2021 08:04:16 -0700 Subject: Build error with gradle (command line) In-Reply-To: <20210511142422.Horde.Sj4XXtEQLb908t-I3j_JtQ3@webmail.df.eu> References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> <1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com> <20210511142422.Horde.Sj4XXtEQLb908t-I3j_JtQ3@webmail.df.eu> Message-ID: On 5/11/21 5:24 AM, Jeanette Winzenburg wrote: > deleting the caches did work, at last ;) That's also what I had to do after similar errors. I thought there might be some bumps in the road when I proposed adding the Gradle dependency verification, but I hope we can retain enough of it to make the builds safer than before. If we notice that the the POM files are changing (without updating their versions), Kevin's idea of removing the POM entries should help. Even the Gradle documentation anticipates some problems, saying "It means that you will be tempted to switch it off." [1] The more I learn Gradle, the less likely I am to choose it for my own projects, but it is far ahead of Maven, for example, in protecting against supply-chain attacks. For Maven, this feature is still just a couple of old bug reports: Extend the Project Object Model (POM) with trust information (OpenPGP, hash values) https://issues.apache.org/jira/browse/MNG-6026 Switch the default checksum policy from "warn" to "fail" https://issues.apache.org/jira/browse/MNG-5728 John [1] https://docs.gradle.org/current/userguide/dependency_verification.html From sykora at openjdk.java.net Tue May 11 15:23:00 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Tue, 11 May 2021 15:23:00 GMT Subject: Integrated: 8266919: Gradle verification fails on windows x86 In-Reply-To: References: Message-ID: On Tue, 11 May 2021 14:30:08 GMT, Joeri Sykora wrote: > This pull request fixes gradle verification failures when building JavaFX with a Windows 32-bit JDK. This pull request has now been integrated. Changeset: 3ac6bf0c Author: Joeri Sykora Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/3ac6bf0cb48549f1383e55820104b88880a126be Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8266919: Gradle verification fails on windows x86 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/494 From arapte at openjdk.java.net Tue May 11 17:00:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 11 May 2021 17:00:08 GMT Subject: RFR: 8266757: Add entry for jdk-12_doc-all.zip to gradle/verification-metadata.xml In-Reply-To: References: Message-ID: <7L87wwQDFGdQCz2OayY3iW8saIqtO4_ROJ_jeuWQt6w=.6651af0a-93cc-45f8-805b-2e2ce348d96d@github.com> On Fri, 7 May 2021 17:30:37 GMT, Kevin Rushforth wrote: > As indicated in JBS this PR adds a missing entry for the JDK 12 API docs zip bundle for javadoc offline processing. This missing entry is causing a build failure on my system (which will soon propagate to our CI builds). Looks good to me, verified with a local build on mac machine. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/489 From johan.vos at gluonhq.com Tue May 11 17:27:36 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 11 May 2021 19:27:36 +0200 Subject: Build error with gradle (command line) In-Reply-To: References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> <1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com> <20210511142422.Horde.Sj4XXtEQLb908t-I3j_JtQ3@webmail.df.eu> Message-ID: Hi John, Regardless of the issues some of us have now, I believe the verification is a good thing to add, so thank you for that enhancement. Security often comes with a price, and if removing caches is all that it takes, I'm happy. Unrelated to that, I'm worried about the maintenance cost of Gradle, and the fact that some features are deprecated while their replacements are still incubating is not increasing my confidence. In the Java world, we're used to maturity and long-term support and I don't feel 100% confident Gradle provides this (which doesn't mean it isn't a great tool, but maybe not so for projects like this). But balancing pro's and con's (migration effort), I'm still +1 to keep Gradle for OpenJFX. - Johan On Tue, May 11, 2021 at 5:05 PM John Neffenger wrote: > On 5/11/21 5:24 AM, Jeanette Winzenburg wrote: > > deleting the caches did work, at last ;) > > That's also what I had to do after similar errors. I thought there might > be some bumps in the road when I proposed adding the Gradle dependency > verification, but I hope we can retain enough of it to make the builds > safer than before. > > If we notice that the the POM files are changing (without updating their > versions), Kevin's idea of removing the POM entries should help. Even > the Gradle documentation anticipates some problems, saying "It means > that you will be tempted to switch it off." [1] > > The more I learn Gradle, the less likely I am to choose it for my own > projects, but it is far ahead of Maven, for example, in protecting > against supply-chain attacks. For Maven, this feature is still just a > couple of old bug reports: > > Extend the Project Object Model (POM) with trust information (OpenPGP, > hash values) > https://issues.apache.org/jira/browse/MNG-6026 > > Switch the default checksum policy from "warn" to "fail" > https://issues.apache.org/jira/browse/MNG-5728 > > John > > [1] https://docs.gradle.org/current/userguide/dependency_verification.html > From pbansal at openjdk.java.net Tue May 11 18:53:02 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 11 May 2021 18:53:02 GMT Subject: RFR: 8266757: Add entry for jdk-12_doc-all.zip to gradle/verification-metadata.xml In-Reply-To: References: Message-ID: On Fri, 7 May 2021 17:30:37 GMT, Kevin Rushforth wrote: > As indicated in JBS this PR adds a missing entry for the JDK 12 API docs zip bundle for javadoc offline processing. This missing entry is causing a build failure on my system (which will soon propagate to our CI builds). Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/489 From kcr at openjdk.java.net Tue May 11 20:07:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 11 May 2021 20:07:13 GMT Subject: Integrated: 8266757: Add entry for jdk-12_doc-all.zip to gradle/verification-metadata.xml In-Reply-To: References: Message-ID: On Fri, 7 May 2021 17:30:37 GMT, Kevin Rushforth wrote: > As indicated in JBS this PR adds a missing entry for the JDK 12 API docs zip bundle for javadoc offline processing. This missing entry is causing a build failure on my system (which will soon propagate to our CI builds). This pull request has now been integrated. Changeset: c7833f12 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/c7833f1205e3a97b49abb945d0a2eeff9b9c34bc Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8266757: Add entry for jdk-12_doc-all.zip to gradle/verification-metadata.xml Reviewed-by: arapte, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/489 From john at status6.com Tue May 11 20:13:36 2021 From: john at status6.com (John Neffenger) Date: Tue, 11 May 2021 13:13:36 -0700 Subject: Build error with gradle (command line) In-Reply-To: References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> <1c3a81d6-15c2-32be-58fd-1e94b17525f9@oracle.com> <20210511142422.Horde.Sj4XXtEQLb908t-I3j_JtQ3@webmail.df.eu> Message-ID: On 5/11/21 10:27 AM, Johan Vos wrote: > I'm still +1 to keep Gradle for OpenJFX. The OpenJFX build is shockingly complicated. It's not just a Gradle build. It's a Gradle, Groovy Custom Task, Apache Maven, Apache Ant, GNU Make, CMake, Ninja, ANTLR, JUnit, GNU GCC, XCode, Visual Studio, MSBuild, and Windows Batch File build. I think the only missing is Bazel. ?? John From fastegal at openjdk.java.net Tue May 11 20:45:14 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 11 May 2021 20:45:14 GMT Subject: RFR: 8266811: Openjfx controls test build broken (Eclipse) Message-ID: was introduced with fix [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) which uses MockListObserver in tests. Fix is analogous to previous eclipse build problems (f.i. [JDK-8265513](https://bugs.openjdk.java.net/browse/JDK-8265513)): add-exports to allow access to base' test package. ------------- Commit messages: - 8266811: Openjfx controls test build broken (Eclipse) Changes: https://git.openjdk.java.net/jfx/pull/493/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=493&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266811 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/493.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/493/head:pull/493 PR: https://git.openjdk.java.net/jfx/pull/493 From almatvee at openjdk.java.net Tue May 11 23:49:40 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 11 May 2021 23:49:40 GMT Subject: RFR: 8266860: [macos] Incorrect duration reported for HLS live streams Message-ID: <6EmIy98NOjbtbDBCS1BpvgF_6WkwFMs8ZyqZ6TFxtS4=.348dc137-27f2-4f66-8d60-fdd891269528@github.com> For indefinite durations CMTimeGetSeconds was returning NaN (not-a-number double value) and our code expects -1.0. Based on doc we should be using CMTIME_IS_INDEFINITE to test if duration is indefinite. Fixed by using CMTIME_IS_INDEFINITE to test if duration is indefinite and if true -1.0 will be return to our Java layer. ------------- Commit messages: - 8266860: [macos] Incorrect duration reported for HLS live streams Changes: https://git.openjdk.java.net/jfx/pull/495/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=495&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266860 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/495.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/495/head:pull/495 PR: https://git.openjdk.java.net/jfx/pull/495 From fkirmaier at openjdk.java.net Wed May 12 08:13:32 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 12 May 2021 08:13:32 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v12] In-Reply-To: References: Message-ID: <9PlAK2Hcn8Fcz4vei-lhslHK9l68bCDO23979BgCDzE=.1c7fcd48-6ff5-4e13-b26d-7f9b721d41dd@github.com> > Fixing ListCell editing status is true, when index changes while editing. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8264127: we now use a try finally statement, to make sure updateEditingIndex is reset! ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/441/files - new: https://git.openjdk.java.net/jfx/pull/441/files/461ffb85..f4af1d26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=10-11 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/441/head:pull/441 PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Wed May 12 08:13:34 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 12 May 2021 08:13:34 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v11] In-Reply-To: References: Message-ID: <6T6E9oSpT2dh-QQ59dmzOtPRlMZdWNwT8eVuluahZFQ=.b8e4d9bd-be86-4a9f-b427-c0a48146d400@github.com> On Tue, 27 Apr 2021 11:52:58 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > removed accidentally commited print statements. I've now added the try-finally statement to reset the updateEditingIndex, just like in the other PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fastegal at openjdk.java.net Wed May 12 10:39:06 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 12 May 2021 10:39:06 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v12] In-Reply-To: <9PlAK2Hcn8Fcz4vei-lhslHK9l68bCDO23979BgCDzE=.1c7fcd48-6ff5-4e13-b26d-7f9b721d41dd@github.com> References: <9PlAK2Hcn8Fcz4vei-lhslHK9l68bCDO23979BgCDzE=.1c7fcd48-6ff5-4e13-b26d-7f9b721d41dd@github.com> Message-ID: On Wed, 12 May 2021 08:13:32 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > we now use a try finally statement, to make sure updateEditingIndex is reset! coming nearer :) see my inline comments modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 546: > 544: > 545: if (editing && (index == -1 || list == null || index != editIndex)) { > 546: // If my index is not the one being edited then I need to cancel probably just me not being able to see at a glance if the overall logic in the method is the exact same as before the fix (modulo the fix itself :), but: I would prefer an extra method used in both early return for the -1/null-list and the old else-if. If the second reviewer sees the equivalence at a glance, I'll believe his eyes :) ------------- Changes requested by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/441 From fastegal at openjdk.java.net Wed May 12 10:39:07 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 12 May 2021 10:39:07 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v8] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 09:26:05 GMT, Florian Kirmaier wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellTest.java line 921: >> >>> 919: assertFalse("cell must not be editing if cell index is " + cell.getIndex(), cell.isEditing()); >>> 920: assertEquals(1, events.size()); >>> 921: } >> >> still missing: assert that list editingIndex is unchanged (see the assertTo test). Without that assert, you don't see any difference in the test between your previous and this commit (which was surrounding the call to cancelEdit with setting the updateEditingIndex flags), do you ;) >> >> A personal note: tests are our friends, red-green (repeatedly) the color **sequence** that brings satisfaction :) Just changing a code snippet without making certain to have a failing test before (and passes after) a change is .. well .. suboptimal. > > Yes, i can confirm that it's required to find the issue with the updateEditingIndex. I've added more tests and in general its now more symmetric to the other test! missing test for the try/finally ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From ajoseph at openjdk.java.net Wed May 12 13:34:38 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 12 May 2021 13:34:38 GMT Subject: RFR: 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest Message-ID: The system test test.com.sun.webkit.LocalStorageAccessTest fails on Windows as mentioned in [JDK-8265661](https://bugs.openjdk.java.net/browse/JDK-8265661). We should skip this test until it is fixed. ------------- Commit messages: - 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest Changes: https://git.openjdk.java.net/jfx/pull/497/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=497&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266968 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/497.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/497/head:pull/497 PR: https://git.openjdk.java.net/jfx/pull/497 From aghaisas at openjdk.java.net Wed May 12 15:20:28 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 12 May 2021 15:20:28 GMT Subject: RFR: 8264138: Replace uses of Class.newInstance [v2] In-Reply-To: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> References: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> Message-ID: > This PR replaces Class.newInstance() deprecated method with Contructor.newinstance(). Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: fix apps and unit tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/491/files - new: https://git.openjdk.java.net/jfx/pull/491/files/82503d14..d47ce2d5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=491&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=491&range=00-01 Stats: 42 lines in 17 files changed: 2 ins; 8 del; 32 mod Patch: https://git.openjdk.java.net/jfx/pull/491.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/491/head:pull/491 PR: https://git.openjdk.java.net/jfx/pull/491 From aghaisas at openjdk.java.net Wed May 12 15:20:28 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 12 May 2021 15:20:28 GMT Subject: RFR: 8264138: Replace uses of Class.newInstance In-Reply-To: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> References: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> Message-ID: On Mon, 10 May 2021 12:09:09 GMT, Ajit Ghaisas wrote: > This PR replaces Class.newInstance() deprecated method with Contructor.newinstance(). Found and replaced deprecated Class.newInstance() instances in apps and unit tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/491 From kcr at openjdk.java.net Wed May 12 18:37:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 May 2021 18:37:25 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 Message-ID: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. ### Notes to Reviewers: The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` 3. Added missing `@Input` annotation to custom Groovy task properties 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` 2. Updated the gradle version in `build.properties` to `7.0.1` 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` ------------- Commit messages: - Revert auto-generated change to DEFAULT_JVM_OPTS in gradlew scripts - 8263760: Update gradle to version 7.0.1 - 8240336: JavaFX build uses deprecated features that will be removed in gradle 7 Changes: https://git.openjdk.java.net/jfx/pull/498/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=498&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263760 Stats: 145 lines in 13 files changed: 45 ins; 5 del; 95 mod Patch: https://git.openjdk.java.net/jfx/pull/498.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/498/head:pull/498 PR: https://git.openjdk.java.net/jfx/pull/498 From github.com+1445818+crazyjavahacking at openjdk.java.net Wed May 12 18:37:25 2021 From: github.com+1445818+crazyjavahacking at openjdk.java.net (Crazyjavahacking) Date: Wed, 12 May 2021 18:37:25 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 In-Reply-To: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Wed, 12 May 2021 14:54:09 GMT, Kevin Rushforth wrote: > This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. > > In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. > > I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. > > ### Notes to Reviewers: > > The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. > > The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: > > 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed > 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` > 3. Added missing `@Input` annotation to custom Groovy task properties > 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) > > > The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: > > 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` > 2. Updated the gradle version in `build.properties` to `7.0.1` > 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` buildSrc/src/main/groovy/com/sun/javafx/gradle/CCTask.groovy line 34: > 32: @Optional @Input List linkerOptions = new ArrayList(); > 33: @Optional @InputDirectory File headers; > 34: @Optional @Input Closure eachOutputFile; // will be given a File and must return a File Is this field actually used anywhere? As this field is not initialized + there is the `@Optional` annotation, Gradle will not verify this is fine. Gradle docs is specifying that: 1. `@Input` can be used on Closure if it is a provider of `File` (which means no param in closure). 2. `@Input` can be used for any `Serializable` which `Closure` actually is. It's not obvious if Gradle will correctly handle `Closure` taking argument. buildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy line 44: > 42: @Optional @Input String matches; // regex for matching input files > 43: @Input List params = new ArrayList(); > 44: @Input List sourceRoots = new ArrayList(); Shouldn't this be `@Internal`?: 1. `updateFiles()` uses `sourceRoots` and maps that into the `allFiles` field, which has already `@InputFiles`. If the `sourceRoots` is changed in a way that does not affect `allFiles`, this task can remain `UP_TO_DATE` and save task execution. gradlew line 47: > 45: > 46: # Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script. > 47: DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"' This is automatically generated by Gradle, but the heap memory seems to be too low. + the same for `gradlew.bat` ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From kcr at openjdk.java.net Wed May 12 18:37:26 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 May 2021 18:37:26 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 In-Reply-To: References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Wed, 12 May 2021 17:02:27 GMT, Crazyjavahacking wrote: >> This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. >> >> In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. >> >> I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. >> >> ### Notes to Reviewers: >> >> The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. >> >> The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: >> >> 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed >> 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` >> 3. Added missing `@Input` annotation to custom Groovy task properties >> 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) >> >> >> The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: >> >> 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` >> 2. Updated the gradle version in `build.properties` to `7.0.1` >> 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` > > gradlew line 47: > >> 45: >> 46: # Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script. >> 47: DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"' > > This is automatically generated by Gradle, but the heap memory seems to be too low. > > + the same for `gradlew.bat` I agree with this concern, and will revert this auto-generated change. I don't know why the gradle team felt that a 64Mbyte heap was sufficient. ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From kcr at openjdk.java.net Wed May 12 18:47:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 May 2021 18:47:57 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 In-Reply-To: References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Wed, 12 May 2021 17:30:20 GMT, Crazyjavahacking wrote: >> This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. >> >> In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. >> >> I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. >> >> ### Notes to Reviewers: >> >> The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. >> >> The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: >> >> 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed >> 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` >> 3. Added missing `@Input` annotation to custom Groovy task properties >> 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) >> >> >> The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: >> >> 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` >> 2. Updated the gradle version in `build.properties` to `7.0.1` >> 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` > > buildSrc/src/main/groovy/com/sun/javafx/gradle/CCTask.groovy line 34: > >> 32: @Optional @Input List linkerOptions = new ArrayList(); >> 33: @Optional @InputDirectory File headers; >> 34: @Optional @Input Closure eachOutputFile; // will be given a File and must return a File > > Is this field actually used anywhere? > > As this field is not initialized + there is the `@Optional` annotation, Gradle will not verify this is fine. Gradle docs is specifying that: > 1. `@Input` can be used on Closure if it is a provider of `File` (which means no param in closure). > 2. `@Input` can be used for any `Serializable` which `Closure` actually is. > > It's not obvious if Gradle will correctly handle `Closure` taking argument. I'll take a look, but I will likely want to do any cleanup of this in a follow-on issue. As you note the `eachOutputFile` property is unused...as is the `exe` property. They were formerly used by one of the `javapackager` tasks, which has since been removed. > buildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy line 44: > >> 42: @Optional @Input String matches; // regex for matching input files >> 43: @Input List params = new ArrayList(); >> 44: @Input List sourceRoots = new ArrayList(); > > Shouldn't this be `@Internal`?: > > 1. `updateFiles()` uses `sourceRoots` and maps that into the `allFiles` field, which has already `@InputFiles`. If the `sourceRoots` is changed in a way that does not affect `allFiles`, this task can remain `UP_TO_DATE` and save task execution. Perhaps, but I wouldn't want to make this change as part of this bug fix. I'd rather not have to do the analysis of whether there is any case where `sourceRoots` can change in a way that wouldn't affect the outputs. If not, then this is only a theoretical concern, and if so, it seems better to err on the side of correctness unless you can prove that all similar cases won't affect the outputs. ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From kcr at openjdk.java.net Wed May 12 20:37:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 May 2021 20:37:09 GMT Subject: RFR: 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest In-Reply-To: References: Message-ID: On Wed, 12 May 2021 13:18:25 GMT, Arun Joseph wrote: > The system test test.com.sun.webkit.LocalStorageAccessTest fails on Windows as mentioned in [JDK-8265661](https://bugs.openjdk.java.net/browse/JDK-8265661). We should skip this test until it is fixed. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/497 From nlisker at openjdk.java.net Wed May 12 21:14:53 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 12 May 2021 21:14:53 GMT Subject: RFR: 8266811: Openjfx controls test build broken (Eclipse) In-Reply-To: References: Message-ID: On Tue, 11 May 2021 09:36:29 GMT, Jeanette Winzenburg wrote: > was introduced with fix [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) which uses MockListObserver in tests. Fix is analogous to previous eclipse build problems (f.i. [JDK-8265513](https://bugs.openjdk.java.net/browse/JDK-8265513)): add-exports to allow access to base' test package. Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/493 From fastegal at openjdk.java.net Wed May 12 22:54:11 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 12 May 2021 22:54:11 GMT Subject: Integrated: 8266811: Openjfx controls test build broken (Eclipse) In-Reply-To: References: Message-ID: On Tue, 11 May 2021 09:36:29 GMT, Jeanette Winzenburg wrote: > was introduced with fix [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) which uses MockListObserver in tests. Fix is analogous to previous eclipse build problems (f.i. [JDK-8265513](https://bugs.openjdk.java.net/browse/JDK-8265513)): add-exports to allow access to base' test package. This pull request has now been integrated. Changeset: e40b0b88 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/e40b0b88a5b95931f19b7a767e34c156d49f1c6b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8266811: Openjfx controls test build broken (Eclipse) Reviewed-by: nlisker ------------- PR: https://git.openjdk.java.net/jfx/pull/493 From kcr at openjdk.java.net Thu May 13 00:01:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 May 2021 00:01:05 GMT Subject: RFR: 8264138: Replace uses of Class.newInstance [v2] In-Reply-To: References: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> Message-ID: On Wed, 12 May 2021 15:20:28 GMT, Ajit Ghaisas wrote: >> This PR replaces Class.newInstance() deprecated method with Contructor.newinstance(). > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > fix apps and unit tests I left a couple comments (in tests), where the replacement code isn't equivalent. modules/javafx.controls/src/test/java/test/javafx/scene/control/cell/ParameterisedPrebuiltCellTest.java line 73: > 71: try { > 72: cell = cellClass.getDeclaredConstructor().newInstance(); > 73: } catch (Exception e) { This will now catch and ignore runtime exceptions as well, where it previously would cause the test to fail. This could end up missing a real problem. The two additional checked exceptions, along with any runtime exceptions, should cause the test to fail. In fact, I don't know why the existing exceptions are ignored (unless there is a compelling reason to ignore them that I'm not aware of), so probably the best thing to do would be to eliminate the try / catch entirely, and instead add a `throws Exception` to the method declaration. modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1329: > 1327: value = type.getDeclaredConstructor().newInstance(); > 1328: } catch (Exception e) { > 1329: throw constructLoadException(e); This isn't quite equivalent, since it will now wrap a `RuntimeException` in a `LoadException`, but I think that's OK in this case. modules/javafx.graphics/src/test/java/test/com/sun/javafx/test/binding/ReflectionHelper.java line 46: > 44: try { > 45: return cls.getDeclaredConstructor().newInstance(); > 46: } catch (final Exception e) { This could re-wrap a `RuntimeException` needlessly, but is OK in this case (it's a test and it won't change whether or not it fails). The more equivalent fix would be to either list the checked exception individually, or to add a `catch (RuntimeException)` before the `catch (Exception)` and re-throw the rte without wrapping it. ------------- PR: https://git.openjdk.java.net/jfx/pull/491 From mstrauss at openjdk.java.net Thu May 13 00:12:08 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 13 May 2021 00:12:08 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces Message-ID: This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. ------------- Commit messages: - Use cmd /s option when building on Windows Changes: https://git.openjdk.java.net/jfx/pull/499/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=499&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267059 Stats: 45 lines in 1 file changed: 27 ins; 15 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/499.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/499/head:pull/499 PR: https://git.openjdk.java.net/jfx/pull/499 From ajoseph at openjdk.java.net Thu May 13 01:59:01 2021 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Thu, 13 May 2021 01:59:01 GMT Subject: Integrated: 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest In-Reply-To: References: Message-ID: On Wed, 12 May 2021 13:18:25 GMT, Arun Joseph wrote: > The system test test.com.sun.webkit.LocalStorageAccessTest fails on Windows as mentioned in [JDK-8265661](https://bugs.openjdk.java.net/browse/JDK-8265661). We should skip this test until it is fixed. This pull request has now been integrated. Changeset: 389e8c04 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/389e8c04c42bbc19eebbade69ed175c7e56cf65d Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/497 From nlisker at openjdk.java.net Thu May 13 02:09:07 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 13 May 2021 02:09:07 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction Can we continue with the review? We need to decide about the rotation behavior and the performance options need to be tested. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From aghaisas at openjdk.java.net Thu May 13 10:57:17 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 13 May 2021 10:57:17 GMT Subject: RFR: 8264138: Replace uses of Class.newInstance [v3] In-Reply-To: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> References: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> Message-ID: > This PR replaces Class.newInstance() deprecated method with Contructor.newinstance(). Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: fix review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/491/files - new: https://git.openjdk.java.net/jfx/pull/491/files/d47ce2d5..ff6fd21e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=491&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=491&range=01-02 Stats: 9 lines in 2 files changed: 2 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/491.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/491/head:pull/491 PR: https://git.openjdk.java.net/jfx/pull/491 From aghaisas at openjdk.java.net Thu May 13 10:57:18 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 13 May 2021 10:57:18 GMT Subject: RFR: 8264138: Replace uses of Class.newInstance [v2] In-Reply-To: References: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> Message-ID: On Wed, 12 May 2021 23:36:01 GMT, Kevin Rushforth wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> fix apps and unit tests > > modules/javafx.controls/src/test/java/test/javafx/scene/control/cell/ParameterisedPrebuiltCellTest.java line 73: > >> 71: try { >> 72: cell = cellClass.getDeclaredConstructor().newInstance(); >> 73: } catch (Exception e) { > > This will now catch and ignore runtime exceptions as well, where it previously would cause the test to fail. This could end up missing a real problem. The two additional checked exceptions, along with any runtime exceptions, should cause the test to fail. In fact, I don't know why the existing exceptions are ignored (unless there is a compelling reason to ignore them that I'm not aware of), so probably the best thing to do would be to eliminate the try / catch entirely, and instead add a `throws Exception` to the method declaration. Removed try/catch block and marked the method with `throws Exception` > modules/javafx.graphics/src/test/java/test/com/sun/javafx/test/binding/ReflectionHelper.java line 46: > >> 44: try { >> 45: return cls.getDeclaredConstructor().newInstance(); >> 46: } catch (final Exception e) { > > This could re-wrap a `RuntimeException` needlessly, but is OK in this case (it's a test and it won't change whether or not it fails). The more equivalent fix would be to either list the checked exception individually, or to add a `catch (RuntimeException)` before the `catch (Exception)` and re-throw the rte without wrapping it. Avoided the re-wrap of a `RuntimeException` as suggested. ------------- PR: https://git.openjdk.java.net/jfx/pull/491 From kcr at openjdk.java.net Thu May 13 12:14:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 May 2021 12:14:58 GMT Subject: RFR: 8264138: Replace uses of Class.newInstance [v3] In-Reply-To: References: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> Message-ID: On Thu, 13 May 2021 10:57:17 GMT, Ajit Ghaisas wrote: >> This PR replaces Class.newInstance() deprecated method with Contructor.newinstance(). > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > fix review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/491 From fastegal at openjdk.java.net Thu May 13 12:28:36 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 13 May 2021 12:28:36 GMT Subject: RFR: 8265210: TreeCell: cell editing state not updated on cell re-use Message-ID: fix is analogous to similar issues for Tree/TableCell (combined [JDK-8150525](https://bugs.openjdk.java.net/browse/JDK-8150525) and [JDK-8265206](https://bugs.openjdk.java.net/browse/JDK-8265206)) added tests that failed before and passed after the fix note: this PR also adds two asserts (which I forgot in the previous [PR 473](https://github.com/openjdk/jfx/pull/473);) in Tree/TableEditingTest which are unrelated to this fix. ------------- Commit messages: - 8265210: TreeCell: cell editing state not updated on cell re-use Changes: https://git.openjdk.java.net/jfx/pull/501/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=501&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265210 Stats: 385 lines in 5 files changed: 354 ins; 17 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/501.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/501/head:pull/501 PR: https://git.openjdk.java.net/jfx/pull/501 From fastegal at openjdk.java.net Thu May 13 12:33:03 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 13 May 2021 12:33:03 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v12] In-Reply-To: <9PlAK2Hcn8Fcz4vei-lhslHK9l68bCDO23979BgCDzE=.1c7fcd48-6ff5-4e13-b26d-7f9b721d41dd@github.com> References: <9PlAK2Hcn8Fcz4vei-lhslHK9l68bCDO23979BgCDzE=.1c7fcd48-6ff5-4e13-b26d-7f9b721d41dd@github.com> Message-ID: <6KilXTDPm2wXIDazfX5_9X2N8701lPWXtZLx967181M=.90bb8e3c-f111-43e1-9922-adb136c368ae@github.com> On Wed, 12 May 2021 08:13:32 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > we now use a try finally statement, to make sure updateEditingIndex is reset! Changes requested by fastegal (Committer). modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 342: > 340: } > 341: updateEditing(); > 342: } forgot yesterday: to keep consistent with TreeTableCell (and TreeCell), the updateEditing should be moved into the else-block (as last call) - couldn't find any difference (in fact couldn't reproduce the error the if/else is supposed to solve) as long as updateEditing behaves, though. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From mvs at openjdk.java.net Thu May 13 12:58:32 2021 From: mvs at openjdk.java.net (Manukumar V S) Date: Thu, 13 May 2021 12:58:32 GMT Subject: RFR: 8266516: One label typo in the properties for bi-directional text Message-ID: A typo in one of the labels of Bidi text has been corrected. This is located in Samples > Controls > Text > Bidi ------------- Commit messages: - 8266516: One label typo in the properties for bi-directional text Changes: https://git.openjdk.java.net/jfx/pull/500/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=500&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266516 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/500.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/500/head:pull/500 PR: https://git.openjdk.java.net/jfx/pull/500 From kcr at openjdk.java.net Thu May 13 12:58:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 May 2021 12:58:33 GMT Subject: RFR: 8266516: One label typo in the properties for bi-directional text In-Reply-To: References: Message-ID: On Thu, 13 May 2021 09:21:10 GMT, Manukumar V S wrote: > A typo in one of the labels of Bidi text has been corrected. This is located in Samples > Controls > Text > Bidi @manukumarvs since you have an entry in the [OpenJDK Census](https://openjdk.java.net/census#mvs), you can instead file a JBS issue to associate your GitHub username with your OpenJDK ID (the second of the above three options). ------------- PR: https://git.openjdk.java.net/jfx/pull/500 From pbansal at openjdk.java.net Thu May 13 13:16:02 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 13 May 2021 13:16:02 GMT Subject: RFR: 8266516: One label typo in the properties for bi-directional text In-Reply-To: References: Message-ID: On Thu, 13 May 2021 09:21:10 GMT, Manukumar V S wrote: > A typo in one of the labels of Bidi text has been corrected. This is located in Samples > Controls > Text > Bidi Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/500 From nlisker at gmail.com Thu May 13 14:25:33 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 13 May 2021 17:25:33 +0300 Subject: Convenience factories for Border and Background In-Reply-To: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: Doesn't seem like that are any more opinions. How do you want to proceed? On Tue, Apr 27, 2021 at 2:45 AM Kevin Rushforth wrote: > I would lean towards the simpler solution that Nir has proposed. I would > like to be informed by what application developers want. > > -- Kevin > > > On 4/26/2021 2:03 PM, Marius Hanl wrote: > > I'm fine with either way. > > Both approaches are nice, while the factory/builder approach will > > probably be a bit better as it will cover more use cases, but of > course > > takes a bit more time. > > In any case we can create a Border/Background very easily and both > are > > quite short, the factory/builder approach will be shorter though. > > > > e.g. > > setBorder(new Border(new BorderStroke(Color.BLACK, > > BorderStrokeStyle.SOLID))); > > setBorder(BorderFactory.createSolidBorder(Color.BLACK)); > > > > > > Gesendet: Sonntag, 25. April 2021 um 13:05 Uhr > > Von: "Nir Lisker" > > An: mariushanl at web.de > > Cc: "openjfx-dev at openjdk.java.net Mailing" > > > > Betreff: Re: Convenience factories for Border and Background > > > > I think a minimal constructor would be a nice first step. > > > > > > I want to avoid adding more constructors, so factory methods would be > > my go-to. > > > > We may can go further from that and create something similar like > > the BorderFactory > > > > > > A factory class or a builder require a whole new class and solves the > > problems of wanting to create many combinations of constructor > > arguments. So we have to ask ourselves if using the full and complex > > constructor for complex cases, and the simple proposed methods for > the > > simple cases is enough, or if there is enough middleground of > > combinations that we need a more advanced solution. > > > > > > On Sat, Apr 24, 2021 at 7:24 PM <[1]mariushanl at web.de> wrote: > > > > Hi Nir, > > this is a really good idea and something I want to see since the > > first > > time I used to set a Background/Border. > > I think a minimal constructor would be a nice first step. > > So instead of: > > - setBackground(new Background(new BackgroundFill(Color.BLACK, > > CornerRadii.EMPTY, Insets.EMPTY))) > > -> setBackground(new Background(new > BackgroundFill(Color.BLACK))) > > and: > > - setBorder(new Border(new BorderStroke(Color.BLACK, > > BorderStrokeStyle.SOLID, CornerRadii.EMPTY, > > BorderStroke.DEFAULT_WIDTHS))) > > -> setBorder(new Border(new BorderStroke(Color.BLACK, > > BorderStrokeStyle.SOLID))) > > We may can go further from that and create something similar > like > > the > > BorderFactory class in swing, where you can create a lot of > > different > > borders easily. (Same to Background) > > Reference: > > > > [1][2] > https://github.com/openjdk/jdk/blob/master/src/java.desktop/sh > > are/cl > > asses/javax/swing/BorderFactory.java > > - Marius > > Gesendet: Donnerstag, 22. April 2021 um 15:45 Uhr > > Von: "Nir Lisker" <[3]nlisker at gmail.com> > > An: "[4]openjfx-dev at openjdk.java.net Mailing" > > <[5]openjfx-dev at openjdk.java.net> > > Betreff: Convenience factories for Border and Background > > Hi, > > Many times when I want to create a simple solid Background or > > Border, > > it is > > quite a hassle because of the configurability these classes > have: > > new Border(new BorderStroke(Color. BLACK, > > BorderStrokeStyle.SOLID, > > null, > > null)); > > new Background(new BackgroundFill(Color.BLACK, null, null)); > > I was thinking of adding convenience factory methods > > Border.of(Paint stroke), or Border.stroke(Paint stroke) > > Background.of((Paint fill), or Background.fill(Paint fill) > > I was wondering if others would like this, or is everyone using > > CSS > > anyway? > > - Nir > > References > > 1. > > [6] > https://deref-web.de/mail/client/sT3TQpQ3T6k/dereferrer/?redirect > > > Url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2 > > > Fjava.desktop%2Fshare%2Fclasses%2Fjavax%2Fswing%2FBorderFactory.java > > > > References > > > > 1. mailto:mariushanl at web.de > > 2. > https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/cl > > 3. mailto:nlisker at gmail.com > > 4. mailto:openjfx-dev at openjdk.java.net > > 5. mailto:openjfx-dev at openjdk.java.net > > 6. > https://deref-web.de/mail/client/sT3TQpQ3T6k/dereferrer/?redirectUrl=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2Fjava.desktop%2Fshare%2Fclasses%2Fjavax%2Fswing%2FBorderFactory.java > > From kcr at openjdk.java.net Thu May 13 15:09:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 May 2021 15:09:52 GMT Subject: RFR: 8266516: One label typo in the properties for bi-directional text In-Reply-To: References: Message-ID: On Thu, 13 May 2021 09:21:10 GMT, Manukumar V S wrote: > A typo in one of the labels of Bidi text has been corrected. This is located in Samples > Controls > Text > Bidi Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/500 From mvs at openjdk.java.net Thu May 13 15:22:54 2021 From: mvs at openjdk.java.net (Manukumar V S) Date: Thu, 13 May 2021 15:22:54 GMT Subject: RFR: 8266516: One label typo in the properties for bi-directional text In-Reply-To: References: Message-ID: On Thu, 13 May 2021 11:48:38 GMT, Kevin Rushforth wrote: >> A typo in one of the labels of Bidi text has been corrected. This is located in Samples > Controls > Text > Bidi > > @manukumarvs since you have an entry in the [OpenJDK Census](https://openjdk.java.net/census#mvs), you can instead file a JBS issue to associate your GitHub username with your OpenJDK ID (the second of the above three options). @kevinrushforth can you sponsor this change? ------------- PR: https://git.openjdk.java.net/jfx/pull/500 From mvs at openjdk.java.net Thu May 13 15:25:53 2021 From: mvs at openjdk.java.net (Manukumar V S) Date: Thu, 13 May 2021 15:25:53 GMT Subject: Integrated: 8266516: One label typo in the properties for bi-directional text In-Reply-To: References: Message-ID: On Thu, 13 May 2021 09:21:10 GMT, Manukumar V S wrote: > A typo in one of the labels of Bidi text has been corrected. This is located in Samples > Controls > Text > Bidi This pull request has now been integrated. Changeset: 9e8c617a Author: Manukumar V S Committer: Pankaj Bansal URL: https://git.openjdk.java.net/jfx/commit/9e8c617a11a0f348d3b0572316b9c00c0f5a7f14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8266516: One label typo in the properties for bi-directional text Reviewed-by: pbansal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/500 From michaelstrau2 at gmail.com Thu May 13 15:41:41 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 13 May 2021 17:41:41 +0200 Subject: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: Another option could be to mirror the `Color` API in both `Border` and `Background`, like in the following examples: Color.rgb(125, 100, 75) Border.rgb(125, 100, 75) Background.rgb(125, 100, 75) Color.gray(127) Border.gray(127) Background.gray(127) Color.web("orange", 0.5) Border.web("orange", 0.5) Background.web("orange", 0.5) We could also mirror the named color constants, which would enable a very compact syntax: StackPane pane = new StackPane(); pane.setBorder(Border.RED); pane.setBackground(Background.BLUE); This is very similar to how "red" or "blue" are valid values for "-fx-border" or "-fx-background" in CSS. From kevin.rushforth at oracle.com Thu May 13 16:08:56 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 May 2021 09:08:56 -0700 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: <1cd21321-9f51-9ea1-da6e-1d8d8908e959@oracle.com> No, I don't like this option at all. This would just duplicate a lot of API methods that would end up delegating to Color. And it would be much worse to duplicate the color constants. This just doesn't seem like a clean API approach. -- Kevin On 5/13/2021 8:41 AM, Michael Strau? wrote: > Another option could be to mirror the `Color` API in both `Border` and > `Background`, like in the following examples: > > Color.rgb(125, 100, 75) > Border.rgb(125, 100, 75) > Background.rgb(125, 100, 75) > > Color.gray(127) > Border.gray(127) > Background.gray(127) > > Color.web("orange", 0.5) > Border.web("orange", 0.5) > Background.web("orange", 0.5) > > We could also mirror the named color constants, which would enable a > very compact syntax: > > StackPane pane = new StackPane(); > pane.setBorder(Border.RED); > pane.setBackground(Background.BLUE); > > This is very similar to how "red" or "blue" are valid values for > "-fx-border" or "-fx-background" in CSS. From jgneff at openjdk.java.net Thu May 13 20:30:19 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Thu, 13 May 2021 20:30:19 GMT Subject: RFR: JDK-8266396: Allow VSCMD_DEBUG to work as intended [v3] In-Reply-To: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Skip sending telemetry to fix "file in use" error I wrote a Bash shell script, included below, that can help in reviewing this pull request. It isolates the call to `vcvarsall.bat`, making it easier to experiment with different choices, such as: - leaving `VSCMD_SKIP_SENDTELEMETRY` undefined, - adding the `/q` option to `cmd`, - removing `2>&1` to use the default standard error, or - discarding standard output with `> /dev/null`. #!/bin/bash # Tests the Visual Studio 'vcvarsall.bat' batch file trap exit INT TERM set -o errexit # Path to 'vcvarsall.bat' batch file vsroot="C:\\Program Files (x86)\\Microsoft Visual Studio" vcfile="2019\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat" vcpath="$vsroot\$vcfile" # Windows command interpreter and options # /C Carries out the command specified by string and then terminates # /Q Turns echo off command="cmd /c" # Skips calling PowerShell script to send telemetry export VSCMD_SKIP_SENDTELEMETRY="1" printf "VSCMD_SKIP_SENDTELEMETRY="%s"\n" "$VSCMD_SKIP_SENDTELEMETRY" # VSCMD_DEBUG undefined unset VSCMD_DEBUG printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG" $command "$vcpath" x86 > 0-debug.log 2>&1 $command "$vcpath" x64 >> 0-debug.log 2>&1 # VSCMD_DEBUG = 1 (basic), 2 (detailed), and 3 (trace) for n in 1 2 3; do export VSCMD_DEBUG="$n" printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG" $command "$vcpath" x86 > $n-debug.log 2>&1 $command "$vcpath" x64 >> $n-debug.log 2>&1 done I run the script under Cygwin on Windows and evaluate its output as follows: $ ./vcvarstest.sh VSCMD_SKIP_SENDTELEMETRY="1" Testing VSCMD_DEBUG="" Testing VSCMD_DEBUG="1" Testing VSCMD_DEBUG="2" Testing VSCMD_DEBUG="3" $ wc -l *.log 10 0-debug.log 92 1-debug.log 508 2-debug.log 5690 3-debug.log 6300 total ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From kcr at openjdk.java.net Thu May 13 21:37:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 May 2021 21:37:16 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 In-Reply-To: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Wed, 12 May 2021 14:54:09 GMT, Kevin Rushforth wrote: > This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. > > In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. > > I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. > > ### Notes to Reviewers: > > The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. > > The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: > > 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed > 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` > 3. Added missing `@Input` annotation to custom Groovy task properties > 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) > > > The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: > > 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` > 2. Updated the gradle version in `build.properties` to `7.0.1` > 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` On closer inspection, I am reverting my earlier change to `gradlew` (the one that reverted the setting of `DEFAULT_JVM_OPTS` to a 64Mbyte heap). The `gradle` launcher in gradle 7.0.1 also sets its `DEFAULT_JVM_OPTS` to a 64Mbyte heap as you can see in the following, taken from `gradle-7.0.1/bin/gradle`: # Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script. DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"' So even though I agree that a 64 Mbyte heap is a bit on the small side, it's more important that running `gradlew` behave the same as installing gradle and running `$GRADLE_HOME/bin/gradle`. Plus I'd prefer not to maintain local modifications of this upstream script. ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From kcr at openjdk.java.net Thu May 13 21:55:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 May 2021 21:55:59 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: > This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. > > In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. > > I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. > > ### Notes to Reviewers: > > The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. > > The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: > > 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed > 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` > 3. Added missing `@Input` annotation to custom Groovy task properties > 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) > > > The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: > > 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` > 2. Updated the gradle version in `build.properties` to `7.0.1` > 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Revert "Revert auto-generated change to DEFAULT_JVM_OPTS in gradlew scripts" This reverts commit 0b70d096055f5b5c892f052d5eee54da357eab63. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/498/files - new: https://git.openjdk.java.net/jfx/pull/498/files/0b70d096..f1a337d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=498&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=498&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/498.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/498/head:pull/498 PR: https://git.openjdk.java.net/jfx/pull/498 From kcr at openjdk.java.net Fri May 14 01:58:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 01:58:39 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces In-Reply-To: References: Message-ID: <1s0MIAaqjEyNSOxeH9P5kiHu0dp70zv5n8b6ucFlqvY=.794b1dce-1455-4025-ad60-e09ba907dd49@github.com> On Thu, 13 May 2021 00:07:15 GMT, Michael Strau? wrote: > This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. > > The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. This will need careful testing. ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From github.com+1445818+crazyjavahacking at openjdk.java.net Fri May 14 08:41:36 2021 From: github.com+1445818+crazyjavahacking at openjdk.java.net (Crazyjavahacking) Date: Fri, 14 May 2021 08:41:36 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 In-Reply-To: References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Thu, 13 May 2021 21:18:33 GMT, Kevin Rushforth wrote: > On closer inspection, I am reverting my earlier change to `gradlew` (the one that reverted the setting of `DEFAULT_JVM_OPTS` to a 64Mbyte heap). The `gradle` launcher in gradle 7.0.1 also sets its `DEFAULT_JVM_OPTS` to a 64Mbyte heap as you can see in the following, taken from `gradle-7.0.1/bin/gradle`: > > ``` > # Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script. > DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"' > ``` > > So even though I agree that a 64 Mbyte heap is a bit on the small side, it's more important that running `gradlew` behave the same as installing gradle and running `$GRADLE_HOME/bin/gradle`. Plus I'd prefer not to maintain local modifications of this upstream script. I don't think this is a good idea. The only modification of the wrapper scripts would need to be the removal of the heap setting, nothing else. Setting 64MB heap will definitely cause performance issues for JFX builds (because of Garbage collection, not enough memory for caching, ...). + the previous setting was not to restrict the heap in Wrapper scripts. So someone already removed the heap setting as 64MB is the setting back from at least Gradle 4. ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From fkirmaier at openjdk.java.net Fri May 14 13:26:55 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 14 May 2021 13:26:55 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v13] In-Reply-To: References: Message-ID: <6smRdL2M-o3RDqhxUqaynC9pHpjqyCD2CPEa4Lu2A8A=.b5ad5b77-f363-4a66-aa05-daadcae2f564@github.com> > Fixing ListCell editing status is true, when index changes while editing. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8264127 More changes, simplifications and tests based on CR ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/441/files - new: https://git.openjdk.java.net/jfx/pull/441/files/f4af1d26..1fa3738a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=11-12 Stats: 54 lines in 2 files changed: 46 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/441/head:pull/441 PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Fri May 14 13:26:56 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 14 May 2021 13:26:56 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v12] In-Reply-To: <9PlAK2Hcn8Fcz4vei-lhslHK9l68bCDO23979BgCDzE=.1c7fcd48-6ff5-4e13-b26d-7f9b721d41dd@github.com> References: <9PlAK2Hcn8Fcz4vei-lhslHK9l68bCDO23979BgCDzE=.1c7fcd48-6ff5-4e13-b26d-7f9b721d41dd@github.com> Message-ID: On Wed, 12 May 2021 08:13:32 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127: > we now use a try finally statement, to make sure updateEditingIndex is reset! I've added a test for the try-catch-finally block, based on the test in the TreeTableCell. (for some reason i can't comment it in the CR) ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Fri May 14 13:26:57 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Fri, 14 May 2021 13:26:57 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v12] In-Reply-To: <6KilXTDPm2wXIDazfX5_9X2N8701lPWXtZLx967181M=.90bb8e3c-f111-43e1-9922-adb136c368ae@github.com> References: <9PlAK2Hcn8Fcz4vei-lhslHK9l68bCDO23979BgCDzE=.1c7fcd48-6ff5-4e13-b26d-7f9b721d41dd@github.com> <6KilXTDPm2wXIDazfX5_9X2N8701lPWXtZLx967181M=.90bb8e3c-f111-43e1-9922-adb136c368ae@github.com> Message-ID: On Thu, 13 May 2021 12:29:46 GMT, Jeanette Winzenburg wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8264127: >> we now use a try finally statement, to make sure updateEditingIndex is reset! > > modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 342: > >> 340: } >> 341: updateEditing(); >> 342: } > > forgot yesterday: to keep consistent with TreeTableCell (and TreeCell), the updateEditing should be moved into the else-block (as last call) - couldn't find any difference (in fact couldn't reproduce the error the if/else is supposed to solve) as long as updateEditing behaves, though. I've moved it to the if-else. Probably doesn't matter. > modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 546: > >> 544: >> 545: if (editing && (index == -1 || list == null || index != editIndex)) { >> 546: // If my index is not the one being edited then I need to cancel > > probably just me not being able to see at a glance if the overall logic in the method is the exact same as before the fix (modulo the fix itself :), but: I would prefer an extra method used in both early return for the -1/null-list and the old else-if. > > If the second reviewer sees the equivalence at a glance, I'll believe his eyes :) I've simplified the if-else statements. Should now be obvious that it's the same as in TreeTableCell. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From jvos at openjdk.java.net Fri May 14 14:43:05 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 14 May 2021 14:43:05 GMT Subject: RFR: 8267160: Monocle mouse never get ENTERED state Message-ID: allow to pass a fallback window in case the existing one is null (or can't be computed). Fix for JDK-8267160 ------------- Commit messages: - allow to pass a fallback window in case the existing one is null (or can't be computed). Changes: https://git.openjdk.java.net/jfx/pull/502/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=502&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267160 Stats: 13 lines in 2 files changed: 7 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/502.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/502/head:pull/502 PR: https://git.openjdk.java.net/jfx/pull/502 From kevin.rushforth at oracle.com Fri May 14 15:22:59 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 May 2021 08:22:59 -0700 Subject: CFV: New OpenJFX Reviewer: Arun Joseph Message-ID: I hereby nominate Arun Joseph [1] to OpenJFX Reviewer. Arun is a member of JavaFX team at Oracle, who has contributed 41 commits [2][3][4] to OpenJFX. Arun often participates in code reviews of various OpenJFX pull requests. Votes are due by May 28, 2021 at 16:00 UTC. Only current OpenJFX Reviewers [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [6]. Nomination to a project Reviewer is described in [7]. Thanks. -- Kevin [1] https://openjdk.java.net/census#ajoseph [2] https://github.com/openjdk/jfx/search?q=author-email%3Aajoseph%40openjdk.org&s=author-date&type=Commits [3] https://github.com/openjdk/jfx/search?q=author-email%3Aarun.aj.joseph%40oracle.com&s=author-date&type=Commits [4] https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 [5] https://openjdk.java.net/census#openjfx [6] https://openjdk.java.net/bylaws#three-vote-consensus [7] https://openjdk.java.net/projects#project-reviewer From kevin.rushforth at oracle.com Fri May 14 15:23:12 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 May 2021 08:23:12 -0700 Subject: CFV: New OpenJFX Reviewer: Jeanette Winzenburg Message-ID: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> I hereby nominate Jeanette Winzenburg [1] to OpenJFX Reviewer. Jeanette is an OpenJFX community member, who has contributed 33 commits [2][3] to OpenJFX. Jeanette consistently participates in code reviews of various OpenJFX pull requests, specifically in the area of UI Controls. Votes are due by May 28, 2021 at 16:00 UTC. Only current OpenJFX Reviewers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [5]. Nomination to a project Reviewer is described in [6]. Thanks. -- Kevin [1] https://openjdk.java.net/census#fastegal [2] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits [3] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits [4] https://openjdk.java.net/census#openjfx [5] https://openjdk.java.net/bylaws#three-vote-consensus [6] https://openjdk.java.net/projects#project-reviewer From kevin.rushforth at oracle.com Fri May 14 15:24:35 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 May 2021 08:24:35 -0700 Subject: CFV: New OpenJFX Reviewer: Arun Joseph In-Reply-To: References: Message-ID: Vote: YES -- Kevin On 5/14/2021 8:22 AM, Kevin Rushforth wrote: > I hereby nominate Arun Joseph [1] to OpenJFX Reviewer. From kevin.rushforth at oracle.com Fri May 14 15:25:05 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 May 2021 08:25:05 -0700 Subject: CFV: New OpenJFX Reviewer: Jeanette Winzenburg In-Reply-To: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> References: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> Message-ID: Vote: YES -- Kevin On 5/14/2021 8:23 AM, Kevin Rushforth wrote: > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Reviewer. From kcr at openjdk.java.net Fri May 14 15:42:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 15:42:40 GMT Subject: RFR: 8267160: Monocle mouse never get ENTERED state In-Reply-To: References: Message-ID: <7TtlwUvPzy7sj-4mK_Xr_9jQobWPDo8-lOKvH3CJY_0=.0dfe5dc0-6fb2-43af-a870-419368bcb370@github.com> On Fri, 14 May 2021 14:37:04 GMT, Johan Vos wrote: > allow to pass a fallback window in case the existing one is null (or can't be computed). > > Fix for JDK-8267160 I'm not sure I understand the fix. Questions inline. modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MouseState.java line 94: > 92: */ > 93: MonocleWindow getWindow(boolean recalculateCache, MonocleWindow fallback) { > 94: if (recalculateCache) { Two questions: 1. It looks like `fallback` is effectively unused (always null). Did you add this for a future use case? 2. Unless I'm missing something, the only behavioral change is that it no longer executes the `if` block when the window is null if `recalculateCache` is false. ------------- PR: https://git.openjdk.java.net/jfx/pull/502 From jvos at openjdk.java.net Fri May 14 15:58:39 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 14 May 2021 15:58:39 GMT Subject: RFR: 8267160: Monocle mouse never get ENTERED state In-Reply-To: <7TtlwUvPzy7sj-4mK_Xr_9jQobWPDo8-lOKvH3CJY_0=.0dfe5dc0-6fb2-43af-a870-419368bcb370@github.com> References: <7TtlwUvPzy7sj-4mK_Xr_9jQobWPDo8-lOKvH3CJY_0=.0dfe5dc0-6fb2-43af-a870-419368bcb370@github.com> Message-ID: <9esHnkKNPV7XmSPbUSEEEDRZKl_Lgg1vgRtnafKPGaI=.2366fd66-7e7b-4b23-be95-c1496d82dfb7@github.com> On Fri, 14 May 2021 15:37:38 GMT, Kevin Rushforth wrote: >> allow to pass a fallback window in case the existing one is null (or can't be computed). >> >> Fix for JDK-8267160 > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MouseState.java line 94: > >> 92: */ >> 93: MonocleWindow getWindow(boolean recalculateCache, MonocleWindow fallback) { >> 94: if (recalculateCache) { > > Two questions: > > 1. It looks like `fallback` is effectively unused (always null). Did you add this for a future use case? > 2. Unless I'm missing something, the only behavioral change is that it no longer executes the `if` block when the window is null if `recalculateCache` is false. true to both questions. The reason for this change is that this is now doing the same as what is done in `monocle.TouchState` and `monocle.TouchInput`. TBH, I would prefer a different approach, where no fallback is passed, and the `if` block is only executed when `recalculateCache` is set to `true`. The only case where this `getWindow` method is invoked, is from `MouseInput` and it is only used to detect if the "old" window is different from the current window. Hence, it all seems a bit overkill to me, but for some reason, I thought keeping things consistent (mouseState versus TouchState) would make sense. If you are ok with it, I can simply rewrite this without looking at the TouchState case? ------------- PR: https://git.openjdk.java.net/jfx/pull/502 From kcr at openjdk.java.net Fri May 14 16:32:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 16:32:34 GMT Subject: RFR: 8267160: Monocle mouse never get ENTERED state In-Reply-To: References: Message-ID: <-Q3FdxaXARrWSibbs9pOWdmxM9qug9YgRAVOppY4PU0=.ca5d9e51-c7a8-416f-9720-c939ebb755a0@github.com> On Fri, 14 May 2021 14:37:04 GMT, Johan Vos wrote: > allow to pass a fallback window in case the existing one is null (or can't be computed). > > Fix for JDK-8267160 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/502 From kcr at openjdk.java.net Fri May 14 16:32:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 16:32:35 GMT Subject: RFR: 8267160: Monocle mouse never get ENTERED state In-Reply-To: <9esHnkKNPV7XmSPbUSEEEDRZKl_Lgg1vgRtnafKPGaI=.2366fd66-7e7b-4b23-be95-c1496d82dfb7@github.com> References: <7TtlwUvPzy7sj-4mK_Xr_9jQobWPDo8-lOKvH3CJY_0=.0dfe5dc0-6fb2-43af-a870-419368bcb370@github.com> <9esHnkKNPV7XmSPbUSEEEDRZKl_Lgg1vgRtnafKPGaI=.2366fd66-7e7b-4b23-be95-c1496d82dfb7@github.com> Message-ID: <5AAacwWsqSJ0h-6kCz-Q98vjTORt6yx2Ly705bt9Uvs=.8819a6dc-2c4e-4b35-9e99-3aa345cc071c@github.com> On Fri, 14 May 2021 15:55:48 GMT, Johan Vos wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MouseState.java line 94: >> >>> 92: */ >>> 93: MonocleWindow getWindow(boolean recalculateCache, MonocleWindow fallback) { >>> 94: if (recalculateCache) { >> >> Two questions: >> >> 1. It looks like `fallback` is effectively unused (always null). Did you add this for a future use case? >> 2. Unless I'm missing something, the only behavioral change is that it no longer executes the `if` block when the window is null if `recalculateCache` is false. > > true to both questions. > The reason for this change is that this is now doing the same as what is done in `monocle.TouchState` and `monocle.TouchInput`. > TBH, I would prefer a different approach, where no fallback is passed, and the `if` block is only executed when `recalculateCache` is set to `true`. The only case where this `getWindow` method is invoked, is from `MouseInput` and it is only used to detect if the "old" window is different from the current window. Hence, it all seems a bit overkill to me, but for some reason, I thought keeping things consistent (mouseState versus TouchState) would make sense. > If you are ok with it, I can simply rewrite this without looking at the TouchState case? Either is fine with me. As long as this fixes your problem, go ahead with the fix. Or if you prefer, go ahead and rewrite it. ------------- PR: https://git.openjdk.java.net/jfx/pull/502 From nlisker at gmail.com Fri May 14 16:47:30 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 14 May 2021 19:47:30 +0300 Subject: CFV: New OpenJFX Reviewer: Arun Joseph In-Reply-To: References: Message-ID: Vote: YES On Fri, May 14, 2021 at 6:25 PM Kevin Rushforth wrote: > Vote: YES > > -- Kevin > > On 5/14/2021 8:22 AM, Kevin Rushforth wrote: > > I hereby nominate Arun Joseph [1] to OpenJFX Reviewer. > > From nlisker at gmail.com Fri May 14 16:48:07 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 14 May 2021 19:48:07 +0300 Subject: CFV: New OpenJFX Reviewer: Jeanette Winzenburg In-Reply-To: References: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> Message-ID: Vote: YES On Fri, May 14, 2021 at 6:25 PM Kevin Rushforth wrote: > Vote: YES > > -- Kevin > > On 5/14/2021 8:23 AM, Kevin Rushforth wrote: > > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Reviewer. > > From jvos at openjdk.java.net Fri May 14 16:55:36 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 14 May 2021 16:55:36 GMT Subject: RFR: 8267160: Monocle mouse never get ENTERED state In-Reply-To: <5AAacwWsqSJ0h-6kCz-Q98vjTORt6yx2Ly705bt9Uvs=.8819a6dc-2c4e-4b35-9e99-3aa345cc071c@github.com> References: <7TtlwUvPzy7sj-4mK_Xr_9jQobWPDo8-lOKvH3CJY_0=.0dfe5dc0-6fb2-43af-a870-419368bcb370@github.com> <9esHnkKNPV7XmSPbUSEEEDRZKl_Lgg1vgRtnafKPGaI=.2366fd66-7e7b-4b23-be95-c1496d82dfb7@github.com> <5AAacwWsqSJ0h-6kCz-Q98vjTORt6yx2Ly705bt9Uvs=.8819a6dc-2c4e-4b35-9e99-3aa345cc071c@github.com> Message-ID: On Fri, 14 May 2021 16:29:19 GMT, Kevin Rushforth wrote: >> true to both questions. >> The reason for this change is that this is now doing the same as what is done in `monocle.TouchState` and `monocle.TouchInput`. >> TBH, I would prefer a different approach, where no fallback is passed, and the `if` block is only executed when `recalculateCache` is set to `true`. The only case where this `getWindow` method is invoked, is from `MouseInput` and it is only used to detect if the "old" window is different from the current window. Hence, it all seems a bit overkill to me, but for some reason, I thought keeping things consistent (mouseState versus TouchState) would make sense. >> If you are ok with it, I can simply rewrite this without looking at the TouchState case? > > Either is fine with me. As long as this fixes your problem, go ahead with the fix. Or if you prefer, go ahead and rewrite it. I'll keep it like this for now, and I created a follow-up issue (JDK-8267175) for dealing with touch/mouse/key state/input handling in general in monocle. ------------- PR: https://git.openjdk.java.net/jfx/pull/502 From jvos at openjdk.java.net Fri May 14 16:55:37 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 14 May 2021 16:55:37 GMT Subject: Integrated: 8267160: Monocle mouse never get ENTERED state In-Reply-To: References: Message-ID: On Fri, 14 May 2021 14:37:04 GMT, Johan Vos wrote: > allow to pass a fallback window in case the existing one is null (or can't be computed). > > Fix for JDK-8267160 This pull request has now been integrated. Changeset: 8ca7815a Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/8ca7815afc2d592fe057ec50328fdc41ca86112e Stats: 13 lines in 2 files changed: 7 ins; 0 del; 6 mod 8267160: Monocle mouse never get ENTERED state Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/502 From johan.vos at gluonhq.com Fri May 14 17:28:04 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 14 May 2021 19:28:04 +0200 Subject: CFV: New OpenJFX Reviewer: Arun Joseph In-Reply-To: References: Message-ID: Vote: YES On Fri, May 14, 2021 at 5:23 PM Kevin Rushforth wrote: > I hereby nominate Arun Joseph [1] to OpenJFX Reviewer. > > Arun is a member of JavaFX team at Oracle, who has contributed 41 > commits [2][3][4] to OpenJFX. Arun often participates in code reviews of > various OpenJFX pull requests. > > Votes are due by May 28, 2021 at 16:00 UTC. > > Only current OpenJFX Reviewers [5] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [6]. Nomination to a > project Reviewer is described in [7]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#ajoseph > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Aajoseph%40openjdk.org&s=author-date&type=Commits > > [3] > > https://github.com/openjdk/jfx/search?q=author-email%3Aarun.aj.joseph%40oracle.com&s=author-date&type=Commits > > [4] > > https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 > > [5] https://openjdk.java.net/census#openjfx > > [6] https://openjdk.java.net/bylaws#three-vote-consensus > > [7] https://openjdk.java.net/projects#project-reviewer > > From johan.vos at gluonhq.com Fri May 14 17:28:23 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 14 May 2021 19:28:23 +0200 Subject: CFV: New OpenJFX Reviewer: Jeanette Winzenburg In-Reply-To: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> References: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> Message-ID: Vote: YES On Fri, May 14, 2021 at 5:23 PM Kevin Rushforth wrote: > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Reviewer. > > Jeanette is an OpenJFX community member, who has contributed 33 commits > [2][3] to OpenJFX. Jeanette consistently participates in code reviews of > various OpenJFX pull requests, specifically in the area of UI Controls. > > Votes are due by May 28, 2021 at 16:00 UTC. > > Only current OpenJFX Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [5]. Nomination to a > project Reviewer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#fastegal > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits > > [3] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits > > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#three-vote-consensus > > [6] https://openjdk.java.net/projects#project-reviewer > > From kcr at openjdk.java.net Fri May 14 21:30:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 21:30:50 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction I started to look at this today, and will continue next week. There is also the outstanding issue with a retina display (scale=2) on macOS. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Fri May 14 21:47:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 21:47:47 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 15:20:41 GMT, Michael Strau? wrote: > The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). > > However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. > > ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). > > The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. > > This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. > > I've filed a bug report with the same title. The fix looks good, but I noted two places where I think you need to initialize `oldValue`. modules/javafx.base/src/main/java/com/sun/javafx/binding/BidirectionalBinding.java line 585: > 583: private TypedGenericBidirectionalBinding(Property property1, Property property2) { > 584: super(property1, property2); > 585: propertyRef1 = new WeakReference<>(property1); Don't you need to initialize `oldValue` here? oldValue = property1.get(); modules/javafx.base/src/main/java/com/sun/javafx/binding/BidirectionalBinding.java line 657: > 655: private TypedNumberBidirectionalBinding(Property property1, Property property2) { > 656: super(property1, property2); > 657: propertyRef1 = new WeakReference<>(property1); Same comment as above. Shouldn't `oldValue` be set? ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From nlisker at openjdk.java.net Fri May 14 22:25:47 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 14 May 2021 22:25:47 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Fri, 14 May 2021 21:28:15 GMT, Kevin Rushforth wrote: > There is also the outstanding issue with a retina display (scale=2) on macOS. Yes, it has to be looked at, but I think it is unrelated to this particular patch. If this is the case, we can file a different issue and continue with this one. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mstrauss at openjdk.java.net Fri May 14 22:30:16 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 14 May 2021 22:30:16 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing [v2] In-Reply-To: References: Message-ID: <1-TeKM4ICdqznUlus7ujsERthr8HFCkez8qL9eM3cS4=.4ba84240-0f1d-4fd8-bfcb-de6b88c0d764@github.com> > The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). > > However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. > > ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). > > The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. > > This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. > > I've filed a bug report with the same title. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added missing oldValue assignments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/454/files - new: https://git.openjdk.java.net/jfx/pull/454/files/1142087a..538b9b38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=454&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=454&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/454.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/454/head:pull/454 PR: https://git.openjdk.java.net/jfx/pull/454 From mstrauss at openjdk.java.net Fri May 14 22:30:18 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 14 May 2021 22:30:18 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 15:20:41 GMT, Michael Strau? wrote: > The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). > > However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. > > ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). > > The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. > > This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. > > I've filed a bug report with the same title. I've added the two missing `oldValue` initializations. ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From mstrauss at openjdk.java.net Fri May 14 22:30:22 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 14 May 2021 22:30:22 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing [v2] In-Reply-To: References: Message-ID: On Fri, 14 May 2021 21:40:39 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> added missing oldValue assignments > > modules/javafx.base/src/main/java/com/sun/javafx/binding/BidirectionalBinding.java line 585: > >> 583: private TypedGenericBidirectionalBinding(Property property1, Property property2) { >> 584: super(property1, property2); >> 585: propertyRef1 = new WeakReference<>(property1); > > Don't you need to initialize `oldValue` here? > > > oldValue = property1.get(); Yes, it should be initialized. ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From kcr at openjdk.java.net Fri May 14 22:32:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 22:32:39 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction You may be right about the scale problem being preexisting. I'll double check when I test on Mac next week (both Retina and external screen). ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Fri May 14 22:51:53 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 22:51:53 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing [v2] In-Reply-To: <1-TeKM4ICdqznUlus7ujsERthr8HFCkez8qL9eM3cS4=.4ba84240-0f1d-4fd8-bfcb-de6b88c0d764@github.com> References: <1-TeKM4ICdqznUlus7ujsERthr8HFCkez8qL9eM3cS4=.4ba84240-0f1d-4fd8-bfcb-de6b88c0d764@github.com> Message-ID: On Fri, 14 May 2021 22:30:16 GMT, Michael Strau? wrote: >> The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). >> >> However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. >> >> ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). >> >> The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. >> >> This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. >> >> I've filed a bug report with the same title. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added missing oldValue assignments Looks good (I note that the test failure on Linux is an unrelated bug that is under evaluation). ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/454 From kcr at openjdk.java.net Fri May 14 23:05:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 23:05:40 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Thu, 13 May 2021 21:55:59 GMT, Kevin Rushforth wrote: >> This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. >> >> In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. >> >> I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. >> >> ### Notes to Reviewers: >> >> The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. >> >> The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: >> >> 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed >> 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` >> 3. Added missing `@Input` annotation to custom Groovy task properties >> 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) >> >> >> The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: >> >> 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` >> 2. Updated the gradle version in `build.properties` to `7.0.1` >> 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Revert auto-generated change to DEFAULT_JVM_OPTS in gradlew scripts" > > This reverts commit 0b70d096055f5b5c892f052d5eee54da357eab63. We haven't updated the gradle wrapper since gradle 4.3. I did it this time as a better practice, which came up during the review of PR #411 in [this comment](https://github.com/openjdk/jfx/pull/411#issuecomment-784438990). Anyway, I do agree with you that the value is (surprisingly) low, but it's easy to override this by setting the `GRADLE_OPTS` env var. That's what we've always done in our CI build. Let's see what the reviewers think. If others think we should change it, I'd certainly be willing to reconsider setting it to a higher value (which seems better than just removing the setting like I did in the earlier, now-reverted commit). ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From swpalmer at openjdk.java.net Fri May 14 23:36:43 2021 From: swpalmer at openjdk.java.net (Scott Palmer) Date: Fri, 14 May 2021 23:36:43 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Thu, 13 May 2021 21:55:59 GMT, Kevin Rushforth wrote: >> This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. >> >> In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. >> >> I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. >> >> ### Notes to Reviewers: >> >> The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. >> >> The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: >> >> 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed >> 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` >> 3. Added missing `@Input` annotation to custom Groovy task properties >> 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) >> >> >> The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: >> >> 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` >> 2. Updated the gradle version in `build.properties` to `7.0.1` >> 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Revert auto-generated change to DEFAULT_JVM_OPTS in gradlew scripts" > > This reverts commit 0b70d096055f5b5c892f052d5eee54da357eab63. Isn't that just?the settings for running the gradle wrapper - i.e.? it is not setting the heap used by the gradle daemon process that will actually run the build?script? I only see it used one spot in the script to run the gradle-wrapper.jar, in which case it makes sense that it is intentionally set low as the wrapper itself isn't doing much other than ensuring the correct version of Gradle is used. ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From kcr at openjdk.java.net Fri May 14 23:42:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 14 May 2021 23:42:54 GMT Subject: RFR: 8266860: [macos] Incorrect duration reported for HLS live streams In-Reply-To: <6EmIy98NOjbtbDBCS1BpvgF_6WkwFMs8ZyqZ6TFxtS4=.348dc137-27f2-4f66-8d60-fdd891269528@github.com> References: <6EmIy98NOjbtbDBCS1BpvgF_6WkwFMs8ZyqZ6TFxtS4=.348dc137-27f2-4f66-8d60-fdd891269528@github.com> Message-ID: On Tue, 11 May 2021 23:43:36 GMT, Alexander Matveev wrote: > For indefinite durations CMTimeGetSeconds was returning NaN (not-a-number double value) and our code expects -1.0. Based on doc we should be using CMTIME_IS_INDEFINITE to test if duration is indefinite. Fixed by using CMTIME_IS_INDEFINITE to test if duration is indefinite and if true -1.0 will be return to our Java layer. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/495 From kcr at openjdk.java.net Sat May 15 12:49:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 15 May 2021 12:49:43 GMT Subject: RFR: 8266860: [macos] Incorrect duration reported for HLS live streams In-Reply-To: <6EmIy98NOjbtbDBCS1BpvgF_6WkwFMs8ZyqZ6TFxtS4=.348dc137-27f2-4f66-8d60-fdd891269528@github.com> References: <6EmIy98NOjbtbDBCS1BpvgF_6WkwFMs8ZyqZ6TFxtS4=.348dc137-27f2-4f66-8d60-fdd891269528@github.com> Message-ID: On Tue, 11 May 2021 23:43:36 GMT, Alexander Matveev wrote: > For indefinite durations CMTimeGetSeconds was returning NaN (not-a-number double value) and our code expects -1.0. Based on doc we should be using CMTIME_IS_INDEFINITE to test if duration is indefinite. Fixed by using CMTIME_IS_INDEFINITE to test if duration is indefinite and if true -1.0 will be return to our Java layer. I requested 2 reviewers before I reviewed the fix, since changes in media are usually complex enough that a second reviewer is needed. In this case the fix is simple and obvious, so I don't think a second reviewer is required. @sashamatveev I recommend to wait until later in the day Monday to integrate this in case anyone else wants to take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/495 From kcr at openjdk.java.net Sat May 15 13:16:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 15 May 2021 13:16:39 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Fri, 14 May 2021 23:33:44 GMT, Scott Palmer wrote: > Isn't that just?the settings for running the gradle wrapper - i.e.? it is not setting the heap used by the gradle daemon process that will actually run the build?script? Ah yes, you are right. I just verified this with a test build. So this is definitely not an issue then. Thanks! ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From kcr at openjdk.java.net Sat May 15 14:08:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 15 May 2021 14:08:05 GMT Subject: RFR: 8267121: Illegal access to private "size" field of ArrayList from build.gradle Message-ID: A test of our CI build with gradle 7.0.1 and JDK 16.0.1 revealed a latent bug in `build.gradle` in the `fetchExternalTools()` method. It checks the size of an `ArrayList` in two places, but rather than calling the `size()` method it omits the `()` which means it is accessing the private `size` field. Starting in JDK 16, which has default strong encapsulation, this no longer works, so we need to fix this before switching. We really should fix it anyway, since accessing the internal field is both unnecessary and wrong. ------------- Commit messages: - 8267121: Illegal access to private "size" field of ArrayList from build.gradle Changes: https://git.openjdk.java.net/jfx/pull/503/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=503&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267121 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/503.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/503/head:pull/503 PR: https://git.openjdk.java.net/jfx/pull/503 From github.com+1445818+crazyjavahacking at openjdk.java.net Sun May 16 12:41:34 2021 From: github.com+1445818+crazyjavahacking at openjdk.java.net (Crazyjavahacking) Date: Sun, 16 May 2021 12:41:34 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Thu, 13 May 2021 21:55:59 GMT, Kevin Rushforth wrote: >> This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. >> >> In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. >> >> I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. >> >> ### Notes to Reviewers: >> >> The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. >> >> The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: >> >> 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed >> 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` >> 3. Added missing `@Input` annotation to custom Groovy task properties >> 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) >> >> >> The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: >> >> 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` >> 2. Updated the gradle version in `build.properties` to `7.0.1` >> 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Revert auto-generated change to DEFAULT_JVM_OPTS in gradlew scripts" > > This reverts commit 0b70d096055f5b5c892f052d5eee54da357eab63. Sorry for confusion. I misunderstand the mechanics. ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From guru.hb at oracle.com Mon May 17 03:57:03 2021 From: guru.hb at oracle.com (Guru Prasad H B) Date: Mon, 17 May 2021 03:57:03 +0000 Subject: CFV: New OpenJFX Reviewer: Jeanette Winzenburg In-Reply-To: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> References: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> Message-ID: <2CECE9D7-095F-455F-9F11-BE6773903725@oracle.com> Vote: Yes Thanks, Guru > On 14-May-2021, at 8:53 PM, Kevin Rushforth wrote: > > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Reviewer. > > Jeanette is an OpenJFX community member, who has contributed 33 commits [2][3] to OpenJFX. Jeanette consistently participates in code reviews of various OpenJFX pull requests, specifically in the area of UI Controls. > > Votes are due by May 28, 2021 at 16:00 UTC. > > Only current OpenJFX Reviewers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [5]. Nomination to a project Reviewer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#fastegal > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits > > [3] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#three-vote-consensus > > [6] https://openjdk.java.net/projects#project-reviewer > From guru.hb at oracle.com Mon May 17 03:57:24 2021 From: guru.hb at oracle.com (Guru Prasad H B) Date: Mon, 17 May 2021 03:57:24 +0000 Subject: CFV: New OpenJFX Reviewer: Arun Joseph In-Reply-To: References: Message-ID: <7EFE3682-69AD-412A-A860-49A713791424@oracle.com> Vote: Yes Thanks, Guru > On 14-May-2021, at 8:52 PM, Kevin Rushforth wrote: > > I hereby nominate Arun Joseph [1] to OpenJFX Reviewer. > > Arun is a member of JavaFX team at Oracle, who has contributed 41 commits [2][3][4] to OpenJFX. Arun often participates in code reviews of various OpenJFX pull requests. > > Votes are due by May 28, 2021 at 16:00 UTC. > > Only current OpenJFX Reviewers [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [6]. Nomination to a project Reviewer is described in [7]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#ajoseph > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Aajoseph%40openjdk.org&s=author-date&type=Commits > > [3] https://github.com/openjdk/jfx/search?q=author-email%3Aarun.aj.joseph%40oracle.com&s=author-date&type=Commits > > [4] https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 > > [5] https://openjdk.java.net/census#openjfx > > [6] https://openjdk.java.net/bylaws#three-vote-consensus > > [7] https://openjdk.java.net/projects#project-reviewer > From ajit.ghaisas at oracle.com Mon May 17 05:28:16 2021 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 17 May 2021 10:58:16 +0530 Subject: CFV: New OpenJFX Reviewer: Arun Joseph In-Reply-To: References: Message-ID: <1E10AACA-5590-4028-90BB-8C79893DD66F@oracle.com> Vote : YES Regards, Ajit > On 14-May-2021, at 8:52 PM, Kevin Rushforth wrote: > > I hereby nominate Arun Joseph [1] to OpenJFX Reviewer. > > Arun is a member of JavaFX team at Oracle, who has contributed 41 commits [2][3][4] to OpenJFX. Arun often participates in code reviews of various OpenJFX pull requests. > > Votes are due by May 28, 2021 at 16:00 UTC. > > Only current OpenJFX Reviewers [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [6]. Nomination to a project Reviewer is described in [7]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#ajoseph > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Aajoseph%40openjdk.org&s=author-date&type=Commits > > [3] https://github.com/openjdk/jfx/search?q=author-email%3Aarun.aj.joseph%40oracle.com&s=author-date&type=Commits > > [4] https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 > > [5] https://openjdk.java.net/census#openjfx > > [6] https://openjdk.java.net/bylaws#three-vote-consensus > > [7] https://openjdk.java.net/projects#project-reviewer > From ajit.ghaisas at oracle.com Mon May 17 05:28:54 2021 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 17 May 2021 10:58:54 +0530 Subject: CFV: New OpenJFX Reviewer: Jeanette Winzenburg In-Reply-To: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> References: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> Message-ID: Vote : YES Regards, Ajit > On 14-May-2021, at 8:53 PM, Kevin Rushforth wrote: > > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Reviewer. > > Jeanette is an OpenJFX community member, who has contributed 33 commits [2][3] to OpenJFX. Jeanette consistently participates in code reviews of various OpenJFX pull requests, specifically in the area of UI Controls. > > Votes are due by May 28, 2021 at 16:00 UTC. > > Only current OpenJFX Reviewers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [5]. Nomination to a project Reviewer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#fastegal > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits > > [3] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#three-vote-consensus > > [6] https://openjdk.java.net/projects#project-reviewer > From jonathan at jonathangiles.net Mon May 17 05:37:16 2021 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Mon, 17 May 2021 17:37:16 +1200 Subject: CFV: New OpenJFX Reviewer: Jeanette Winzenburg In-Reply-To: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> References: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> Message-ID: Yes -- Jonathan On Sat, 15 May 2021, 3:23 am Kevin Rushforth, wrote: > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Reviewer. > > Jeanette is an OpenJFX community member, who has contributed 33 commits > [2][3] to OpenJFX. Jeanette consistently participates in code reviews of > various OpenJFX pull requests, specifically in the area of UI Controls. > > Votes are due by May 28, 2021 at 16:00 UTC. > > Only current OpenJFX Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [5]. Nomination to a > project Reviewer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#fastegal > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits > > [3] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits > > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#three-vote-consensus > > [6] https://openjdk.java.net/projects#project-reviewer > > From arapte at openjdk.java.net Mon May 17 08:36:46 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 08:36:46 GMT Subject: RFR: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 Message-ID: Issue: When css file is added to a `Scene.getStylesheets()` of a Scene which has few controls in addition to a Label then css style of a different control gets applied to Label after Stage is hidden and shown. This is a regression of [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). The sample program attached to JBS adds a Label, Button, CheckBox and another Label to Scene. The css style of the Button gets applied to second Label after Stage is hidden and shown. Fix: Do not `recalculateRelativeSizeProperties()` when `resetToInitialValues()` is in progress. After Stage is hidden and shown, the css style is reset to initial value in method `resetToInitialValues()`, which resets the font size of a Control to default font size. This reset results in execution of method `recalculateRelativeSizeProperties()` that was added as part of fix for JDK-8204568. `recalculateRelativeSizeProperties()` uses `getStyleMap()` to get `StyleMap` of the node. In this case `getStyleMap()` returns an incorrect `StyleMap` as the reset is still in progress. A comment is added in this fix to explain how the StyleMap is stored and retrieved. Added a system test which fails before and passes after this fix. ------------- Commit messages: - do not recalculate when reseting css Changes: https://git.openjdk.java.net/jfx/pull/504/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=504&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266966 Stats: 130 lines in 3 files changed: 127 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/504.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/504/head:pull/504 PR: https://git.openjdk.java.net/jfx/pull/504 From arapte at openjdk.java.net Mon May 17 08:39:59 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 08:39:59 GMT Subject: RFR: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing [v2] In-Reply-To: <1-TeKM4ICdqznUlus7ujsERthr8HFCkez8qL9eM3cS4=.4ba84240-0f1d-4fd8-bfcb-de6b88c0d764@github.com> References: <1-TeKM4ICdqznUlus7ujsERthr8HFCkez8qL9eM3cS4=.4ba84240-0f1d-4fd8-bfcb-de6b88c0d764@github.com> Message-ID: <9_XayhrGMUkyuQqwTkmP-K_eji-9geofwokv2ANh1m8=.ceb5f7c6-9499-43f9-8a65-ebb35beac7f4@github.com> On Fri, 14 May 2021 22:30:16 GMT, Michael Strau? wrote: >> The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). >> >> However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. >> >> ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). >> >> The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. >> >> This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. >> >> I've filed a bug report with the same title. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added missing oldValue assignments Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From fastegal at openjdk.java.net Mon May 17 08:45:45 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 17 May 2021 08:45:45 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v13] In-Reply-To: <6smRdL2M-o3RDqhxUqaynC9pHpjqyCD2CPEa4Lu2A8A=.b5ad5b77-f363-4a66-aa05-daadcae2f564@github.com> References: <6smRdL2M-o3RDqhxUqaynC9pHpjqyCD2CPEa4Lu2A8A=.b5ad5b77-f363-4a66-aa05-daadcae2f564@github.com> Message-ID: On Fri, 14 May 2021 13:26:55 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127 > More changes, simplifications and tests based on CR fix looks okay, commented the added test method inline. BTW: I assume you will fix the trailing whitespace error in your next commit :) modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellTest.java line 936: > 934: assertFalse("cell must not be editing", cell.isEditing()); > 935: assertEquals("table must be editing at intermediate index", intermediate, list.getEditingIndex()); > 936: } that's good - except for a minor omission: the catch-block is never reached, instead it is printed to sysout (or syserr, don't nail me) That happens because ExpressionHelper kind of swallows all exceptions in change notifications by passing them to the uncaughtExceptionHandler. To fix this, a test should un-/install (in After/Before methods) an uncaught exception handler. For examples, see f.i. TableCellTest. really minor: replace "table" by "list" in the failure message :) modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellTest.java line 947: > 945: } finally { > 946: assertFalse("cell must not be editing", cell.isEditing()); > 947: assertEquals("table editing must be cancelled by cell", notEditingIndex, list.getEditingIndex()); same minor c&p error as above ------------- Changes requested by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/441 From arapte at openjdk.java.net Mon May 17 09:54:00 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 09:54:00 GMT Subject: RFR: 8267121: Illegal access to private "size" field of ArrayList from build.gradle In-Reply-To: References: Message-ID: On Sat, 15 May 2021 12:42:56 GMT, Kevin Rushforth wrote: > A test of our CI build with gradle 7.0.1 and JDK 16.0.1 revealed a latent bug in `build.gradle` in the `fetchExternalTools()` method. It checks the size of an `ArrayList` in two places, but rather than calling the `size()` method it omits the `()` which means it is accessing the private `size` field. > > Starting in JDK 16, which has default strong encapsulation, this no longer works, so we need to fix this before switching. We really should fix it anyway, since accessing the internal field is both unnecessary and wrong. lgtm, Did not find any other instance where `size` member variable is used. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/503 From jvos at openjdk.java.net Mon May 17 09:54:00 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 17 May 2021 09:54:00 GMT Subject: RFR: 8267121: Illegal access to private "size" field of ArrayList from build.gradle In-Reply-To: References: Message-ID: On Sat, 15 May 2021 12:42:56 GMT, Kevin Rushforth wrote: > A test of our CI build with gradle 7.0.1 and JDK 16.0.1 revealed a latent bug in `build.gradle` in the `fetchExternalTools()` method. It checks the size of an `ArrayList` in two places, but rather than calling the `size()` method it omits the `()` which means it is accessing the private `size` field. > > Starting in JDK 16, which has default strong encapsulation, this no longer works, so we need to fix this before switching. We really should fix it anyway, since accessing the internal field is both unnecessary and wrong. looks good. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/503 From jvos at openjdk.java.net Mon May 17 09:57:06 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 17 May 2021 09:57:06 GMT Subject: RFR: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 In-Reply-To: References: Message-ID: On Mon, 17 May 2021 08:30:26 GMT, Ambarish Rapte wrote: > Issue: > When css file is added to a `Scene.getStylesheets()` of a Scene which has few controls in addition to a Label then css style of a different control gets applied to Label after Stage is hidden and shown. This is a regression of [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). > > The sample program attached to JBS adds a Label, Button, CheckBox and another Label to Scene. The css style of the Button gets applied to second Label after Stage is hidden and shown. > > Fix: Do not `recalculateRelativeSizeProperties()` when `resetToInitialValues()` is in progress. > After Stage is hidden and shown, the css style is reset to initial value in method `resetToInitialValues()`, which resets the font size of a Control to default font size. This reset results in execution of method `recalculateRelativeSizeProperties()` that was added as part of fix for JDK-8204568. `recalculateRelativeSizeProperties()` uses `getStyleMap()` to get `StyleMap` of the node. In this case `getStyleMap()` returns an incorrect `StyleMap` as the reset is still in progress. > > A comment is added in this fix to explain how the StyleMap is stored and retrieved. > Added a system test which fails before and passes after this fix. @jperedadnr Can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/504 From arapte at openjdk.java.net Mon May 17 10:55:49 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 10:55:49 GMT Subject: RFR: 8266539: [TreeView]: Change.getRemoved() contains null item when deselecting a TreeItem In-Reply-To: References: Message-ID: <-FsiD2qzirmT7Bbq7q-uC2T_OPHyvstcHtAfQLCD36o=.5f302dc8-aa86-424c-adc7-e5184bb7995e@github.com> On Mon, 10 May 2021 17:26:52 GMT, Michael Strau? wrote: > This PR contains a fix that was de-scoped from #480 and solves an issue where an incorrect index is used in `MultipleSelectionModelBase.SelectedIndicesList.clear(int)`. Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/492 From aghaisas at openjdk.java.net Mon May 17 12:45:41 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 17 May 2021 12:45:41 GMT Subject: RFR: 8186904: TableColumnHeader: resize cursor lost on right click In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 20:26:35 GMT, Marius Hanl wrote: > This PR is fixing a bug, when a right click on a table column is performed. > By doing that, the table columns will lose the resize cursor thus they can not be resized anymore. > > The reason for that is that the **columnDragLock** will not reset (to false). > This flag is set to true, when a mouse press is detected (on a table column) and to false, when a mouse release is detected. Unfortunately, this flag is not reset on a right click, because a check (**#isPopupTrigger()**) will guard against it. > > With this PR, this flag will always reset to false inside the mouse released handler. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/483 From arapte at openjdk.java.net Mon May 17 12:50:57 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 12:50:57 GMT Subject: RFR: 8266643: Intermittent failure of HonorDeveloperSettingsTest unit test Message-ID: The test fails intermittently on github build. But I do not observe this issue locally on my Ubuntu20.04 VM. I am suspecting that the reason of failure is that the test are not cleaned up correctly. The changes in this PR cleans up the test, by removing all children added to root and hiding the stage. ------------- Commit messages: - keep only SM.forget(scene), revert other changes - try SM.forget(scene) - reset css style manager before clearing scene - reset to original - skip setScene(null) - change order - css_test_cleanup_fix Changes: https://git.openjdk.java.net/jfx/pull/496/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=496&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266643 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/496.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/496/head:pull/496 PR: https://git.openjdk.java.net/jfx/pull/496 From arapte at openjdk.java.net Mon May 17 12:50:57 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 12:50:57 GMT Subject: RFR: 8266643: Intermittent failure of HonorDeveloperSettingsTest unit test In-Reply-To: References: Message-ID: <6lrp_E3h4AmmsjTS66sHS3Wbiog1Sgj8z1NA50kNpYg=.b3787d0a-50ce-4ef2-8463-ec89210211d7@github.com> On Wed, 12 May 2021 11:53:16 GMT, Ambarish Rapte wrote: > The test fails intermittently on github build. But I do not observe this issue locally on my Ubuntu20.04 VM. > I am suspecting that the reason of failure is that the test are not cleaned up correctly. The changes in this PR cleans up the test, by removing all children added to root and hiding the stage. Hello Kevin, Adding a call to `StyleManager.getInstance().forget(scene)` seems like a proper fix because it clears the `StyleManager`. This PR executed the tests two times using only this call and did not fail the test. Does this look good OR should we also include `root.getChildren().clear()` and `stage.hide()` calls ? ------------- PR: https://git.openjdk.java.net/jfx/pull/496 From kcr at openjdk.java.net Mon May 17 12:50:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 17 May 2021 12:50:58 GMT Subject: RFR: 8266643: Intermittent failure of HonorDeveloperSettingsTest unit test In-Reply-To: References: Message-ID: On Wed, 12 May 2021 11:53:16 GMT, Ambarish Rapte wrote: > The test fails intermittently on github build. But I do not observe this issue locally on my Ubuntu20.04 VM. > I am suspecting that the reason of failure is that the test are not cleaned up correctly. The changes in this PR cleans up the test, by removing all children added to root and hiding the stage. modules/javafx.graphics/src/test/java/test/javafx/css/HonorDeveloperSettingsTest.java line 61: > 59: private Text text; > 60: Stage stage; > 61: Group root; Can these be private? modules/javafx.graphics/src/test/java/test/javafx/css/HonorDeveloperSettingsTest.java line 76: > 74: resetStyleManager(); > 75: root.getChildren().clear(); > 76: stage.hide(); I recommend protecting these with null checks. You might also set `stage` and `root` to null after clearing / hiding (but since they are instance variables that doesn't really matter). ------------- PR: https://git.openjdk.java.net/jfx/pull/496 From mstrauss at openjdk.java.net Mon May 17 12:57:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 17 May 2021 12:57:43 GMT Subject: Integrated: 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 15:20:41 GMT, Michael Strau? wrote: > The internal BidirectionalBinding class implements bidirectional bindings for JavaFX properties. The design intent of this class is to provide specializations for primitive value types to prevent boxing conversions (cf. specializations of the Property class with a similar design intent). > > However, the primitive BidirectionalBinding implementations do not meet the design goal of preventing boxing conversions, because they implement ChangeListener. > > ChangeListener is a generic SAM interface, which makes it impossibe to invoke an implementation of ChangeListener::changed with a primitive value (i.e. any primitive value will be auto-boxed). > > The boxing conversion happens, as with all ChangeListeners, at the invocation site (for example, in ExpressionHelper). Since the boxing conversion has already happened by the time any of the BidirectionalBinding implementations is invoked, there's no point in using primitive specializations of BidirectionalBinding after the fact. > > This issue can be solved by having BidirectionalBinding implement InvalidationListener instead, which by itself does not incur a boxing conversion. Because bidirectional bindings are eagerly evaluated, the observable behavior remains the same. > > I've filed a bug report with the same title. This pull request has now been integrated. Changeset: 285a0b65 Author: Michael Strau? Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/285a0b65907e2cf5cd12dec1a88f729ba2c1c9ba Stats: 113 lines in 3 files changed: 44 ins; 5 del; 64 mod 8264770: BidirectionalBinding should use InvalidationListener to prevent boxing Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/454 From mstrauss at openjdk.java.net Mon May 17 12:58:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 17 May 2021 12:58:43 GMT Subject: Integrated: 8266539: [TreeView]: Change.getRemoved() contains null item when deselecting a TreeItem In-Reply-To: References: Message-ID: On Mon, 10 May 2021 17:26:52 GMT, Michael Strau? wrote: > This PR contains a fix that was de-scoped from #480 and solves an issue where an incorrect index is used in `MultipleSelectionModelBase.SelectedIndicesList.clear(int)`. This pull request has now been integrated. Changeset: f236a7dc Author: Michael Strau? Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/f236a7dcb231c0b87d4499158adc500ed06e5178 Stats: 17 lines in 2 files changed: 14 ins; 0 del; 3 mod 8266539: [TreeView]: Change.getRemoved() contains null item when deselecting a TreeItem Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/492 From kcr at openjdk.java.net Mon May 17 13:04:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 17 May 2021 13:04:42 GMT Subject: Integrated: 8267121: Illegal access to private "size" field of ArrayList from build.gradle In-Reply-To: References: Message-ID: On Sat, 15 May 2021 12:42:56 GMT, Kevin Rushforth wrote: > A test of our CI build with gradle 7.0.1 and JDK 16.0.1 revealed a latent bug in `build.gradle` in the `fetchExternalTools()` method. It checks the size of an `ArrayList` in two places, but rather than calling the `size()` method it omits the `()` which means it is accessing the private `size` field. > > Starting in JDK 16, which has default strong encapsulation, this no longer works, so we need to fix this before switching. We really should fix it anyway, since accessing the internal field is both unnecessary and wrong. This pull request has now been integrated. Changeset: 9c97d9b2 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/9c97d9b21232a67a10debdc8dc3b10c419780f7a Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8267121: Illegal access to private "size" field of ArrayList from build.gradle Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/503 From ambarish.rapte at oracle.com Mon May 17 13:08:43 2021 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 17 May 2021 13:08:43 +0000 Subject: CFV: New OpenJFX Reviewer: Jeanette Winzenburg In-Reply-To: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> References: <14bc025c-7ce6-8e74-88e3-402f446f8c1a@oracle.com> Message-ID: Vote: YES -----Original Message----- From: openjfx-dev On Behalf Of Kevin Rushforth Sent: Friday, May 14, 2021 8:53 PM To: Jeanette Winzenburg ; openjfx-dev at openjdk.java.net Subject: CFV: New OpenJFX Reviewer: Jeanette Winzenburg I hereby nominate Jeanette Winzenburg [1] to OpenJFX Reviewer. Jeanette is an OpenJFX community member, who has contributed 33 commits [2][3] to OpenJFX. Jeanette consistently participates in code reviews of various OpenJFX pull requests, specifically in the area of UI Controls. Votes are due by May 28, 2021 at 16:00 UTC. Only current OpenJFX Reviewers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [5]. Nomination to a project Reviewer is described in [6]. Thanks. -- Kevin [1] https://openjdk.java.net/census#fastegal [2] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits [3] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits [4] https://openjdk.java.net/census#openjfx [5] https://openjdk.java.net/bylaws#three-vote-consensus [6] https://openjdk.java.net/projects#project-reviewer From ambarish.rapte at oracle.com Mon May 17 13:09:05 2021 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 17 May 2021 13:09:05 +0000 Subject: CFV: New OpenJFX Reviewer: Arun Joseph In-Reply-To: References: Message-ID: Vote: YES -----Original Message----- From: openjfx-dev On Behalf Of Kevin Rushforth Sent: Friday, May 14, 2021 8:53 PM To: Arun Joseph ; openjfx-dev at openjdk.java.net Subject: CFV: New OpenJFX Reviewer: Arun Joseph I hereby nominate Arun Joseph [1] to OpenJFX Reviewer. Arun is a member of JavaFX team at Oracle, who has contributed 41 commits [2][3][4] to OpenJFX. Arun often participates in code reviews of various OpenJFX pull requests. Votes are due by May 28, 2021 at 16:00 UTC. Only current OpenJFX Reviewers [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [6]. Nomination to a project Reviewer is described in [7]. Thanks. -- Kevin [1] https://openjdk.java.net/census#ajoseph [2] https://github.com/openjdk/jfx/search?q=author-email%3Aajoseph%40openjdk.org&s=author-date&type=Commits [3] https://github.com/openjdk/jfx/search?q=author-email%3Aarun.aj.joseph%40oracle.com&s=author-date&type=Commits [4] https://github.com/openjdk/jfx/commit/b2d85645ffc7edc327b28e12eede6505912d7491 [5] https://openjdk.java.net/census#openjfx [6] https://openjdk.java.net/bylaws#three-vote-consensus [7] https://openjdk.java.net/projects#project-reviewer From kcr at openjdk.java.net Mon May 17 14:16:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 17 May 2021 14:16:37 GMT Subject: RFR: 8266643: Intermittent failure of HonorDeveloperSettingsTest unit test In-Reply-To: <6lrp_E3h4AmmsjTS66sHS3Wbiog1Sgj8z1NA50kNpYg=.b3787d0a-50ce-4ef2-8463-ec89210211d7@github.com> References: <6lrp_E3h4AmmsjTS66sHS3Wbiog1Sgj8z1NA50kNpYg=.b3787d0a-50ce-4ef2-8463-ec89210211d7@github.com> Message-ID: On Mon, 17 May 2021 07:16:06 GMT, Ambarish Rapte wrote: > should we also include `root.getChildren().clear()` and `stage.hide()` calls ? I see no need for `root.getChildren().clear()`. I think all graphics unit tests that call `stage.show()` should call `stage.hide()` in a cleanup method, but I see that most of them don't. Maybe that can be done globally in a follow-up test bug (perhaps in a future test sprint)? ------------- PR: https://git.openjdk.java.net/jfx/pull/496 From jpereda at openjdk.java.net Mon May 17 14:23:56 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 17 May 2021 14:23:56 GMT Subject: RFR: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 In-Reply-To: References: Message-ID: On Mon, 17 May 2021 08:30:26 GMT, Ambarish Rapte wrote: > Issue: > When css file is added to a `Scene.getStylesheets()` of a Scene which has few controls in addition to a Label then css style of a different control gets applied to Label after Stage is hidden and shown. This is a regression of [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). > > The sample program attached to JBS adds a Label, Button, CheckBox and another Label to Scene. The css style of the Button gets applied to second Label after Stage is hidden and shown. > > Fix: Do not `recalculateRelativeSizeProperties()` when `resetToInitialValues()` is in progress. > After Stage is hidden and shown, the css style is reset to initial value in method `resetToInitialValues()`, which resets the font size of a Control to default font size. This reset results in execution of method `recalculateRelativeSizeProperties()` that was added as part of fix for JDK-8204568. `recalculateRelativeSizeProperties()` uses `getStyleMap()` to get `StyleMap` of the node. In this case `getStyleMap()` returns an incorrect `StyleMap` as the reset is still in progress. > > A comment is added in this fix to explain how the StyleMap is stored and retrieved. > Added a system test which fails before and passes after this fix. Looks good to me, tested the proposed patch, and it works as expected. Just added two minor comments. modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 456: > 454: } > 455: > 456: private boolean resetInProgress = false; Add a new line? modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 607: > 605: // CssStyleHelper.CacheContainer.smapId as key. > 606: // So, when resetToInitialValues() is in progress: the StyleManager.styleMapList gets updated > 607: // and getStyleMap(node) may return an incorrect StyleMap for a given node. Probably a better wording could be: // When resetToInitialValues() is in progress, the StyleManager.styleMapList gets updated, therefore // calls to getStyleMap(node) should be avoided, as it may return an incorrect StyleMap for a given node. ------------- PR: https://git.openjdk.java.net/jfx/pull/504 From kcr at openjdk.java.net Mon May 17 15:07:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 17 May 2021 15:07:17 GMT Subject: RFR: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 In-Reply-To: References: Message-ID: On Mon, 17 May 2021 08:30:26 GMT, Ambarish Rapte wrote: > Issue: > When css file is added to a `Scene.getStylesheets()` of a Scene which has few controls in addition to a Label then css style of a different control gets applied to Label after Stage is hidden and shown. This is a regression of [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). > > The sample program attached to JBS adds a Label, Button, CheckBox and another Label to Scene. The css style of the Button gets applied to second Label after Stage is hidden and shown. > > Fix: Do not `recalculateRelativeSizeProperties()` when `resetToInitialValues()` is in progress. > After Stage is hidden and shown, the css style is reset to initial value in method `resetToInitialValues()`, which resets the font size of a Control to default font size. This reset results in execution of method `recalculateRelativeSizeProperties()` that was added as part of fix for JDK-8204568. `recalculateRelativeSizeProperties()` uses `getStyleMap()` to get `StyleMap` of the node. In this case `getStyleMap()` returns an incorrect `StyleMap` as the reset is still in progress. > > A comment is added in this fix to explain how the StyleMap is stored and retrieved. > Added a system test which fails before and passes after this fix. Looks good. I confirm that it fixes the bug, and that the new test fails without the fix and passes with the fix. I also did a full build / test (including manual tests) and don't see any other regressions. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/504 From mstrauss at openjdk.java.net Mon May 17 16:16:16 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 17 May 2021 16:16:16 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: > The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. > > `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' into fixes/JDK-8196065 # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java - Merge branch 'master' into fixes/JDK-8196065 - Merge branch 'master' into fixes/JDK-8196065 # Conflicts: # modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java - Cleanup - Fixed clear-and-select change notification - Add failing tests - Cleanup - Added tests - Fix incorrect index when multiple remove changes are handled in SelectedItemsReadOnlyObservableList - Add failing test ------------- Changes: https://git.openjdk.java.net/jfx/pull/478/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=05 Stats: 350 lines in 8 files changed: 328 ins; 2 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/478.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/478/head:pull/478 PR: https://git.openjdk.java.net/jfx/pull/478 From kcr at openjdk.java.net Mon May 17 18:03:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 17 May 2021 18:03:48 GMT Subject: RFR: 8266643: Intermittent failure of HonorDeveloperSettingsTest unit test In-Reply-To: References: Message-ID: On Wed, 12 May 2021 11:53:16 GMT, Ambarish Rapte wrote: > The test fails intermittently on github build. But I do not observe this issue locally on my Ubuntu20.04 VM. > I am suspecting that the reason of failure is that the test are not cleaned up correctly. The changes in this PR cleans up the test, by removing all children added to root and hiding the stage. Looks good. In addition to testing this locally, I kicked off two GitHub actions builds (the Linux systems used by GitHub actions is are the only systems on which we've seen this fail), and both passed. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/496 From arapte at openjdk.java.net Mon May 17 19:35:09 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 19:35:09 GMT Subject: RFR: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 [v2] In-Reply-To: References: Message-ID: > Issue: > When css file is added to a `Scene.getStylesheets()` of a Scene which has few controls in addition to a Label then css style of a different control gets applied to Label after Stage is hidden and shown. This is a regression of [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). > > The sample program attached to JBS adds a Label, Button, CheckBox and another Label to Scene. The css style of the Button gets applied to second Label after Stage is hidden and shown. > > Fix: Do not `recalculateRelativeSizeProperties()` when `resetToInitialValues()` is in progress. > After Stage is hidden and shown, the css style is reset to initial value in method `resetToInitialValues()`, which resets the font size of a Control to default font size. This reset results in execution of method `recalculateRelativeSizeProperties()` that was added as part of fix for JDK-8204568. `recalculateRelativeSizeProperties()` uses `getStyleMap()` to get `StyleMap` of the node. In this case `getStyleMap()` returns an incorrect `StyleMap` as the reset is still in progress. > > A comment is added in this fix to explain how the StyleMap is stored and retrieved. > Added a system test which fails before and passes after this fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/504/files - new: https://git.openjdk.java.net/jfx/pull/504/files/4413dcca..ea0d1bcb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=504&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=504&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/504.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/504/head:pull/504 PR: https://git.openjdk.java.net/jfx/pull/504 From arapte at openjdk.java.net Mon May 17 19:35:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 19:35:10 GMT Subject: RFR: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 14:20:33 GMT, Jose Pereda wrote: > Just added two minor comments. Updated PR according to comments, please have a re-look. > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 456: > >> 454: } >> 455: >> 456: private boolean resetInProgress = false; > > Add a new line? Added a new line. > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 607: > >> 605: // CssStyleHelper.CacheContainer.smapId as key. >> 606: // So, when resetToInitialValues() is in progress: the StyleManager.styleMapList gets updated >> 607: // and getStyleMap(node) may return an incorrect StyleMap for a given node. > > Probably a better wording could be: > > // When resetToInitialValues() is in progress, the StyleManager.styleMapList gets updated, therefore > // calls to getStyleMap(node) should be avoided, as it may return an incorrect StyleMap for a given node. Changed the two lines as suggested. ------------- PR: https://git.openjdk.java.net/jfx/pull/504 From arapte at openjdk.java.net Mon May 17 19:40:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 19:40:40 GMT Subject: RFR: 8266643: Intermittent failure of HonorDeveloperSettingsTest unit test In-Reply-To: References: <6lrp_E3h4AmmsjTS66sHS3Wbiog1Sgj8z1NA50kNpYg=.b3787d0a-50ce-4ef2-8463-ec89210211d7@github.com> Message-ID: <9ZMD53T2TObHFdTJQ1dgLKrjtpiQkS26qv7yBqPGMDQ=.bc30f715-3a3e-4d44-b620-e02f279ec027@github.com> On Mon, 17 May 2021 14:13:53 GMT, Kevin Rushforth wrote: > Maybe that can be done globally in a follow-up test bug (perhaps in a future test sprint)? Sounds good to me too, shall raise a bug to track. ------------- PR: https://git.openjdk.java.net/jfx/pull/496 From arapte at openjdk.java.net Mon May 17 19:40:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 17 May 2021 19:40:40 GMT Subject: Integrated: 8266643: Intermittent failure of HonorDeveloperSettingsTest unit test In-Reply-To: References: Message-ID: On Wed, 12 May 2021 11:53:16 GMT, Ambarish Rapte wrote: > The test fails intermittently on github build. But I do not observe this issue locally on my Ubuntu20.04 VM. > I am suspecting that the reason of failure is that the test are not cleaned up correctly. The changes in this PR cleans up the test, by removing all children added to root and hiding the stage. This pull request has now been integrated. Changeset: d2d145d3 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/d2d145d37d4e902054164c26236cdcbb653ae7b1 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8266643: Intermittent failure of HonorDeveloperSettingsTest unit test Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/496 From kcr at openjdk.java.net Mon May 17 19:47:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 17 May 2021 19:47:43 GMT Subject: RFR: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 19:35:09 GMT, Ambarish Rapte wrote: >> Issue: >> When css file is added to a `Scene.getStylesheets()` of a Scene which has few controls in addition to a Label then css style of a different control gets applied to Label after Stage is hidden and shown. This is a regression of [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). >> >> The sample program attached to JBS adds a Label, Button, CheckBox and another Label to Scene. The css style of the Button gets applied to second Label after Stage is hidden and shown. >> >> Fix: Do not `recalculateRelativeSizeProperties()` when `resetToInitialValues()` is in progress. >> After Stage is hidden and shown, the css style is reset to initial value in method `resetToInitialValues()`, which resets the font size of a Control to default font size. This reset results in execution of method `recalculateRelativeSizeProperties()` that was added as part of fix for JDK-8204568. `recalculateRelativeSizeProperties()` uses `getStyleMap()` to get `StyleMap` of the node. In this case `getStyleMap()` returns an incorrect `StyleMap` as the reset is still in progress. >> >> A comment is added in this fix to explain how the StyleMap is stored and retrieved. >> Added a system test which fails before and passes after this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/504 From jpereda at openjdk.java.net Mon May 17 21:16:39 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 17 May 2021 21:16:39 GMT Subject: RFR: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 [v2] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 19:35:09 GMT, Ambarish Rapte wrote: >> Issue: >> When css file is added to a `Scene.getStylesheets()` of a Scene which has few controls in addition to a Label then css style of a different control gets applied to Label after Stage is hidden and shown. This is a regression of [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). >> >> The sample program attached to JBS adds a Label, Button, CheckBox and another Label to Scene. The css style of the Button gets applied to second Label after Stage is hidden and shown. >> >> Fix: Do not `recalculateRelativeSizeProperties()` when `resetToInitialValues()` is in progress. >> After Stage is hidden and shown, the css style is reset to initial value in method `resetToInitialValues()`, which resets the font size of a Control to default font size. This reset results in execution of method `recalculateRelativeSizeProperties()` that was added as part of fix for JDK-8204568. `recalculateRelativeSizeProperties()` uses `getStyleMap()` to get `StyleMap` of the node. In this case `getStyleMap()` returns an incorrect `StyleMap` as the reset is still in progress. >> >> A comment is added in this fix to explain how the StyleMap is stored and retrieved. >> Added a system test which fails before and passes after this fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Marked as reviewed by jpereda (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/504 From almatvee at openjdk.java.net Tue May 18 01:06:49 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 18 May 2021 01:06:49 GMT Subject: Integrated: 8266860: [macos] Incorrect duration reported for HLS live streams In-Reply-To: <6EmIy98NOjbtbDBCS1BpvgF_6WkwFMs8ZyqZ6TFxtS4=.348dc137-27f2-4f66-8d60-fdd891269528@github.com> References: <6EmIy98NOjbtbDBCS1BpvgF_6WkwFMs8ZyqZ6TFxtS4=.348dc137-27f2-4f66-8d60-fdd891269528@github.com> Message-ID: On Tue, 11 May 2021 23:43:36 GMT, Alexander Matveev wrote: > For indefinite durations CMTimeGetSeconds was returning NaN (not-a-number double value) and our code expects -1.0. Based on doc we should be using CMTIME_IS_INDEFINITE to test if duration is indefinite. Fixed by using CMTIME_IS_INDEFINITE to test if duration is indefinite and if true -1.0 will be return to our Java layer. This pull request has now been integrated. Changeset: c511789b Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/c511789b106a3f3172aef606419d372bcbca606f Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8266860: [macos] Incorrect duration reported for HLS live streams Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/495 From arapte at openjdk.java.net Tue May 18 03:32:41 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 18 May 2021 03:32:41 GMT Subject: Integrated: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 In-Reply-To: References: Message-ID: On Mon, 17 May 2021 08:30:26 GMT, Ambarish Rapte wrote: > Issue: > When css file is added to a `Scene.getStylesheets()` of a Scene which has few controls in addition to a Label then css style of a different control gets applied to Label after Stage is hidden and shown. This is a regression of [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). > > The sample program attached to JBS adds a Label, Button, CheckBox and another Label to Scene. The css style of the Button gets applied to second Label after Stage is hidden and shown. > > Fix: Do not `recalculateRelativeSizeProperties()` when `resetToInitialValues()` is in progress. > After Stage is hidden and shown, the css style is reset to initial value in method `resetToInitialValues()`, which resets the font size of a Control to default font size. This reset results in execution of method `recalculateRelativeSizeProperties()` that was added as part of fix for JDK-8204568. `recalculateRelativeSizeProperties()` uses `getStyleMap()` to get `StyleMap` of the node. In this case `getStyleMap()` returns an incorrect `StyleMap` as the reset is still in progress. > > A comment is added in this fix to explain how the StyleMap is stored and retrieved. > Added a system test which fails before and passes after this fix. This pull request has now been integrated. Changeset: 93de5840 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/93de5840b19868fbe8850b846418c3f6f72df256 Stats: 132 lines in 3 files changed: 129 ins; 0 del; 3 mod 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/504 From aghaisas at openjdk.java.net Tue May 18 04:55:52 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 18 May 2021 04:55:52 GMT Subject: Integrated: 8264138: Replace uses of Class.newInstance In-Reply-To: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> References: <8Y-HEP1WAihb9pwc1cfXKIuBkrdDPmNWmCpETIPVvI0=.23ac0a7d-7e5b-4058-b93a-1721754bd9bb@github.com> Message-ID: On Mon, 10 May 2021 12:09:09 GMT, Ajit Ghaisas wrote: > This PR replaces Class.newInstance() deprecated method with Contructor.newinstance(). This pull request has now been integrated. Changeset: 4619cddf Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/4619cddfb961ab215cac10c91b828342d10299df Stats: 79 lines in 25 files changed: 2 ins; 17 del; 60 mod 8264138: Replace uses of Class.newInstance Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/491 From github.com+66004280+maran23 at openjdk.java.net Tue May 18 05:05:50 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Tue, 18 May 2021 05:05:50 GMT Subject: Integrated: 8186904: TableColumnHeader: resize cursor lost on right click In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 20:26:35 GMT, Marius Hanl wrote: > This PR is fixing a bug, when a right click on a table column is performed. > By doing that, the table columns will lose the resize cursor thus they can not be resized anymore. > > The reason for that is that the **columnDragLock** will not reset (to false). > This flag is set to true, when a mouse press is detected (on a table column) and to false, when a mouse release is detected. Unfortunately, this flag is not reset on a right click, because a check (**#isPopupTrigger()**) will guard against it. > > With this PR, this flag will always reset to false inside the mouse released handler. This pull request has now been integrated. Changeset: e76b7b1d Author: Marius Hanl Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/e76b7b1d65cef917630d1c8528d6be56c16c015f Stats: 56 lines in 3 files changed: 50 ins; 3 del; 3 mod 8186904: TableColumnHeader: resize cursor lost on right click Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/483 From pbansal at openjdk.java.net Tue May 18 07:10:40 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 18 May 2021 07:10:40 GMT Subject: RFR: 8264219: tools/scripts/build.ps1 is out of date and no longer works In-Reply-To: References: Message-ID: On Sat, 8 May 2021 14:13:34 GMT, Kevin Rushforth wrote: > As noted in PR #212 the unused `tools/scripts/build.ps1` script no longer works. This script was added in support of the Appveyor builds in the old `javafxports/openjdk-jfx` sandbox repo, which haven't been used in nearly two years. In its current state, it is more harmful to leave it in, as it is a source of confusion. Since the script is unused, this PR will simply delete it. looks good to me ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/490 From fkirmaier at openjdk.java.net Tue May 18 10:14:11 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 18 May 2021 10:14:11 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v14] In-Reply-To: References: Message-ID: > Fixing ListCell editing status is true, when index changes while editing. Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: - 8264127 fixed assertion text, exception handler is now installed/uninstalled like in TableCellTest - 8264127 fixed trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/441/files - new: https://git.openjdk.java.net/jfx/pull/441/files/1fa3738a..ba5dc2e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=12-13 Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/441/head:pull/441 PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Tue May 18 10:14:12 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 18 May 2021 10:14:12 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v13] In-Reply-To: References: <6smRdL2M-o3RDqhxUqaynC9pHpjqyCD2CPEa4Lu2A8A=.b5ad5b77-f363-4a66-aa05-daadcae2f564@github.com> Message-ID: <7AAYgQtjKatCFCKYqP_u_efGBoZ_o4Cb5YmR7rr4awo=.bfb1c53b-798b-4799-a914-4ae3518924ed@github.com> On Mon, 17 May 2021 08:40:44 GMT, Jeanette Winzenburg wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8264127 >> More changes, simplifications and tests based on CR > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellTest.java line 936: > >> 934: assertFalse("cell must not be editing", cell.isEditing()); >> 935: assertEquals("table must be editing at intermediate index", intermediate, list.getEditingIndex()); >> 936: } > > that's good - except for a minor omission: the catch-block is never reached, instead it is printed to sysout (or syserr, don't nail me) That happens because ExpressionHelper kind of swallows all exceptions in change notifications by passing them to the uncaughtExceptionHandler. To fix this, a test should un-/install (in After/Before methods) an uncaught exception handler. For examples, see f.i. TableCellTest. > > really minor: replace "table" by "list" in the failure message :) I've now added the exception handler, like in TreeCellTest. And I've fixed the texts of the failure messages. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From fastegal at openjdk.java.net Tue May 18 13:06:52 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 18 May 2021 13:06:52 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v14] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:14:11 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: > > - 8264127 > fixed assertion text, > exception handler is now installed/uninstalled like in TableCellTest > - 8264127 > fixed trailing whitespace fix and tests look good :) ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/441 From fastegal at openjdk.java.net Tue May 18 13:14:49 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 18 May 2021 13:14:49 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v14] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:14:11 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: > > - 8264127 > fixed assertion text, > exception handler is now installed/uninstalled like in TableCellTest > - 8264127 > fixed trailing whitespace wondering why the bot removed the rfr label (about three weeks ago) and re-added it a earlier today? ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From michaelstrau2 at gmail.com Tue May 18 14:59:03 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 18 May 2021 16:59:03 +0200 Subject: Minimum JDK policy for OpenJFX Message-ID: Currently, JDK 11 is required for the latest version of OpenJFX. What is the policy for bumping this requirement? Does it always correspond to the latest JDK LTS release (the next of which will be JDK 17), or is it independent from the release cycle of OpenJDK? From arapte at openjdk.java.net Tue May 18 15:04:43 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 18 May 2021 15:04:43 GMT Subject: RFR: 8264219: tools/scripts/build.ps1 is out of date and no longer works In-Reply-To: References: Message-ID: On Sat, 8 May 2021 14:13:34 GMT, Kevin Rushforth wrote: > As noted in PR #212 the unused `tools/scripts/build.ps1` script no longer works. This script was added in support of the Appveyor builds in the old `javafxports/openjdk-jfx` sandbox repo, which haven't been used in nearly two years. In its current state, it is more harmful to leave it in, as it is a source of confusion. Since the script is unused, this PR will simply delete it. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/490 From arapte at openjdk.java.net Tue May 18 15:15:04 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 18 May 2021 15:15:04 GMT Subject: [jfx11u] RFR: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 Message-ID: Fixes a css style regression issue caused by [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). ------------- Commit messages: - 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 Changes: https://git.openjdk.java.net/jfx11u/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=17&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266966 Stats: 132 lines in 3 files changed: 129 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx11u/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/17/head:pull/17 PR: https://git.openjdk.java.net/jfx11u/pull/17 From kevin.rushforth at oracle.com Tue May 18 15:17:08 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 May 2021 08:17:08 -0700 Subject: Minimum JDK policy for OpenJFX In-Reply-To: References: Message-ID: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> A very timely question. I was already planning to raise this as a discussion after we update our boot JDK to JDK 16 (blocked by the in-progress gradle 7 update), which I hope to do later this week. I think that this is the right time to consider bumping the minimum required version to run JavaFX 17 to JDK 16, which would allow us to start using APIs and language features from JDK 12 through JDK 16 inclusive. In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In practice, though, we don't bump it for each release, as there are some advantages in being able to run with the latest JDK LTS. Since JavaFX 17 will release at roughly the same time as JDK 17 LTS, I can't think of a good reason to not update our minimum. Comments? -- Kevin On 5/18/2021 7:59 AM, Michael Strau? wrote: > Currently, JDK 11 is required for the latest version of OpenJFX. What > is the policy for bumping this requirement? Does it always correspond > to the latest JDK LTS release (the next of which will be JDK 17), or > is it independent from the release cycle of OpenJDK? From michaelstrau2 at gmail.com Tue May 18 15:33:06 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 18 May 2021 17:33:06 +0200 Subject: Minimum JDK policy for OpenJFX In-Reply-To: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: Sounds good, although it is a bit unfortunate that sealed classes will only be un-previewed in JDK 17. I think this feature has great value for reasoning about code, in particular for library development. Do you think we could bump it directly to JDK 17, which I think is very fitting because it's the next LTS release, after all. Am Di., 18. Mai 2021 um 17:17 Uhr schrieb Kevin Rushforth : > > A very timely question. I was already planning to raise this as a > discussion after we update our boot JDK to JDK 16 (blocked by the > in-progress gradle 7 update), which I hope to do later this week. > > I think that this is the right time to consider bumping the minimum > required version to run JavaFX 17 to JDK 16, which would allow us to > start using APIs and language features from JDK 12 through JDK 16 inclusive. > > In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In > practice, though, we don't bump it for each release, as there are some > advantages in being able to run with the latest JDK LTS. Since JavaFX 17 > will release at roughly the same time as JDK 17 LTS, I can't think of a > good reason to not update our minimum. > > Comments? > > -- Kevin > > > On 5/18/2021 7:59 AM, Michael Strau? wrote: > > Currently, JDK 11 is required for the latest version of OpenJFX. What > > is the policy for bumping this requirement? Does it always correspond > > to the latest JDK LTS release (the next of which will be JDK 17), or > > is it independent from the release cycle of OpenJDK? > From jvos at openjdk.java.net Tue May 18 17:18:00 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 18 May 2021 17:18:00 GMT Subject: [jfx11u] RFR: 8264536: Building OpenJFX on Apple AARCH64 not possible Message-ID: Reviewed-by: kcr ------------- Commit messages: - 8264536: Building OpenJFX on Apple AARCH64 not possible Changes: https://git.openjdk.java.net/jfx11u/pull/18/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=18&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264536 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/18.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/18/head:pull/18 PR: https://git.openjdk.java.net/jfx11u/pull/18 From jvos at openjdk.java.net Tue May 18 17:18:27 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 18 May 2021 17:18:27 GMT Subject: [jfx11u] RFR: 8257758: Allow building of JavaFX native libs for Apple Silicon Message-ID: Reviewed-by: kcr ------------- Commit messages: - 8257758: Allow building of JavaFX native libs for Apple Silicon Changes: https://git.openjdk.java.net/jfx11u/pull/19/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=19&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257758 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/19/head:pull/19 PR: https://git.openjdk.java.net/jfx11u/pull/19 From tom.schindl at bestsolution.at Tue May 18 17:45:02 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 18 May 2021 19:45:02 +0200 Subject: Dependencies on java.desktop In-Reply-To: <5ABA3874.10405@oracle.com> References: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> <5ABA3874.10405@oracle.com> Message-ID: <9ca3397c-7e91-381c-9df7-da6c792a16c1@bestsolution.at> Uff - I'd like to revisit this topic. As I did some jlink stuff for our applications adding java.desktop once more bugged me. I guess the first thing to do is to file a JIRA-Ticket but it really starts to bug me to include java.desktop although I don't plan to use printing (and I guess > 90% of the JavaFX don't use the printing API either but produce PDFs or whatever) and Java-Beans. Tom Am 27.03.18 um 14:26 schrieb Kevin Rushforth: > Hi Tom, > > Yes, this is an unfortunate dependency. It is "only" an implementation > dependency, meaning that nothing in the public API depends on > java.desktop (which is why we don't "requires transient java.desktop"), > so it should be possible to remove this dependency in the future. As > noted, it is only there because Java Beans is part of the java.desktop > module. > > In the interim, your suggestion of "requires static java.base" could be > the way to go. It would need a spec change to the JavaFX beans adapter > classes documenting that they would throw an > UnsupportedOperationException if java.desktop was not present at > runtime, along with a recommendation that applications needing that > functionality should add "requires java.desktop" to their own > module-info.java. > > Note that this would only help non-graphical JavaFX applications that > use javafx.base for its collections, properties, and bindings, since > javafx.graphics requires java.desktop in a way that currently cannot > easily be made optional (not without reimplementing printing support > anyway). > > -- Kevin > > > Tom Schindl wrote: >> Hi, >> >> Anyone else has an opinion on that? Is require static the way to go? >> >> Tom >> >> On 21.03.18 23:23, Tom Schindl wrote: >>> Hi, >>> >>> I always thought the JavaFX-Codebase should be able to run with just the >>> java.base module but I was browsing the codebase a bit and was suprised >>> (or rather shocked) that even the base-module requires java.desktop. >>> >>> If I get it correct this because of the java.beans (provided by the >>> adapters) stuff is found in there. Why hasn't the requires there not >>> defined as: >>> >>> requires static java.desktop; >>> >>> Tom >>> From kcr at openjdk.java.net Tue May 18 17:54:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 May 2021 17:54:40 GMT Subject: Integrated: 8264219: tools/scripts/build.ps1 is out of date and no longer works In-Reply-To: References: Message-ID: On Sat, 8 May 2021 14:13:34 GMT, Kevin Rushforth wrote: > As noted in PR #212 the unused `tools/scripts/build.ps1` script no longer works. This script was added in support of the Appveyor builds in the old `javafxports/openjdk-jfx` sandbox repo, which haven't been used in nearly two years. In its current state, it is more harmful to leave it in, as it is a source of confusion. Since the script is unused, this PR will simply delete it. This pull request has now been integrated. Changeset: 485b242d Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/485b242d5993024e5e2b7dcf8d306e0a889ce07e Stats: 72 lines in 1 file changed: 0 ins; 72 del; 0 mod 8264219: tools/scripts/build.ps1 is out of date and no longer works Reviewed-by: pbansal, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/490 From jvos at openjdk.java.net Tue May 18 18:15:40 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 18 May 2021 18:15:40 GMT Subject: [jfx11u] Integrated: 8257758: Allow building of JavaFX native libs for Apple Silicon In-Reply-To: References: Message-ID: On Tue, 18 May 2021 17:12:17 GMT, Johan Vos wrote: > Reviewed-by: kcr This pull request has now been integrated. Changeset: 37d25bce Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/37d25bce9a917677381a2675d7d75b5ae3e7165f Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod 8257758: Allow building of JavaFX native libs for Apple Silicon Backport-of: e1adfa9179bb05a879b419b6221e8aa980fd6af1 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/19 From jvos at openjdk.java.net Tue May 18 18:15:45 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 18 May 2021 18:15:45 GMT Subject: [jfx11u] Integrated: 8264536: Building OpenJFX on Apple AARCH64 not possible In-Reply-To: References: Message-ID: On Tue, 18 May 2021 17:11:35 GMT, Johan Vos wrote: > Reviewed-by: kcr This pull request has now been integrated. Changeset: d3ba1cec Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/d3ba1cec162e63bfd850de08e112d8bf43006cf1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8264536: Building OpenJFX on Apple AARCH64 not possible Backport-of: eec2f394dc81b9a1f9da6cc97ddc0cc39c6e62c5 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/18 From arapte at openjdk.java.net Tue May 18 18:23:42 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 18 May 2021 18:23:42 GMT Subject: [jfx11u] Integrated: 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 In-Reply-To: References: Message-ID: <7IHr7MJV6iIoA9j-sF5N0TOBBPKN_o6YVpyEtO6CVPQ=.89b485cf-3a70-4f8b-9d2a-3b33b802504a@github.com> On Tue, 18 May 2021 15:06:05 GMT, Ambarish Rapte wrote: > Fixes a css style regression issue caused by [JDK-8204568](https://bugs.openjdk.java.net/browse/JDK-8204568). This pull request has now been integrated. Changeset: b2d930e7 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/b2d930e7585cc5452de0ae79a959391a870b439a Stats: 132 lines in 3 files changed: 129 ins; 0 del; 3 mod 8266966: Wrong CSS properties are applied to other nodes after fix for JDK-8204568 Backport-of: 93de5840b19868fbe8850b846418c3f6f72df256 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/17 From jvos at openjdk.java.net Tue May 18 18:34:13 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 18 May 2021 18:34:13 GMT Subject: [jfx11u] RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon Message-ID: Co-authored-by: Johan Vos Reviewed-by: jvos, kcr ------------- Commit messages: - 8257895: Allow building of JavaFX media libs for Apple Silicon Changes: https://git.openjdk.java.net/jfx11u/pull/20/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=20&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257895 Stats: 3577 lines in 19 files changed: 3553 ins; 5 del; 19 mod Patch: https://git.openjdk.java.net/jfx11u/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/20/head:pull/20 PR: https://git.openjdk.java.net/jfx11u/pull/20 From sykora at openjdk.java.net Tue May 18 18:55:27 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Tue, 18 May 2021 18:55:27 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Thu, 13 May 2021 21:55:59 GMT, Kevin Rushforth wrote: >> This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. >> >> In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. >> >> I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. >> >> ### Notes to Reviewers: >> >> The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. >> >> The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: >> >> 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed >> 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` >> 3. Added missing `@Input` annotation to custom Groovy task properties >> 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) >> >> >> The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: >> >> 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` >> 2. Updated the gradle version in `build.properties` to `7.0.1` >> 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Revert auto-generated change to DEFAULT_JVM_OPTS in gradlew scripts" > > This reverts commit 0b70d096055f5b5c892f052d5eee54da357eab63. I've ran the build jobs and building and testing both completed successfully on all platforms. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/498 From jvos at openjdk.java.net Tue May 18 20:09:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 18 May 2021 20:09:42 GMT Subject: [jfx11u] Integrated: 8257895: Allow building of JavaFX media libs for Apple Silicon In-Reply-To: References: Message-ID: On Tue, 18 May 2021 18:27:10 GMT, Johan Vos wrote: > Co-authored-by: Johan Vos > Reviewed-by: jvos, kcr This pull request has now been integrated. Changeset: 7e16449b Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/7e16449b2bdeb093b14c1433459bfeb0e49a9f91 Stats: 3577 lines in 19 files changed: 3553 ins; 5 del; 19 mod 8257895: Allow building of JavaFX media libs for Apple Silicon Backport-of: 8adbc673d095607e8a6109fbb951fa17b9d6caad ------------- PR: https://git.openjdk.java.net/jfx11u/pull/20 From jvos at openjdk.java.net Tue May 18 20:10:01 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 18 May 2021 20:10:01 GMT Subject: [jfx11u] RFR: 8266554: Change default macOS min version for aarch64 to 11.0 Message-ID: Require at least MacOSX 11.0 to build on mac-AArch64. Don't increase minimum SDK version when building on x86-64 (contrary to JDK-8265031) ------------- Commit messages: - Increase minimum SDK version when building on AArch64 Changes: https://git.openjdk.java.net/jfx11u/pull/21/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=21&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266554 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/21.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/21/head:pull/21 PR: https://git.openjdk.java.net/jfx11u/pull/21 From mblaesing at doppel-helix.eu Tue May 18 20:52:23 2021 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Tue, 18 May 2021 22:52:23 +0200 Subject: Minimum JDK policy for OpenJFX In-Reply-To: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: <6ca58b780ce00240985f77c8598563b47edd5c37.camel@doppel-helix.eu> Hi, Am Dienstag, dem 18.05.2021 um 08:17 -0700 schrieb Kevin Rushforth: > > In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In > practice, though, we don't bump it for each release, as there are some > advantages in being able to run with the latest JDK LTS. Since JavaFX 17 > will release at roughly the same time as JDK 17 LTS, I can't think of a > good reason to not update our minimum. > > Comments? I'd like to be able to use JavaFX with NetBeans. Everytime I tried to reach a state where it became usable I hit issues in FX and the latest crasher bug will only be fixed in 17 and at this time NetBeans still tries to stretch from 8 to 16 (ok, 9 and 10 were left in the dust). IMHO stability and compatibility with the past is a feature, not a bug and the "lets brake it" attitude I feel the last years in the java landscape is irritating. Greetings Matthias From cjgunzel at gmail.com Tue May 18 21:11:25 2021 From: cjgunzel at gmail.com (Chuck Davis) Date: Tue, 18 May 2021 14:11:25 -0700 Subject: Minimum JDK policy for OpenJFX In-Reply-To: <6ca58b780ce00240985f77c8598563b47edd5c37.camel@doppel-helix.eu> References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> <6ca58b780ce00240985f77c8598563b47edd5c37.camel@doppel-helix.eu> Message-ID: I use JFX with NetBeans every day with no problems. NetBeans 12.3 and JFX 16 on OpenJDK16.... SceneBuilder creates the dialogs. NetBeans writes the code. The NB JFX is too old. You have to update from Maven (which is, itself, still stuck on old versions of JFX -- hasn't been updated for some time, unfortunately). BUT, using JFX with NetBeans is not a problem here. On Tue, May 18, 2021 at 1:52 PM Matthias Bl?sing wrote: > Hi, > > Am Dienstag, dem 18.05.2021 um 08:17 -0700 schrieb Kevin Rushforth: > > > > In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In > > practice, though, we don't bump it for each release, as there are some > > advantages in being able to run with the latest JDK LTS. Since JavaFX 17 > > will release at roughly the same time as JDK 17 LTS, I can't think of a > > good reason to not update our minimum. > > > > Comments? > > I'd like to be able to use JavaFX with NetBeans. Everytime I tried to > reach a state where it became usable I hit issues in FX and the latest > crasher bug will only be fixed in 17 and at this time NetBeans still > tries to stretch from 8 to 16 (ok, 9 and 10 were left in the dust). > > IMHO stability and compatibility with the past is a feature, not a bug > and the "lets brake it" attitude I feel the last years in the java > landscape is irritating. > > Greetings > > Matthias > > From nlisker at gmail.com Tue May 18 21:11:40 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 19 May 2021 00:11:40 +0300 Subject: Dependencies on java.desktop In-Reply-To: <9ca3397c-7e91-381c-9df7-da6c792a16c1@bestsolution.at> References: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> <5ABA3874.10405@oracle.com> <9ca3397c-7e91-381c-9df7-da6c792a16c1@bestsolution.at> Message-ID: I would also be surprised if printing and bean adapters are used much, but what are the options? Rewrite the printing implementation. On Tue, May 18, 2021 at 8:45 PM Tom Schindl wrote: > Uff - I'd like to revisit this topic. As I did some jlink stuff for our > applications adding java.desktop once more bugged me. > > I guess the first thing to do is to file a JIRA-Ticket but it really > starts to bug me to include java.desktop although I don't plan to use > printing (and I guess > 90% of the JavaFX don't use the printing API > either but produce PDFs or whatever) and Java-Beans. > > Tom > > Am 27.03.18 um 14:26 schrieb Kevin Rushforth: > > Hi Tom, > > > > Yes, this is an unfortunate dependency. It is "only" an implementation > > dependency, meaning that nothing in the public API depends on > > java.desktop (which is why we don't "requires transient java.desktop"), > > so it should be possible to remove this dependency in the future. As > > noted, it is only there because Java Beans is part of the java.desktop > > module. > > > > In the interim, your suggestion of "requires static java.base" could be > > the way to go. It would need a spec change to the JavaFX beans adapter > > classes documenting that they would throw an > > UnsupportedOperationException if java.desktop was not present at > > runtime, along with a recommendation that applications needing that > > functionality should add "requires java.desktop" to their own > > module-info.java. > > > > Note that this would only help non-graphical JavaFX applications that > > use javafx.base for its collections, properties, and bindings, since > > javafx.graphics requires java.desktop in a way that currently cannot > > easily be made optional (not without reimplementing printing support > > anyway). > > > > -- Kevin > > > > > > Tom Schindl wrote: > >> Hi, > >> > >> Anyone else has an opinion on that? Is require static the way to go? > >> > >> Tom > >> > >> On 21.03.18 23:23, Tom Schindl wrote: > >>> Hi, > >>> > >>> I always thought the JavaFX-Codebase should be able to run with just > the > >>> java.base module but I was browsing the codebase a bit and was suprised > >>> (or rather shocked) that even the base-module requires java.desktop. > >>> > >>> If I get it correct this because of the java.beans (provided by the > >>> adapters) stuff is found in there. Why hasn't the requires there not > >>> defined as: > >>> > >>> requires static java.desktop; > >>> > >>> Tom > >>> > From kevin.rushforth at oracle.com Tue May 18 21:40:55 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 May 2021 14:40:55 -0700 Subject: [External] : Re: Dependencies on java.desktop In-Reply-To: <9ca3397c-7e91-381c-9df7-da6c792a16c1@bestsolution.at> References: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> <5ABA3874.10405@oracle.com> <9ca3397c-7e91-381c-9df7-da6c792a16c1@bestsolution.at> Message-ID: As noted in the thread you quoted below, removing the dependency on java.desktop from javafx.base isn't a particularly hard problem, and is tracked by JDK-8240844 [1]. And even though it will require a spec change (meaning a CSR), it doesn't result in any loss of functionality, since in order to usefully do anything with the JavaBeanXxxxx classes requires java.desktop anyway. Removing the dependency on java.desktop from javafx.graphics is a larger issue because of printing. There is also an implementation dependency on the Desktop class to implement HostServices::showDocument that would need to be redone. And of course it depends on the above (eliminating the dependency from javafx.base) being done first. For printing we would need to do one of two things: 1. Eliminate the implementation dependency on the Java2D printing code. This is a large effort, but would preserve existing functionality. 2. Make the JavaFX Printing function "optional" (i.e., make it a "ConditionalFeature"), such that if java.desktop is not present, printing doesn't work (all of the printing APIs would throw an UnsupportedOperationException if java.desktop is not available). An application that wants to do printing would need to include java.desktop. Option 1 would be my preferred approach, but as mentioned above it's a lot of work. Option 2 would need a spec change, and I'm not convinced we want to do it. If there are enough other developers who would want this, we could open it up for discussion for some future version (not JavaFX 17). Phil might have some thoughts on this. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8240844 On 5/18/2021 10:45 AM, Tom Schindl wrote: > Uff - I'd like to revisit this topic. As I did some jlink stuff for > our applications adding java.desktop once more bugged me. > > I guess the first thing to do is to file a JIRA-Ticket but it really > starts to bug me to include java.desktop although I don't plan to use > printing (and I guess > 90% of the JavaFX don't use the printing API > either but produce PDFs or whatever) and Java-Beans. > > Tom > > Am 27.03.18 um 14:26 schrieb Kevin Rushforth: >> Hi Tom, >> >> Yes, this is an unfortunate dependency. It is "only" an >> implementation dependency, meaning that nothing in the public API >> depends on java.desktop (which is why we don't "requires transient >> java.desktop"), so it should be possible to remove this dependency in >> the future. As noted, it is only there because Java Beans is part of >> the java.desktop module. >> >> In the interim, your suggestion of "requires static java.base" could >> be the way to go. It would need a spec change to the JavaFX beans >> adapter classes documenting that they would throw an >> UnsupportedOperationException if java.desktop was not present at >> runtime, along with a recommendation that applications needing that >> functionality should add "requires java.desktop" to their own >> module-info.java. >> >> Note that this would only help non-graphical JavaFX applications that >> use javafx.base for its collections, properties, and bindings, since >> javafx.graphics requires java.desktop in a way that currently cannot >> easily be made optional (not without reimplementing printing support >> anyway). >> >> -- Kevin >> >> >> Tom Schindl wrote: >>> Hi, >>> >>> Anyone else has an opinion on that? Is require static the way to go? >>> >>> Tom >>> >>> On 21.03.18 23:23, Tom Schindl wrote: >>>> Hi, >>>> >>>> I always thought the JavaFX-Codebase should be able to run with >>>> just the >>>> java.base module but I was browsing the codebase a bit and was >>>> suprised >>>> (or rather shocked) that even the base-module requires java.desktop. >>>> >>>> If I get it correct this because of the java.beans (provided by the >>>> adapters) stuff is found in there. Why hasn't the requires there not >>>> defined as: >>>> >>>> requires static java.desktop; >>>> >>>> Tom >>>> From nlisker at gmail.com Tue May 18 21:42:45 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 19 May 2021 00:42:45 +0300 Subject: Minimum JDK policy for OpenJFX In-Reply-To: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: > > there are some advantages in being able to run with the latest JDK LTS > One *potential* issue with this approach is that LTS is not defined in OpenJDK as far as I know. The LTS versions are a business decision of each distributor. For now, they have all aligned on 8, 11, 17, but nothing guarantees that this will stay so. What if different vendors LTS different versions? Suppose that Valhalla and Loom add very attractive features in JDK 19 (big performance enhancements, leads to big money savings on hardware, leads to economic incentives to use these, leads to requests to support these), now vendors can declare JDK 19 as LTS, and what will JavaFX do? In OpenJDK all versions are treated equally as it is a spec and not a business model. Should JavaFX be coupled to business models? Maybe Gluon has some insights since they give JavaFX LTS support. A second point, as Michael Strau? mentioned, is that maybe we should see what features are going to be delivered in the next versions and judge if there's something attractive enough for library developers to base our decision on. Sealed classes from Amber are certainly one of them. Panama might provide handy features for JavaFX's interfacing with native code, like Foreign Memory Access, though I didn't look into it in detail. Valhalla is certainly too far away to consider, and Loom is rather irrelevant for JavaFX and GUIs in general. If anyone has insights into relevant upcoming features I'll be happy to learn. - Nir On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth wrote: > A very timely question. I was already planning to raise this as a > discussion after we update our boot JDK to JDK 16 (blocked by the > in-progress gradle 7 update), which I hope to do later this week. > > I think that this is the right time to consider bumping the minimum > required version to run JavaFX 17 to JDK 16, which would allow us to > start using APIs and language features from JDK 12 through JDK 16 > inclusive. > > In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In > practice, though, we don't bump it for each release, as there are some > advantages in being able to run with the latest JDK LTS. Since JavaFX 17 > will release at roughly the same time as JDK 17 LTS, I can't think of a > good reason to not update our minimum. > > Comments? > > -- Kevin > > > On 5/18/2021 7:59 AM, Michael Strau? wrote: > > Currently, JDK 11 is required for the latest version of OpenJFX. What > > is the policy for bumping this requirement? Does it always correspond > > to the latest JDK LTS release (the next of which will be JDK 17), or > > is it independent from the release cycle of OpenJDK? > > From kevin.rushforth at oracle.com Tue May 18 22:38:53 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 May 2021 15:38:53 -0700 Subject: [External] : Re: Minimum JDK policy for OpenJFX In-Reply-To: References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: <34340f11-8bb7-7bd6-8110-99ada0eb73be@oracle.com> You raise a good point about whether or not it should matter if a version is (generally considered to be) an LTS release. I wasn't suggesting that we necessarily wait until the next LTS to consider picking up an important new feature, just that it could be one factor. I also would be very interested to hear from Gluon on this point. Your second point is the more interesting one. It comes down to the question of when is there a new feature (or set of new features) that is compelling enough that we want to require that version of the JDK in order to be able to use it. So for this specific discussion: Is there any language feature or API in JDK 12 - 16 that is compelling enough that we would want to bump the JDK in order to be able to use it? -- Kevin On 5/18/2021 2:42 PM, Nir Lisker wrote: > > there are some advantages in being able to run with the latest JDK LTS > > > One *potential* issue with this approach is that LTS is not defined in > OpenJDK as far as I know. The LTS versions are a business decision of > each distributor. For now, they have all aligned on 8, 11, 17, but > nothing guarantees that this will stay so. What if different vendors > LTS different versions? Suppose that Valhalla and Loom add very > attractive features in JDK 19 (big performance enhancements, leads to > big money savings on hardware, leads to economic incentives to use > these, leads to requests to support these), now vendors can declare > JDK 19 as LTS, and what will JavaFX do? > In OpenJDK all versions are treated equally as it is a spec and not a > business model. Should JavaFX be coupled to business models? Maybe > Gluon has some insights since they give JavaFX LTS support. > > A second point, as Michael Strau? mentioned, is that maybe we should > see what features are going to be delivered in the next versions and > judge if there's something attractive enough for library developers to > base our decision on. Sealed classes from Amber are certainly one of > them. Panama might provide handy features for JavaFX's interfacing > with native code, like Foreign Memory Access, though I didn't look > into it in detail. Valhalla is certainly too far away to consider, and > Loom is rather irrelevant for JavaFX and GUIs in general. > If anyone has insights into relevant upcoming features I'll be happy > to learn. > > - Nir > > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth > > wrote: > > A very timely question. I was already planning to raise this as a > discussion after we update our boot JDK to JDK 16 (blocked by the > in-progress gradle 7 update), which I hope to do later this week. > > I think that this is the right time to consider bumping the minimum > required version to run JavaFX 17 to JDK 16, which would allow us to > start using APIs and language features from JDK 12 through JDK 16 > inclusive. > > In general, we only guarantee that JavaFX N runs on JDK N-1 or > later. In > practice, though, we don't bump it for each release, as there are > some > advantages in being able to run with the latest JDK LTS. Since > JavaFX 17 > will release at roughly the same time as JDK 17 LTS, I can't think > of a > good reason to not update our minimum. > > Comments? > > -- Kevin > > > On 5/18/2021 7:59 AM, Michael Strau? wrote: > > Currently, JDK 11 is required for the latest version of OpenJFX. > What > > is the policy for bumping this requirement? Does it always > correspond > > to the latest JDK LTS release (the next of which will be JDK 17), or > > is it independent from the release cycle of OpenJDK? > From ebresie at gmail.com Wed May 19 00:46:22 2021 From: ebresie at gmail.com (Eric Bresie) Date: Tue, 18 May 2021 19:46:22 -0500 Subject: Minimum JDK policy for OpenJFX In-Reply-To: CA+0ynh8sSeut6On1ckwZEz1gexesM77E3Svov1oCpXDdARRfdQ@mail.gmail.com References: CAJEpuXS4CqVhd_LfsAfaUfY-wgRN2T+CCPjNDJcuLmDup-MZEQ@mail.gmail.com 8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com 8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com Message-ID: <9a717b5a-a62e-4e7d-b112-9532b12fc5bb@Erics-iPhone-12-Pro-Max> Are there any deprecated or removed (1) (2) dependencies that could cause problems? (1) https://jdk.java.net/16/release-notes#removed (2) https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005191.html Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On May 18, 2021 at 4:42:45 PM CDT, Nir Lisker wrote: > > > > there are some advantages in being able to run with the latest JDK LTS > > > > One *potential* issue with this approach is that LTS is not defined in > OpenJDK as far as I know. The LTS versions are a business decision of each > distributor. For now, they have all aligned on 8, 11, 17, but nothing > guarantees that this will stay so. What if different vendors LTS different > versions? Suppose that Valhalla and Loom add very attractive features in > JDK 19 (big performance enhancements, leads to big money savings on > hardware, leads to economic incentives to use these, leads to requests to > support these), now vendors can declare JDK 19 as LTS, and what will JavaFX > do? > In OpenJDK all versions are treated equally as it is a spec and not a > business model. Should JavaFX be coupled to business models? Maybe Gluon > has some insights since they give JavaFX LTS support. > > A second point, as Michael Strau? mentioned, is that maybe we should see > what features are going to be delivered in the next versions and judge if > there's something attractive enough for library developers to base our > decision on. Sealed classes from Amber are certainly one of them. Panama > might provide handy features for JavaFX's interfacing with native code, > like Foreign Memory Access, though I didn't look into it in detail. > Valhalla is certainly too far away to consider, and Loom is rather > irrelevant for JavaFX and GUIs in general. > If anyone has insights into relevant upcoming features I'll be happy to > learn. > > - Nir > > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth > wrote: > > > A very timely question. I was already planning to raise this as a > > discussion after we update our boot JDK to JDK 16 (blocked by the > > in-progress gradle 7 update), which I hope to do later this week. > > > > I think that this is the right time to consider bumping the minimum > > required version to run JavaFX 17 to JDK 16, which would allow us to > > start using APIs and language features from JDK 12 through JDK 16 > > inclusive. > > > > In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In > > practice, though, we don't bump it for each release, as there are some > > advantages in being able to run with the latest JDK LTS. Since JavaFX 17 > > will release at roughly the same time as JDK 17 LTS, I can't think of a > > good reason to not update our minimum. > > > > Comments? > > > > -- Kevin > > > > > > On 5/18/2021 7:59 AM, Michael Strau? wrote: > > > Currently, JDK 11 is required for the latest version of OpenJFX. What > > > is the policy for bumping this requirement? Does it always correspond > > > to the latest JDK LTS release (the next of which will be JDK 17), or > > > is it independent from the release cycle of OpenJDK? > > > > From kcr at openjdk.java.net Wed May 19 01:48:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 May 2021 01:48:39 GMT Subject: [jfx11u] RFR: 8266554: Change default macOS min version for aarch64 to 11.0 In-Reply-To: References: Message-ID: On Tue, 18 May 2021 20:05:03 GMT, Johan Vos wrote: > Require at least MacOSX 11.0 to build on mac-AArch64. > Don't increase minimum SDK version when building on x86-64 (contrary to JDK-8265031) Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx11u/pull/21 From nlisker at gmail.com Wed May 19 05:36:38 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 19 May 2021 08:36:38 +0300 Subject: Build error with gradle (command line) In-Reply-To: <20210511124353.Horde.Dik7tUKfsYEvNQQuLBHRZw8@webmail.df.eu> References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> <20210511124353.Horde.Dik7tUKfsYEvNQQuLBHRZw8@webmail.df.eu> Message-ID: I'm getting this error in Eclipse when it tries to load the tasks, but in the command line I can build and test. I already refreshed the dependencies and cleaned the cache. Did you solve this in Eclipse? On Tue, May 11, 2021 at 1:44 PM Jeanette Winzenburg wrote: > > Thanks Johan, Ajit > > --refresh-dependencies did it .. nearly ;) > > now the error is down to: > > * What went wrong: > Execution failed for task ':base:compileTestJava'. > Dependency verification failed for configuration > ':base:testCompileClasspath' > One artifact failed verification: junit-4.8.2.pom > (junit:junit:4.8.2) from repository MavenRepo > This can indicate that a dependency has been compromised. Please > carefully verify the checksums. > > .. will cleanup the gradle cache and see what happens (all these > complete builds take some time, my machine is not the fastest, to put > it mildly) > > > > Zitat von Ajit Ghaisas : > > > Hi Jeanette, > > > > I had faced this on my local system last week. > > Although the root cause is unknown - "gradle > > --refresh-dependencies? command had helped to get rid of this error. > > > > I did not pursue it as this error is not seen in our CI builds. > > > > Regards, > > Ajit > > > >> On 11-May-2021, at 2:58 PM, Jeanette Winzenburg > >> wrote: > >> > >> > >> Just sync'ed my local repository with upstream .. now can't build > >> with gradle, the error: > >> > >> * Where: > >> Build file > >> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > line: > >> 4249 > >> > >> * What went wrong: > >> A problem occurred evaluating root project 'jfx-fork'. > >>> Dependency verification failed for configuration ':apps:lucene' > >> 8 artifacts failed verification: > >> - apache-13.pom (org.apache:apache:13) from repository MavenRepo > >> - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) > >> from repository MavenRepo > >> - lucene-grouping-7.7.3.pom > >> (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo > >> - lucene-parent-7.7.3.pom > >> (org.apache.lucene:lucene-parent:7.7.3) from repository MavenRepo > >> - lucene-queries-7.7.3.pom > >> (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo > >> - lucene-queryparser-7.7.3.pom > >> (org.apache.lucene:lucene-queryparser:7.7.3) from repository > >> MavenRepo > >> - lucene-sandbox-7.7.3.pom > >> (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo > >> - lucene-solr-grandparent-7.7.3.pom > >> (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository > >> MavenRepo > >> This can indicate that a dependency has been compromised. Please > >> carefully verify the checksums. > >> > >> Looks like I have to update some local files, shouldn't that happen > >> automagically? > >> > >> -- Jeanette > >> > >> > > > > From jvos at openjdk.java.net Wed May 19 06:16:43 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 19 May 2021 06:16:43 GMT Subject: [jfx11u] Integrated: 8266554: Change default macOS min version for aarch64 to 11.0 In-Reply-To: References: Message-ID: On Tue, 18 May 2021 20:05:03 GMT, Johan Vos wrote: > Require at least MacOSX 11.0 to build on mac-AArch64. > Don't increase minimum SDK version when building on x86-64 (contrary to JDK-8265031) This pull request has now been integrated. Changeset: 8805e436 Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/8805e436c9eb8a622a4ec7b6f2a168ec5b713d81 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8266554: Change default macOS min version for aarch64 to 11.0 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx11u/pull/21 From fastegal at swingempire.de Wed May 19 10:26:33 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 19 May 2021 12:26:33 +0200 Subject: Build error with gradle (command line) In-Reply-To: References: <20210511112855.Horde.OGBtBBvvJa9O9p7kuKhunw3@webmail.df.eu> <20210511124353.Horde.Dik7tUKfsYEvNQQuLBHRZw8@webmail.df.eu> Message-ID: <20210519122633.Horde.8pdCRtTAE8WY2VdUv5oBfw5@webmail.df.eu> Zitat von Nir Lisker : > I'm getting this error in Eclipse when it tries to load the tasks, but in > the command line I can build and test. I already refreshed the dependencies > and cleaned the cache. > > Did you solve this in Eclipse? > I'm not using gradle inside Eclipse: its build remained working fine, it was just the commandline in cygwin. > On Tue, May 11, 2021 at 1:44 PM Jeanette Winzenburg > wrote: > >> >> Thanks Johan, Ajit >> >> --refresh-dependencies did it .. nearly ;) >> >> now the error is down to: >> >> * What went wrong: >> Execution failed for task ':base:compileTestJava'. >> Dependency verification failed for configuration >> ':base:testCompileClasspath' >> One artifact failed verification: junit-4.8.2.pom >> (junit:junit:4.8.2) from repository MavenRepo >> This can indicate that a dependency has been compromised. Please >> carefully verify the checksums. >> >> .. will cleanup the gradle cache and see what happens (all these >> complete builds take some time, my machine is not the fastest, to put >> it mildly) >> >> >> >> Zitat von Ajit Ghaisas : >> >> > Hi Jeanette, >> > >> > I had faced this on my local system last week. >> > Although the root cause is unknown - "gradle >> > --refresh-dependencies? command had helped to get rid of this error. >> > >> > I did not pursue it as this error is not seen in our CI builds. >> > >> > Regards, >> > Ajit >> > >> >> On 11-May-2021, at 2:58 PM, Jeanette Winzenburg >> >> wrote: >> >> >> >> >> >> Just sync'ed my local repository with upstream .. now can't build >> >> with gradle, the error: >> >> >> >> * Where: >> >> Build file >> >> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' >> line: >> >> 4249 >> >> >> >> * What went wrong: >> >> A problem occurred evaluating root project 'jfx-fork'. >> >>> Dependency verification failed for configuration ':apps:lucene' >> >> 8 artifacts failed verification: >> >> - apache-13.pom (org.apache:apache:13) from repository MavenRepo >> >> - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) >> >> from repository MavenRepo >> >> - lucene-grouping-7.7.3.pom >> >> (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo >> >> - lucene-parent-7.7.3.pom >> >> (org.apache.lucene:lucene-parent:7.7.3) from repository MavenRepo >> >> - lucene-queries-7.7.3.pom >> >> (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo >> >> - lucene-queryparser-7.7.3.pom >> >> (org.apache.lucene:lucene-queryparser:7.7.3) from repository >> >> MavenRepo >> >> - lucene-sandbox-7.7.3.pom >> >> (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo >> >> - lucene-solr-grandparent-7.7.3.pom >> >> (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository >> >> MavenRepo >> >> This can indicate that a dependency has been compromised. Please >> >> carefully verify the checksums. >> >> >> >> Looks like I have to update some local files, shouldn't that happen >> >> automagically? >> >> >> >> -- Jeanette >> >> >> >> >> >> >> >> From kevin.rushforth at oracle.com Wed May 19 11:39:24 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 May 2021 04:39:24 -0700 Subject: Minimum JDK policy for OpenJFX In-Reply-To: <9a717b5a-a62e-4e7d-b112-9532b12fc5bb@Erics-iPhone-12-Pro-Max> References: <9a717b5a-a62e-4e7d-b112-9532b12fc5bb@Erics-iPhone-12-Pro-Max> Message-ID: <80a15077-e980-66c3-5f84-c202c0f3a26f@oracle.com> No. I've already done a full build and test using JDK 16 (and a full build using JDK 17 ea for that matter). -- Kevin On 5/18/2021 5:46 PM, Eric Bresie wrote: > Are there any deprecated or removed (1) (2) dependencies that could cause problems? > > (1) https://jdk.java.net/16/release-notes#removed > (2) https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005191.html > > Eric Bresie > Ebresie at gmail.com (mailto:Ebresie at gmail.com) > >> On May 18, 2021 at 4:42:45 PM CDT, Nir Lisker wrote: >>> there are some advantages in being able to run with the latest JDK LTS >>> >> One *potential* issue with this approach is that LTS is not defined in >> OpenJDK as far as I know. The LTS versions are a business decision of each >> distributor. For now, they have all aligned on 8, 11, 17, but nothing >> guarantees that this will stay so. What if different vendors LTS different >> versions? Suppose that Valhalla and Loom add very attractive features in >> JDK 19 (big performance enhancements, leads to big money savings on >> hardware, leads to economic incentives to use these, leads to requests to >> support these), now vendors can declare JDK 19 as LTS, and what will JavaFX >> do? >> In OpenJDK all versions are treated equally as it is a spec and not a >> business model. Should JavaFX be coupled to business models? Maybe Gluon >> has some insights since they give JavaFX LTS support. >> >> A second point, as Michael Strau? mentioned, is that maybe we should see >> what features are going to be delivered in the next versions and judge if >> there's something attractive enough for library developers to base our >> decision on. Sealed classes from Amber are certainly one of them. Panama >> might provide handy features for JavaFX's interfacing with native code, >> like Foreign Memory Access, though I didn't look into it in detail. >> Valhalla is certainly too far away to consider, and Loom is rather >> irrelevant for JavaFX and GUIs in general. >> If anyone has insights into relevant upcoming features I'll be happy to >> learn. >> >> - Nir >> >> On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth >> wrote: >> >>> A very timely question. I was already planning to raise this as a >>> discussion after we update our boot JDK to JDK 16 (blocked by the >>> in-progress gradle 7 update), which I hope to do later this week. >>> >>> I think that this is the right time to consider bumping the minimum >>> required version to run JavaFX 17 to JDK 16, which would allow us to >>> start using APIs and language features from JDK 12 through JDK 16 >>> inclusive. >>> >>> In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In >>> practice, though, we don't bump it for each release, as there are some >>> advantages in being able to run with the latest JDK LTS. Since JavaFX 17 >>> will release at roughly the same time as JDK 17 LTS, I can't think of a >>> good reason to not update our minimum. >>> >>> Comments? >>> >>> -- Kevin >>> >>> >>> On 5/18/2021 7:59 AM, Michael Strau? wrote: >>>> Currently, JDK 11 is required for the latest version of OpenJFX. What >>>> is the policy for bumping this requirement? Does it always correspond >>>> to the latest JDK LTS release (the next of which will be JDK 17), or >>>> is it independent from the release cycle of OpenJDK? >>> From kevin.rushforth at oracle.com Wed May 19 12:00:43 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 May 2021 05:00:43 -0700 Subject: [External] : Re: Minimum JDK policy for OpenJFX In-Reply-To: References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: I missed seeing this reply yesterday. We can't bump the minimum to JDK 17 until at least JavaFX 18 without changing our policy that JavaFX N is able to build and run with JDK N-1. If we were to change that we would also need to delay our release to be after JDK 17 date (currently JavaFX N is released a week ahead of JDK N). Also, there are technical challenges building with the JDK 17 EA as a moving target (at least for the next few weeks) that we would need to deal with. In summary, I would not want to propose this. -- Kevin On 5/18/2021 8:33 AM, Michael Strau? wrote: > Sounds good, although it is a bit unfortunate that sealed classes will > only be un-previewed in JDK 17. I think this feature has great value > for reasoning about code, in particular for library development. Do > you think we could bump it directly to JDK 17, which I think is very > fitting because it's the next LTS release, after all. > > Am Di., 18. Mai 2021 um 17:17 Uhr schrieb Kevin Rushforth > : >> A very timely question. I was already planning to raise this as a >> discussion after we update our boot JDK to JDK 16 (blocked by the >> in-progress gradle 7 update), which I hope to do later this week. >> >> I think that this is the right time to consider bumping the minimum >> required version to run JavaFX 17 to JDK 16, which would allow us to >> start using APIs and language features from JDK 12 through JDK 16 inclusive. >> >> In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In >> practice, though, we don't bump it for each release, as there are some >> advantages in being able to run with the latest JDK LTS. Since JavaFX 17 >> will release at roughly the same time as JDK 17 LTS, I can't think of a >> good reason to not update our minimum. >> >> Comments? >> >> -- Kevin >> >> >> On 5/18/2021 7:59 AM, Michael Strau? wrote: >>> Currently, JDK 11 is required for the latest version of OpenJFX. What >>> is the policy for bumping this requirement? Does it always correspond >>> to the latest JDK LTS release (the next of which will be JDK 17), or >>> is it independent from the release cycle of OpenJDK? From kcr at openjdk.java.net Wed May 19 14:04:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 May 2021 14:04:54 GMT Subject: RFR: 8267392: ENTER key press on editable TableView throws NPE In-Reply-To: References: Message-ID: <8Esb01VIM_RC4cVXYfS0H5Cic6rUIaloikvfOA33sKs=.d9e46c0d-929a-4089-b64c-2335dcf8e0d7@github.com> On Wed, 19 May 2021 00:48:18 GMT, Marius Hanl wrote: > **Note: I reported the bug already, waiting for approval. Internal tracking id: 9070318. I will update the title as soon as the ticket is created.** > > This PR is fixing a NP, which is thrown when you press ENTER on an editbale table, after it is initially shown. > > When pressing ENTER, **TableViewBehaviorBase#activate** is retrieving the current focused row (**getFocusedCell()**) and from there the corresponding table column. > This is null, when a table is initially shown. It can also be null, when the items from the underlying table are changed (e.g. **setItems()**) or when **getFocusModel().focus(row)** is used. > Therefore, null is a valid value and we should guard against it. The fix looks simple and safe enough. I'll let @aghaisas and @kleopatra review it. I left one naming comment, which also applies to the PR title (I already updated the JBS bug title). The bug has been transferred to JDK project: https://bugs.openjdk.java.net/browse/JDK-8267392 modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewKeyInputTest.java line 196: > 194: > 195: @Test > 196: public void testEnterOnFocusedRowDoesNotThrowNP() { The usual abbreviation for NullPointerException is `NPE` rather than `NP`, so I recommend updating the test method names and comments accordingly. ------------- PR: https://git.openjdk.java.net/jfx/pull/505 From fastegal at openjdk.java.net Wed May 19 14:04:55 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 19 May 2021 14:04:55 GMT Subject: RFR: 8267392: ENTER key press on editable TableView throws NPE In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:48:18 GMT, Marius Hanl wrote: > **Note: I reported the bug already, waiting for approval. Internal tracking id: 9070318. I will update the title as soon as the ticket is created.** > > This PR is fixing a NP, which is thrown when you press ENTER on an editbale table, after it is initially shown. > > When pressing ENTER, **TableViewBehaviorBase#activate** is retrieving the current focused row (**getFocusedCell()**) and from there the corresponding table column. > This is null, when a table is initially shown. It can also be null, when the items from the underlying table are changed (e.g. **setItems()**) or when **getFocusModel().focus(row)** is used. > Therefore, null is a valid value and we should guard against it. sounds like a duplicate of [JDK-8089652](https://bugs.openjdk.java.net/browse/JDK-8089652) - faintly remember that it's a dark pit: there are issues in selection/focus model implementations, see f.i. [JDK-8219720](https://bugs.openjdk.java.net/browse/JDK-8219720). Starting with fixing the NPE is goood :)) ------------- PR: https://git.openjdk.java.net/jfx/pull/505 From github.com+66004280+maran23 at openjdk.java.net Wed May 19 14:04:54 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 19 May 2021 14:04:54 GMT Subject: RFR: 8267392: ENTER key press on editable TableView throws NPE Message-ID: **Note: I reported the bug already, waiting for approval. Internal tracking id: 9070318. I will update the title as soon as the ticket is created.** This PR is fixing a NP, which is thrown when you press ENTER on an editbale table, after it is initially shown. When pressing ENTER, **TableViewBehaviorBase#activate** is retrieving the current focused row (**getFocusedCell()**) and from there the corresponding table column. This is null, when a table is initially shown. It can also be null, when the items from the underlying table are changed (e.g. **setItems()**) or when **getFocusModel().focus(row)** is used. Therefore, null is a valid value and we should guard against it. ------------- Commit messages: - Fixed NP when ENTER is pressed on an editable table Changes: https://git.openjdk.java.net/jfx/pull/505/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=505&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267392 Stats: 39 lines in 3 files changed: 33 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/505.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/505/head:pull/505 PR: https://git.openjdk.java.net/jfx/pull/505 From github.com+66004280+maran23 at openjdk.java.net Wed May 19 14:08:48 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 19 May 2021 14:08:48 GMT Subject: RFR: 8267392: ENTER key press on editable TableView throws NPE In-Reply-To: References: Message-ID: On Wed, 19 May 2021 11:03:52 GMT, Jeanette Winzenburg wrote: > > > sounds like a duplicate of [JDK-8089652](https://bugs.openjdk.java.net/browse/JDK-8089652) - faintly remember that it's a dark pit: there are issues in selection/focus model implementations, see f.i. [JDK-8219720](https://bugs.openjdk.java.net/browse/JDK-8219720). Starting with fixing the NPE is goood :)) Should I add this issue to this PR then? I'm not sure, as with my fix, ENTER won't start editing the cell still. This is due the whole row is initially focused, not a particular cell (getFocusModel().focus(row) -> no table column will be set inside the focused cell table position). The only difference you will see, when pressing ENTER, is a change from the focused state (this light blue border) to the selected state (row is highlighted blue) and of course no NPE inside the console. ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/505 From github.com+66004280+maran23 at openjdk.java.net Wed May 19 14:15:00 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 19 May 2021 14:15:00 GMT Subject: RFR: 8267392: ENTER key press on editable TableView throws NPE [v2] In-Reply-To: References: Message-ID: > ~~Note: I reported the bug already, waiting for approval. Internal tracking id: 9070318. I will update the title as soon as the ticket is created.~~ > EDIT: Changed the title. :) > > This PR is fixing a NP, which is thrown when you press ENTER on an editbale table, after it is initially shown. > > When pressing ENTER, **TableViewBehaviorBase#activate** is retrieving the current focused row (**getFocusedCell()**) and from there the corresponding table column. > This is null, when a table is initially shown. It can also be null, when the items from the underlying table are changed (e.g. **setItems()**) or when **getFocusModel().focus(row)** is used. > Therefore, null is a valid value and we should guard against it. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Addressed review comment (changed from NP to NPE) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/505/files - new: https://git.openjdk.java.net/jfx/pull/505/files/1b0cf0ed..89e65ccd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=505&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=505&range=00-01 Stats: 18 lines in 2 files changed: 7 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/505.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/505/head:pull/505 PR: https://git.openjdk.java.net/jfx/pull/505 From github.com+66004280+maran23 at openjdk.java.net Wed May 19 14:15:01 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 19 May 2021 14:15:01 GMT Subject: RFR: 8267392: ENTER key press on editable TableView throws NPE [v2] In-Reply-To: <8Esb01VIM_RC4cVXYfS0H5Cic6rUIaloikvfOA33sKs=.d9e46c0d-929a-4089-b64c-2335dcf8e0d7@github.com> References: <8Esb01VIM_RC4cVXYfS0H5Cic6rUIaloikvfOA33sKs=.d9e46c0d-929a-4089-b64c-2335dcf8e0d7@github.com> Message-ID: <-ab0c21sdQtLtZ0WxQhyG0XKkK25MPOrPIuIDoYaqiw=.bf3c4057-3ca9-43f1-b1a3-398027bf166e@github.com> On Wed, 19 May 2021 12:15:55 GMT, Kevin Rushforth wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comment (changed from NP to NPE) > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewKeyInputTest.java line 196: > >> 194: >> 195: @Test >> 196: public void testEnterOnFocusedRowDoesNotThrowNP() { > > The usual abbreviation for NullPointerException is `NPE` rather than `NP`, so I recommend updating the test method names and comments accordingly. You are right, my bad. Fixed it. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/505 From kcr at openjdk.java.net Wed May 19 14:19:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 May 2021 14:19:45 GMT Subject: RFR: 8267392: ENTER key press on editable TableView throws NPE In-Reply-To: References: Message-ID: On Wed, 19 May 2021 14:06:21 GMT, Marius Hanl wrote: > > sounds like a duplicate of [JDK-8089652](https://bugs.openjdk.java.net/browse/JDK-8089652) - faintly remember that it's a dark pit: there are issues in selection/focus model implementations, see f.i. [JDK-8219720](https://bugs.openjdk.java.net/browse/JDK-8219720). Starting with fixing the NPE is goood :)) > > Should I add this issue to this PR then? I'm not sure, as with my fix, ENTER won't start editing the cell still. No. While this fixes the NPE noted in [JDK-8089652](https://bugs.openjdk.java.net/browse/JDK-8089652), it doesn't fix all of the problems described in that bug. ------------- PR: https://git.openjdk.java.net/jfx/pull/505 From johan.vos at gluonhq.com Wed May 19 14:35:49 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 19 May 2021 16:35:49 +0200 Subject: [External] : Re: Minimum JDK policy for OpenJFX In-Reply-To: <34340f11-8bb7-7bd6-8110-99ada0eb73be@oracle.com> References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> <34340f11-8bb7-7bd6-8110-99ada0eb73be@oracle.com> Message-ID: Hi, This is an important and good discussion, and I've read a number of valid points. To reiterate what I've always stated: * we don't want to increase the base (JDK) version just for the sake of increasing * we don't want to lose significant benefits (or developer productivity) by sticking with old versions. This comes down to the question that is indeed the most important: are there *language* features in JDK 12 or higher that would improve the quality of OpenJFX? Clearly we're not talking about runtime improvements, as it's up to the developer/use to choose a runtime. Personally, I don't see many possible huge improvements in the JavaFX API by using JDK 12+ features, but I might be missing things. Related to the LTS discussion (disclaimer: just my personal opinion here, not an "official" Gluon statement): I don't see that as the primary reason for bumping the dependency. The thing we want to avoid though is that there is a jump in the required Java SDK inside an LTS family (e.g. JavaFX 11 has Java 11 as its base, and JavaFX 11.0.12 will have Java 11 as its base as well). This might become harder in the future, as I can imagine Valhalla having a bigger impact on OpenJFX then e.g. Loom. Hence, in case 17 is an LTS version and it starts being based on Java 11, and in case we decide to bump the base level for JavaFX 20 to e.g. Java 19, it might become much harder to backport issues into the 17-tree. In that spirit, it would make sense to bump the version for 17, but it seems a bit artificial as the major new language benefits (to OpenJFX) in the JDK might occur in between 2 LTS families. - Johan On Wed, May 19, 2021 at 12:39 AM Kevin Rushforth wrote: > You raise a good point about whether or not it should matter if a > version is (generally considered to be) an LTS release. I wasn't > suggesting that we necessarily wait until the next LTS to consider > picking up an important new feature, just that it could be one factor. I > also would be very interested to hear from Gluon on this point. > > Your second point is the more interesting one. It comes down to the > question of when is there a new feature (or set of new features) that is > compelling enough that we want to require that version of the JDK in > order to be able to use it. > > So for this specific discussion: Is there any language feature or API in > JDK 12 - 16 that is compelling enough that we would want to bump the JDK > in order to be able to use it? > > -- Kevin > > > On 5/18/2021 2:42 PM, Nir Lisker wrote: > > > > there are some advantages in being able to run with the latest JDK > LTS > > > > > > One *potential* issue with this approach is that LTS is not defined in > > OpenJDK as far as I know. The LTS versions are a business decision of > > each distributor. For now, they have all aligned on 8, 11, 17, but > > nothing guarantees that this will stay so. What if different vendors > > LTS different versions? Suppose that Valhalla and Loom add very > > attractive features in JDK 19 (big performance enhancements, leads to > > big money savings on hardware, leads to economic incentives to use > > these, leads to requests to support these), now vendors can declare > > JDK 19 as LTS, and what will JavaFX do? > > In OpenJDK all versions are treated equally as it is a spec and not a > > business model. Should JavaFX be coupled to business models? Maybe > > Gluon has some insights since they give JavaFX LTS support. > > > > A second point, as Michael Strau? mentioned, is that maybe we should > > see what features are going to be delivered in the next versions and > > judge if there's something attractive enough for library developers to > > base our decision on. Sealed classes from Amber are certainly one of > > them. Panama might provide handy features for JavaFX's interfacing > > with native code, like Foreign Memory Access, though I didn't look > > into it in detail. Valhalla is certainly too far away to consider, and > > Loom is rather irrelevant for JavaFX and GUIs in general. > > If anyone has insights into relevant upcoming features I'll be happy > > to learn. > > > > - Nir > > > > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth > > > wrote: > > > > A very timely question. I was already planning to raise this as a > > discussion after we update our boot JDK to JDK 16 (blocked by the > > in-progress gradle 7 update), which I hope to do later this week. > > > > I think that this is the right time to consider bumping the minimum > > required version to run JavaFX 17 to JDK 16, which would allow us to > > start using APIs and language features from JDK 12 through JDK 16 > > inclusive. > > > > In general, we only guarantee that JavaFX N runs on JDK N-1 or > > later. In > > practice, though, we don't bump it for each release, as there are > > some > > advantages in being able to run with the latest JDK LTS. Since > > JavaFX 17 > > will release at roughly the same time as JDK 17 LTS, I can't think > > of a > > good reason to not update our minimum. > > > > Comments? > > > > -- Kevin > > > > > > On 5/18/2021 7:59 AM, Michael Strau? wrote: > > > Currently, JDK 11 is required for the latest version of OpenJFX. > > What > > > is the policy for bumping this requirement? Does it always > > correspond > > > to the latest JDK LTS release (the next of which will be JDK 17), > or > > > is it independent from the release cycle of OpenJDK? > > > > From tom.schindl at bestsolution.at Wed May 19 14:52:49 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 19 May 2021 16:52:49 +0200 Subject: .classpath files for Eclipse Message-ID: <2076b439-9bb2-d07a-77b1-3f9b4f5ce299@bestsolution.at> Hi Nir/Jeannette, As you are both using Eclipse for development I'd like to get your take on the following things. Dealing with OS specific ------------------------ The graphics module has to have different source folders depending on the OS you are developing on: * Windows: build/hlsl/Decora and build/hslPrism * Linux/OS-X: build/gensrc/jsl-decora build/gensrc/jsl-prism So when importing the projects Eclipse does not even build anything until you fix the .classpath file - I'd like to propose to mark those Source-Folders optional. Swing-Project ------------- There the .classpath has a none existing "src/test/java" I wonder where that source is and if not there anymore remove the offending entry from .classpath-File BuildSrc -------- What's the purpose of that project? The classpath is incorrect and does it have to be a Java-Project? Tom From kevin.rushforth at oracle.com Wed May 19 15:16:29 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 May 2021 08:16:29 -0700 Subject: [External] : Re: Minimum JDK policy for OpenJFX In-Reply-To: References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> <34340f11-8bb7-7bd6-8110-99ada0eb73be@oracle.com> Message-ID: <568b5a38-006e-9fc8-2687-950a4dcb1e0c@oracle.com> These are all excellent points. I would add that while a new language feature would be the biggest reason to update, there could be new JDK API that we would want to use as an argument type or return type in a new FX API. I'm not aware of any in the JDK 12-16 range (at least not ones that don't also have language changes such as records), but it has happened before. So taking all of this into account, it seems that unless someone wants to make an argument for a feature (language or API) from JDK 12 or later that we need to use in JavaFX 17, it seems unlikely that we will bump the minimum. -- Kevin On 5/19/2021 7:35 AM, Johan Vos wrote: > Hi, > > This is an important and good discussion, and I've read a number of > valid points. To reiterate what I've always stated: > * we don't want to increase the base (JDK) version just for the sake > of increasing > * we don't want to lose significant benefits (or developer > productivity) by sticking with old versions. > > This comes down to the question that is indeed the most important: are > there *language* features in JDK 12 or higher that would improve the > quality of OpenJFX? Clearly we're not talking about runtime > improvements, as it's up to the developer/use to choose a runtime. > > Personally, I don't see many possible huge improvements in the JavaFX > API by using JDK 12+ features, but I might be missing things. > > Related to the LTS discussion (disclaimer: just my personal opinion > here, not an "official" Gluon statement): I don't see that as the > primary reason for bumping the dependency. The thing we want to avoid > though is that there is a jump in the required Java SDK inside an LTS > family (e.g. JavaFX 11 has Java 11 as its base, and JavaFX 11.0.12 > will have Java 11 as its base as well). > This might become harder in the future, as I can imagine Valhalla > having a bigger impact on OpenJFX then e.g. Loom. Hence, in case 17 is > an LTS version and it starts being based on Java 11, and in case we > decide to bump the base level for JavaFX 20 to e.g. Java 19, it might > become much harder to backport issues into the 17-tree. > In that spirit, it would make sense to bump the version for 17, but it > seems a bit artificial as the major new language benefits (to OpenJFX) > in the JDK might occur in between 2 LTS families. > > - Johan > > > On Wed, May 19, 2021 at 12:39 AM Kevin Rushforth > > wrote: > > You raise a good point about whether or not it should matter if a > version is (generally considered to be) an LTS release. I wasn't > suggesting that we necessarily wait until the next LTS to consider > picking up an important new feature, just that it could be one > factor. I > also would be very interested to hear from Gluon on this point. > > Your second point is the more interesting one. It comes down to the > question of when is there a new feature (or set of new features) > that is > compelling enough that we want to require that version of the JDK in > order to be able to use it. > > So for this specific discussion: Is there any language feature or > API in > JDK 12 - 16 that is compelling enough that we would want to bump > the JDK > in order to be able to use it? > > -- Kevin > > > On 5/18/2021 2:42 PM, Nir Lisker wrote: > > > >? ? ?there are some advantages in being able to run with the > latest JDK LTS > > > > > > One *potential* issue with this approach is that LTS is not > defined in > > OpenJDK as far as I know. The LTS versions are a business > decision of > > each distributor. For now, they have all aligned on 8, 11, 17, but > > nothing guarantees that this will stay so. What if different > vendors > > LTS different versions? Suppose that Valhalla and Loom add very > > attractive features in JDK 19 (big performance enhancements, > leads to > > big money savings on hardware, leads to economic incentives to use > > these, leads to requests to support these), now vendors can declare > > JDK 19 as LTS, and what will JavaFX do? > > In OpenJDK all versions are treated equally as it is a spec and > not a > > business model. Should JavaFX be coupled to business models? Maybe > > Gluon has some insights since they give JavaFX LTS support. > > > > A second point, as Michael Strau? mentioned, is that maybe we > should > > see what features are going to be delivered in the next versions > and > > judge if there's something attractive enough for library > developers to > > base our decision on. Sealed classes from Amber are certainly > one of > > them. Panama might provide handy features for JavaFX's interfacing > > with native code, like Foreign Memory Access, though I didn't look > > into it in detail. Valhalla is certainly too far away to > consider, and > > Loom is rather irrelevant for JavaFX and GUIs in general. > > If anyone has insights into relevant upcoming features I'll be > happy > > to learn. > > > > - Nir > > > > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth > > > >> wrote: > > > >? ? ?A very timely question. I was already planning to raise this > as a > >? ? ?discussion after we update our boot JDK to JDK 16 (blocked > by the > >? ? ?in-progress gradle 7 update), which I hope to do later this > week. > > > >? ? ?I think that this is the right time to consider bumping the > minimum > >? ? ?required version to run JavaFX 17 to JDK 16, which would > allow us to > >? ? ?start using APIs and language features from JDK 12 through > JDK 16 > >? ? ?inclusive. > > > >? ? ?In general, we only guarantee that JavaFX N runs on JDK N-1 or > >? ? ?later. In > >? ? ?practice, though, we don't bump it for each release, as > there are > >? ? ?some > >? ? ?advantages in being able to run with the latest JDK LTS. Since > >? ? ?JavaFX 17 > >? ? ?will release at roughly the same time as JDK 17 LTS, I can't > think > >? ? ?of a > >? ? ?good reason to not update our minimum. > > > >? ? ?Comments? > > > >? ? ?-- Kevin > > > > > >? ? ?On 5/18/2021 7:59 AM, Michael Strau? wrote: > >? ? ?> Currently, JDK 11 is required for the latest version of > OpenJFX. > >? ? ?What > >? ? ?> is the policy for bumping this requirement? Does it always > >? ? ?correspond > >? ? ?> to the latest JDK LTS release (the next of which will be > JDK 17), or > >? ? ?> is it independent from the release cycle of OpenJDK? > > > From arapte at openjdk.java.net Wed May 19 15:23:41 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 19 May 2021 15:23:41 GMT Subject: RFR: 8263760: Update gradle to version 7.0.1 [v2] In-Reply-To: References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: On Thu, 13 May 2021 21:55:59 GMT, Kevin Rushforth wrote: >> This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. >> >> In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. >> >> I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. >> >> ### Notes to Reviewers: >> >> The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. >> >> The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: >> >> 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed >> 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` >> 3. Added missing `@Input` annotation to custom Groovy task properties >> 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) >> >> >> The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: >> >> 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` >> 2. Updated the gradle version in `build.properties` to `7.0.1` >> 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Revert auto-generated change to DEFAULT_JVM_OPTS in gradlew scripts" > > This reverts commit 0b70d096055f5b5c892f052d5eee54da357eab63. Looks good to me. Verified build and test execution on mac and windows machine. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/498 From kcr at openjdk.java.net Wed May 19 16:17:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 May 2021 16:17:45 GMT Subject: Integrated: 8263760: Update gradle to version 7.0.1 In-Reply-To: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> References: <_zvi7IyxtPQ8f50q7ZM1wQ7mcU9fQggqtCXo9r-0tcE=.5fe2c2a5-411b-4c20-bdcc-416ee057856b@github.com> Message-ID: <4lHVwdQLT2mQGz403lM5UdGBa1WwA34bsl9HK2GAwQQ=.cebfb5bd-eebc-4c74-ba16-db83b0611cbe@github.com> On Wed, 12 May 2021 14:54:09 GMT, Kevin Rushforth wrote: > This PR fixes the gradle deprecation warnings described in [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates the JavaFX build to use gradle 7.0.1 as described in [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum version of gradle is set to 6.3. > > In addition to keeping gradle up to date, updating to gradle 7 will allow building and testing JavaFX with JDK 16. > > I have done a full build and test on all three platforms, comparing the artifacts produced before and after this change. > > ### Notes to Reviewers: > > The PR branch has two separate commits, one for each fix, in case reviewers want to look at them separately. As always, they will be squashed into a single commit when integrated. Both bug IDs will be listed in the commit. > > The following changes were done for [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate the use of deprecated features removed in gradle 7: > > 1. Replaced `compile` with either `implementation` or `compileClasspath` as needed > 2. Replaced obsolete `archiveName` and `destinationDir` properties in archive tasks with `archiveFileName` and `destinationDirectory` > 3. Added missing `@Input` annotation to custom Groovy task properties > 4. Bumped the minimum version of gradle to 6.3 (which we have been using for more than 1 year) > > > The following changes were done for [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to gradle 7.0.1: > > 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1` > 2. Updated the gradle version in `build.properties` to `7.0.1` > 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties` This pull request has now been integrated. Changeset: 111bac41 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/111bac4180a646662a81223bdbb56880789d5a90 Stats: 147 lines in 13 files changed: 45 ins; 5 del; 97 mod 8263760: Update gradle to version 7.0.1 8240336: JavaFX build uses deprecated features that will be removed in gradle 7 Reviewed-by: sykora, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/498 From tom.schindl at bestsolution.at Wed May 19 17:20:41 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 19 May 2021 19:20:41 +0200 Subject: [External] : Re: Dependencies on java.desktop In-Reply-To: References: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> <5ABA3874.10405@oracle.com> <9ca3397c-7e91-381c-9df7-da6c792a16c1@bestsolution.at> Message-ID: <82497ed5-790b-25a6-74d7-2879c33fe8d7@bestsolution.at> Hi, Well I looked a bit closer now and the situation and you are right. I think need to do that one by one. I think getting rid of HostServices::showDocument is quite easy as the code in Java-AWT is just 1 JNI-Method so copying that to OpenJFX should be fairly easy. Now on the printing story which is the real problem a fairly radical approach would be to split up javafx.graphics into multiple modules and make javafx.graphics a META-Module who provides the backward compat using "requires transitive". We would end up with: * javafx.graphics * javafx.graphics.base * javafx.graphics.print * javafx.graphics.prism.base * javafx.graphics.prism.j2d * javafx.graphics.prism.es2 * javafx.graphics.prism.d3d * javafx.graphics.glass.base * javafx.graphics.glass.win32 * javafx.graphics.glass.mac * ... I know that sounds radical but from a pure architectual point of view this would be better than optional features in javafx.graphics and would not require us to reimplement printing to get rid of java.desktop. Out of curiosity I tried that locally and it just works ;-) Tom Am 18.05.21 um 23:40 schrieb Kevin Rushforth: > As noted in the thread you quoted below, removing the dependency on > java.desktop from javafx.base isn't a particularly hard problem, and is > tracked by JDK-8240844 [1]. And even though it will require a spec > change (meaning a CSR), it doesn't result in any loss of functionality, > since in order to usefully do anything with the JavaBeanXxxxx classes > requires java.desktop anyway. > > Removing the dependency on java.desktop from javafx.graphics is a larger > issue because of printing. There is also an implementation dependency on > the Desktop class to implement HostServices::showDocument that would > need to be redone. And of course it depends on the above (eliminating > the dependency from javafx.base) being done first. > > For printing we would need to do one of two things: > > 1. Eliminate the implementation dependency on the Java2D printing code. > This is a large effort, but would preserve existing functionality. > > 2. Make the JavaFX Printing function "optional" (i.e., make it a > "ConditionalFeature"), such that if java.desktop is not present, > printing doesn't work (all of the printing APIs would throw an > UnsupportedOperationException if java.desktop is not available). An > application that wants to do printing would need to include java.desktop. > > Option 1 would be my preferred approach, but as mentioned above it's a > lot of work. Option 2 would need a spec change, and I'm not convinced we > want to do it. If there are enough other developers who would want this, > we could open it up for discussion for some future version (not JavaFX 17). > > Phil might have some thoughts on this. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8240844 > > > On 5/18/2021 10:45 AM, Tom Schindl wrote: >> Uff - I'd like to revisit this topic. As I did some jlink stuff for >> our applications adding java.desktop once more bugged me. >> >> I guess the first thing to do is to file a JIRA-Ticket but it really >> starts to bug me to include java.desktop although I don't plan to use >> printing (and I guess > 90% of the JavaFX don't use the printing API >> either but produce PDFs or whatever) and Java-Beans. >> >> Tom >> >> Am 27.03.18 um 14:26 schrieb Kevin Rushforth: >>> Hi Tom, >>> >>> Yes, this is an unfortunate dependency. It is "only" an >>> implementation dependency, meaning that nothing in the public API >>> depends on java.desktop (which is why we don't "requires transient >>> java.desktop"), so it should be possible to remove this dependency in >>> the future. As noted, it is only there because Java Beans is part of >>> the java.desktop module. >>> >>> In the interim, your suggestion of "requires static java.base" could >>> be the way to go. It would need a spec change to the JavaFX beans >>> adapter classes documenting that they would throw an >>> UnsupportedOperationException if java.desktop was not present at >>> runtime, along with a recommendation that applications needing that >>> functionality should add "requires java.desktop" to their own >>> module-info.java. >>> >>> Note that this would only help non-graphical JavaFX applications that >>> use javafx.base for its collections, properties, and bindings, since >>> javafx.graphics requires java.desktop in a way that currently cannot >>> easily be made optional (not without reimplementing printing support >>> anyway). >>> >>> -- Kevin >>> >>> >>> Tom Schindl wrote: >>>> Hi, >>>> >>>> Anyone else has an opinion on that? Is require static the way to go? >>>> >>>> Tom >>>> >>>> On 21.03.18 23:23, Tom Schindl wrote: >>>>> Hi, >>>>> >>>>> I always thought the JavaFX-Codebase should be able to run with >>>>> just the >>>>> java.base module but I was browsing the codebase a bit and was >>>>> suprised >>>>> (or rather shocked) that even the base-module requires java.desktop. >>>>> >>>>> If I get it correct this because of the java.beans (provided by the >>>>> adapters) stuff is found in there. Why hasn't the requires there not >>>>> defined as: >>>>> >>>>> requires static java.desktop; >>>>> >>>>> Tom >>>>> > From kcr at openjdk.java.net Wed May 19 17:34:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 May 2021 17:34:05 GMT Subject: RFR: 8263761: Update boot JDK to 16.0.1 Message-ID: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> This PR updates the boot JDK for JavaFX builds to use JDK 16.0.1. The minimum version of the JDK remains unchanged at JDK 11. ------------- Commit messages: - 8263761: Update boot JDK to 16.0.1 Changes: https://git.openjdk.java.net/jfx/pull/507/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=507&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263761 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/507.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/507/head:pull/507 PR: https://git.openjdk.java.net/jfx/pull/507 From kcr at openjdk.java.net Wed May 19 18:08:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 May 2021 18:08:38 GMT Subject: RFR: 8263761: Update boot JDK to 16.0.1 In-Reply-To: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> References: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> Message-ID: On Wed, 19 May 2021 17:28:34 GMT, Kevin Rushforth wrote: > This PR updates the boot JDK for JavaFX builds to use JDK 16.0.1. The minimum version of the JDK remains unchanged at JDK 11. It looks like we are still seeing occasional failures in `HonorDeveloperSettingsTest` on Linux. I filed [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) to track this. ------------- PR: https://git.openjdk.java.net/jfx/pull/507 From kevin.rushforth at oracle.com Wed May 19 19:07:48 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 May 2021 12:07:48 -0700 Subject: [External] : Re: Dependencies on java.desktop In-Reply-To: <82497ed5-790b-25a6-74d7-2879c33fe8d7@bestsolution.at> References: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> <5ABA3874.10405@oracle.com> <9ca3397c-7e91-381c-9df7-da6c792a16c1@bestsolution.at> <82497ed5-790b-25a6-74d7-2879c33fe8d7@bestsolution.at> Message-ID: That's an interesting idea, although splitting it up to the degree you listed below would be unwieldy at best and likely unworkable (due to split package issues and interdependencies). It also would be wrong to create any implementation modules unless they are 100% hidden from the application developer. If any of them would (or even could) ever show up in a developer's .pom, .xml, or .gradle file, then it would be a non-starter since that would amount to leaking implementation details. Irrespective of how the graphics module might be broken up, I suspect that splitting any of our existing modules might run into compatibility problems in the maven.central deployment case, unless gradle and maven have completely solved the module dependencies properly such that application can specify, for example, javafx.controls and have it automatically pull in all of the other javafx dependencies. Leaving that last point aside, I can see how splitting it up into just two modules *might* be workable with a bit of refactoring: javafx.graphics --> depends on javafx.graphics.* (requires transitive) ? javafx.graphics.core (includes all of the public API except printing, and all of the implementation except printing + j2d pipeline) ? javafx.graphics.printing --> depends on javafx.graphics.core, java.desktop (includes printing api, printing impl, j2d pipeline) An application that doesn't need printing could depend on javafx.graphics.core. Of course, that leaves out UI controls-based applications, since javafx.controls "requires transitive" javafx.graphics. So you'd have to split that one too, and possibly javafx.fxml, in order to really get any benefit from this. Anyway, I'm not really in favor of this approach, just pointing out a less radical idea that we could at least discuss further as a possibility. I still think making printing optional might be a feasible alternative to reimplementing it natively (which isn't as odd an idea as it might seem initially, since embedded / mobile systems don't typically have a? printer). If so, a better approach to throwing an exception would probably be to just to report no printers if the Java2D library (the java.desktop module) isn't available. Need to think about this one some more. > Out of curiosity I tried that locally and it just works ;-) I'm sure it depends on your definition of "just works". If you mean taking the class files after the fact and cobbling together some modules from the built class files and running something, then maybe, although even then I don't see how it could work seamlessly. -- Kevin On 5/19/2021 10:20 AM, Tom Schindl wrote: > Hi, > > Well I looked a bit closer now and the situation and you are right. I > think need to do that one by one. > > I think getting rid of HostServices::showDocument is quite easy as the > code in Java-AWT is just 1 JNI-Method so copying that to OpenJFX > should be fairly easy. > > Now on the printing story which is the real problem a fairly radical > approach would be to split up javafx.graphics into multiple modules > and make javafx.graphics a META-Module who provides the backward > compat using "requires transitive". > > We would end up with: > > * javafx.graphics > ? * javafx.graphics.base > ? * javafx.graphics.print > ? * javafx.graphics.prism.base > ? * javafx.graphics.prism.j2d > ? * javafx.graphics.prism.es2 > ? * javafx.graphics.prism.d3d > ? * javafx.graphics.glass.base > ? * javafx.graphics.glass.win32 > ? * javafx.graphics.glass.mac > ? * ... > > I know that sounds radical but from a pure architectual point of view > this would be better than optional features in javafx.graphics and > would not require us to reimplement printing to get rid of java.desktop. > > Out of curiosity I tried that locally and it just works ;-) > > Tom > > Am 18.05.21 um 23:40 schrieb Kevin Rushforth: >> As noted in the thread you quoted below, removing the dependency on >> java.desktop from javafx.base isn't a particularly hard problem, and >> is tracked by JDK-8240844 [1]. And even though it will require a spec >> change (meaning a CSR), it doesn't result in any loss of >> functionality, since in order to usefully do anything with the >> JavaBeanXxxxx classes requires java.desktop anyway. >> >> Removing the dependency on java.desktop from javafx.graphics is a >> larger issue because of printing. There is also an implementation >> dependency on the Desktop class to implement >> HostServices::showDocument that would need to be redone. And of >> course it depends on the above (eliminating the dependency from >> javafx.base) being done first. >> >> For printing we would need to do one of two things: >> >> 1. Eliminate the implementation dependency on the Java2D printing >> code. This is a large effort, but would preserve existing functionality. >> >> 2. Make the JavaFX Printing function "optional" (i.e., make it a >> "ConditionalFeature"), such that if java.desktop is not present, >> printing doesn't work (all of the printing APIs would throw an >> UnsupportedOperationException if java.desktop is not available). An >> application that wants to do printing would need to include >> java.desktop. >> >> Option 1 would be my preferred approach, but as mentioned above it's >> a lot of work. Option 2 would need a spec change, and I'm not >> convinced we want to do it. If there are enough other developers who >> would want this, we could open it up for discussion for some future >> version (not JavaFX 17). >> >> Phil might have some thoughts on this. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8240844 >> >> >> On 5/18/2021 10:45 AM, Tom Schindl wrote: >>> Uff - I'd like to revisit this topic. As I did some jlink stuff for >>> our applications adding java.desktop once more bugged me. >>> >>> I guess the first thing to do is to file a JIRA-Ticket but it really >>> starts to bug me to include java.desktop although I don't plan to >>> use printing (and I guess > 90% of the JavaFX don't use the printing >>> API either but produce PDFs or whatever) and Java-Beans. >>> >>> Tom >>> >>> Am 27.03.18 um 14:26 schrieb Kevin Rushforth: >>>> Hi Tom, >>>> >>>> Yes, this is an unfortunate dependency. It is "only" an >>>> implementation dependency, meaning that nothing in the public API >>>> depends on java.desktop (which is why we don't "requires transient >>>> java.desktop"), so it should be possible to remove this dependency >>>> in the future. As noted, it is only there because Java Beans is >>>> part of the java.desktop module. >>>> >>>> In the interim, your suggestion of "requires static java.base" >>>> could be the way to go. It would need a spec change to the JavaFX >>>> beans adapter classes documenting that they would throw an >>>> UnsupportedOperationException if java.desktop was not present at >>>> runtime, along with a recommendation that applications needing that >>>> functionality should add "requires java.desktop" to their own >>>> module-info.java. >>>> >>>> Note that this would only help non-graphical JavaFX applications >>>> that use javafx.base for its collections, properties, and bindings, >>>> since javafx.graphics requires java.desktop in a way that currently >>>> cannot easily be made optional (not without reimplementing printing >>>> support anyway). >>>> >>>> -- Kevin >>>> >>>> >>>> Tom Schindl wrote: >>>>> Hi, >>>>> >>>>> Anyone else has an opinion on that? Is require static the way to go? >>>>> >>>>> Tom >>>>> >>>>> On 21.03.18 23:23, Tom Schindl wrote: >>>>>> Hi, >>>>>> >>>>>> I always thought the JavaFX-Codebase should be able to run with >>>>>> just the >>>>>> java.base module but I was browsing the codebase a bit and was >>>>>> suprised >>>>>> (or rather shocked) that even the base-module requires java.desktop. >>>>>> >>>>>> If I get it correct this because of the java.beans (provided by the >>>>>> adapters) stuff is found in there. Why hasn't the requires there not >>>>>> defined as: >>>>>> >>>>>> requires static java.desktop; >>>>>> >>>>>> Tom >>>>>> >> From philip.race at oracle.com Wed May 19 19:51:55 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 19 May 2021 12:51:55 -0700 Subject: [External] : Re: Dependencies on java.desktop In-Reply-To: References: <2fa51511-c20d-cc9c-10f7-5e1de2b2a48d@bestsolution.at> <03ff46ce-4f07-7108-2cdd-bc258e0db488@bestsolution.at> <5ABA3874.10405@oracle.com> <9ca3397c-7e91-381c-9df7-da6c792a16c1@bestsolution.at> Message-ID: Did someone mention my name ? Implementing FX printing on top of 2D printing was always a pragmatic way of delivering in FX 8. Never something that was done because we wanted to for any reason. A new native implementation will still cost the same amount of work that we put off in JDK 8. So it needs to be prioritised. But note that I think it can be done one platform at a time. So if we did a Windows print implementation javafx.graphics might no longer require it on Windows (at least for printing) but would still need it on macOS. This is the right long term answer rather than @ConditionalFeature. -phil. On 5/18/21 2:40 PM, Kevin Rushforth wrote: > As noted in the thread you quoted below, removing the dependency on > java.desktop from javafx.base isn't a particularly hard problem, and > is tracked by JDK-8240844 [1]. And even though it will require a spec > change (meaning a CSR), it doesn't result in any loss of > functionality, since in order to usefully do anything with the > JavaBeanXxxxx classes requires java.desktop anyway. > > Removing the dependency on java.desktop from javafx.graphics is a > larger issue because of printing. There is also an implementation > dependency on the Desktop class to implement > HostServices::showDocument that would need to be redone. And of course > it depends on the above (eliminating the dependency from javafx.base) > being done first. > > For printing we would need to do one of two things: > > 1. Eliminate the implementation dependency on the Java2D printing > code. This is a large effort, but would preserve existing functionality. > > 2. Make the JavaFX Printing function "optional" (i.e., make it a > "ConditionalFeature"), such that if java.desktop is not present, > printing doesn't work (all of the printing APIs would throw an > UnsupportedOperationException if java.desktop is not available). An > application that wants to do printing would need to include java.desktop. > > Option 1 would be my preferred approach, but as mentioned above it's a > lot of work. Option 2 would need a spec change, and I'm not convinced > we want to do it. If there are enough other developers who would want > this, we could open it up for discussion for some future version (not > JavaFX 17). > > Phil might have some thoughts on this. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8240844 > > > On 5/18/2021 10:45 AM, Tom Schindl wrote: >> Uff - I'd like to revisit this topic. As I did some jlink stuff for >> our applications adding java.desktop once more bugged me. >> >> I guess the first thing to do is to file a JIRA-Ticket but it really >> starts to bug me to include java.desktop although I don't plan to use >> printing (and I guess > 90% of the JavaFX don't use the printing API >> either but produce PDFs or whatever) and Java-Beans. >> >> Tom >> >> Am 27.03.18 um 14:26 schrieb Kevin Rushforth: >>> Hi Tom, >>> >>> Yes, this is an unfortunate dependency. It is "only" an >>> implementation dependency, meaning that nothing in the public API >>> depends on java.desktop (which is why we don't "requires transient >>> java.desktop"), so it should be possible to remove this dependency >>> in the future. As noted, it is only there because Java Beans is part >>> of the java.desktop module. >>> >>> In the interim, your suggestion of "requires static java.base" could >>> be the way to go. It would need a spec change to the JavaFX beans >>> adapter classes documenting that they would throw an >>> UnsupportedOperationException if java.desktop was not present at >>> runtime, along with a recommendation that applications needing that >>> functionality should add "requires java.desktop" to their own >>> module-info.java. >>> >>> Note that this would only help non-graphical JavaFX applications >>> that use javafx.base for its collections, properties, and bindings, >>> since javafx.graphics requires java.desktop in a way that currently >>> cannot easily be made optional (not without reimplementing printing >>> support anyway). >>> >>> -- Kevin >>> >>> >>> Tom Schindl wrote: >>>> Hi, >>>> >>>> Anyone else has an opinion on that? Is require static the way to go? >>>> >>>> Tom >>>> >>>> On 21.03.18 23:23, Tom Schindl wrote: >>>>> Hi, >>>>> >>>>> I always thought the JavaFX-Codebase should be able to run with >>>>> just the >>>>> java.base module but I was browsing the codebase a bit and was >>>>> suprised >>>>> (or rather shocked) that even the base-module requires java.desktop. >>>>> >>>>> If I get it correct this because of the java.beans (provided by the >>>>> adapters) stuff is found in there. Why hasn't the requires there not >>>>> defined as: >>>>> >>>>> requires static java.desktop; >>>>> >>>>> Tom >>>>> > From youngty1997 at gmail.com Wed May 19 20:17:38 2021 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 19 May 2021 15:17:38 -0500 Subject: Minimum JDK policy for OpenJFX In-Reply-To: References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: If you want to learn more about Panama you can read the JEP page: https://openjdk.java.net/jeps/412 You can also join the panama-dev list and ask questions: https://mail.openjdk.java.net/mailman/listinfo/panama-dev Biggest things for JavaFX that I can think of is jextract, a tool for generating Java headers from a C header, and having all binding code written in Java. It may be easier to upgrade to newer GTK versions using Panama as there is no C shim required and the bindings are, again, generated for you. jextract does have issues, one of which is that any binding generated using it are platform-specific even if the library itself is cross-platform. You can make bindings by hand that are cross-platform if you want, though. Speaking of GTK, when is JavaFX going to support GTK4? On 5/18/21 4:42 PM, Nir Lisker wrote: >> there are some advantages in being able to run with the latest JDK LTS >> > One *potential* issue with this approach is that LTS is not defined in > OpenJDK as far as I know. The LTS versions are a business decision of each > distributor. For now, they have all aligned on 8, 11, 17, but nothing > guarantees that this will stay so. What if different vendors LTS different > versions? Suppose that Valhalla and Loom add very attractive features in > JDK 19 (big performance enhancements, leads to big money savings on > hardware, leads to economic incentives to use these, leads to requests to > support these), now vendors can declare JDK 19 as LTS, and what will JavaFX > do? > In OpenJDK all versions are treated equally as it is a spec and not a > business model. Should JavaFX be coupled to business models? Maybe Gluon > has some insights since they give JavaFX LTS support. > > A second point, as Michael Strau? mentioned, is that maybe we should see > what features are going to be delivered in the next versions and judge if > there's something attractive enough for library developers to base our > decision on. Sealed classes from Amber are certainly one of them. Panama > might provide handy features for JavaFX's interfacing with native code, > like Foreign Memory Access, though I didn't look into it in detail. > Valhalla is certainly too far away to consider, and Loom is rather > irrelevant for JavaFX and GUIs in general. > If anyone has insights into relevant upcoming features I'll be happy to > learn. > > - Nir > > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth > wrote: > >> A very timely question. I was already planning to raise this as a >> discussion after we update our boot JDK to JDK 16 (blocked by the >> in-progress gradle 7 update), which I hope to do later this week. >> >> I think that this is the right time to consider bumping the minimum >> required version to run JavaFX 17 to JDK 16, which would allow us to >> start using APIs and language features from JDK 12 through JDK 16 >> inclusive. >> >> In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In >> practice, though, we don't bump it for each release, as there are some >> advantages in being able to run with the latest JDK LTS. Since JavaFX 17 >> will release at roughly the same time as JDK 17 LTS, I can't think of a >> good reason to not update our minimum. >> >> Comments? >> >> -- Kevin >> >> >> On 5/18/2021 7:59 AM, Michael Strau? wrote: >>> Currently, JDK 11 is required for the latest version of OpenJFX. What >>> is the policy for bumping this requirement? Does it always correspond >>> to the latest JDK LTS release (the next of which will be JDK 17), or >>> is it independent from the release cycle of OpenJDK? >> From michaelstrau2 at gmail.com Wed May 19 20:36:14 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 19 May 2021 22:36:14 +0200 Subject: Support loading images from inline data-URIs Message-ID: I would like to propose adding support for loading images from inline data-URIs, as commonly supported by web browsers. This is a low-impact addition to the image loading infrastructure as seen in this draft PR: https://github.com/openjdk/jfx/pull/508 As a follow-on feature, I'd also like to support loading stylesheets from data-URIs. With both features implemented, developers have more flexibility in working with stylesheets. For example, it'd be possible to dynamically generate and add stylesheets to applications without deploying temporary files on disk. Another scenario would be to include small theme-specific icons in their respective stylesheets, which can simplify deployment. Any thoughts? From github.com+66004280+maran23 at openjdk.java.net Wed May 19 21:14:57 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Wed, 19 May 2021 21:14:57 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work Message-ID: Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly. This PR fixes the errors you get, when cloning and working with OpenJFX in IntelliJ IDE: - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. For IntelliJ users: This is the language level shown inside the **Project Structure**. (File -> Project Structure...) - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize JUnit 4. Also the shims are included/recognized (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) ------------- Commit messages: - Made IntelliJ build working Changes: https://git.openjdk.java.net/jfx/pull/506/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=506&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267418 Stats: 62 lines in 6 files changed: 55 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/506.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/506/head:pull/506 PR: https://git.openjdk.java.net/jfx/pull/506 From kcr at openjdk.java.net Wed May 19 21:14:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 May 2021 21:14:57 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work In-Reply-To: References: Message-ID: On Wed, 19 May 2021 16:12:45 GMT, Marius Hanl wrote: > Question: I was wondering, should I create a ticket for this as well? All fixes need a bug ID in JBS. For this one, it seemed easier for me to just file it directly, so I did: [JDK-8267418](https://bugs.openjdk.java.net/browse/JDK-8267418). ------------- PR: https://git.openjdk.java.net/jfx/pull/506 From nlisker at gmail.com Thu May 20 02:21:05 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 20 May 2021 05:21:05 +0300 Subject: .classpath files for Eclipse In-Reply-To: <2076b439-9bb2-d07a-77b1-3f9b4f5ce299@bestsolution.at> References: <2076b439-9bb2-d07a-77b1-3f9b4f5ce299@bestsolution.at> Message-ID: The Eclipse files are due an update. There were previous reports on issues on Linux too (probably the ones you mentioned). We were hoping to be able to remove them with Gradle generating them during the build, but last time it was checked it couldn't. Don't know if Gradle 7 changed anything. I saw the Swing error too. The apps and tests projects are also misconfigured. On Wed, May 19, 2021 at 5:53 PM Tom Schindl wrote: > Hi Nir/Jeannette, > > As you are both using Eclipse for development I'd like to get your take > on the following things. > > Dealing with OS specific > ------------------------ > The graphics module has to have different source folders depending on > the OS you are developing on: > * Windows: build/hlsl/Decora and build/hslPrism > * Linux/OS-X: build/gensrc/jsl-decora build/gensrc/jsl-prism > > So when importing the projects Eclipse does not even build anything > until you fix the .classpath file - I'd like to propose to mark those > Source-Folders optional. > > Swing-Project > ------------- > There the .classpath has a none existing "src/test/java" I wonder where > that source is and if not there anymore remove the offending entry from > .classpath-File > > BuildSrc > -------- > What's the purpose of that project? The classpath is incorrect and does > it have to be a Java-Project? > > > Tom > From arapte at openjdk.java.net Thu May 20 05:56:36 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 20 May 2021 05:56:36 GMT Subject: RFR: 8263761: Update boot JDK to 16.0.1 In-Reply-To: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> References: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> Message-ID: <3BA1YcFmA8YwanBnry1Gl3kirb50uIgwndkUmTm80_E=.5f1408a9-b930-4760-8b12-a2cba795b3f1@github.com> On Wed, 19 May 2021 17:28:34 GMT, Kevin Rushforth wrote: > This PR updates the boot JDK for JavaFX builds to use JDK 16.0.1. The minimum version of the JDK remains unchanged at JDK 11. Linux build failure is not related to this change, failed test: test.javafx.css.HonorDeveloperSettingsTest > testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle FAILED Looks like the fix of #496 is not sufficient. ------------- PR: https://git.openjdk.java.net/jfx/pull/507 From arapte at openjdk.java.net Thu May 20 06:02:46 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 20 May 2021 06:02:46 GMT Subject: RFR: 8263761: Update boot JDK to 16.0.1 In-Reply-To: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> References: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> Message-ID: On Wed, 19 May 2021 17:28:34 GMT, Kevin Rushforth wrote: > This PR updates the boot JDK for JavaFX builds to use JDK 16.0.1. The minimum version of the JDK remains unchanged at JDK 11. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/507 From aghaisas at openjdk.java.net Thu May 20 07:05:38 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 20 May 2021 07:05:38 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v14] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:14:11 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: > > - 8264127 > fixed assertion text, > exception handler is now installed/uninstalled like in TableCellTest > - 8264127 > fixed trailing whitespace Fix are tests look good to me. I have listed minor editing comments. modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 543: > 541: final int editIndex = list == null ? -1 : list.getEditingIndex(); > 542: final boolean editing = isEditing(); > 543: final boolean match = list != null && index != -1 && index == editIndex; Minor : Readability can be improved with brackets around the conditions. (list != null) && (index != -1) && (index == editIndex); modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 545: > 543: final boolean match = list != null && index != -1 && index == editIndex; > 544: > 545: if (match && ! editing) { Minor : code convention : there should not be a space after `!` modules/javafx.controls/src/main/java/javafx/scene/control/ListCell.java line 547: > 545: if (match && ! editing) { > 546: startEdit(); > 547: } else if (! match && editing) { Minor : code convention : there should not be a space after ! ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From arapte at openjdk.java.net Thu May 20 07:24:57 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 20 May 2021 07:24:57 GMT Subject: RFR: 8267425: Intermittent failure of HonorDeveloperSettingsTest unit test Message-ID: The same failure was earlier fixed at PR #496, which seems insufficient. The changes in this PR were also tried ealier in the PR #496 but later removed, as they seemed not necessary. Fix is to clean up the test, by removing all children added to root and hiding the stage. The test only fails on the GHA run, if it continues to fail after this fix then we shall skip it till next test sprint. ------------- Commit messages: - root.getChildren().clear(); stage.hide(); Changes: https://git.openjdk.java.net/jfx/pull/509/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=509&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267425 Stats: 14 lines in 1 file changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/509.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/509/head:pull/509 PR: https://git.openjdk.java.net/jfx/pull/509 From fastegal at swingempire.de Thu May 20 10:52:11 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Thu, 20 May 2021 12:52:11 +0200 Subject: .classpath files for Eclipse In-Reply-To: <2076b439-9bb2-d07a-77b1-3f9b4f5ce299@bestsolution.at> References: <2076b439-9bb2-d07a-77b1-3f9b4f5ce299@bestsolution.at> Message-ID: <20210520125211.Horde.QwaUrG1L61tNBZJcCjaTgg9@webmail.df.eu> Hi Tom, can't say anything to your questions: being on win only and just having Eclipse projects for base, graphics, controls (everything else is handled by gradle from the commandline) -- Jeanette Zitat von Tom Schindl : > Hi Nir/Jeannette, > > As you are both using Eclipse for development I'd like to get your > take on the following things. > > Dealing with OS specific > ------------------------ > The graphics module has to have different source folders depending > on the OS you are developing on: > * Windows: build/hlsl/Decora and build/hslPrism > * Linux/OS-X: build/gensrc/jsl-decora build/gensrc/jsl-prism > > So when importing the projects Eclipse does not even build anything > until you fix the .classpath file - I'd like to propose to mark > those Source-Folders optional. > > Swing-Project > ------------- > There the .classpath has a none existing "src/test/java" I wonder > where that source is and if not there anymore remove the offending > entry from .classpath-File > > BuildSrc > -------- > What's the purpose of that project? The classpath is incorrect and > does it have to be a Java-Project? > > > Tom From fastegal at openjdk.java.net Thu May 20 10:52:32 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 20 May 2021 10:52:32 GMT Subject: RFR: 8267392: ENTER key press on editable TableView throws NPE [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 14:15:00 GMT, Marius Hanl wrote: >> ~~Note: I reported the bug already, waiting for approval. Internal tracking id: 9070318. I will update the title as soon as the ticket is created.~~ >> EDIT: Changed the title. :) >> >> This PR is fixing a NP, which is thrown when you press ENTER on an editbale table, after it is initially shown. >> >> When pressing ENTER, **TableViewBehaviorBase#activate** is retrieving the current focused row (**getFocusedCell()**) and from there the corresponding table column. >> This is null, when a table is initially shown. It can also be null, when the items from the underlying table are changed (e.g. **setItems()**) or when **getFocusModel().focus(row)** is used. >> Therefore, null is a valid value and we should guard against it. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment (changed from NP to NPE) Fix looks good - verified that the new tests fail before and pass after ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/505 From fkirmaier at openjdk.java.net Thu May 20 11:12:09 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 20 May 2021 11:12:09 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v15] In-Reply-To: References: Message-ID: > Fixing ListCell editing status is true, when index changes while editing. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8264127 small changes based on CR ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/441/files - new: https://git.openjdk.java.net/jfx/pull/441/files/ba5dc2e0..7c22f036 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=441&range=13-14 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/441/head:pull/441 PR: https://git.openjdk.java.net/jfx/pull/441 From fkirmaier at openjdk.java.net Thu May 20 11:12:12 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 20 May 2021 11:12:12 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v14] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 10:14:11 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: > > - 8264127 > fixed assertion text, > exception handler is now installed/uninstalled like in TableCellTest > - 8264127 > fixed trailing whitespace I've done the 3 requested minor code convention changes ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From aghaisas at openjdk.java.net Thu May 20 12:06:51 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 20 May 2021 12:06:51 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v15] In-Reply-To: References: Message-ID: On Thu, 20 May 2021 11:12:09 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127 > small changes based on CR Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From kcr at openjdk.java.net Thu May 20 15:37:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 May 2021 15:37:37 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v14] In-Reply-To: References: Message-ID: On Tue, 18 May 2021 13:11:39 GMT, Jeanette Winzenburg wrote: >> Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8264127 >> fixed assertion text, >> exception handler is now installed/uninstalled like in TableCellTest >> - 8264127 >> fixed trailing whitespace > > wondering why the bot removed the rfr label (about three weeks ago) and re-added it a earlier today? This one should have been set to require 2 reviewers. I'll do it now, but even if Skara doesn't remove the `ready` label, please wait to integrate it until @kleopatra re-reviews it. ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From kcr at openjdk.java.net Thu May 20 17:30:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 May 2021 17:30:50 GMT Subject: RFR: 8264140: Add -Djava.security.manager=allow to JavaFX tests calling setSecurityManager Message-ID: The security manager is being deprecated for removal by [JEP 411](https://openjdk.java.net/jeps/411), which is proposed for JDK 17. The implementation of JEP 411 is out for review here: openjdk/jdk#4073. Along with the deprecation of most security manager classes and methods, the default value of the `java.security.manager` system property will be treated as "`disallow`". This means that the deprecated `System::setSecurityManager` method will throw `UnsupportedOperationException` unless `-Djava.security.manager=allow` is set on the command line. A few system tests and javafx.web unit tests set a security manager and will fail without setting that system property. The fix is to set the `-Djava.security.manager=allow` in `build.gradle` when running tests in the `:systemTests` and `:web` projects. Support for setting `java.security.manager` to "`allow`" was added in JDK 12, so we also check that the boot JDK is >= 12 (the check is needed because JDK 11 is the minimum boot JDK). As part of this PR I am removing the legacy `ServiceWithSecurityManagerTest` to address [JDK-8234175](https://bugs.openjdk.java.net/browse/JDK-8234175). `ServiceWithSecurityManagerTest` is the only unit test in the `javafx.graphics` module that sets a security manager, and the test has skipped via `@Ignore` since FX 8 with the comment that the test "appears to be bogus". Since there are no active `javafx.graphics` tests that set the security manager, I don't see the need to set `-Djava.security.manager=allow` for `javafx.graphics` tests. Better to just remove the test. I have done a full build / test using JDK 15 as a boot JDK. I then did a full build / test using a locally-built JDK 17-ea with the fix for JEP 411, and setting `JDK_HOME` to that JDK. With that, I can confirm that the tests that set the security manager fail without this fix and pass with this fix. ------------- Commit messages: - 8264140: Add -Djava.security.manager=allow to JavaFX tests calling setSecurityManager - 8234175: Remove obsolete ServiceWithSecurityManagerTest unit test Changes: https://git.openjdk.java.net/jfx/pull/510/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=510&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264140 Stats: 139 lines in 2 files changed: 11 ins; 128 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/510.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/510/head:pull/510 PR: https://git.openjdk.java.net/jfx/pull/510 From kcr at openjdk.java.net Thu May 20 19:31:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 May 2021 19:31:37 GMT Subject: RFR: 8264140: Add -Djava.security.manager=allow to JavaFX tests calling setSecurityManager In-Reply-To: References: Message-ID: On Thu, 20 May 2021 17:23:56 GMT, Kevin Rushforth wrote: > The security manager is being deprecated for removal by [JEP 411](https://openjdk.java.net/jeps/411), which is proposed for JDK 17. The implementation of JEP 411 is out for review here: openjdk/jdk#4073. > > Along with the deprecation of most security manager classes and methods, the default value of the `java.security.manager` system property will be treated as "`disallow`". This means that the deprecated `System::setSecurityManager` method will throw `UnsupportedOperationException` unless `-Djava.security.manager=allow` is set on the command line. A few system tests and javafx.web unit tests set a security manager and will fail without setting that system property. > > The fix is to set the `-Djava.security.manager=allow` in `build.gradle` when running tests in the `:systemTests` and `:web` projects. Support for setting `java.security.manager` to "`allow`" was added in JDK 12, so we also check that the boot JDK is >= 12 (the check is needed because JDK 11 is the minimum boot JDK). > > As part of this PR I am removing the legacy `ServiceWithSecurityManagerTest` to address [JDK-8234175](https://bugs.openjdk.java.net/browse/JDK-8234175). `ServiceWithSecurityManagerTest` is the only unit test in the `javafx.graphics` module that sets a security manager, and the test has skipped via `@Ignore` since FX 8 with the comment that the test "appears to be bogus". Since there are no active `javafx.graphics` tests that set the security manager, I don't see the need to set `-Djava.security.manager=allow` for `javafx.graphics` tests. Better to just remove the test. > > I have done a full build / test using JDK 15 as a boot JDK. I then did a full build / test using a locally-built JDK 17-ea with the fix for JEP 411, and setting `JDK_HOME` to that JDK. With that, I can confirm that the tests that set the security manager fail without this fix and pass with this fix. Note that this does not provide fine-grained setting of `-Djava.security.manager=allow`. It would require refactoring the tests to separate out all of the ones that set a security manager to a different test group. Until such time as we make JDK 17 the minimum (which won't be at least until JavaFX 18) it doesn't make sense to consider such a refactoring. ------------- PR: https://git.openjdk.java.net/jfx/pull/510 From github.com+12087024+beldenfox at openjdk.java.net Thu May 20 22:28:37 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Thu, 20 May 2021 22:28:37 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: <2lZHLjMKi_GL7duYnXx3c081a1W9GOEfATBTpi5bZ3A=.afb95acb-0425-4e24-97e1-11822ab286f8@github.com> On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace error. I would like to get this review restarted. Sorry I let it lapse for so long. I was asked to evaluate a Swing-style solution which determines the Java key code based on the keystroke?s character. If the character can?t be mapped to a key code the system falls back to the US QWERTY key code instead. I?ve run some test code that loops through the keyboard layouts in macOS (all 189 of them) to sanity-check this approach. The executive summary is that it?s entirely work-able and in isolation would involve a lot less code than the current PR. I say "in isolation" because I?m also working on code to fix problems with KeyCharacterCombinations on the Mac and those fixes rely on some of the same machinery, particularly the calls to UCKeyTranslate, so even if we removed most of that code for this PR some of it would just re-appear in the next. If you want I could put together a separate PR that uses the Swing-style solution for comparison purposes. To make it a fair comparison I would also incorporate the changes for the KeyCharacterCombination problems (I don?t have the bug numbers handy). The one place where this approach falls down is the Robot. To send a key event using the Robot we have to map from a Java key code to a physical key. If the key code is determined based on data that?s only available while processing a keystroke it?s just not possible to map the other way reliably. Swing punts and assumes a US QWERTY layout as does the current JavaFX code. This has produced bad results for years but based on the bug database I'm not sure anyone has noticed. (The code I submitted with this PR assigns key codes without reference to key strokes and can work in both directions reliably.) A comment in the Swing sources describes this approach as "hokey" and I agree. It relies on most keyboard layouts being similar to US QWERTY and that most of the system ignores non-letter and non-digit key codes (this algorithm often generates bogus codes). But for all it?s hokey-ness it gets the job done surprisingly well. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From nlisker at gmail.com Thu May 20 23:29:32 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 21 May 2021 02:29:32 +0300 Subject: Missing class declarations referenced from tests Message-ID: Hi, I'm looking inside tests/functional and I see that this file https://github.com/openjdk/jfx/blob/master/tests/functional/animation/javafx/animation/AnimationFunctionalTestBase.java references com.sun.javafx.functions.Function0, but this class can't be found. There is also a commented out section in FloodGame.java in apps referencing this class. This file also has a declaration protected class SimpleTimeline extends Timeline {... which gives an error because Timeline is final. There are more errors there and in its package. What is this package and how does it suppose to work? From kcr at openjdk.java.net Thu May 20 23:51:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 20 May 2021 23:51:46 GMT Subject: RFR: 8267425: Intermittent failure of HonorDeveloperSettingsTest unit test In-Reply-To: References: Message-ID: <1QPYGIQtAoa3lmY88Keg00dcl9k6CR_LJeybh-f9TQs=.5e07fca7-9954-476d-ae8e-7009aaf4b960@github.com> On Thu, 20 May 2021 07:18:28 GMT, Ambarish Rapte wrote: > The same failure was earlier fixed at PR #496, which seems insufficient. > The changes in this PR were also tried ealier in the PR #496 but later removed, as they seemed not necessary. > Fix is to clean up the test, by removing all children added to root and hiding the stage. > The test only fails on the GHA run, if it continues to fail after this fix then we shall skip it till next test sprint. The cleanup looks safe enough, although I still don't think that removing the children is needed. I took a look at what the `resetStyleManager` method in the test does, and it seems like clearing `StyleManager::cacheContainerMap` should have prevented any leftovers from the old scene from being processed the next time around. And yet that's what it looks like is happening. I'd prefer to understand why it is causing a problem rather than just adding more cleanup and hoping that it's enough this time. I'll take a closer look tomorrow. ------------- PR: https://git.openjdk.java.net/jfx/pull/509 From kevin.rushforth at oracle.com Fri May 21 00:04:58 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 May 2021 17:04:58 -0700 Subject: Missing class declarations referenced from tests In-Reply-To: References: Message-ID: <84ed2263-b6c5-6803-ada3-fa0cfc041687@oracle.com> The tests under tests/functional are legacy tests. Since they aren't wired up to the build, it isn't surprising that they don't compile or run. Some of the stuff under apps is likely in the same state. Anything that isn't built or maintained is subject to bit-rot and should probably be deleted or cleaned up and put somewhere where it is built regularly and run at least occasionally. -- Kevin On 5/20/2021 4:29 PM, Nir Lisker wrote: > Hi, > > I'm looking inside tests/functional and I see that this file > > https://github.com/openjdk/jfx/blob/master/tests/functional/animation/javafx/animation/AnimationFunctionalTestBase.java > > references com.sun.javafx.functions.Function0, but this class can't be > found. There is also a commented out section in FloodGame.java in apps > referencing this class. > > This file also has a declaration > > protected class SimpleTimeline extends Timeline {... > > which gives an error because Timeline is final. > > There are more errors there and in its package. What is this package and > how does it suppose to work? From nlisker at gmail.com Fri May 21 00:42:19 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 21 May 2021 03:42:19 +0300 Subject: Missing class declarations referenced from tests In-Reply-To: <84ed2263-b6c5-6803-ada3-fa0cfc041687@oracle.com> References: <84ed2263-b6c5-6803-ada3-fa0cfc041687@oracle.com> Message-ID: Can you compile a list of items to remove and I'll submit a PR? If something needs to move somewhere I can include that too. I'm updating the Eclipse files so I want to know what's relevant and what's not. On Fri, May 21, 2021 at 3:05 AM Kevin Rushforth wrote: > The tests under tests/functional are legacy tests. Since they aren't > wired up to the build, it isn't surprising that they don't compile or > run. Some of the stuff under apps is likely in the same state. Anything > that isn't built or maintained is subject to bit-rot and should probably > be deleted or cleaned up and put somewhere where it is built regularly > and run at least occasionally. > > -- Kevin > > > On 5/20/2021 4:29 PM, Nir Lisker wrote: > > Hi, > > > > I'm looking inside tests/functional and I see that this file > > > > > https://github.com/openjdk/jfx/blob/master/tests/functional/animation/javafx/animation/AnimationFunctionalTestBase.java > > > > references com.sun.javafx.functions.Function0, but this class can't be > > found. There is also a commented out section in FloodGame.java in apps > > referencing this class. > > > > This file also has a declaration > > > > protected class SimpleTimeline extends Timeline {... > > > > which gives an error because Timeline is final. > > > > There are more errors there and in its package. What is this package and > > how does it suppose to work? > > From michaelstrau2 at gmail.com Fri May 21 04:36:57 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 21 May 2021 06:36:57 +0200 Subject: Make themes a first-class concept in JavaFX Message-ID: Currently, the two themes shipped with JavaFX (Caspian and Modena) are implemented as a set of stylesheets and some internal logic, mostly in `PlatformImpl`. Much of this logic deals with optional features or platform-specific theme modifications. Another piece of logic deals with accessibility themes: on Windows platforms, both Caspian and Modena have high-contrast stylesheets that are added or removed in response to OS theme changes. Apart from the fact that high-contrast detection only works on English locales (and there's no simple fix, see JDK-8185447), a major downside of this implementation is that it special-cases the built-in themes and doesn't offer enough extension points to make it easy for developers to create new rich themes. I think this can be very much improved by making themes a first-class citizen in JavaFX, and removing the special handling of the two built-in themes. Here's my draft PR of this feature: https://github.com/openjdk/jfx/pull/511 This PR adds a new interface in the javafx.application package: public interface Theme { ObservableList getStylesheets(); void platformThemeChanged(Map properties); } An implementation of this interface populates the list returned by `Theme.getStylesheets()` with its collection of stylesheets. Optionally, it can listen to the platform theme properties reported by `Theme.platformThemeChanged(...)` and modify its list of stylesheets accordingly. Platform properties are platform-specific key-value pairs, and theme implementations are responsible for interpreting the values. For example, on the Windows platform, a theme implementation might listen to the "Windows.SPI_HighContrastOn" property in order to detect whether or not a high-contrast stylesheet should be used. The `Theme` class documents all currently supported platform properties. A theme is activated by setting it as the user-agent stylesheet of the application, where "theme:" is a custom URI scheme: Application.setUserAgentStylesheet("theme:com.example.CustomTheme"); The existing constants `Application.STYLESHEET_CASPIAN` and `Application.STYLESHEET_MODENA` are simply redefined to their new `Theme` implementations ("theme:com.sun.javafx.application.theme.Caspian" and "theme:com.sun.javafx.application.theme.Modena"). Because theme-specific code is now located in its corresponding `Theme` class, I've been able to clean up `PlatformImpl` so that it doesn't special-case the built-in themes anymore. Going forward: If we add support for loading stylesheets from data-URIs (similar to https://github.com/openjdk/jfx/pull/508), we can then fix the high-contrast themes by reading the system colors reported back by Windows, and creating an in-memory stylesheet for these colors within the `Modena` implementation. This feature will also allow developers to create themes that dynamically adjust to OS-level accent colors or dark mode settings. For example, a `Theme` implementation can detect dark mode on Windows 10 by listening to the "Windows.UI.ViewManagement.UISettings.ColorValue_Background" and "Windows.UI.ViewManagement.UISettings.ColorValue_Foreground" properties. I'm looking forward to any opinions on this. From tbee at tbee.org Fri May 21 07:12:00 2021 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 21 May 2021 09:12:00 +0200 Subject: Make themes a first-class concept in JavaFX In-Reply-To: References: Message-ID: I've been a proponent of a theme implementation for a long time, even before JavaFX was separated out (had quite a few discussions with Jonathan about it). So this proposal is great! On 2021-05-21 06:36, Michael Strau? wrote: > Currently, the two themes shipped with JavaFX (Caspian and Modena) are > implemented as a set of stylesheets and some internal logic, mostly in > `PlatformImpl`. > > Much of this logic deals with optional features or platform-specific > theme modifications. Another piece of logic deals with accessibility > themes: on Windows platforms, both Caspian and Modena have > high-contrast stylesheets that are added or removed in response to OS > theme changes. > > Apart from the fact that high-contrast detection only works on English > locales (and there's no simple fix, see JDK-8185447), a major downside > of this implementation is that it special-cases the built-in themes > and doesn't offer enough extension points to make it easy for > developers to create new rich themes. > > I think this can be very much improved by making themes a first-class > citizen in JavaFX, and removing the special handling of the two > built-in themes. Here's my draft PR of this feature: > https://github.com/openjdk/jfx/pull/511 > > This PR adds a new interface in the javafx.application package: > > public interface Theme { > ObservableList getStylesheets(); > void platformThemeChanged(Map properties); > } > > An implementation of this interface populates the list returned by > `Theme.getStylesheets()` with its collection of stylesheets. > Optionally, it can listen to the platform theme properties reported by > `Theme.platformThemeChanged(...)` and modify its list of stylesheets > accordingly. > > Platform properties are platform-specific key-value pairs, and theme > implementations are responsible for interpreting the values. For > example, on the Windows platform, a theme implementation might listen > to the "Windows.SPI_HighContrastOn" property in order to detect > whether or not a high-contrast stylesheet should be used. The `Theme` > class documents all currently supported platform properties. > > A theme is activated by setting it as the user-agent stylesheet of the > application, where "theme:" is a custom URI scheme: > Application.setUserAgentStylesheet("theme:com.example.CustomTheme"); > > The existing constants `Application.STYLESHEET_CASPIAN` and > `Application.STYLESHEET_MODENA` are simply redefined to their new > `Theme` implementations > ("theme:com.sun.javafx.application.theme.Caspian" and > "theme:com.sun.javafx.application.theme.Modena"). > > Because theme-specific code is now located in its corresponding > `Theme` class, I've been able to clean up `PlatformImpl` so that it > doesn't special-case the built-in themes anymore. > > Going forward: If we add support for loading stylesheets from > data-URIs (similar to https://github.com/openjdk/jfx/pull/508), we can > then fix the high-contrast themes by reading the system colors > reported back by Windows, and creating an in-memory stylesheet for > these colors within the `Modena` implementation. > > This feature will also allow developers to create themes that > dynamically adjust to OS-level accent colors or dark mode settings. > For example, a `Theme` implementation can detect dark mode on Windows > 10 by listening to the > "Windows.UI.ViewManagement.UISettings.ColorValue_Background" and > "Windows.UI.ViewManagement.UISettings.ColorValue_Foreground" > properties. > > I'm looking forward to any opinions on this. From fastegal at openjdk.java.net Fri May 21 08:14:45 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 21 May 2021 08:14:45 GMT Subject: RFR: 8264127: ListCell editing status is true, when index changes while editing [v15] In-Reply-To: References: Message-ID: <2C3xy_MHHt3bVv0gnYf-E-Z4tpQU5J08BZr3iD0t0wo=.e164f044-499c-47c8-bf73-49f4ed1dcedc@github.com> On Thu, 20 May 2021 11:12:09 GMT, Florian Kirmaier wrote: >> Fixing ListCell editing status is true, when index changes while editing. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8264127 > small changes based on CR Marked as reviewed by fastegal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From aghaisas at openjdk.java.net Fri May 21 10:28:37 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 21 May 2021 10:28:37 GMT Subject: RFR: 8267392: ENTER key press on editable TableView throws NPE [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 14:15:00 GMT, Marius Hanl wrote: >> ~~Note: I reported the bug already, waiting for approval. Internal tracking id: 9070318. I will update the title as soon as the ticket is created.~~ >> EDIT: Changed the title. :) >> >> This PR is fixing a NP, which is thrown when you press ENTER on an editbale table, after it is initially shown. >> >> When pressing ENTER, **TableViewBehaviorBase#activate** is retrieving the current focused row (**getFocusedCell()**) and from there the corresponding table column. >> This is null, when a table is initially shown. It can also be null, when the items from the underlying table are changed (e.g. **setItems()**) or when **getFocusModel().focus(row)** is used. >> Therefore, null is a valid value and we should guard against it. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment (changed from NP to NPE) Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/505 From tschindl at openjdk.java.net Fri May 21 11:13:44 2021 From: tschindl at openjdk.java.net (Tom Schindl) Date: Fri, 21 May 2021 11:13:44 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace error. For reference this was the code I had around from my first iteration working on that problem diff --git a/modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m b/modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m index 38a828a41e..8657519f13 100644 --- a/modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m +++ b/modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m @@ -247,6 +247,24 @@ jint GetJavaKeyCodeFor(unsigned short keyCode) jint GetJavaKeyCode(NSEvent *event) { + NSString *chars = [event charactersIgnoringModifiers]; + + if ([chars length] > 0) { + NSInteger offset; + + unichar ch = [chars characterAtIndex:0]; + if ([[NSCharacterSet letterCharacterSet] characterIsMember:ch]) { + NSLog(@"Letter char"); + unichar lower; + lower = tolower(ch); + offset = lower - 'a'; + if (offset >= 0 && offset <= 25) { + NSLog(@"Hello Char it is"); + return com_sun_glass_events_KeyEvent_VK_A + offset; + } + } + } + return GetJavaKeyCodeFor([event keyCode]); } ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From aghaisas at openjdk.java.net Fri May 21 11:55:54 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 21 May 2021 11:55:54 GMT Subject: RFR: 8252783: Remove the css Selector and ShapeConverter constructors Message-ID: The javafx.css.Selector and javafx.css.converter.ShapeConverter constructors were deprecated for removal in openjfx16. This PR removes these constructors (targeted for openjfx17). ------------- Commit messages: - 8252783 fix Changes: https://git.openjdk.java.net/jfx/pull/512/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=512&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252783 Stats: 8 lines in 2 files changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/512.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/512/head:pull/512 PR: https://git.openjdk.java.net/jfx/pull/512 From github.com+66004280+maran23 at openjdk.java.net Fri May 21 12:02:35 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Fri, 21 May 2021 12:02:35 GMT Subject: Integrated: 8267392: ENTER key press on editable TableView throws NPE In-Reply-To: References: Message-ID: On Wed, 19 May 2021 00:48:18 GMT, Marius Hanl wrote: > ~~Note: I reported the bug already, waiting for approval. Internal tracking id: 9070318. I will update the title as soon as the ticket is created.~~ > EDIT: Changed the title. :) > > This PR is fixing a NP, which is thrown when you press ENTER on an editbale table, after it is initially shown. > > When pressing ENTER, **TableViewBehaviorBase#activate** is retrieving the current focused row (**getFocusedCell()**) and from there the corresponding table column. > This is null, when a table is initially shown. It can also be null, when the items from the underlying table are changed (e.g. **setItems()**) or when **getFocusModel().focus(row)** is used. > Therefore, null is a valid value and we should guard against it. This pull request has now been integrated. Changeset: 58439103 Author: Marius Hanl Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/5843910333ebdbc4ea14033461e980b0d0692ca8 Stats: 39 lines in 3 files changed: 33 ins; 0 del; 6 mod 8267392: ENTER key press on editable TableView throws NPE Reviewed-by: fastegal, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/505 From jpereda at openjdk.java.net Fri May 21 14:12:28 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 21 May 2021 14:12:28 GMT Subject: RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 Message-ID: This PR limits the `tableIndex` value, used by the LZWDecoder algorithm in `GIFImageLoader2`, to avoid a potential AIOOB exception that happens on some animated GIFs, to the maximum size of the tables used (4096). In some occasions loading an animated GIF like the one used in the included test, doesn't throw such exception, because we `allow partially loaded animated images` in `ImageStorage`, but only a few frames are loaded. In theory, greater values of such index would operate over completely full tables, so there is no need to add new values in this case, and therefore, there is no risk in limiting the value to 4096. This PR will prevent the exception and all the frames should load. The included test passes now (and fails loading only 10 frames out of 44 without the proposed fix). ------------- Commit messages: - Limit tableIndex value to avoid AIOOB exception Changes: https://git.openjdk.java.net/jfx/pull/513/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=513&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267314 Stats: 23 lines in 2 files changed: 11 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/513.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/513/head:pull/513 PR: https://git.openjdk.java.net/jfx/pull/513 From kcr at openjdk.java.net Fri May 21 14:12:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 May 2021 14:12:33 GMT Subject: RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 In-Reply-To: References: Message-ID: On Fri, 21 May 2021 13:02:14 GMT, Jose Pereda wrote: > This PR limits the `tableIndex` value, used by the LZWDecoder algorithm in `GIFImageLoader2`, to avoid a potential AIOOB exception that happens on some animated GIFs, to the maximum size of the tables used (4096). > > In some occasions loading an animated GIF like the one used in the included test, doesn't throw such exception, because we `allow partially loaded animated images` in `ImageStorage`, but only a few frames are loaded. > > In theory, greater values of such index would operate over completely full tables, so there is no need to add new values in this case, and therefore, there is no risk in limiting the value to 4096. > > This PR will prevent the exception and all the frames should load. The included test passes now (and fails loading only 10 frames out of 44 without the proposed fix). The fix seems safe enough, although should have a second reviewer. The test will need changes. modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java line 91: > 89: @Test > 90: public void testLoadAllFramesAnimatedGIF() throws ImageStorageException { > 91: String path = "https://upload.wikimedia.org/wikipedia/commons/2/2c/Rotating_earth_%28large%29.gif"; Except for specific network tests we don't want to load anything from the internet during a run. For one thing this will fail behind a firewall (without setting a proxy, which we don't want to require). For another, the content could change out from under us. The best solution would be to generate a synthetic image with properties that will cause it to fail (we can't use a preexisting image due to copyright issues). ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/513 From kcr at openjdk.java.net Fri May 21 14:15:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 May 2021 14:15:09 GMT Subject: RFR: 8252783: Remove the css Selector and ShapeConverter constructors In-Reply-To: References: Message-ID: <9mpn2KhUcrulwVityaI_lqY5PIkk9YxgHEpXApVv0uI=.1b682866-c9a2-44ba-8309-5e0267147442@github.com> On Fri, 21 May 2021 11:48:21 GMT, Ajit Ghaisas wrote: > The javafx.css.Selector and javafx.css.converter.ShapeConverter constructors were deprecated for removal in openjfx16. > This PR removes these constructors (targeted for openjfx17). Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/512 From michaelstrau2 at gmail.com Fri May 21 15:39:41 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 21 May 2021 17:39:41 +0200 Subject: Make themes a first-class concept in JavaFX In-Reply-To: References: Message-ID: Here's a CSR that explains the details of the proposed public API: https://bugs.openjdk.java.net/browse/JDK-8267540 From kevin.rushforth at oracle.com Fri May 21 16:08:23 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 May 2021 09:08:23 -0700 Subject: Make themes a first-class concept in JavaFX In-Reply-To: References: Message-ID: Please file an Enhancement request first, and from that enhancement create a new CSR. Ideally JBS would prevent direct creation of an issue with an issuetype of CSR. As for the feature itself, it seems useful, but will need discussion as to the value proposition (i.e., cost / benefit), and then agreement on the API itself. One thing that would help in this is some discussion around how an application developer would use it. I have one initial comment on the currently proposed API. You'll likely need to rethink your proposed change to the STYLESHEET_CASPIAN and STYLESHEET_MODENA constants. It seems attractive to change it for consistency, but it is an incompatible change. It is likely there are applications or third-party controls that rely on the current values. Also, it leaks the name of the internal com.sun.javafx.* package where it happens to live today, which is an implementation detail. I think you should stick with the existing constants and translate it on use in the implementation as needed. -- Kevin On 5/21/2021 8:39 AM, Michael Strau? wrote: > Here's a CSR that explains the details of the proposed public API: > https://bugs.openjdk.java.net/browse/JDK-8267540 From pbansal at openjdk.java.net Fri May 21 16:29:08 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 21 May 2021 16:29:08 GMT Subject: RFR: 8252783: Remove the css Selector and ShapeConverter constructors In-Reply-To: References: Message-ID: On Fri, 21 May 2021 11:48:21 GMT, Ajit Ghaisas wrote: > The javafx.css.Selector and javafx.css.converter.ShapeConverter constructors were deprecated for removal in openjfx16. > This PR removes these constructors (targeted for openjfx17). Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/512 From michaelstrau2 at gmail.com Fri May 21 17:03:25 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 21 May 2021 19:03:25 +0200 Subject: Make themes a first-class concept in JavaFX In-Reply-To: References: Message-ID: Good point about the STYLESHEET_CASPIAN and STYLESHEET_MODENA values. Here are a few more aspects for discussion: Any sufficiently sophisticated theme will probably be comprised of several stylesheets. In fact, the built-in themes are a good example for that. Since the current API doesn't allow to specify more than a single user-agent stylesheet, this is quite limiting and requires some workarounds, for example by manually adding auxiliary stylesheets to every Scene. A thing that is quite common for real-world apps is to keep the built-in theme, and then manually add stylesheets that change aspects of the built-in theme. The downside of this is that this creates a dependency on a particular version of the JavaFX built-in theme. A more reliable solution would be to fork the built-in theme and create a custom theme from that. Since the proposed API has a very thin surface and treats themes simply as dynamic collections of stylesheets, forking an existing theme requires duplicating the logic code that might be contained. In order to keep maintenance cost for the OpenJFX project down, interpreting platform theme properties is the sole responsibility of theme developers. This may incur a significant effort, since theme developers may need to understand the meaning behind various optional properties of different platforms. As it stands, platform properties are only reported for Windows platforms. It will require additional development effort to add support for this to other Glass backends. Am Fr., 21. Mai 2021 um 18:08 Uhr schrieb Kevin Rushforth : > > Please file an Enhancement request first, and from that enhancement > create a new CSR. Ideally JBS would prevent direct creation of an issue > with an issuetype of CSR. > > As for the feature itself, it seems useful, but will need discussion as > to the value proposition (i.e., cost / benefit), and then agreement on > the API itself. One thing that would help in this is some discussion > around how an application developer would use it. > > I have one initial comment on the currently proposed API. You'll likely > need to rethink your proposed change to the STYLESHEET_CASPIAN and > STYLESHEET_MODENA constants. It seems attractive to change it for > consistency, but it is an incompatible change. It is likely there are > applications or third-party controls that rely on the current values. > Also, it leaks the name of the internal com.sun.javafx.* package where > it happens to live today, which is an implementation detail. I think you > should stick with the existing constants and translate it on use in the > implementation as needed. > > -- Kevin From mstrauss at openjdk.java.net Fri May 21 17:58:11 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 May 2021 17:58:11 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs Message-ID: This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. ------------- Commit messages: - Added data-URI loading support for images Changes: https://git.openjdk.java.net/jfx/pull/508/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267551 Stats: 437 lines in 8 files changed: 414 ins; 9 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From kevin.rushforth at oracle.com Fri May 21 18:04:34 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 May 2021 11:04:34 -0700 Subject: Support loading images from inline data-URIs In-Reply-To: References: Message-ID: <8b6b4d1b-dcbc-11f3-7599-354131e3b40e@oracle.com> This seems like a very reasonable proposal. I'd like to see it documented in the Image class, so I'll mark it as needing a CSR. -- Kevin On 5/19/2021 1:36 PM, Michael Strau? wrote: > I would like to propose adding support for loading images from inline > data-URIs, as commonly supported by web browsers. > This is a low-impact addition to the image loading infrastructure as > seen in this draft PR: https://github.com/openjdk/jfx/pull/508 > > As a follow-on feature, I'd also like to support loading stylesheets > from data-URIs. > With both features implemented, developers have more flexibility in > working with stylesheets. > > For example, it'd be possible to dynamically generate and add > stylesheets to applications without deploying temporary files on disk. > Another scenario would be to include small theme-specific icons in > their respective stylesheets, which can simplify deployment. > > Any thoughts? From kcr at openjdk.java.net Fri May 21 18:26:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 May 2021 18:26:05 GMT Subject: RFR: 8267425: Intermittent failure of HonorDeveloperSettingsTest unit test In-Reply-To: References: Message-ID: On Thu, 20 May 2021 07:18:28 GMT, Ambarish Rapte wrote: > The same failure was earlier fixed at PR #496, which seems insufficient. > The changes in this PR were also tried ealier in the PR #496 but later removed, as they seemed not necessary. > Fix is to clean up the test, by removing all children added to root and hiding the stage. > The test only fails on the GHA run, if it continues to fail after this fix then we shall skip it till next test sprint. I tried to instrument the code earlier this morning to see what is going on, but I couldn't make it fail, even running it in a loop via GitHub actions on Linux. One thing to note is that the failure suggests some leftover state that has been partially, but not fully cleaned up. Given where the NPE is, there must be a node in the `cacheContainerMap` of `StyleManager` with a non-null scene where the root node of that scene is null. However, unless I'm missing something, this should not be possible since a scene with a null root node is an error. Scene::setRoot throws NPE if you attempt to construct a Scene with a null root or if you later set it to null. Very odd. ------------- PR: https://git.openjdk.java.net/jfx/pull/509 From kcr at openjdk.java.net Fri May 21 18:29:01 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 May 2021 18:29:01 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs In-Reply-To: References: Message-ID: On Wed, 19 May 2021 20:24:31 GMT, Michael Strau? wrote: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. I'd like to see this documented somewhere in the `Image` class docs. ------------- PR: https://git.openjdk.java.net/jfx/pull/508 From jpereda at openjdk.java.net Fri May 21 19:24:19 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 21 May 2021 19:24:19 GMT Subject: RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 [v2] In-Reply-To: References: Message-ID: > This PR limits the `tableIndex` value, used by the LZWDecoder algorithm in `GIFImageLoader2`, to avoid a potential AIOOB exception that happens on some animated GIFs, to the maximum size of the tables used (4096). > > In some occasions loading an animated GIF like the one used in the included test, doesn't throw such exception, because we `allow partially loaded animated images` in `ImageStorage`, but only a few frames are loaded. > > In theory, greater values of such index would operate over completely full tables, so there is no need to add new values in this case, and therefore, there is no risk in limiting the value to 4096. > > This PR will prevent the exception and all the frames should load. The included test passes now (and fails loading only 10 frames out of 44 without the proposed fix). Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Modify test to avoid online resources ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/513/files - new: https://git.openjdk.java.net/jfx/pull/513/files/d6748b89..03897b70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=513&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=513&range=00-01 Stats: 113 lines in 1 file changed: 108 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/513.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/513/head:pull/513 PR: https://git.openjdk.java.net/jfx/pull/513 From jpereda at openjdk.java.net Fri May 21 19:24:20 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 21 May 2021 19:24:20 GMT Subject: RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 13:10:50 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Modify test to avoid online resources > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java line 91: > >> 89: @Test >> 90: public void testLoadAllFramesAnimatedGIF() throws ImageStorageException { >> 91: String path = "https://upload.wikimedia.org/wikipedia/commons/2/2c/Rotating_earth_%28large%29.gif"; > > Except for specific network tests we don't want to load anything from the internet during a run. For one thing this will fail behind a firewall (without setting a proxy, which we don't want to require). For another, the content could change out from under us. > > The best solution would be to generate a synthetic image with properties that will cause it to fail (we can't use a preexisting image due to copyright issues). Okay, I've replaced the test with an encoded image of a single frame. It fails with IAOOB without the fix, passes with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/513 From kcr at openjdk.java.net Fri May 21 20:55:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 May 2021 20:55:15 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction I think the API as currently defined is what we want. Having an explicit direction vector, and then transforming that by the transform of the light is quite flexible in a natural and expected way. I took the existing [`LightMotion`](https://github.com/openjdk/jfx/blob/master/apps/toys/FX8-3DFeatures/src/fx83dfeatures/LightMotion.java) example program, and created a new `SpotLightMotion` program (attached). It's easy to programmatically point the light to the object you wish to illuminate (the sphere or cylinder, in this example). And once you do, rotation works naturally. Here is the code that computes the spot light direction: final Point3D light2Dir = sphereTranslate.subtract(light2Translate); No modification was needed to the existing rotation code. You can run the program and then press `]` to start the red light orbiting in a circle (sorry, no UI controls). [SpotLightMotion.java.txt](https://github.com/openjdk/jfx/files/6524997/SpotLightMotion.java.txt) [SpotLightMotion.diff.log](https://github.com/openjdk/jfx/files/6524999/SpotLightMotion.diff.log) ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mstrauss at openjdk.java.net Fri May 21 22:06:18 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 May 2021 22:06:18 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v2] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Added javadoc ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/4f273d0f..e23ab085 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=00-01 Stats: 65 lines in 3 files changed: 40 ins; 8 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Fri May 21 22:23:21 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 May 2021 22:23:21 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v3] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Added javadoc ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/e23ab085..71eb2d20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Fri May 21 22:25:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 May 2021 22:25:06 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Fri, 14 May 2021 22:29:25 GMT, Kevin Rushforth wrote: > You may be right about the scale problem being preexisting. I'll double check when I test on Mac next week (both Retina and external screen). I can confirm that the scaling problem on macOS Retina a preexisting bug (not related to either this or the earlier addition of attenuation). So I'll file a separate issue for this. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mstrauss at openjdk.java.net Fri May 21 22:36:31 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 21 May 2021 22:36:31 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v4] In-Reply-To: References: Message-ID: <-W1V4N7V6yJwy8SLEyefTE7aJl6bhxfxakuQUGk_dm4=.d8064cff-c0a1-45ed-8196-2e4d19453e9b@github.com> > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - Added javadoc - Added javadoc ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/71eb2d20..07ff1aa4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=02-03 Stats: 49 lines in 1 file changed: 16 ins; 11 del; 22 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From kcr at openjdk.java.net Fri May 21 23:15:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 May 2021 23:15:03 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction Here is the performance of mesh on my macOS system with a discrete graphics chip using the LightingSample test program with a mesh of 1000 quads rendered with 3 point lights: | Run | fps | | ----- | ---- | | Baseline (FX 15) | 25.8 | | After Attenuation added (FX 16) | 15.4 | | SpotLight support (this PR) | 10.6 | This was the same program in all three cases, so no SpotLight and no attenuation. This is the same "worst case" stress test that we used when evaluating attenuation. Hopefully we can optimize and get some of the performance back with optimization. In any case, I think this adds additional motivation for a future Directional Light type that has an optimized shader (in the case of a scene with only directional lights). ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From mstrauss at openjdk.java.net Sat May 22 01:48:25 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 22 May 2021 01:48:25 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v5] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Moved test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/07ff1aa4..3a77ac0b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=03-04 Stats: 44 lines in 3 files changed: 24 ins; 18 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From nlisker at openjdk.java.net Sat May 22 02:35:18 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sat, 22 May 2021 02:35:18 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction Did you test the different `computeSpotlightFactor` methods in the shader? I got some 4 fps difference between the best and worst cases. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at gmail.com Sat May 22 05:56:45 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 22 May 2021 08:56:45 +0300 Subject: .classpath files for Eclipse In-Reply-To: <20210520125211.Horde.QwaUrG1L61tNBZJcCjaTgg9@webmail.df.eu> References: <2076b439-9bb2-d07a-77b1-3f9b4f5ce299@bestsolution.at> <20210520125211.Horde.QwaUrG1L61tNBZJcCjaTgg9@webmail.df.eu> Message-ID: There is an open bug report [1] that I created before the transition to GitHub that fixes BuildSrc and some apps, I will update it for the latest changes. Right now I am waiting to see which folders are still relevant. [1] https://bugs.openjdk.java.net/browse/JDK-8221708 On Thu, May 20, 2021 at 1:52 PM Jeanette Winzenburg wrote: > > Hi Tom, > > can't say anything to your questions: being on win only and just > having Eclipse projects for base, graphics, controls (everything else > is handled by gradle from the commandline) > > -- Jeanette > > Zitat von Tom Schindl : > > > Hi Nir/Jeannette, > > > > As you are both using Eclipse for development I'd like to get your > > take on the following things. > > > > Dealing with OS specific > > ------------------------ > > The graphics module has to have different source folders depending > > on the OS you are developing on: > > * Windows: build/hlsl/Decora and build/hslPrism > > * Linux/OS-X: build/gensrc/jsl-decora build/gensrc/jsl-prism > > > > So when importing the projects Eclipse does not even build anything > > until you fix the .classpath file - I'd like to propose to mark > > those Source-Folders optional. > > > > Swing-Project > > ------------- > > There the .classpath has a none existing "src/test/java" I wonder > > where that source is and if not there anymore remove the offending > > entry from .classpath-File > > > > BuildSrc > > -------- > > What's the purpose of that project? The classpath is incorrect and > > does it have to be a Java-Project? > > > > > > Tom > > > > From fkirmaier at openjdk.java.net Sat May 22 09:29:01 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sat, 22 May 2021 09:29:01 GMT Subject: Integrated: 8264127: ListCell editing status is true, when index changes while editing In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 14:58:40 GMT, Florian Kirmaier wrote: > Fixing ListCell editing status is true, when index changes while editing. This pull request has now been integrated. Changeset: 240d28ff Author: Florian Kirmaier Committer: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/240d28ff4c73777f57fdf88250cceb601e5c18c1 Stats: 151 lines in 2 files changed: 137 ins; 1 del; 13 mod 8264127: ListCell editing status is true, when index changes while editing Reviewed-by: fastegal, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/441 From kcr at openjdk.java.net Sat May 22 11:41:01 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 22 May 2021 11:41:01 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> Message-ID: On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Combined rotation and direction No, but I can do that. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From kcr at openjdk.java.net Sat May 22 12:43:01 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 22 May 2021 12:43:01 GMT Subject: RFR: 8210199: [linux / macOS] fileChooser can't handle emojis In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:42:04 GMT, Jose Pereda wrote: > Both `GlassDialogs.m` for macOS and `GlassCommonDialogs.c` for Linux use UTF8 encoding for the file names selected via native FileChooser, and this will fail if there are emojis in the file name. > > This PR uses the same approach as in [JDK-8258381](https://bugs.openjdk.java.net/browse/JDK-8258381) for macOS, using UTF16 encoding. > > For Linux, the Java `String(byte[] bytes)` constructor with default charset is used instead, preventing the need of using UTF8 encoding. I can reproduce the problem Pankaj reported on Linux, and can confirm that it is unrelated to FileChooser. It looks like some sort of deadlock that happens when calling `java.awt.Desktop::open` from the event handler. I'll file a separate bug for that. I modified the test program to call `Files.readString(file.toPath())` instead, and can confirm that the fix works on Linux as well as on macOS. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/471 From kcr at openjdk.java.net Sat May 22 14:00:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 22 May 2021 14:00:59 GMT Subject: RFR: 8210199: [linux / macOS] fileChooser can't handle emojis In-Reply-To: References: Message-ID: <0mtTFnNFbQqFOtgUE5alcVjunXp6K3CqAQ9HM2D5t9w=.7b2062d2-2a84-460c-b2ed-d3a010210022@github.com> On Wed, 21 Apr 2021 10:42:04 GMT, Jose Pereda wrote: > Both `GlassDialogs.m` for macOS and `GlassCommonDialogs.c` for Linux use UTF8 encoding for the file names selected via native FileChooser, and this will fail if there are emojis in the file name. > > This PR uses the same approach as in [JDK-8258381](https://bugs.openjdk.java.net/browse/JDK-8258381) for macOS, using UTF16 encoding. > > For Linux, the Java `String(byte[] bytes)` constructor with default charset is used instead, preventing the need of using UTF8 encoding. I filed [JDK-8267572](https://bugs.openjdk.java.net/browse/JDK-8267572) to track the hang on Linux. ------------- PR: https://git.openjdk.java.net/jfx/pull/471 From kcr at openjdk.java.net Sat May 22 14:49:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 22 May 2021 14:49:59 GMT Subject: RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 19:24:19 GMT, Jose Pereda wrote: >> This PR limits the `tableIndex` value, used by the LZWDecoder algorithm in `GIFImageLoader2`, to avoid a potential AIOOB exception that happens on some animated GIFs, to the maximum size of the tables used (4096). >> >> In some occasions loading an animated GIF like the one used in the included test, doesn't throw such exception, because we `allow partially loaded animated images` in `ImageStorage`, but only a few frames are loaded. >> >> In theory, greater values of such index would operate over completely full tables, so there is no need to add new values in this case, and therefore, there is no risk in limiting the value to 4096. >> >> This PR will prevent the exception and all the frames should load. The included test passes now (and fails loading only 10 frames out of 44 without the proposed fix). > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Modify test to avoid online resources Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/513 From mstrauss at openjdk.java.net Sat May 22 15:01:27 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 22 May 2021 15:01:27 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v6] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into feature/image-datauri - Moved test - Added javadoc - Added javadoc - Added javadoc - Added javadoc - Added data-URI loading support for images ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/3a77ac0b..4302e9f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=04-05 Stats: 683 lines in 52 files changed: 400 ins; 98 del; 185 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat May 22 15:47:14 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 22 May 2021 15:47:14 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v7] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Changed data URI detection ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/4302e9f1..907bc782 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=05-06 Stats: 65 lines in 6 files changed: 12 ins; 25 del; 28 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From jpereda at openjdk.java.net Sat May 22 19:14:00 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sat, 22 May 2021 19:14:00 GMT Subject: Integrated: 8210199: [linux / macOS] fileChooser can't handle emojis In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:42:04 GMT, Jose Pereda wrote: > Both `GlassDialogs.m` for macOS and `GlassCommonDialogs.c` for Linux use UTF8 encoding for the file names selected via native FileChooser, and this will fail if there are emojis in the file name. > > This PR uses the same approach as in [JDK-8258381](https://bugs.openjdk.java.net/browse/JDK-8258381) for macOS, using UTF16 encoding. > > For Linux, the Java `String(byte[] bytes)` constructor with default charset is used instead, preventing the need of using UTF8 encoding. This pull request has now been integrated. Changeset: aebac072 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/aebac072b1919e68f7732de929dc085d00c62e92 Stats: 15 lines in 2 files changed: 12 ins; 0 del; 3 mod 8210199: [linux / macOS] fileChooser can't handle emojis Reviewed-by: pbansal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/471 From mstrauss at openjdk.java.net Sat May 22 23:31:27 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 22 May 2021 23:31:27 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v8] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - Allow leading and trailing whitespace in data URI - Removed test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/907bc782..d707615e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=06-07 Stats: 35 lines in 3 files changed: 27 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Sat May 22 23:47:21 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 22 May 2021 23:47:21 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v9] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Reverted a change ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/d707615e..30211a4c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From nlisker at openjdk.java.net Sun May 23 00:34:27 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 23 May 2021 00:34:27 GMT Subject: RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 19:24:19 GMT, Jose Pereda wrote: >> This PR limits the `tableIndex` value, used by the LZWDecoder algorithm in `GIFImageLoader2`, to avoid a potential AIOOB exception that happens on some animated GIFs, to the maximum size of the tables used (4096). >> >> In some occasions loading an animated GIF like the one used in the included test, doesn't throw such exception, because we `allow partially loaded animated images` in `ImageStorage`, but only a few frames are loaded. >> >> In theory, greater values of such index would operate over completely full tables, so there is no need to add new values in this case, and therefore, there is no risk in limiting the value to 4096. >> >> This PR will prevent the exception and all the frames should load. The included test passes now (and fails loading only 10 frames out of 44 without the proposed fix). > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Modify test to avoid online resources @jperedadnr Since you're looking at this already, can you check if https://bugs.openjdk.java.net/browse/JDK-8209560 is related? ------------- PR: https://git.openjdk.java.net/jfx/pull/513 From sykora at openjdk.java.net Sun May 23 08:31:08 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Sun, 23 May 2021 08:31:08 GMT Subject: RFR: 8263761: Update boot JDK to 16.0.1 In-Reply-To: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> References: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> Message-ID: On Wed, 19 May 2021 17:28:34 GMT, Kevin Rushforth wrote: > This PR updates the boot JDK for JavaFX builds to use JDK 16.0.1. The minimum version of the JDK remains unchanged at JDK 11. Build and test ran successfully on windows, mac and linux. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/507 From jvos at openjdk.java.net Sun May 23 08:42:39 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 23 May 2021 08:42:39 GMT Subject: RFR: 8263761: Update boot JDK to 16.0.1 In-Reply-To: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> References: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> Message-ID: <3QNi9cOLBjZx47-KxLyT97wJULYyaiflWbq8kImqj7M=.15422821-84db-491e-98a4-71512c24b59b@github.com> On Wed, 19 May 2021 17:28:34 GMT, Kevin Rushforth wrote: > This PR updates the boot JDK for JavaFX builds to use JDK 16.0.1. The minimum version of the JDK remains unchanged at JDK 11. +1 ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/507 From fastegal at openjdk.java.net Sun May 23 10:16:46 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 23 May 2021 10:16:46 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 16:16:16 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' into fixes/JDK-8196065 > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java > - Merge branch 'master' into fixes/JDK-8196065 > - Merge branch 'master' into fixes/JDK-8196065 > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java > - Cleanup > - Fixed clear-and-select change notification > - Add failing tests > - Cleanup > - Added tests > - Fix incorrect index when multiple remove changes are handled in SelectedItemsReadOnlyObservableList > - Add failing test modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableList.java line 54: > 52: while (c.next()) { > 53: if (c.wasReplaced()) { > 54: List removed = getRemovedElements(c, totalRemovedSize); hmm, don't quite understand all the fuss (but might be overlooking something, has been a while since I did a deeper dig into the selection issues ;) - we have a copy of the items (itemsRefs) with the same coordinates we receive from the change - this list is in sync with the indices, that is it contains the items at the respective selectedIndices - currently, that's done in a bulk setting at the end of the listener code Why not sync our copy while working through the change? Doing so, would automatically collect the state of our own change, or what am I missing? ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From jpereda at openjdk.java.net Sun May 23 10:38:45 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sun, 23 May 2021 10:38:45 GMT Subject: RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 [v2] In-Reply-To: References: Message-ID: On Sun, 23 May 2021 00:31:13 GMT, Nir Lisker wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Modify test to avoid online resources > > @jperedadnr Since you're looking at this already, can you check if https://bugs.openjdk.java.net/browse/JDK-8209560 is related? @nlisker yes, I can confirm that all the linked gifs (except 7.gif which is a broken link) work with this PR, fail without it. In all cases, the same AIOOB exception shows up after some frames being loaded. ------------- PR: https://git.openjdk.java.net/jfx/pull/513 From nlisker at openjdk.java.net Sun May 23 10:52:01 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 23 May 2021 10:52:01 GMT Subject: RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 19:24:19 GMT, Jose Pereda wrote: >> This PR limits the `tableIndex` value, used by the LZWDecoder algorithm in `GIFImageLoader2`, to avoid a potential AIOOB exception that happens on some animated GIFs, to the maximum size of the tables used (4096). >> >> In some occasions loading an animated GIF like the one used in the included test, doesn't throw such exception, because we `allow partially loaded animated images` in `ImageStorage`, but only a few frames are loaded. >> >> In theory, greater values of such index would operate over completely full tables, so there is no need to add new values in this case, and therefore, there is no risk in limiting the value to 4096. >> >> This PR will prevent the exception and all the frames should load. The included test passes now (and fails loading only 10 frames out of 44 without the proposed fix). > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Modify test to avoid online resources I closed JDK-8209560 as a duplicate of this one. ------------- PR: https://git.openjdk.java.net/jfx/pull/513 From fastegal at openjdk.java.net Sun May 23 13:59:09 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 23 May 2021 13:59:09 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: On Mon, 17 May 2021 16:16:16 GMT, Michael Strau? wrote: >> The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. >> >> `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' into fixes/JDK-8196065 > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java > - Merge branch 'master' into fixes/JDK-8196065 > - Merge branch 'master' into fixes/JDK-8196065 > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java > - Cleanup > - Fixed clear-and-select change notification > - Add failing tests > - Cleanup > - Added tests > - Fix incorrect index when multiple remove changes are handled in SelectedItemsReadOnlyObservableList > - Add failing test modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableListTest.java line 120: > 118: assertEquals(change(replaced(0, range("foo"), range("bar"))), changes.get(0)); > 119: } > 120: Another thingy I don't quite understand, sry ;) What do you want to test here? We have: selectedItems before: [foo, bar] selectedItems after: [bar, foo] so we need a change (the "should be" snippet in the description of this method) replaced [foo, bar] by [bar, foo] at 0 we get: replaced [foo] by [bar] at 0 which is an incorrect notification (because it's incomplete, doesn't notify at all about the replace at 1) covered by a passing test .. feels fishy. The other way round: if selectedItems cannot react to such a use-case with a correct notification, it might be broken? ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Sun May 23 15:10:04 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 23 May 2021 15:10:04 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: On Sun, 23 May 2021 10:13:48 GMT, Jeanette Winzenburg wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - Merge branch 'master' into fixes/JDK-8196065 >> >> # Conflicts: >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java >> - Merge branch 'master' into fixes/JDK-8196065 >> - Merge branch 'master' into fixes/JDK-8196065 >> >> # Conflicts: >> # modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java >> - Cleanup >> - Fixed clear-and-select change notification >> - Add failing tests >> - Cleanup >> - Added tests >> - Fix incorrect index when multiple remove changes are handled in SelectedItemsReadOnlyObservableList >> - Add failing test > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableList.java line 54: > >> 52: while (c.next()) { >> 53: if (c.wasReplaced()) { >> 54: List removed = getRemovedElements(c, totalRemovedSize); > > hmm, don't quite understand all the fuss (but might be overlooking something, has been a while since I did a deeper dig into the selection issues ;) > > - we have a copy of the items (itemsRefs) with the same coordinates we receive from the change > - this list is in sync with the indices, that is it contains the items at the respective selectedIndices > - currently, that's done in a bulk setting at the end of the listener code > > Why not sync our copy while working through the change? Doing so, would automatically collect the state of our own change, or what am I missing? This was my first thought, too. However, it doesn't work because `SelectedItemsReadOnlyObservableList` doesn't truthfully report its changes, so we can't simply replay its reported changes onto our copy of the items list. For example, consider the following simple piece of code: ListView listView = new ListView<>(FXCollections.observableArrayList("foo", "bar")); MultipleSelectionModel model = listView.getSelectionModel(); model.setSelectionMode(SelectionMode.SINGLE); model.getSelectedIndices().addListener((ListChangeListener)System.out::println); model.select(0); model.select(1); You'd expect the following output: { [0] added at 0 } { [0] replaced by [1] at 0 } However, the actual output is: { [0] added at 0 } { [1] added at 0 } While that is a bug, it almost seems like it is a bug _by design_. `MultipleSelectionModelBase` actually contains lots of code to suppress change notifications. In this particular example, a crucial change notification is suppressed in `MultipleSelectionModelBase:405`: if (getSelectionMode() == SINGLE) { startAtomic(); quietClearSelection(); stopAtomic(); } selectedIndices.set(row); The reason why `MultipleSelectionModelBase` interferes with `selectedIndices` change notifications is to prevent surfacing all kinds of invalid intermediate selection states. I tried to fix this by making `selectedIndices` changes transactional, where each of the `MultipleSelectionModel` operations would be a transaction that silently accumulates changes (clear, set, and so on), and at the end of a transaction, the changes would be distilled down into a single change notification. However, in doing so, I ended up rewriting large parts of `MultipleSelectionModelBase`. This seemed like too big of a change. Also, I noticed that at one point you prototyped a new implementation of `SelectionModel`... maybe starting from scratch is better than adding transactions on top of the existing implementation. > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableListTest.java line 120: > >> 118: assertEquals(change(replaced(0, range("foo"), range("bar"))), changes.get(0)); >> 119: } >> 120: > > Another thingy I don't quite understand, sry ;) > > What do you want to test here? We have: > > selectedItems before: [foo, bar] > selectedItems after: [bar, foo] > > so we need a change (the "should be" snippet in the description of this method) > > replaced [foo, bar] by [bar, foo] at 0 > > we get: > > replaced [foo] by [bar] at 0 > > which is an incorrect notification (because it's incomplete, doesn't notify at all about the replace at 1) covered by a passing test .. feels fishy. The other way round: if selectedItems cannot react to such a use-case with a correct notification, it might be broken? Yes, `selectedItems` is broken. I agree that having an objectively incorrect test pass is fishy, but the alternative would be to not have the test at all, and lose the "free" heads-up if at some point in the future the underlying issue is fixed. Do you think it's better to have the correct test, but ignore it? ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From nlisker at openjdk.java.net Mon May 24 05:08:13 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 24 May 2021 05:08:13 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Update documentation ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/3d6cdb19..6d181b84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=13-14 Stats: 27 lines in 1 file changed: 14 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Mon May 24 05:08:14 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 24 May 2021 05:08:14 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> <-3pQYfaFzDDDaxLFes5JSm93gRpdWWdSfbb_b1AcuVw=.b6a4a21f-7539-4bcc-b765-c0211fbb6149@github.com> Message-ID: On Fri, 16 Apr 2021 13:33:36 GMT, Ambarish Rapte wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 46: >> >>> 44: *

>>> 45: * The light cone is defined by 3 factors: an {@link #innerAngleProperty() inner angle}, an {@link #outerAngleProperty() >>> 46: * outer angle}, and a {@link #falloffProperty() falloff} factor. For a point whose angle to the light is {@code a}, if >> >> -> >> A {@code SpotLight} is a {@code PointLight} that radiates a cone of light in a specific direction. >> < p > >> The direction is defined by the {@link #directionProperty() direction} property. >> The light cone is defined by 3 properties: an {@link #innerAngleProperty() inner angle}, an {@link #outerAngleProperty() outer angle}, and a {@link #falloffProperty() falloff} property. > > Also Will it be illustrative to mention these three properties using li tags with a statement that briefs the use of property. > Something like, > - {@link #innerAngleProperty() inner angle}: Angle of the inner cone where light intensity is always maximum. > - {@link #outerAngleProperty() outer angle}: Angle of the outer cone where light intensity attenuates based on fallof. > - {@link #falloffProperty() falloff}: The attenuation factor that controls the attenuation of light intensity from edge of inner cone to the edge of outer cone. I used bullet points, but the descriptions of the intensity behaviors are described later anyway in more detail, so I kept these short. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Mon May 24 05:08:15 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 24 May 2021 05:08:15 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: <-3pQYfaFzDDDaxLFes5JSm93gRpdWWdSfbb_b1AcuVw=.b6a4a21f-7539-4bcc-b765-c0211fbb6149@github.com> References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> <-3pQYfaFzDDDaxLFes5JSm93gRpdWWdSfbb_b1AcuVw=.b6a4a21f-7539-4bcc-b765-c0211fbb6149@github.com> Message-ID: On Fri, 16 Apr 2021 13:26:56 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Combined rotation and direction > > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 55: > >> 53: * {@code falloff >= 0}; values outside either of these ranges can produce unexpected results. >> 54: *

>> 55: * Image of the Spotlight > > Should we have cone depicted in the diagram ? Not sure how to do that in a clear way. If you want to create an image I will use it. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Mon May 24 06:30:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 24 May 2021 06:30:10 GMT Subject: RFR: 8264140: Add -Djava.security.manager=allow to JavaFX tests calling setSecurityManager In-Reply-To: References: Message-ID: On Thu, 20 May 2021 17:23:56 GMT, Kevin Rushforth wrote: > The security manager is being deprecated for removal by [JEP 411](https://openjdk.java.net/jeps/411), which is proposed for JDK 17. The implementation of JEP 411 is out for review here: openjdk/jdk#4073. > > Along with the deprecation of most security manager classes and methods, the default value of the `java.security.manager` system property will be treated as "`disallow`". This means that the deprecated `System::setSecurityManager` method will throw `UnsupportedOperationException` unless `-Djava.security.manager=allow` is set on the command line. A few system tests and javafx.web unit tests set a security manager and will fail without setting that system property. > > The fix is to set the `-Djava.security.manager=allow` in `build.gradle` when running tests in the `:systemTests` and `:web` projects. Support for setting `java.security.manager` to "`allow`" was added in JDK 12, so we also check that the boot JDK is >= 12 (the check is needed because JDK 11 is the minimum boot JDK). > > As part of this PR I am removing the legacy `ServiceWithSecurityManagerTest` to address [JDK-8234175](https://bugs.openjdk.java.net/browse/JDK-8234175). `ServiceWithSecurityManagerTest` is the only unit test in the `javafx.graphics` module that sets a security manager, and the test has skipped via `@Ignore` since FX 8 with the comment that the test "appears to be bogus". Since there are no active `javafx.graphics` tests that set the security manager, I don't see the need to set `-Djava.security.manager=allow` for `javafx.graphics` tests. Better to just remove the test. > > I have done a full build / test using JDK 15 as a boot JDK. I then did a full build / test using a locally-built JDK 17-ea with the fix for JEP 411, and setting `JDK_HOME` to that JDK. With that, I can confirm that the tests that set the security manager fail without this fix and pass with this fix. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/510 From arapte at openjdk.java.net Mon May 24 11:12:51 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 24 May 2021 11:12:51 GMT Subject: RFR: 8244075: Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene Message-ID: Issue: There are several issues related to Accelerator of MenuItem of a ConextMenu set on Control. 1. Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene 2. Accelerator is not updated correctly when the Control is removed from a Scene and Added to a different Scene 3. Accelerator is not removed from Scene when the anchor node is removed from Scene and then it's ContextMenu is set to null Fix: The accelerator should be added or removed correctly according to the Scene property of the anchor node. The issue#3 in above list is only fixed for Button and fails for other Controls. A test is added for this scenario and I shall report a new issue to address it. Added tests that fails before and pass after the fix. ------------- Commit messages: - corrrections - Correct the listener Changes: https://git.openjdk.java.net/jfx/pull/515/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=515&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244075 Stats: 125 lines in 2 files changed: 112 ins; 12 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/515.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/515/head:pull/515 PR: https://git.openjdk.java.net/jfx/pull/515 From jpereda at openjdk.java.net Mon May 24 12:02:36 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 24 May 2021 12:02:36 GMT Subject: RFR: 8267505: {List, Set, Map}PropertyBase::bind should check against identity Message-ID: ListPropertyBase::bind, SetPropertyBase::bind, MapPropertyBase::bind have a check on whether a different instance of the observable is the same, and this PR changes that to check against identity. Tests are included. ------------- Commit messages: - Check against identity when binding List, Map, Set PropertyBase, and include tests Changes: https://git.openjdk.java.net/jfx/pull/516/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=516&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267505 Stats: 110 lines in 6 files changed: 107 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/516.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/516/head:pull/516 PR: https://git.openjdk.java.net/jfx/pull/516 From kcr at openjdk.java.net Mon May 24 12:09:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 24 May 2021 12:09:52 GMT Subject: Integrated: 8263761: Update boot JDK to 16.0.1 In-Reply-To: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> References: <5EwFnLihwPKKynSpl7xjdN7tmuswGonoEiG9fP3xHWw=.0c4023af-027e-4ac9-acc8-4f76e3fa07d4@github.com> Message-ID: On Wed, 19 May 2021 17:28:34 GMT, Kevin Rushforth wrote: > This PR updates the boot JDK for JavaFX builds to use JDK 16.0.1. The minimum version of the JDK remains unchanged at JDK 11. This pull request has now been integrated. Changeset: 2fd5092a Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/2fd5092accded6f40eb866e5e228aa913dd02463 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8263761: Update boot JDK to 16.0.1 Reviewed-by: arapte, sykora, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/507 From kcr at openjdk.java.net Mon May 24 12:12:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 24 May 2021 12:12:08 GMT Subject: Integrated: 8264140: Add -Djava.security.manager=allow to JavaFX tests calling setSecurityManager In-Reply-To: References: Message-ID: On Thu, 20 May 2021 17:23:56 GMT, Kevin Rushforth wrote: > The security manager is being deprecated for removal by [JEP 411](https://openjdk.java.net/jeps/411), which is proposed for JDK 17. The implementation of JEP 411 is out for review here: openjdk/jdk#4073. > > Along with the deprecation of most security manager classes and methods, the default value of the `java.security.manager` system property will be treated as "`disallow`". This means that the deprecated `System::setSecurityManager` method will throw `UnsupportedOperationException` unless `-Djava.security.manager=allow` is set on the command line. A few system tests and javafx.web unit tests set a security manager and will fail without setting that system property. > > The fix is to set the `-Djava.security.manager=allow` in `build.gradle` when running tests in the `:systemTests` and `:web` projects. Support for setting `java.security.manager` to "`allow`" was added in JDK 12, so we also check that the boot JDK is >= 12 (the check is needed because JDK 11 is the minimum boot JDK). > > As part of this PR I am removing the legacy `ServiceWithSecurityManagerTest` to address [JDK-8234175](https://bugs.openjdk.java.net/browse/JDK-8234175). `ServiceWithSecurityManagerTest` is the only unit test in the `javafx.graphics` module that sets a security manager, and the test has skipped via `@Ignore` since FX 8 with the comment that the test "appears to be bogus". Since there are no active `javafx.graphics` tests that set the security manager, I don't see the need to set `-Djava.security.manager=allow` for `javafx.graphics` tests. Better to just remove the test. > > I have done a full build / test using JDK 15 as a boot JDK. I then did a full build / test using a locally-built JDK 17-ea with the fix for JEP 411, and setting `JDK_HOME` to that JDK. With that, I can confirm that the tests that set the security manager fail without this fix and pass with this fix. This pull request has now been integrated. Changeset: 9507ea41 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/9507ea416a14639ed41e4cfdd87df7c12114078c Stats: 139 lines in 2 files changed: 11 ins; 128 del; 0 mod 8264140: Add -Djava.security.manager=allow to JavaFX tests calling setSecurityManager 8234175: Remove obsolete ServiceWithSecurityManagerTest unit test Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/510 From aghaisas at openjdk.java.net Mon May 24 12:17:01 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 24 May 2021 12:17:01 GMT Subject: RFR: 8265210: TreeCell: cell editing state not updated on cell re-use In-Reply-To: References: Message-ID: On Thu, 13 May 2021 12:22:47 GMT, Jeanette Winzenburg wrote: > fix is analogous to similar issues for Tree/TableCell (combined [JDK-8150525](https://bugs.openjdk.java.net/browse/JDK-8150525) and [JDK-8265206](https://bugs.openjdk.java.net/browse/JDK-8265206)) > > added tests that failed before and passed after the fix > > note: this PR also adds two asserts (which I forgot in the previous [PR 473](https://github.com/openjdk/jfx/pull/473);) in Tree/TableEditingTest which are unrelated to this fix. The fix looks good to me. I have made one minor test cleanup observation. Once fixed, it it ready to be pushed. modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeCellEditingTest.java line 45: > 43: import javafx.scene.control.TreeCell; > 44: import javafx.scene.control.TreeItem; > 45: //import javafx.scene.control.TableColumn; Minor - 2 commented imports can be removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/501 From kcr at openjdk.java.net Mon May 24 12:50:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 24 May 2021 12:50:17 GMT Subject: RFR: 8267505: {List, Set, Map}PropertyBase::bind should check against identity In-Reply-To: References: Message-ID: On Mon, 24 May 2021 11:56:35 GMT, Jose Pereda wrote: > ListPropertyBase::bind, SetPropertyBase::bind, MapPropertyBase::bind have a check on whether a different instance of the observable is the same, and this PR changes that to check against identity. > > Tests are included. This seems like the right fix to me, but it begs the question of why `.equals()` was used in the first place when these classes were created. It's possible that it was just a mistake. Can you think of any cases where two sets that are not the same object, but are `equals` should be treated as the same for the purpose of checking whether to unbind? I can't, but want to take a closer look. ------------- PR: https://git.openjdk.java.net/jfx/pull/516 From fastegal at openjdk.java.net Mon May 24 13:04:46 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 24 May 2021 13:04:46 GMT Subject: RFR: 8265210: TreeCell: cell editing state not updated on cell re-use [v2] In-Reply-To: References: Message-ID: <7W60TYDTAyEakmoZ1hgxy3CRJ-m7zWmoZwk4QAcNcfc=.1474dc26-2fcc-450c-b9ef-18bcc93b42d8@github.com> > fix is analogous to similar issues for Tree/TableCell (combined [JDK-8150525](https://bugs.openjdk.java.net/browse/JDK-8150525) and [JDK-8265206](https://bugs.openjdk.java.net/browse/JDK-8265206)) > > added tests that failed before and passed after the fix > > note: this PR also adds two asserts (which I forgot in the previous [PR 473](https://github.com/openjdk/jfx/pull/473);) in Tree/TableEditingTest which are unrelated to this fix. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: removed commented imports ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/501/files - new: https://git.openjdk.java.net/jfx/pull/501/files/84823ef4..9c0827b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=501&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=501&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/501.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/501/head:pull/501 PR: https://git.openjdk.java.net/jfx/pull/501 From fastegal at openjdk.java.net Mon May 24 13:04:50 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 24 May 2021 13:04:50 GMT Subject: RFR: 8265210: TreeCell: cell editing state not updated on cell re-use [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 12:11:21 GMT, Ajit Ghaisas wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> removed commented imports > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeCellEditingTest.java line 45: > >> 43: import javafx.scene.control.TreeCell; >> 44: import javafx.scene.control.TreeItem; >> 45: //import javafx.scene.control.TableColumn; > > Minor - 2 commented imports can be removed. removed (c&p shows, always ;) - thanks! ------------- PR: https://git.openjdk.java.net/jfx/pull/501 From aghaisas at openjdk.java.net Mon May 24 13:51:22 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 24 May 2021 13:51:22 GMT Subject: RFR: 8265210: TreeCell: cell editing state not updated on cell re-use [v2] In-Reply-To: <7W60TYDTAyEakmoZ1hgxy3CRJ-m7zWmoZwk4QAcNcfc=.1474dc26-2fcc-450c-b9ef-18bcc93b42d8@github.com> References: <7W60TYDTAyEakmoZ1hgxy3CRJ-m7zWmoZwk4QAcNcfc=.1474dc26-2fcc-450c-b9ef-18bcc93b42d8@github.com> Message-ID: <0Ne94647KM_YRrVQezhtcngeEIbvKDZGhSlwMmqzUss=.2e2c0c21-46f4-4ad5-a6ed-ee86d5489894@github.com> On Mon, 24 May 2021 13:04:46 GMT, Jeanette Winzenburg wrote: >> fix is analogous to similar issues for Tree/TableCell (combined [JDK-8150525](https://bugs.openjdk.java.net/browse/JDK-8150525) and [JDK-8265206](https://bugs.openjdk.java.net/browse/JDK-8265206)) >> >> added tests that failed before and passed after the fix >> >> note: this PR also adds two asserts (which I forgot in the previous [PR 473](https://github.com/openjdk/jfx/pull/473);) in Tree/TableEditingTest which are unrelated to this fix. > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > removed commented imports Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/501 From fastegal at openjdk.java.net Mon May 24 14:38:01 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 24 May 2021 14:38:01 GMT Subject: Integrated: 8265210: TreeCell: cell editing state not updated on cell re-use In-Reply-To: References: Message-ID: On Thu, 13 May 2021 12:22:47 GMT, Jeanette Winzenburg wrote: > fix is analogous to similar issues for Tree/TableCell (combined [JDK-8150525](https://bugs.openjdk.java.net/browse/JDK-8150525) and [JDK-8265206](https://bugs.openjdk.java.net/browse/JDK-8265206)) > > added tests that failed before and passed after the fix > > note: this PR also adds two asserts (which I forgot in the previous [PR 473](https://github.com/openjdk/jfx/pull/473);) in Tree/TableEditingTest which are unrelated to this fix. This pull request has now been integrated. Changeset: 24ffe353 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/24ffe353e175d1c4e9824e7ec1840e531014a500 Stats: 383 lines in 5 files changed: 352 ins; 17 del; 14 mod 8265210: TreeCell: cell editing state not updated on cell re-use Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/501 From github.com+12087024+beldenfox at openjdk.java.net Mon May 24 15:28:56 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Mon, 24 May 2021 15:28:56 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace error. Is there some reason you would prefer a Swing-style implementation over the approach I submitted in this PR? The Swing code breaks down if an accelerator calls for the Option modifier alone or in addition to Command. I'm still investigating work-arounds. (Long story short, Command alters the character we receive in a good way, providing a low-ASCII character even on non-ASCII layouts like Cyrillic. Option alters the character in a bad way, often producing an arbitrary symbol. Prior to macOS 10.15 we can't toss one modifier without tossing the other short of using UCKeyTranslate.) ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From jpereda at openjdk.java.net Mon May 24 15:34:10 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 24 May 2021 15:34:10 GMT Subject: RFR: 8267505: {List, Set, Map}PropertyBase::bind should check against identity In-Reply-To: References: Message-ID: On Mon, 24 May 2021 11:56:35 GMT, Jose Pereda wrote: > ListPropertyBase::bind, SetPropertyBase::bind, MapPropertyBase::bind have a check on whether a different instance of the observable is the same, and this PR changes that to check against identity. > > Tests are included. Having a look at the `equals` implementation in ReadOnly{List/Set/Map}Property, it is oriented to check the contents of the collection. For the List case, for instance, `List::equals` javadoc clearly states that > two lists are defined to be equal if they contain the same elements in the same order While this makes sense in many cases, it doesn't for _binding_ a {List/Set/Map}PropertyBase, as we don't bind each collection's items one by one, but the collections themselves. In this case, calling: c.bind(a); c.bind(b); over two different collections, even if they have the exact same content, would necessary imply a change of observables, and the need to unbind first the old binding and update the observable/listener accordingly. If later on `b` is modified, but not `a`, it would be expected that `c` will react to those changes. However, that is not happening as `equals` is currently preventing it. So I can't see a possible use case for this. ------------- PR: https://git.openjdk.java.net/jfx/pull/516 From pedro.duquevieira at gmail.com Mon May 24 15:47:57 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 24 May 2021 16:47:57 +0100 Subject: Make themes a first-class concept in JavaFX Message-ID: Hi, I've been developing JMetro: https://pixelduke.com/java-javafx-theme-jmetro/ , it's a javafx I've been developing since 2013 when I have some free spare time. I thought I'd chime in since this has been an interest of mine for quite some time. A few issues I experience with the current JavaFX API: 1 - Like Michael said here, the current way all themes are usually developed is to extend the default JavaFX theme (currently modena). This has a few problems: 1.1 - If you want it to be a user agent stylesheet you have to copy everything from the default theme into your theme 1.2 - If you're NOT going to go for it being an user agent stylesheet, you simply add your theme "on top" of the default user agent stylesheet (e.g. Modena) but this has a problem because now the rules of your theme will have precedence over rules set through code (e.g. style rules in FXML, style rules in code).. which can be unexpected from a user using the theme. 2 - There's no built-in support for new theme features existing in most Operating Systems nowadays like: dark/light style, chosen accent color... --- I think adding an API to solve this is a good idea. As a first comment and focusing only on the stuff I would change, I don't particularly like the "void platformThemeChanged(Map properties);" Namely the fact that we're using strings to identify properties like whether we use dark or light style, etc. I would prefer as a developer to not have to match strings, etc (which can be a problem if you misspell a string and you'll only notice these problems during runtime). I would like for there to be an API for the user to say whether he wants the dark or light style, also for whether light or dark style is selected in the OS itself. I would also like to have an API for selecting the accent color and to know which accent color is set in the OS. Potentially we could have javafx properties for each one of these, at least for whether we want light or dark style and which accent color we're using. I would also like for there to be some API where one could say whether the theme is supposed to be a user agent stylesheet or not. Allowing one to build on top of the default theme stylesheet (Modena) without copying the default theme definitions but still being able to say that you want your custom theme to be a user agent stylesheet. I don't have much time right now to comment further on the API or give precise suggestions (I'll probably have more time next week) but here's my 2 cents. Thanks, -- Pedro Duque Vieira - https://www.pixelduke.com Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From arapte at openjdk.java.net Mon May 24 16:56:18 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 24 May 2021 16:56:18 GMT Subject: RFR: 8267621: Mark HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle as unstable Message-ID: The test HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle is failing intermittently only on GHA build on Linux platform. see: [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) A fix proposed at #509 is a potential fix which adds cleanup of test. But we do not know the root cause of this failure. Identifying the root cause may take longer which we might push that to next test sprint and the test failure results in failing the Github checks on PR. So we need to mark this test as unstable. As of now the test fails only on Linux so we will mark it unstable only for Linux. ------------- Commit messages: - mark unstable Changes: https://git.openjdk.java.net/jfx/pull/517/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=517&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267621 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/517.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/517/head:pull/517 PR: https://git.openjdk.java.net/jfx/pull/517 From kcr at openjdk.java.net Mon May 24 17:04:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 24 May 2021 17:04:34 GMT Subject: RFR: 8267621: Mark HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle as unstable In-Reply-To: References: Message-ID: On Mon, 24 May 2021 16:48:57 GMT, Ambarish Rapte wrote: > The test HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle is failing intermittently only on GHA build on Linux platform. see: [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) > > A fix proposed at #509 is a potential fix which adds cleanup of test. But we do not know the root cause of this failure. > Identifying the root cause may take longer which we might push that to next test sprint and the test failure results in failing the Github checks on PR. So we need to mark this test as unstable. > As of now the test fails only on Linux so we will mark it unstable only for Linux. Since the NPE is happening in the `setUp` method, which is annotated with `@Before` and runs before the test itself, it seems unlikely that marking just a single test method as unstable is sufficient. ------------- PR: https://git.openjdk.java.net/jfx/pull/517 From arapte at openjdk.java.net Mon May 24 17:11:15 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 24 May 2021 17:11:15 GMT Subject: RFR: 8267621: Mark HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle as unstable In-Reply-To: References: Message-ID: On Mon, 24 May 2021 16:48:57 GMT, Ambarish Rapte wrote: > The test HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle is failing intermittently only on GHA build on Linux platform. see: [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) > > A fix proposed at #509 is a potential fix which adds cleanup of test. But we do not know the root cause of this failure. > Identifying the root cause may take longer which we might push that to next test sprint and the test failure results in failing the Github checks on PR. So we need to mark this test as unstable. > As of now the test fails only on Linux so we will mark it unstable only for Linux. True, it is possible that some other test may fail similarly. Shall we mark all tests as unstable ? ------------- PR: https://git.openjdk.java.net/jfx/pull/517 From kcr at openjdk.java.net Mon May 24 17:16:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 24 May 2021 17:16:16 GMT Subject: RFR: 8267621: Mark HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle as unstable In-Reply-To: References: Message-ID: On Mon, 24 May 2021 16:48:57 GMT, Ambarish Rapte wrote: > The test HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle is failing intermittently only on GHA build on Linux platform. see: [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) > > A fix proposed at #509 is a potential fix which adds cleanup of test. But we do not know the root cause of this failure. > Identifying the root cause may take longer which we might push that to next test sprint and the test failure results in failing the Github checks on PR. So we need to mark this test as unstable. > As of now the test fails only on Linux so we will mark it unstable only for Linux. I would mark the whole class as unstable. You can do this by adding a static method annotated with `@BeforeClass`. Or you can add it to the existing per-test `setUp` method. ------------- PR: https://git.openjdk.java.net/jfx/pull/517 From arapte at openjdk.java.net Mon May 24 17:30:22 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 24 May 2021 17:30:22 GMT Subject: RFR: 8267621: Mark HonorDeveloperSettingsTest as unstable on Linux [v2] In-Reply-To: References: Message-ID: > The test HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle is failing intermittently only on GHA build on Linux platform. see: [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) > > A fix proposed at #509 is a potential fix which adds cleanup of test. But we do not know the root cause of this failure. > Identifying the root cause may take longer which we might push that to next test sprint and the test failure results in failing the Github checks on PR. So we need to mark this test as unstable. > As of now the test fails only on Linux so we will mark it unstable only for Linux. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: mark all tests in HonorDeveloperSettingsTest as unstable ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/517/files - new: https://git.openjdk.java.net/jfx/pull/517/files/310d932b..bebee03d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=517&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=517&range=00-01 Stats: 11 lines in 1 file changed: 8 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/517.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/517/head:pull/517 PR: https://git.openjdk.java.net/jfx/pull/517 From arapte at openjdk.java.net Mon May 24 17:30:22 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 24 May 2021 17:30:22 GMT Subject: RFR: 8267621: Mark HonorDeveloperSettingsTest as unstable on Linux In-Reply-To: References: Message-ID: On Mon, 24 May 2021 16:48:57 GMT, Ambarish Rapte wrote: > The test HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle is failing intermittently only on GHA build on Linux platform. see: [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) > > A fix proposed at #509 is a potential fix which adds cleanup of test. But we do not know the root cause of this failure. > Identifying the root cause may take longer which we might push that to next test sprint and the test failure results in failing the Github checks on PR. So we need to mark this test as unstable. > As of now the test fails only on Linux so we will mark it unstable only for Linux. Both ways are generating same report, But @BeforeClass looks better to me. Shall I change the JBS summary too ? as _Mark HonorDeveloperSettingsTest as unstable on Linux_ ------------- PR: https://git.openjdk.java.net/jfx/pull/517 From kcr at openjdk.java.net Mon May 24 17:30:22 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 24 May 2021 17:30:22 GMT Subject: RFR: 8267621: Mark HonorDeveloperSettingsTest as unstable on Linux In-Reply-To: References: Message-ID: On Mon, 24 May 2021 16:48:57 GMT, Ambarish Rapte wrote: > The test HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle is failing intermittently only on GHA build on Linux platform. see: [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) > > A fix proposed at #509 is a potential fix which adds cleanup of test. But we do not know the root cause of this failure. > Identifying the root cause may take longer which we might push that to next test sprint and the test failure results in failing the Github checks on PR. So we need to mark this test as unstable. > As of now the test fails only on Linux so we will mark it unstable only for Linux. Yes, please update the JBS title and PR title. ------------- PR: https://git.openjdk.java.net/jfx/pull/517 From kcr at openjdk.java.net Mon May 24 22:22:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 24 May 2021 22:22:17 GMT Subject: RFR: 8267621: Mark HonorDeveloperSettingsTest as unstable on Linux [v2] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 17:30:22 GMT, Ambarish Rapte wrote: >> The test HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle is failing intermittently only on GHA build on Linux platform. see: [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) >> >> A fix proposed at #509 is a potential fix which adds cleanup of test. But we do not know the root cause of this failure. >> Identifying the root cause may take longer which we might push that to next test sprint and the test failure results in failing the Github checks on PR. So we need to mark this test as unstable. >> As of now the test fails only on Linux so we will mark it unstable only for Linux. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > mark all tests in HonorDeveloperSettingsTest as unstable Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/517 From arapte at openjdk.java.net Mon May 24 22:22:18 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 24 May 2021 22:22:18 GMT Subject: Integrated: 8267621: Mark HonorDeveloperSettingsTest as unstable on Linux In-Reply-To: References: Message-ID: <0VdLQ9ab-o9C75vqdD1roTOBkgt_MQqqxsCU_1G7Ilo=.9d960ad6-992b-468d-85ce-1514ae6d1ea3@github.com> On Mon, 24 May 2021 16:48:57 GMT, Ambarish Rapte wrote: > The test HonorDeveloperSettingsTest.testOpacityWithManuallyChangedValueAndInlineStyleIsSetToInlineStyle is failing intermittently only on GHA build on Linux platform. see: [JDK-8267425](https://bugs.openjdk.java.net/browse/JDK-8267425) > > A fix proposed at #509 is a potential fix which adds cleanup of test. But we do not know the root cause of this failure. > Identifying the root cause may take longer which we might push that to next test sprint and the test failure results in failing the Github checks on PR. So we need to mark this test as unstable. > As of now the test fails only on Linux so we will mark it unstable only for Linux. This pull request has now been integrated. Changeset: 329013b3 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/329013b321d0f95a26aa70c36b0702dc90e2f56f Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8267621: Mark HonorDeveloperSettingsTest as unstable on Linux Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/517 From michaelstrau2 at gmail.com Mon May 24 22:48:13 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 25 May 2021 00:48:13 +0200 Subject: Make themes a first-class concept in JavaFX In-Reply-To: References: Message-ID: I can understand that parsing string values feels like a very lackluster API. But let me offer a counterpoint: If we provided a set of APIs that exposed particular OS concepts (light/dark mode, accent coloring, etc.), we would commit ourselves to supporting these APIs for new versions of all kinds of operating systems. We'd also need additional APIs to expose whether or not the particular concept is even available on the current OS. I think developers would then also expect us to keep track of the changing trends of OS design and keep offering up-to-date APIs for new features and design trends. That's a significant cost, considering that JavaFX currently doesn't even offer a theme that would need all these APIs (except for high contrast). On the other hand, assuming the proposed minimal `Theme` API, it would be pretty straightforward for a third-party library to implement `Theme` adapters that offer all of the first-class APIs that you discussed. As to you other point: in order to be able to extend the build-in themes, their theme implementations would need to be public API. In general I think that's okay, provided that the inner workings of the default themes remain a "black box". Am Mo., 24. Mai 2021 um 17:48 Uhr schrieb Pedro Duque Vieira : > > Hi, > > I've been developing JMetro: https://pixelduke.com/java-javafx-theme-jmetro/ > , it's a javafx I've been developing since 2013 when I have some free spare > time. > > I thought I'd chime in since this has been an interest of mine for quite > some time. > > A few issues I experience with the current JavaFX API: > > 1 - Like Michael said here, the current way all themes are usually > developed is to extend the default JavaFX theme (currently modena). This > has a few problems: > 1.1 - If you want it to be a user agent stylesheet you have to copy > everything from the default theme into your theme > 1.2 - If you're NOT going to go for it being an user agent stylesheet, you > simply add your theme "on top" of the default user agent stylesheet (e.g. > Modena) but this has a problem because now the rules of your theme will > have precedence over rules set through code (e.g. style rules in FXML, > style rules in code).. which can be unexpected from a user using the theme. > > 2 - There's no built-in support for new theme features existing in most > Operating Systems nowadays like: dark/light style, chosen accent color... > > --- > > I think adding an API to solve this is a good idea. > As a first comment and focusing only on the stuff I would change, I don't > particularly like the "void platformThemeChanged(Map > properties);" > Namely the fact that we're using strings to identify properties like > whether we use dark or light style, etc. I would prefer as a developer to > not have to match strings, etc (which can be a problem if you misspell a > string and you'll only notice these problems during runtime). > I would like for there to be an API for the user to say whether he wants > the dark or light style, also for whether light or dark style is selected > in the OS itself. I would also like to have an API for selecting the accent > color and to know which accent color is set in the OS. > Potentially we could have javafx properties for each one of these, at least > for whether we want light or dark style and which accent color we're using. > > I would also like for there to be some API where one could say whether the > theme is supposed to be a user agent stylesheet or not. Allowing one to > build on top of the default theme stylesheet (Modena) without copying the > default theme definitions but still being able to say that you want your > custom theme to be a user agent stylesheet. > > I don't have much time right now to comment further on the API or give > precise suggestions (I'll probably have more time next week) but here's my > 2 cents. > > Thanks, > > > > -- > Pedro Duque Vieira - https://www.pixelduke.com From mstrauss at openjdk.java.net Mon May 24 23:55:37 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 24 May 2021 23:55:37 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v10] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Rename DataURI.isValidURI ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/30211a4c..edb6f658 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=08-09 Stats: 15 lines in 4 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From nlisker at gmail.com Tue May 25 08:56:44 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 25 May 2021 11:56:44 +0300 Subject: [External] : Re: Minimum JDK policy for OpenJFX In-Reply-To: <568b5a38-006e-9fc8-2687-950a4dcb1e0c@oracle.com> References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> <34340f11-8bb7-7bd6-8110-99ada0eb73be@oracle.com> <568b5a38-006e-9fc8-2687-950a4dcb1e0c@oracle.com> Message-ID: Looks like the new features that we can use are: - Switch expressions - Records - Text blocks - Pattern matching for instanceof None of them seem pressing. When we get the more complete set of pattern matching (with switch, sealed classes, guards...) it will probably be enough to merit an update. On Wed, May 19, 2021 at 6:16 PM Kevin Rushforth wrote: > These are all excellent points. I would add that while a new language > feature would be the biggest reason to update, there could be new JDK API > that we would want to use as an argument type or return type in a new FX > API. I'm not aware of any in the JDK 12-16 range (at least not ones that > don't also have language changes such as records), but it has happened > before. > > So taking all of this into account, it seems that unless someone wants to > make an argument for a feature (language or API) from JDK 12 or later that > we need to use in JavaFX 17, it seems unlikely that we will bump the > minimum. > > -- Kevin > > > On 5/19/2021 7:35 AM, Johan Vos wrote: > > Hi, > > This is an important and good discussion, and I've read a number of valid > points. To reiterate what I've always stated: > * we don't want to increase the base (JDK) version just for the sake of > increasing > * we don't want to lose significant benefits (or developer productivity) > by sticking with old versions. > > This comes down to the question that is indeed the most important: are > there *language* features in JDK 12 or higher that would improve the > quality of OpenJFX? Clearly we're not talking about runtime improvements, > as it's up to the developer/use to choose a runtime. > > Personally, I don't see many possible huge improvements in the JavaFX API > by using JDK 12+ features, but I might be missing things. > > Related to the LTS discussion (disclaimer: just my personal opinion here, > not an "official" Gluon statement): I don't see that as the primary reason > for bumping the dependency. The thing we want to avoid though is that there > is a jump in the required Java SDK inside an LTS family (e.g. JavaFX 11 has > Java 11 as its base, and JavaFX 11.0.12 will have Java 11 as its base as > well). > This might become harder in the future, as I can imagine Valhalla having a > bigger impact on OpenJFX then e.g. Loom. Hence, in case 17 is an LTS > version and it starts being based on Java 11, and in case we decide to bump > the base level for JavaFX 20 to e.g. Java 19, it might become much harder > to backport issues into the 17-tree. > In that spirit, it would make sense to bump the version for 17, but it > seems a bit artificial as the major new language benefits (to OpenJFX) in > the JDK might occur in between 2 LTS families. > > - Johan > > > On Wed, May 19, 2021 at 12:39 AM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> You raise a good point about whether or not it should matter if a >> version is (generally considered to be) an LTS release. I wasn't >> suggesting that we necessarily wait until the next LTS to consider >> picking up an important new feature, just that it could be one factor. I >> also would be very interested to hear from Gluon on this point. >> >> Your second point is the more interesting one. It comes down to the >> question of when is there a new feature (or set of new features) that is >> compelling enough that we want to require that version of the JDK in >> order to be able to use it. >> >> So for this specific discussion: Is there any language feature or API in >> JDK 12 - 16 that is compelling enough that we would want to bump the JDK >> in order to be able to use it? >> >> -- Kevin >> >> >> On 5/18/2021 2:42 PM, Nir Lisker wrote: >> > >> > there are some advantages in being able to run with the latest JDK >> LTS >> > >> > >> > One *potential* issue with this approach is that LTS is not defined in >> > OpenJDK as far as I know. The LTS versions are a business decision of >> > each distributor. For now, they have all aligned on 8, 11, 17, but >> > nothing guarantees that this will stay so. What if different vendors >> > LTS different versions? Suppose that Valhalla and Loom add very >> > attractive features in JDK 19 (big performance enhancements, leads to >> > big money savings on hardware, leads to economic incentives to use >> > these, leads to requests to support these), now vendors can declare >> > JDK 19 as LTS, and what will JavaFX do? >> > In OpenJDK all versions are treated equally as it is a spec and not a >> > business model. Should JavaFX be coupled to business models? Maybe >> > Gluon has some insights since they give JavaFX LTS support. >> > >> > A second point, as Michael Strau? mentioned, is that maybe we should >> > see what features are going to be delivered in the next versions and >> > judge if there's something attractive enough for library developers to >> > base our decision on. Sealed classes from Amber are certainly one of >> > them. Panama might provide handy features for JavaFX's interfacing >> > with native code, like Foreign Memory Access, though I didn't look >> > into it in detail. Valhalla is certainly too far away to consider, and >> > Loom is rather irrelevant for JavaFX and GUIs in general. >> > If anyone has insights into relevant upcoming features I'll be happy >> > to learn. >> > >> > - Nir >> > >> > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth >> > > wrote: >> > >> > A very timely question. I was already planning to raise this as a >> > discussion after we update our boot JDK to JDK 16 (blocked by the >> > in-progress gradle 7 update), which I hope to do later this week. >> > >> > I think that this is the right time to consider bumping the minimum >> > required version to run JavaFX 17 to JDK 16, which would allow us to >> > start using APIs and language features from JDK 12 through JDK 16 >> > inclusive. >> > >> > In general, we only guarantee that JavaFX N runs on JDK N-1 or >> > later. In >> > practice, though, we don't bump it for each release, as there are >> > some >> > advantages in being able to run with the latest JDK LTS. Since >> > JavaFX 17 >> > will release at roughly the same time as JDK 17 LTS, I can't think >> > of a >> > good reason to not update our minimum. >> > >> > Comments? >> > >> > -- Kevin >> > >> > >> > On 5/18/2021 7:59 AM, Michael Strau? wrote: >> > > Currently, JDK 11 is required for the latest version of OpenJFX. >> > What >> > > is the policy for bumping this requirement? Does it always >> > correspond >> > > to the latest JDK LTS release (the next of which will be JDK 17), >> or >> > > is it independent from the release cycle of OpenJDK? >> > >> >> > From nlisker at gmail.com Tue May 25 08:59:42 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 25 May 2021 11:59:42 +0300 Subject: Minimum JDK policy for OpenJFX In-Reply-To: References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: I looked at jextract a while back. I got the impression that it's more useful when you need to generate new bindings, at the very least because there are fewer ways to make mistakes. Most of the work on JavaFX has already been done in this area and the mistakes have been found and fixed by now, so is there any substantial value in redoing it with jextract? On Thu, May 20, 2021 at 12:25 AM Ty Young wrote: > If you want to learn more about Panama you can read the JEP page: > > > https://openjdk.java.net/jeps/412 > > > You can also join the panama-dev list and ask questions: > > > https://mail.openjdk.java.net/mailman/listinfo/panama-dev > > > Biggest things for JavaFX that I can think of is jextract, a tool for > generating Java headers from a C header, and having all binding code > written in Java. It may be easier to upgrade to newer GTK versions using > Panama as there is no C shim required and the bindings are, again, > generated for you. jextract does have issues, one of which is that any > binding generated using it are platform-specific even if the library > itself is cross-platform. You can make bindings by hand that are > cross-platform if you want, though. > > > Speaking of GTK, when is JavaFX going to support GTK4? > > > > > On 5/18/21 4:42 PM, Nir Lisker wrote: > >> there are some advantages in being able to run with the latest JDK LTS > >> > > One *potential* issue with this approach is that LTS is not defined in > > OpenJDK as far as I know. The LTS versions are a business decision of > each > > distributor. For now, they have all aligned on 8, 11, 17, but nothing > > guarantees that this will stay so. What if different vendors LTS > different > > versions? Suppose that Valhalla and Loom add very attractive features in > > JDK 19 (big performance enhancements, leads to big money savings on > > hardware, leads to economic incentives to use these, leads to requests to > > support these), now vendors can declare JDK 19 as LTS, and what will > JavaFX > > do? > > In OpenJDK all versions are treated equally as it is a spec and not a > > business model. Should JavaFX be coupled to business models? Maybe Gluon > > has some insights since they give JavaFX LTS support. > > > > A second point, as Michael Strau? mentioned, is that maybe we should see > > what features are going to be delivered in the next versions and judge if > > there's something attractive enough for library developers to base our > > decision on. Sealed classes from Amber are certainly one of them. Panama > > might provide handy features for JavaFX's interfacing with native code, > > like Foreign Memory Access, though I didn't look into it in detail. > > Valhalla is certainly too far away to consider, and Loom is rather > > irrelevant for JavaFX and GUIs in general. > > If anyone has insights into relevant upcoming features I'll be happy to > > learn. > > > > - Nir > > > > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth < > kevin.rushforth at oracle.com> > > wrote: > > > >> A very timely question. I was already planning to raise this as a > >> discussion after we update our boot JDK to JDK 16 (blocked by the > >> in-progress gradle 7 update), which I hope to do later this week. > >> > >> I think that this is the right time to consider bumping the minimum > >> required version to run JavaFX 17 to JDK 16, which would allow us to > >> start using APIs and language features from JDK 12 through JDK 16 > >> inclusive. > >> > >> In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In > >> practice, though, we don't bump it for each release, as there are some > >> advantages in being able to run with the latest JDK LTS. Since JavaFX 17 > >> will release at roughly the same time as JDK 17 LTS, I can't think of a > >> good reason to not update our minimum. > >> > >> Comments? > >> > >> -- Kevin > >> > >> > >> On 5/18/2021 7:59 AM, Michael Strau? wrote: > >>> Currently, JDK 11 is required for the latest version of OpenJFX. What > >>> is the policy for bumping this requirement? Does it always correspond > >>> to the latest JDK LTS release (the next of which will be JDK 17), or > >>> is it independent from the release cycle of OpenJDK? > >> > From arapte at openjdk.java.net Tue May 25 09:40:16 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 25 May 2021 09:40:16 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15] In-Reply-To: References: Message-ID: <7L8s7FBgIXgIZS5Tw2eeRDpxMgPRYYizMaFdKGQkSD0=.b76290fa-1aa8-4945-bfae-1490ec3cff28@github.com> On Mon, 24 May 2021 05:08:13 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update documentation Hello Nir, could you please merge this branch with latest master. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From youngty1997 at gmail.com Tue May 25 10:13:59 2021 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 25 May 2021 05:13:59 -0500 Subject: Minimum JDK policy for OpenJFX In-Reply-To: References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: <40456965-1aab-13f4-4cf3-41da70641b80@gmail.com> GTK4 was just released not that long ago. I don't know how much(if any at all) code is shared between versions, but having a tool like jextract might be useful for adding support for that. Just a guess. Also, the bindings are different in that, for everything not a primitive in java(except boolean and char), you need to allocate memory and pass the address of the memory to the function(e.g. structs, unions, arrays). You also need to, depending on which ResourceScope is used, explicitly free your memory. And, again, everything is in Java. Maybe the ability to allocate off-heap arrays is useful somehow? Maybe to somehow reduce GC pressure when resizing the application or something? On 5/25/21 3:59 AM, Nir Lisker wrote: > I looked at jextract a while back. I got the impression that it's more > useful when you need to generate new bindings,?at the very least > because there are fewer?ways to make mistakes. Most of the work on > JavaFX has already been done in this area and the mistakes have been > found and fixed by now, so is there any substantial value in redoing > it with jextract? > > On Thu, May 20, 2021 at 12:25 AM Ty Young > wrote: > > If you want to learn more about Panama you can read the JEP page: > > > https://openjdk.java.net/jeps/412 > > > You can also join the panama-dev list and ask questions: > > > https://mail.openjdk.java.net/mailman/listinfo/panama-dev > > > > Biggest things for JavaFX that I can think of is jextract, a tool for > generating Java headers from a C header, and having all binding code > written in Java. It may be easier to upgrade to newer GTK versions > using > Panama as there is no C shim required and the bindings are, again, > generated for you. jextract does have issues, one of which is that > any > binding generated using it are platform-specific even if the library > itself is cross-platform. You can make bindings by hand that are > cross-platform if you want, though. > > > Speaking of GTK, when is JavaFX going to support GTK4? > > > > > On 5/18/21 4:42 PM, Nir Lisker wrote: > >> there are some advantages in being able to run with the latest > JDK LTS > >> > > One *potential* issue with this approach is that LTS is not > defined in > > OpenJDK as far as I know. The LTS versions are a business > decision of each > > distributor. For now, they have all aligned on 8, 11, 17, but > nothing > > guarantees that this will stay so. What if different vendors LTS > different > > versions? Suppose that Valhalla and Loom add very attractive > features in > > JDK 19 (big performance enhancements, leads to big money savings on > > hardware, leads to economic incentives to use these, leads to > requests to > > support these), now vendors can declare JDK 19 as LTS, and what > will JavaFX > > do? > > In OpenJDK all versions are treated equally as it is a spec and > not a > > business model. Should JavaFX be coupled to business models? > Maybe Gluon > > has some insights since they give JavaFX LTS support. > > > > A second point, as Michael Strau? mentioned, is that maybe we > should see > > what features are going to be delivered in the next versions and > judge if > > there's something attractive enough for library developers to > base our > > decision on. Sealed classes from Amber are certainly one of > them. Panama > > might provide handy features for JavaFX's interfacing with > native code, > > like Foreign Memory Access, though I didn't look into it in detail. > > Valhalla is certainly too far away to consider, and Loom is rather > > irrelevant for JavaFX and GUIs in general. > > If anyone has insights into relevant upcoming features I'll be > happy to > > learn. > > > > - Nir > > > > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth > > > > wrote: > > > >> A very timely question. I was already planning to raise this as a > >> discussion after we update our boot JDK to JDK 16 (blocked by the > >> in-progress gradle 7 update), which I hope to do later this week. > >> > >> I think that this is the right time to consider bumping the minimum > >> required version to run JavaFX 17 to JDK 16, which would allow > us to > >> start using APIs and language features from JDK 12 through JDK 16 > >> inclusive. > >> > >> In general, we only guarantee that JavaFX N runs on JDK N-1 or > later. In > >> practice, though, we don't bump it for each release, as there > are some > >> advantages in being able to run with the latest JDK LTS. Since > JavaFX 17 > >> will release at roughly the same time as JDK 17 LTS, I can't > think of a > >> good reason to not update our minimum. > >> > >> Comments? > >> > >> -- Kevin > >> > >> > >> On 5/18/2021 7:59 AM, Michael Strau? wrote: > >>> Currently, JDK 11 is required for the latest version of > OpenJFX. What > >>> is the policy for bumping this requirement? Does it always > correspond > >>> to the latest JDK LTS release (the next of which will be JDK > 17), or > >>> is it independent from the release cycle of OpenJDK? > >> > From nlisker at openjdk.java.net Tue May 25 10:41:05 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 25 May 2021 10:41:05 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v16] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: - Merge remote-tracking branch 'origin/master' into 8234920_Add_SpotLight_to_the_selection_of_3D_light_types - Merge branch 'master' into 8234920_Add_SpotLight_to_the_selection_of_3D_light_types - Update documentation - Combined rotation and direction - Corrected light direction in the es2 pipeline - Restored PointLight test - Removed whitespace - Updated the system test - Merge remote-tracking branch 'nlisker/8234920_Add_SpotLight_to_the_selection_of_3D_light_types' into 8234920_Add_SpotLight_to_the_selection_of_3D_light_types - Merge remote-tracking branch - ... and 25 more: https://git.openjdk.java.net/jfx/compare/329013b3...1cff7527 ------------- Changes: https://git.openjdk.java.net/jfx/pull/334/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=15 Stats: 1727 lines in 40 files changed: 1302 ins; 108 del; 317 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From tschindl at openjdk.java.net Tue May 25 10:44:00 2021 From: tschindl at openjdk.java.net (Tom Schindl) Date: Tue, 25 May 2021 10:44:00 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 15:25:22 GMT, Martin Fox wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed whitespace error. > > Is there some reason you would prefer a Swing-style implementation over the approach I submitted in this PR? The Swing code breaks down if an accelerator calls for the Option modifier alone or in addition to Command. I'm still investigating work-arounds. > > (Long story short, Command alters the character we receive in a good way, providing a low-ASCII character even on non-ASCII layouts like Cyrillic. Option alters the character in a bad way, often producing an arbitrary symbol. Prior to macOS 10.15 we can't toss one modifier without tossing the other short of using UCKeyTranslate.) @beldenfox I did not say that the swing version is the way to go and in the end its @kevinrushforth call what route should be taken - I just wanted to show what my initial change would have been without saying it is better than what you are proposing which sounds like is more complete than what swing provides today. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From pedro.duquevieira at gmail.com Tue May 25 11:06:26 2021 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 25 May 2021 12:06:26 +0100 Subject: Make themes a first-class concept in JavaFX In-Reply-To: References: Message-ID: Again thanks for bringing this up into discussion and for taking the time to file a PR, etc. I like the idea of having better support for themes. Regarding your first point: 1 - To keep it simple we can discard the idea of having an API to be able to check what are the OS settings for dark/light, accent color, etc, for now. I think that this can be a separate discussion. We could simply start by having an API that a theme has to implement (probably an interface that the theme has to implement like what I think happens with your proposed API). That API has properties: dark/light style, accent color, etc. Each theme can decide to respond or not to changes in those properties hence decide whether or not to support these features. Regarding the second point: 2 - Not sure I explained myself well. What I meant was that right now, and it happens to all themes I know of, theme creators decide to extend the Modena theme. What I mean by "extend" is that they add stylesheets to the Scene/Parent (without being user agent stylesheets). This means they simply build on top of the rules in Modena which is much easier/better but also means that the rules they define in their stylesheets will trump any rules defined by the theme users in their FXMLs, stylesheets (depending on specificity of their rules in their stylesheets), code... I think this can be confusing and not ideal for users of these themes, and I find most of the time theme users don't even know about JavaFX user agent stylesheets feature vs Scene/Parent stylesheets and what that implies. What I would propose is to have an API, perhaps in this theme interface, that toggles whether the theme, theme creators are creating will be a user agent stylesheet or a regular stylesheet. The advantage would be that if it is a user agent stylesheet developers won't need to copy all Modena definitions into their theme stylesheets, they can simply toggle this boolean to say what kind of stylesheet they want their theme to be. Thanks, On Mon, May 24, 2021 at 11:48 PM Michael Strau? wrote: > I can understand that parsing string values feels like a very > lackluster API. But let me offer a counterpoint: > > If we provided a set of APIs that exposed particular OS concepts > (light/dark mode, accent coloring, etc.), we would commit ourselves to > supporting these APIs for new versions of all kinds of operating > systems. We'd also need additional APIs to expose whether or not the > particular concept is even available on the current OS. I think > developers would then also expect us to keep track of the changing > trends of OS design and keep offering up-to-date APIs for new features > and design trends. That's a significant cost, considering that JavaFX > currently doesn't even offer a theme that would need all these APIs > (except for high contrast). > > On the other hand, assuming the proposed minimal `Theme` API, it would > be pretty straightforward for a third-party library to implement > `Theme` adapters that offer all of the first-class APIs that you > discussed. > > As to you other point: in order to be able to extend the build-in > themes, their theme implementations would need to be public API. In > general I think that's okay, provided that the inner workings of the > default themes remain a "black box". > > > > Am Mo., 24. Mai 2021 um 17:48 Uhr schrieb Pedro Duque Vieira > : > > > > Hi, > > > > I've been developing JMetro: > https://pixelduke.com/java-javafx-theme-jmetro/ > > , it's a javafx I've been developing since 2013 when I have some free > spare > > time. > > > > I thought I'd chime in since this has been an interest of mine for quite > > some time. > > > > A few issues I experience with the current JavaFX API: > > > > 1 - Like Michael said here, the current way all themes are usually > > developed is to extend the default JavaFX theme (currently modena). This > > has a few problems: > > 1.1 - If you want it to be a user agent stylesheet you have to copy > > everything from the default theme into your theme > > 1.2 - If you're NOT going to go for it being an user agent stylesheet, > you > > simply add your theme "on top" of the default user agent stylesheet (e.g. > > Modena) but this has a problem because now the rules of your theme will > > have precedence over rules set through code (e.g. style rules in FXML, > > style rules in code).. which can be unexpected from a user using the > theme. > > > > 2 - There's no built-in support for new theme features existing in most > > Operating Systems nowadays like: dark/light style, chosen accent color... > > > > --- > > > > I think adding an API to solve this is a good idea. > > As a first comment and focusing only on the stuff I would change, I don't > > particularly like the "void platformThemeChanged(Map > > properties);" > > Namely the fact that we're using strings to identify properties like > > whether we use dark or light style, etc. I would prefer as a developer to > > not have to match strings, etc (which can be a problem if you misspell a > > string and you'll only notice these problems during runtime). > > I would like for there to be an API for the user to say whether he wants > > the dark or light style, also for whether light or dark style is selected > > in the OS itself. I would also like to have an API for selecting the > accent > > color and to know which accent color is set in the OS. > > Potentially we could have javafx properties for each one of these, at > least > > for whether we want light or dark style and which accent color we're > using. > > > > I would also like for there to be some API where one could say whether > the > > theme is supposed to be a user agent stylesheet or not. Allowing one to > > build on top of the default theme stylesheet (Modena) without copying the > > default theme definitions but still being able to say that you want your > > custom theme to be a user agent stylesheet. > > > > I don't have much time right now to comment further on the API or give > > precise suggestions (I'll probably have more time next week) but here's > my > > 2 cents. > > > > Thanks, > > > > > > > > -- > > Pedro Duque Vieira - https://www.pixelduke.com > -- Pedro Duque Vieira - https://www.pixelduke.com From arapte at openjdk.java.net Tue May 25 11:49:24 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 25 May 2021 11:49:24 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream Message-ID: `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. I have tried three approaches and tested with modena.css which is ~134 KB in size. Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms The time taken by `StyleManager.calculateCheckSum()` with current implementation is, - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. However we can choose approach#2 also. If we choose approach#3 then bug summary should be changed accordingly. ------------- Commit messages: - only buffer[4096], similar to NativeLibLoader.calculateCheckSum() - BufferedInputStream + buffer[4096] - use BufferedInputStream Changes: https://git.openjdk.java.net/jfx/pull/518/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=518&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239138 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/518.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/518/head:pull/518 PR: https://git.openjdk.java.net/jfx/pull/518 From sykora at openjdk.java.net Tue May 25 12:03:58 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Tue, 25 May 2021 12:03:58 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Thu, 13 May 2021 19:11:26 GMT, John Neffenger wrote: >> John Neffenger has updated the pull request incrementally with one additional commit since the last revision: >> >> Skip sending telemetry to fix "file in use" error > > I wrote a Bash shell script, included below, that can help in reviewing this pull request. It isolates the call to `vcvarsall.bat`, making it easier to experiment with different choices, such as: > > - leaving `VSCMD_SKIP_SENDTELEMETRY` undefined, > - adding the `/q` option to `cmd`, > - removing `2>&1` to use the default standard error, or > - discarding standard output with `> /dev/null`. > > > #!/bin/bash > # Tests the Visual Studio 'vcvarsall.bat' batch file > trap exit INT TERM > set -o errexit > > # Path to 'vcvarsall.bat' batch file > vsroot="C:\\Program Files (x86)\\Microsoft Visual Studio" > vcfile="2019\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat" > vcpath="$vsroot\$vcfile" > > # Windows command interpreter and options > # /C Carries out the command specified by string and then terminates > # /Q Turns echo off > command="cmd /c" > > # Skips calling PowerShell script to send telemetry > export VSCMD_SKIP_SENDTELEMETRY="1" > printf "VSCMD_SKIP_SENDTELEMETRY="%s"\n" "$VSCMD_SKIP_SENDTELEMETRY" > > # VSCMD_DEBUG undefined > unset VSCMD_DEBUG > printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG" > $command "$vcpath" x86 > 0-debug.log 2>&1 > $command "$vcpath" x64 >> 0-debug.log 2>&1 > > # VSCMD_DEBUG = 1 (basic), 2 (detailed), and 3 (trace) > for n in 1 2 3; do > export VSCMD_DEBUG="$n" > printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG" > $command "$vcpath" x86 > $n-debug.log 2>&1 > $command "$vcpath" x64 >> $n-debug.log 2>&1 > done > > > I run the script under Cygwin on Windows and evaluate its output as follows: > > > $ ./vcvarstest.sh > VSCMD_SKIP_SENDTELEMETRY="1" > Testing VSCMD_DEBUG="" > Testing VSCMD_DEBUG="1" > Testing VSCMD_DEBUG="2" > Testing VSCMD_DEBUG="3" > $ wc -l *.log > 10 0-debug.log > 92 1-debug.log > 508 2-debug.log > 5690 3-debug.log > 6300 total @jgneff, do you have an idea of what kind of errors would be better detected with these changes? For instance, I've changed the `PATH` environment variable so that it no longer includes `/cygdrive/c/Windows/System32`. When running `./gradlew help` it fails as expected with the known message: > FAIL: WINSDK_DIR not defined However, while inspecting the `build/vcvarsall.log` file to look for clues, it didn't reveal anything interesting to point me to the possible cause of the gradle failure. From the looks of it, it even seems to have been successfully executed. ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From kcr at openjdk.java.net Tue May 25 12:39:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 25 May 2021 12:39:59 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream In-Reply-To: References: Message-ID: On Tue, 25 May 2021 09:04:07 GMT, Ambarish Rapte wrote: > `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. > > I have tried three approaches and tested with modena.css which is ~134 KB in size. > Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, > > 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : > - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms > 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) > - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms > 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. > - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms > > > The time taken by `StyleManager.calculateCheckSum()` with current implementation is, > - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms > > > Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. > However we can choose approach#2 also. > If we choose approach#3 then bug summary should be changed accordingly. I also prefer approach 3, since the body of the try/finally loop is then identical to that of `NativeLibLoader::calculateCheckSum`. Can you add a unit test to validate the checksum method? It should be sufficient to do this by taking a file that is > 4096 bytes, but not a multiple of 4096, manually running `md5sum` on it to get its checksum that you can then use to compare with the computed one. ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From arapte at openjdk.java.net Tue May 25 14:45:59 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 25 May 2021 14:45:59 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 05:08:13 GMT, Nir Lisker wrote: >> Added a SpotLight only to the D3D pipeline currently. >> >> ### API discussion points >> >> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. >> >> - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? >> >> - [ ] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. >> >> ### Implementation discussion points >> >> - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. >> >> ## Performance >> >> Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. >> Using an AMD RX 470 4GB GPU. >> >> In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. >> >> ### Results >> The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. >> >> The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). >> >> **Win 10** >> Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. >> >> **Ubuntu 18** >> The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. >> The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). >> >> **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Update documentation Suggested few doc changes. I have little concern about how the angle of cone/illumination of point is described. Have put a comment for innerAngle description and similar would apply to outer angle. modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGPointLight.java line 48: > 46: /** > 47: * The direction of a {@code SpotLight} that simulates a {@code PointLight}. > 48: * Since the light radiates equaly in all directions, this value is meaningless. minor: equaly -> equally modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 167: > 165: // float attenuationFactor = 1/(c + cL * d + cQ * d * d); > 166: // float intensity = rL * 0.299f + gL * 0.587f + bL * 0.114f; > 167: // intensity *= attenuationFactor; minor: align the `//` or remove them. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 48: > 46: * rotated 90 degrees on the y axis, it will point in the {@code (1, 1, -1)} direction. > 47: *

> 48: * In addition to the attenuation factors defined in {@code PointLight}, the {@code Spotlight}'s intensity is also {@code Spotlight}'s -> {@code Spot**L**ight}'s modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 49: > 47: *

> 48: * In addition to the attenuation factors defined in {@code PointLight}, the {@code Spotlight}'s intensity is also > 49: * affected by 3 factors: I think instead of phrasing it as "**affected** by 3 factors", it should be phrased as something like, `the SpotLight is defined by 3 more properties` Or `the SpotLight possesses 3 more properties` ? modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 142: > 140: > 141: /** > 142: * The angle of the spotlight's inner cone. Surfaces whose angle to the light's origin is less than this angle angle of a cone is angle between the two sides of cone or the total angle of cone. Here we are referring to an angle between the Light's direction vector and any side of cone. which would be half of the angle of a cone. So should we mention it here ? 1. Half of the inner cone angle Or 2. Angle between the direction vector of light and edge/side of cone. Am I over thinking here ? Or we should not describe the behavior in terms of angle but mention it in terms of location/distance of a point. If point is inside the cone or outside the cone, distance of the point from the centre of cone. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 143: > 141: /** > 142: * The angle of the spotlight's inner cone. Surfaces whose angle to the light's origin is less than this angle > 143: * receive the full light's intensity. At larger angles, the light intensity starts to drop. The valid range is The light is brightest at the centre of the cone(inner cone), and light intensity won't be same for all points that fall inside the inner cone. Light intensity reduces as the distance of point from centre of cone increases. so the statement "Surfaces whose angle to the light's origin is less than this angle receive the full light's intensity" won't be accurate. Also I would suggest to mention in terms of point instead of surface. modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 171: > 169: * The angle of the spotlight's outer cone. Surfaces whose angle to the light's origin is greater than this angle > 170: * receive no light. At smaller angles, the light intensity starts to increase. The valid range is > 171: * {@code innerAngle <= outerAngle <= 180}; values outside of this range can produce unexpected results. Similar to innerAngle comment. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Tue May 25 14:45:59 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 25 May 2021 14:45:59 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v14] In-Reply-To: References: <6tAS-nL1RFQPeArofkFpHlrawSmUqZpAbBa1ckdZ1zM=.47006441-43f6-46f2-a09a-36e3f1f225be@github.com> <-3pQYfaFzDDDaxLFes5JSm93gRpdWWdSfbb_b1AcuVw=.b6a4a21f-7539-4bcc-b765-c0211fbb6149@github.com> Message-ID: On Mon, 24 May 2021 05:02:45 GMT, Nir Lisker wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 55: >> >>> 53: * {@code falloff >= 0}; values outside either of these ranges can produce unexpected results. >>> 54: *

>>> 55: * Image of the Spotlight >> >> Should we have cone depicted in the diagram ? > > Not sure how to do that in a clear way. If you want to create an image I will use it. I shall try to create a diagram. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From michaelstrau2 at gmail.com Tue May 25 16:30:26 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 25 May 2021 18:30:26 +0200 Subject: Make themes a first-class concept in JavaFX In-Reply-To: References: Message-ID: Maybe others will chime in regarding the thin vs. rich API discussion. Regarding the extensibility of themes: If Modena and Caspian were public API, you could extend those themes simply by subclassing: public class CustomTheme extends Modena { private final ObservableList allStylesheets = FXCollections.observableArrayList(); private final ObservableList customStylesheets = FXCollections.observableArrayList(); public CustomTheme(Map properties) { super(properties); // Add custom stylesheets here customStylesheets.add("com/example/custom.css"); // Combine with Modena stylesheets allStylesheets = new ListBinding<>() { { bind(super.getStylesheets(), customStylesheets); } @Override protected ObservableList computeValue() { return FXCollections.concat( super.getStylesheets(), customStylesheets); } }; } @Override public ObservableList getStylesheets() { return allStylesheets; } } Am Di., 25. Mai 2021 um 13:06 Uhr schrieb Pedro Duque Vieira : > > Again thanks for bringing this up into discussion and for taking the time to file a PR, etc. I like the idea of having better support for themes. > > Regarding your first point: > 1 - To keep it simple we can discard the idea of having an API to be able to check what are the OS settings for dark/light, accent color, etc, for now. I think that this can be a separate discussion. > We could simply start by having an API that a theme has to implement (probably an interface that the theme has to implement like what I think happens with your proposed API). That API has properties: dark/light style, accent color, etc. Each theme can decide to respond or not to changes in those properties hence decide whether or not to support these features. > > Regarding the second point: > 2 - Not sure I explained myself well. > What I meant was that right now, and it happens to all themes I know of, theme creators decide to extend the Modena theme. What I mean by "extend" is that they add stylesheets to the Scene/Parent (without being user agent stylesheets). This means they simply build on top of the rules in Modena which is much easier/better but also means that the rules they define in their stylesheets will trump any rules defined by the theme users in their FXMLs, stylesheets (depending on specificity of their rules in their stylesheets), code... > I think this can be confusing and not ideal for users of these themes, and I find most of the time theme users don't even know about JavaFX user agent stylesheets feature vs Scene/Parent stylesheets and what that implies. > What I would propose is to have an API, perhaps in this theme interface, that toggles whether the theme, theme creators are creating will be a user agent stylesheet or a regular stylesheet. The advantage would be that if it is a user agent stylesheet developers won't need to copy all Modena definitions into their theme stylesheets, they can simply toggle this boolean to say what kind of stylesheet they want their theme to be. > > Thanks, From jgneff at openjdk.java.net Tue May 25 21:09:35 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Tue, 25 May 2021 21:09:35 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Thu, 13 May 2021 19:11:26 GMT, John Neffenger wrote: >> John Neffenger has updated the pull request incrementally with one additional commit since the last revision: >> >> Skip sending telemetry to fix "file in use" error > > I wrote a Bash shell script, included below, that can help in reviewing this pull request. It isolates the call to `vcvarsall.bat`, making it easier to experiment with different choices, such as: > > - leaving `VSCMD_SKIP_SENDTELEMETRY` undefined, > - adding the `/q` option to `cmd`, > - removing `2>&1` to use the default standard error, or > - discarding standard output with `> /dev/null`. > > > #!/bin/bash > # Tests the Visual Studio 'vcvarsall.bat' batch file > trap exit INT TERM > set -o errexit > > # Path to 'vcvarsall.bat' batch file > vsroot="C:\\Program Files (x86)\\Microsoft Visual Studio" > vcfile="2019\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat" > vcpath="$vsroot\$vcfile" > > # Windows command interpreter and options > # /C Carries out the command specified by string and then terminates > # /Q Turns echo off > command="cmd /c" > > # Skips calling PowerShell script to send telemetry > export VSCMD_SKIP_SENDTELEMETRY="1" > printf "VSCMD_SKIP_SENDTELEMETRY="%s"\n" "$VSCMD_SKIP_SENDTELEMETRY" > > # VSCMD_DEBUG undefined > unset VSCMD_DEBUG > printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG" > $command "$vcpath" x86 > 0-debug.log 2>&1 > $command "$vcpath" x64 >> 0-debug.log 2>&1 > > # VSCMD_DEBUG = 1 (basic), 2 (detailed), and 3 (trace) > for n in 1 2 3; do > export VSCMD_DEBUG="$n" > printf "Testing VSCMD_DEBUG="%s"\n" "$VSCMD_DEBUG" > $command "$vcpath" x86 > $n-debug.log 2>&1 > $command "$vcpath" x64 >> $n-debug.log 2>&1 > done > > > I run the script under Cygwin on Windows and evaluate its output as follows: > > > $ ./vcvarstest.sh > VSCMD_SKIP_SENDTELEMETRY="1" > Testing VSCMD_DEBUG="" > Testing VSCMD_DEBUG="1" > Testing VSCMD_DEBUG="2" > Testing VSCMD_DEBUG="3" > $ wc -l *.log > 10 0-debug.log > 92 1-debug.log > 508 2-debug.log > 5690 3-debug.log > 6300 total > @jgneff, do you have an idea of what kind of errors would be better detected with these changes? Thanks for trying it, Joeri. The intent is to make all such errors better detected, but that can happen only when you run the build with `VSCMD_DEBUG=3` and when you're able to find the errors in the log file. Without `VSCMD_DEBUG=3`, the batch files discard the output and errors of each `reg query` command, as shown below in the file `winsdk.bat`: :GetWin10SdkDir if "%VSCMD_DEBUG%" GEQ "3" goto :GetWin10SdkDirVerbose call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node > nul 2>&1 In addition, it helps to have an idea what to look for in the log file because not all errors are prefixed with something helpful like `ERROR`. In the test that you ran, the following steps could lead you to the source of the problem: $ export VSCMD_DEBUG=3 $ gradle sdk ? > FAIL: WINSDK_DIR not defined ? $ grep -A2 'reg query' build/vcvarsall.log C:\cygwin64\home\john\src\jfx>for /F "tokens=1,2*" %i in ('reg query "HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0" ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From john at status6.com Tue May 25 21:26:19 2021 From: john at status6.com (John Neffenger) Date: Tue, 25 May 2021 14:26:19 -0700 Subject: Unknown command v - for a list of valid commands use /help. Message-ID: > $ grep -A2 'reg query' build/vcvarsall.log > C:\cygwin64\home\john\src\jfx>for /F "tokens=1,2*" %i in > ('reg query "HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v10.0" I did it again -- started a line with a Windows command option inside a Shell Session code block, resulting in a truncated message on the mailing list and the feedback: Unknown command v - for a list of valid commands use /help. For my full comment, please see: https://github.com/openjdk/jfx/pull/488#issuecomment-848264495 Sorry about that. John From github.com+12087024+beldenfox at openjdk.java.net Tue May 25 21:49:05 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Tue, 25 May 2021 21:49:05 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: <7psvBBkKDCQo8VUJPCE3CmreXLyr_d97fy0v-j81TnM=.d1ba2101-11d7-4e46-8175-97e657e2eb25@github.com> On Tue, 25 May 2021 10:40:50 GMT, Tom Schindl wrote: >> Is there some reason you would prefer a Swing-style implementation over the approach I submitted in this PR? The Swing code breaks down if an accelerator calls for the Option modifier alone or in addition to Command. I'm still investigating work-arounds. >> >> (Long story short, Command alters the character we receive in a good way, providing a low-ASCII character even on non-ASCII layouts like Cyrillic. Option alters the character in a bad way, often producing an arbitrary symbol. Prior to macOS 10.15 we can't toss one modifier without tossing the other short of using UCKeyTranslate.) > > @beldenfox I did not say that the swing version is the way to go and in the end its @kevinrushforth call what route should be taken - I just wanted to show what my initial change would have been without saying it is better than what you are proposing which sounds like is more complete than what swing provides today. @tomsontom I've added the Swing-style code as WIP PR #519. There are comments in the PR that probably should be in the code but I wanted to reduce the code diffs. PR #519 (and Swing) tend to get codes for punctuation keys wrong on non-US layouts. That's not a big issue for accelerator processing since accelerators involving punctuation should use KeyCharacterCombinations which work even if the underlying key codes are wrong. (I can't seem to find documentation that tells developers how to choose between KeyCodeCombinations and KeyCharacterCombinations. Am I missing something?) There are isolated instances where PR #519 assigns a letter code to a punctuation key. For example, on the French keyboard it assigns KeyCode.M to the comma/question mark key which is where the M key is on the US layout. This means an app that uses both M and one of those punctuation characters as accelerators might see both fire. This might be a non-issue, the same problem afflicts the current code and I didn't run across any bugs on that. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From aghaisas at openjdk.java.net Wed May 26 05:47:11 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 26 May 2021 05:47:11 GMT Subject: Integrated: 8252783: Remove the css Selector and ShapeConverter constructors In-Reply-To: References: Message-ID: On Fri, 21 May 2021 11:48:21 GMT, Ajit Ghaisas wrote: > The javafx.css.Selector and javafx.css.converter.ShapeConverter constructors were deprecated for removal in openjfx16. > This PR removes these constructors (targeted for openjfx17). This pull request has now been integrated. Changeset: a645b5a4 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/a645b5a4925af00835510ce8fd88068f0f7a2e45 Stats: 8 lines in 2 files changed: 0 ins; 5 del; 3 mod 8252783: Remove the css Selector and ShapeConverter constructors Reviewed-by: kcr, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/512 From mstrauss at openjdk.java.net Wed May 26 05:47:33 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 26 May 2021 05:47:33 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v11] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Merge branch 'openjdk:master' into feature/image-datauri - Rename DataURI.isValidURI - Reverted a change - Allow leading and trailing whitespace in data URI - Removed test - Changed data URI detection - Merge branch 'master' into feature/image-datauri - Moved test - Added javadoc - Added javadoc - ... and 3 more: https://git.openjdk.java.net/jfx/compare/fc92ab9f...f6878f51 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/edb6f658..f6878f51 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=09-10 Stats: 559 lines in 12 files changed: 386 ins; 145 del; 28 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From fastegal at openjdk.java.net Wed May 26 08:57:13 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 26 May 2021 08:57:13 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: On Sun, 23 May 2021 15:03:21 GMT, Michael Strau? wrote: > This was my first thought, too. However, it doesn't work because `SelectedItemsReadOnlyObservableList` doesn't truthfully report its changes, so we can't simply replay its reported changes onto our copy of the items list. You mean `selectedIndices` not reporting truthfully? That's true, but no excuse for selectedItems to misbehave on its own :) The one and only task of selectedItems is to transform the notifications received from the indices into items' value space and that's what it must do correctly. And yes, MultipleSelectionModelBase is a very deep and very dark pit. Some corners where smoothed over the years which generally improved the overall behaviour. The path chosen has hacky elements, though: f.i. exposing internal api (like the nextXX methods) as public is .. extremely suboptimal and introduced the smear of who-does-what without caring overly much about contracts. Now we have to deal with a multi-headed monster that grows new heads whenever one is cut .. /rant-end ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From nlisker at openjdk.java.net Wed May 26 09:12:17 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 26 May 2021 09:12:17 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 10:53:37 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update documentation > > modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java line 167: > >> 165: // float attenuationFactor = 1/(c + cL * d + cQ * d * d); >> 166: // float intensity = rL * 0.299f + gL * 0.587f + bL * 0.114f; >> 167: // intensity *= attenuationFactor; > > minor: align the `//` or remove them. The whole comment section is a bit dubious. We can't know the distance to the light at this stage unless we try to calculate the distance between the light and the closest part of the node. I don't know how beneficial that is. I have a waiting patch that removes the limitation of 3 lights anyway, but it's waiting for this and for the DirectionalLight patches first. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From fastegal at openjdk.java.net Wed May 26 09:18:13 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 26 May 2021 09:18:13 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: On Sun, 23 May 2021 15:07:04 GMT, Michael Strau? wrote: >> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/SelectedItemsReadOnlyObservableListTest.java line 120: >> >>> 118: assertEquals(change(replaced(0, range("foo"), range("bar"))), changes.get(0)); >>> 119: } >>> 120: >> >> Another thingy I don't quite understand, sry ;) >> >> What do you want to test here? We have: >> >> selectedItems before: [foo, bar] >> selectedItems after: [bar, foo] >> >> so we need a change (the "should be" snippet in the description of this method) >> >> replaced [foo, bar] by [bar, foo] at 0 >> >> we get: >> >> replaced [foo] by [bar] at 0 >> >> which is an incorrect notification (because it's incomplete, doesn't notify at all about the replace at 1) covered by a passing test .. feels fishy. The other way round: if selectedItems cannot react to such a use-case with a correct notification, it might be broken? > > Yes, `selectedItems` is broken. I agree that having an objectively incorrect test pass is fishy, but the alternative would be to not have the test at all, and lose the "free" heads-up if at some point in the future the underlying issue is fixed. Do you think it's better to have the correct test, but ignore it? well, false greens are the worst we can have, IMO :). I think the test should concentrate on the isolated selectedItems behavior which __must__ propagate all notifications that it receives (from indices) in terms of items. If it fails to do so, it's a failure of its own implementation and should produce a failing test. Consider two scenarios: A: indices firing 2 separate changes selectedIndices.replaceAll(i -> i == 0 ? 1 : 0); assertEquals(2, changes.size()); assertEquals(change(replaced(0, range("foo"), range("bar"))), changes.get(0)); assertEquals(change(replaced(1, range("bar"), range("foo"))), changes.get(1)); B: indices firing a composed change: selectedIndices._beginChange(); selectedIndices.replaceAll(i -> i == 0 ? 1 : 0); selectedIndices._endChange(); assertEquals(indicesChanges.size(), changes.size()); assertEquals(1, changes.size()); assertEquals(change(replaced(0, range("foo", "bar"), range("bar", "foo"))), changes.get(0)); B passes both before and after the fix, A fails both before and after the fix. Whether or not that can be helped currently, is a different story. If can't be solved right now, I would suggest to keep it failing, file an issue about it and ignore the test with the issue id. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From nlisker at openjdk.java.net Wed May 26 09:43:18 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 26 May 2021 09:43:18 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 11:30:25 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update documentation > > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 49: > >> 47: *

>> 48: * In addition to the attenuation factors defined in {@code PointLight}, the {@code Spotlight}'s intensity is also >> 49: * affected by 3 factors: > > I think instead of phrasing it as "**affected** by 3 factors", it should be phrased as something like, > `the SpotLight is defined by 3 more properties` Or > `the SpotLight possesses 3 more properties` ? I think that a big part of the difficulty in explaining what is happening is that we are dancing around the mathematical formulation instead of giving it directly :) I will update the `SpotLight`'s docs to be more mathematical, but it requires to also update `PointLight`'s docs to be entirely clear. My intention is to update the docs for all the lights and material after we finish adding this one and `DirectionalLight` since it will be possible to do similarities and differences comparisons between them. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Wed May 26 10:20:16 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 26 May 2021 10:20:16 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 14:35:14 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update documentation > > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 142: > >> 140: >> 141: /** >> 142: * The angle of the spotlight's inner cone. Surfaces whose angle to the light's origin is less than this angle > > angle of a cone is angle between the two sides of cone or the total angle of cone. Here we are referring to an angle between the Light's direction vector and any side of cone. which would be half of the angle of a cone. > So should we mention it here ? > 1. Half of the inner cone angle Or > 2. Angle between the direction vector of light and edge/side of cone. > > Am I over thinking here ? > > Or we should not describe the behavior in terms of angle but mention it in terms of location/distance of a point. If point is inside the cone or outside the cone, distance of the point from the centre of cone. I think that it's simply best to refer the reader to the image in the class doc. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Wed May 26 10:23:22 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 26 May 2021 10:23:22 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v15] In-Reply-To: References: Message-ID: <4cTKRtwi00apSBThBqJ1RW6-n-SVWlPJ0E1O2wnSBhw=.4fe131b7-009e-46af-b120-187b3553a0df@github.com> On Tue, 25 May 2021 14:40:28 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Update documentation > > modules/javafx.graphics/src/main/java/javafx/scene/SpotLight.java line 171: > >> 169: * The angle of the spotlight's outer cone. Surfaces whose angle to the light's origin is greater than this angle >> 170: * receive no light. At smaller angles, the light intensity starts to increase. The valid range is >> 171: * {@code innerAngle <= outerAngle <= 180}; values outside of this range can produce unexpected results. > > Similar to innerAngle comment. I made a similar change, but there is a minor caveat I ignored when writing that the point receives no light. The attenuation factor (by distance) can be infinite if we set all the factors to 0. This will give an intensity of 0 * infinity, so depending on the implementation, the point can receive light even outside of the cone. I think we can ignore this in the docs. ------------- PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Wed May 26 10:32:38 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 26 May 2021 10:32:38 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v17] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Addressed feedback on docs ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/1cff7527..6789461d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=15-16 Stats: 35 lines in 3 files changed: 10 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From nlisker at openjdk.java.net Wed May 26 10:37:37 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 26 May 2021 10:37:37 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v18] In-Reply-To: References: Message-ID: > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Fixed whitespace ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/6789461d..f3d7c5ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From arapte at openjdk.java.net Wed May 26 11:36:14 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 26 May 2021 11:36:14 GMT Subject: RFR: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 [v2] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 19:24:19 GMT, Jose Pereda wrote: >> This PR limits the `tableIndex` value, used by the LZWDecoder algorithm in `GIFImageLoader2`, to avoid a potential AIOOB exception that happens on some animated GIFs, to the maximum size of the tables used (4096). >> >> In some occasions loading an animated GIF like the one used in the included test, doesn't throw such exception, because we `allow partially loaded animated images` in `ImageStorage`, but only a few frames are loaded. >> >> In theory, greater values of such index would operate over completely full tables, so there is no need to add new values in this case, and therefore, there is no risk in limiting the value to 4096. >> >> This PR will prevent the exception and all the frames should load. The included test passes now (and fails loading only 10 frames out of 44 without the proposed fix). > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Modify test to avoid online resources Looks good to me. Did sanity check by loading different sized gif images. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/513 From jpereda at openjdk.java.net Wed May 26 12:10:13 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 26 May 2021 12:10:13 GMT Subject: Integrated: 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 In-Reply-To: References: Message-ID: On Fri, 21 May 2021 13:02:14 GMT, Jose Pereda wrote: > This PR limits the `tableIndex` value, used by the LZWDecoder algorithm in `GIFImageLoader2`, to avoid a potential AIOOB exception that happens on some animated GIFs, to the maximum size of the tables used (4096). > > In some occasions loading an animated GIF like the one used in the included test, doesn't throw such exception, because we `allow partially loaded animated images` in `ImageStorage`, but only a few frames are loaded. > > In theory, greater values of such index would operate over completely full tables, so there is no need to add new values in this case, and therefore, there is no risk in limiting the value to 4096. > > This PR will prevent the exception and all the frames should load. The included test passes now (and fails loading only 10 frames out of 44 without the proposed fix). This pull request has now been integrated. Changeset: 7b7050c4 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/7b7050c46299c0e6771ae02fbb5ceaf22104d3e4 Stats: 130 lines in 2 files changed: 118 ins; 1 del; 11 mod 8267314: Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096 Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/513 From perini.davide at dpsoftware.org Wed May 26 13:03:06 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Wed, 26 May 2021 15:03:06 +0200 Subject: TimePicker Message-ID: <11edabd4-f3a9-263c-85e6-b313ae652d73@dpsoftware.org> Hi guys, is there a simple time picker in JavaFX? I only see DatePicker but not TimePicker. Thanks Davide From tbee at tbee.org Wed May 26 14:14:23 2021 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 26 May 2021 16:14:23 +0200 Subject: TimePicker In-Reply-To: <11edabd4-f3a9-263c-85e6-b313ae652d73@dpsoftware.org> References: <11edabd4-f3a9-263c-85e6-b313ae652d73@dpsoftware.org> Message-ID: <532f430a-d8a8-8c61-4ca5-6283f95d281a@tbee.org> JFXtras has one. https://github.com/JFXtras/jfxtras/blob/11/jfxtras-controls/src/main/java/jfxtras/scene/control/LocalTimePicker.java On 2021-05-26 15:03, Davide Perini wrote: > Hi guys, > is there a simple time picker in JavaFX? > > I only see DatePicker but not TimePicker. > > Thanks > Davide From perini.davide at dpsoftware.org Wed May 26 14:29:49 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Wed, 26 May 2021 16:29:49 +0200 Subject: TimePicker In-Reply-To: <532f430a-d8a8-8c61-4ca5-6283f95d281a@tbee.org> References: <11edabd4-f3a9-263c-85e6-b313ae652d73@dpsoftware.org> <532f430a-d8a8-8c61-4ca5-6283f95d281a@tbee.org> Message-ID: <82a37e74-26db-32ee-8256-0565957c101e@dpsoftware.org> But why I need JFXtras to have a timepicker? O_o Il 26/05/2021 16:14, Tom Eugelink ha scritto: > JFXtras has one. > > https://github.com/JFXtras/jfxtras/blob/11/jfxtras-controls/src/main/java/jfxtras/scene/control/LocalTimePicker.java > > > > On 2021-05-26 15:03, Davide Perini wrote: >> Hi guys, >> is there a simple time picker in JavaFX? >> >> I only see DatePicker but not TimePicker. >> >> Thanks >> Davide > > From tbee at tbee.org Wed May 26 14:47:34 2021 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 26 May 2021 16:47:34 +0200 Subject: TimePicker In-Reply-To: <82a37e74-26db-32ee-8256-0565957c101e@dpsoftware.org> References: <11edabd4-f3a9-263c-85e6-b313ae652d73@dpsoftware.org> <532f430a-d8a8-8c61-4ca5-6283f95d281a@tbee.org> <82a37e74-26db-32ee-8256-0565957c101e@dpsoftware.org> Message-ID: Because OpenJFX does not have any? :-D Also if you want a stand alone datepicker instead of one attached to a text field you're out of luck. But there is nothing wrong with not having everything in one library, and including what you need from elsewhere. OpenJFX has enough work to do in other areas. On 2021-05-26 16:29, Davide Perini wrote: > But why I need JFXtras to have a timepicker? O_o > > > > Il 26/05/2021 16:14, Tom Eugelink ha scritto: >> JFXtras has one. >> >> https://github.com/JFXtras/jfxtras/blob/11/jfxtras-controls/src/main/java/jfxtras/scene/control/LocalTimePicker.java >> >> >> On 2021-05-26 15:03, Davide Perini wrote: >>> Hi guys, >>> is there a simple time picker in JavaFX? >>> >>> I only see DatePicker but not TimePicker. >>> >>> Thanks >>> Davide >> >> > From mstrauss at openjdk.java.net Wed May 26 15:51:14 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 26 May 2021 15:51:14 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 08:54:30 GMT, Jeanette Winzenburg wrote: > You mean `selectedIndices` not reporting truthfully? Yes, I meant `selectedIndices`. I'm not quite sure I understand what you're getting at. Are you suggesting to apply the changes reported by `selectedIndices` to our copy of the items (`itemsRefList`) while iterating the changeset? If so, I think that doesn't work because crucial `selectedIndices` notifications are missing. For example, `selectedIndices` sometimes doesn't report removed items. By simply iterating over the changeset, `itemsRefList` would soon be out of sync with `selectedIndices`. The only way to correctly sync `itemsRefList` with `selectedIndices` is to discard all items, and collect them again in a bulk operation (like it's done currently). That alone doesn't make `SelectedItemsReadOnlyObservableList` well-behaved: since its change notifications are generated while iterating over the `selectedIndices` changes, it will also miss some notifications. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Wed May 26 16:30:31 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 26 May 2021 16:30:31 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v12] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Accept regular file paths, change javadoc ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/508/files - new: https://git.openjdk.java.net/jfx/pull/508/files/f6878f51..d30f6109 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=10-11 Stats: 30 lines in 1 file changed: 18 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From mstrauss at openjdk.java.net Wed May 26 16:36:24 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 26 May 2021 16:36:24 GMT Subject: RFR: 8267551: Support loading images from inline data-URIs [v13] In-Reply-To: References: Message-ID: > This PR adds support for loading images from [inline data URIs](https://en.wikipedia.org/wiki/Data_URI_scheme), which is also widely supported by web browsers. This enables developers to package small images in CSS files, rather than separately deploying the images alongside the CSS file. Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'master' into feature/image-datauri # Conflicts: # modules/javafx.graphics/src/test/java/test/com/sun/javafx/iio/ImageStorageTest.java - Accept regular file paths, change javadoc - Merge branch 'openjdk:master' into feature/image-datauri - Rename DataURI.isValidURI - Reverted a change - Allow leading and trailing whitespace in data URI - Removed test - Changed data URI detection - Merge branch 'master' into feature/image-datauri - Moved test - ... and 5 more: https://git.openjdk.java.net/jfx/compare/7b7050c4...315523c5 ------------- Changes: https://git.openjdk.java.net/jfx/pull/508/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=508&range=12 Stats: 566 lines in 8 files changed: 501 ins; 23 del; 42 mod Patch: https://git.openjdk.java.net/jfx/pull/508.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/508/head:pull/508 PR: https://git.openjdk.java.net/jfx/pull/508 From john at status6.com Wed May 26 16:38:08 2021 From: john at status6.com (John Neffenger) Date: Wed, 26 May 2021 09:38:08 -0700 Subject: Unknown command v - for a list of valid commands use /help. In-Reply-To: References: Message-ID: On 5/25/21 2:26 PM, John Neffenger wrote: > ? Unknown command v - for a list of valid commands use /help. Just to follow up, there's a Skara bug report for this glitch: SKARA-755: Anything starting with a "/" is treated as a command https://bugs.openjdk.java.net/browse/SKARA-755 John From perini.davide at dpsoftware.org Wed May 26 18:09:09 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Wed, 26 May 2021 20:09:09 +0200 Subject: TimePicker In-Reply-To: References: <11edabd4-f3a9-263c-85e6-b313ae652d73@dpsoftware.org> <532f430a-d8a8-8c61-4ca5-6283f95d281a@tbee.org> <82a37e74-26db-32ee-8256-0565957c101e@dpsoftware.org> Message-ID: <665120c3-3890-8aae-9cc8-a0df964038c9@dpsoftware.org> Thank you for the answer, I appreciate it. I love Scene Builder and most of the things that you can include from elsewhere are not compatible with Scene Builder, this is the reason why I asked. In any case, long live JavaFX, I really enjoy using it. :) Thanks, Davide Il 26/05/2021 16:47, Tom Eugelink ha scritto: > Because OpenJFX does not have any? :-D Also if you want a stand alone > datepicker instead of one attached to a text field you're out of luck. > > But there is nothing wrong with not having everything in one library, > and including what you need from elsewhere. OpenJFX has enough work to > do in other areas. > > > > > On 2021-05-26 16:29, Davide Perini wrote: >> But why I need JFXtras to have a timepicker? O_o >> >> >> >> Il 26/05/2021 16:14, Tom Eugelink ha scritto: >>> JFXtras has one. >>> >>> https://github.com/JFXtras/jfxtras/blob/11/jfxtras-controls/src/main/java/jfxtras/scene/control/LocalTimePicker.java >>> >>> >>> >>> On 2021-05-26 15:03, Davide Perini wrote: >>>> Hi guys, >>>> is there a simple time picker in JavaFX? >>>> >>>> I only see DatePicker but not TimePicker. >>>> >>>> Thanks >>>> Davide >>> >>> >> > From jpereda at openjdk.java.net Wed May 26 20:50:50 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 26 May 2021 20:50:50 GMT Subject: RFR: 8185447: The special high-contrast mode of JavaFX Controls in Japanese environment do not work. Message-ID: <1olf0WwPCG_Oa4E6nVkGyNJuElqLdSC65mAt661TX_w=.a8a59aca-c092-47aa-9c4b-c448321e9aaf@github.com> This PR adds several resource bundles with High Contrast Scheme possible values for several locales. These values have been found by installing the required language packages on Windows 10 Pro 20H2 (build 19042.985), enabling Settings->High Contrast and finding the high contrast scheme values in the Windows registry (and translating to unicode when needed). Other locales could be generated as well, but so far the list is the same as the locales supported by Controls. With these bundles, and assuming the application uses a locale that matches the system settings language, the theme name provided natively (only on Windows so far) can be matched with the high contrast scheme, and the proper stylesheet can be applied. This PR has been tested on the same Windows machine, selecting each possible language and setting the locale for the app accordingly. ------------- Commit messages: - Use resource bundles with High Contrast Scheme possible values to find correct stylesheet Changes: https://git.openjdk.java.net/jfx/pull/520/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=520&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8185447 Stats: 99 lines in 16 files changed: 92 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/520.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/520/head:pull/520 PR: https://git.openjdk.java.net/jfx/pull/520 From arapte at openjdk.java.net Thu May 27 02:14:32 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 27 May 2021 02:14:32 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v2] In-Reply-To: References: Message-ID: > `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. > > I have tried three approaches and tested with modena.css which is ~134 KB in size. > Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, > > 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : > - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms > 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) > - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms > 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. > - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms > > > The time taken by `StyleManager.calculateCheckSum()` with current implementation is, > - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms > > > Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. > However we can choose approach#2 also. > If we choose approach#3 then bug summary should be changed accordingly. Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: - minor: format correction - add test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/518/files - new: https://git.openjdk.java.net/jfx/pull/518/files/215e1a18..5a4d3b1c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=518&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=518&range=00-01 Stats: 155 lines in 3 files changed: 155 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/518.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/518/head:pull/518 PR: https://git.openjdk.java.net/jfx/pull/518 From arapte at openjdk.java.net Thu May 27 02:14:32 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 27 May 2021 02:14:32 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream In-Reply-To: References: Message-ID: On Tue, 25 May 2021 12:36:54 GMT, Kevin Rushforth wrote: > I also prefer approach 3, since the body of the try/finally loop is then identical to that of `NativeLibLoader::calculateCheckSum`. > Can you add a unit test to validate the checksum method? Hello Kevin, Thanks for the review, I have added a test. Please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From almatvee at openjdk.java.net Thu May 27 04:23:15 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 27 May 2021 04:23:15 GMT Subject: RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread Message-ID: JDK-8264737 introduced new code for audio device removal/arrival notifications which calls CoInitialize/CoUninitialize on separate threads. CoInitialize/CoUninitialize should be called on same thread, since initialization is per thread. Doing it on separate thread will result in unloading COM libraries on that thread and if it uses COM libraries it might not work correctly. Fixed by calling it on same thread in same way it is done in dshowwrapper. ------------- Commit messages: - 8267819: CoInitialize/CoUninitialize should be called on same thread Changes: https://git.openjdk.java.net/jfx/pull/521/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=521&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267819 Stats: 22 lines in 2 files changed: 10 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/521.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/521/head:pull/521 PR: https://git.openjdk.java.net/jfx/pull/521 From kcr at openjdk.java.net Thu May 27 13:02:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 May 2021 13:02:09 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 02:14:32 GMT, Ambarish Rapte wrote: >> `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. >> >> I have tried three approaches and tested with modena.css which is ~134 KB in size. >> Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, >> >> 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : >> - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms >> 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) >> - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms >> 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. >> - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms >> >> >> The time taken by `StyleManager.calculateCheckSum()` with current implementation is, >> - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms >> >> >> Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. >> However we can choose approach#2 also. >> If we choose approach#3 then bug summary should be changed accordingly. > > Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: > > - minor: format correction > - add test The new test looks like it will work, but maybe could be made a bit clearer? modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/StyleManagerTest.java line 1121: > 1119: actualChecksum += Integer.toString((b & 0xff) + 0x100, 16).substring(1); > 1120: } > 1121: assertEquals(expectedChecksum, actualChecksum); It might be clearer to use a `byte` array for the expected checksum and use `Arrays.equals()` to compare them rather than converting to a `String`. I'm scratching my head over the formula in the `Integer.toString` call. modules/javafx.graphics/src/test/resources/test/com/sun/javafx/css/checksum.css line 1: > 1: This file should have a copyright header. ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From arapte at openjdk.java.net Thu May 27 17:22:35 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 27 May 2021 17:22:35 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v3] In-Reply-To: References: Message-ID: <44fYjFVs1OBoJkUdmtHdlAnqJ6vjOyWoIgl6kZGouXE=.e43d636b-052e-4ac0-a438-239bd4994848@github.com> > `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. > > I have tried three approaches and tested with modena.css which is ~134 KB in size. > Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, > > 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : > - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms > 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) > - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms > 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. > - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms > > > The time taken by `StyleManager.calculateCheckSum()` with current implementation is, > - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms > > > Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. > However we can choose approach#2 also. > If we choose approach#3 then bug summary should be changed accordingly. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: review update ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/518/files - new: https://git.openjdk.java.net/jfx/pull/518/files/5a4d3b1c..e1d6dbd7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=518&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=518&range=01-02 Stats: 32 lines in 2 files changed: 26 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/518.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/518/head:pull/518 PR: https://git.openjdk.java.net/jfx/pull/518 From arapte at openjdk.java.net Thu May 27 17:30:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 27 May 2021 17:30:08 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 12:58:07 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: >> >> - minor: format correction >> - add test > > modules/javafx.graphics/src/test/resources/test/com/sun/javafx/css/checksum.css line 1: > >> 1: > > This file should have a copyright header. Added copyright header. ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From arapte at openjdk.java.net Thu May 27 17:33:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 27 May 2021 17:33:08 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v2] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 12:58:26 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: >> >> - minor: format correction >> - add test > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/StyleManagerTest.java line 1121: > >> 1119: actualChecksum += Integer.toString((b & 0xff) + 0x100, 16).substring(1); >> 1120: } >> 1121: assertEquals(expectedChecksum, actualChecksum); > > It might be clearer to use a `byte` array for the expected checksum and use `Arrays.equals()` to compare them rather than converting to a `String`. I'm scratching my head over the formula in the `Integer.toString` call. I have updated the test to use a byte array. Some byte values are greater than 128, those are the negative values. ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From kcr at openjdk.java.net Thu May 27 21:55:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 May 2021 21:55:08 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v3] In-Reply-To: <44fYjFVs1OBoJkUdmtHdlAnqJ6vjOyWoIgl6kZGouXE=.e43d636b-052e-4ac0-a438-239bd4994848@github.com> References: <44fYjFVs1OBoJkUdmtHdlAnqJ6vjOyWoIgl6kZGouXE=.e43d636b-052e-4ac0-a438-239bd4994848@github.com> Message-ID: On Thu, 27 May 2021 17:22:35 GMT, Ambarish Rapte wrote: >> `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. >> >> I have tried three approaches and tested with modena.css which is ~134 KB in size. >> Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, >> >> 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : >> - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms >> 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) >> - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms >> 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. >> - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms >> >> >> The time taken by `StyleManager.calculateCheckSum()` with current implementation is, >> - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms >> >> >> Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. >> However we can choose approach#2 also. >> If we choose approach#3 then bug summary should be changed accordingly. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review update The fix and test look fine now. Unfortunately, if you look at the checks for this PR, the test fails on the GitHub Actions Windows build: 2021-05-27T17:31:48.5184758Z test.com.sun.javafx.css.StyleManagerTest > testCalculateCheckSum FAILED 2021-05-27T17:31:48.5186991Z java.lang.AssertionError: 2021-05-27T17:31:48.5188560Z at org.junit.Assert.fail(Assert.java:91) 2021-05-27T17:31:48.5190261Z at org.junit.Assert.assertTrue(Assert.java:43) 2021-05-27T17:31:48.5192290Z at org.junit.Assert.assertTrue(Assert.java:54) 2021-05-27T17:31:48.5195303Z at test.com.sun.javafx.css.StyleManagerTest.testCalculateCheckSum(StyleManagerTest.java:1121) 2021-05-27T17:31:49.3450264Z This is almost certainly because of DOS line endings courtesy of the native Git for Windows where the default configuration is set to `core.autocrlf = true`. This causes git to convert all files on checkout to Windows-style line endings. I note that others could run into this problem as well -- in fact someone recently ran into an WebKit build error caused by `autocrlf` on their system. I will file a new bug to add a `.gitattributes` to our repo. I note that the `jdk` repo already did this prior to the Skara switch. See [JDK-8241768](https://bugs.openjdk.java.net/browse/JDK-8241768). You can either wait for that newly-filed bug to be integrated or else skip this test on Windows, referring to that bug. I'd probably recommend waiting. ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From kcr at openjdk.java.net Thu May 27 22:00:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 May 2021 22:00:08 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v3] In-Reply-To: <44fYjFVs1OBoJkUdmtHdlAnqJ6vjOyWoIgl6kZGouXE=.e43d636b-052e-4ac0-a438-239bd4994848@github.com> References: <44fYjFVs1OBoJkUdmtHdlAnqJ6vjOyWoIgl6kZGouXE=.e43d636b-052e-4ac0-a438-239bd4994848@github.com> Message-ID: On Thu, 27 May 2021 17:22:35 GMT, Ambarish Rapte wrote: >> `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. >> >> I have tried three approaches and tested with modena.css which is ~134 KB in size. >> Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, >> >> 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : >> - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms >> 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) >> - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms >> 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. >> - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms >> >> >> The time taken by `StyleManager.calculateCheckSum()` with current implementation is, >> - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms >> >> >> Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. >> However we can choose approach#2 also. >> If we choose approach#3 then bug summary should be changed accordingly. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review update I filed [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) to add a `.gitattributes` file. I tested your PR branch with / without the fix, and confirmed that it fails without the `gitattributes` that disables `crlf` and passes with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From kcr at openjdk.java.net Thu May 27 22:20:23 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 27 May 2021 22:20:23 GMT Subject: RFR: 8267892: Add .gitattributes to repo Message-ID: This fix adds a `.gitattributes` file to prevent git from replacing line endings if the global `.gitconfig` file on the client system is configured with core.autocrlf = true (which it is by default when using the native Git for Windows). This can cause build or test problems with scripts or other files that expect Unix-style line endings. For two recent examples of such problems, see [JDK-8267694](https://bugs.openjdk.java.net/browse/JDK-8267694) and [this comment in PR #518](https://github.com/openjdk/jfx/pull/518#issuecomment-849966053). To test this, I set `core.autocrlf = true` in my `$HOME/.gitconfig` and cloned the master branch of the jfx repo into a new local repo. The files all had CRLF line endings. I then cloned the branch with the fix for this PR into a new repo and verified that the line endings are correctly left alone (LF line endings). As a second test, here is a failing GHA build of the patch from PR #518 that fails as expected due to this bug: https://github.com/kevinrushforth/jfx/actions/runs/883603338 Here is a GHA build of that same branch, plus the commit to add `.gitattributes`: https://github.com/kevinrushforth/jfx/actions/runs/883620592 ------------- Commit messages: - 8267892: Add .gitattributes to repo Changes: https://git.openjdk.java.net/jfx/pull/523/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=523&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267892 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/523.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/523/head:pull/523 PR: https://git.openjdk.java.net/jfx/pull/523 From kcr at openjdk.java.net Fri May 28 01:25:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 28 May 2021 01:25:07 GMT Subject: RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:18:24 GMT, Alexander Matveev wrote: > JDK-8264737 introduced new code for audio device removal/arrival notifications which calls CoInitialize/CoUninitialize on separate threads. CoInitialize/CoUninitialize should be called on same thread, since initialization is per thread. Doing it on separate thread will result in unloading COM libraries on that thread and if it uses COM libraries it might not work correctly. Fixed by calling it on same thread in same way it is done in dshowwrapper. Looks good, and I think it's cleaner this way too. Two questions: 1. Have you verified that it still works correctly on RDP reconnect? 2. This isn't really related to your fix, since the logic for this part is the same before and after, should the rest of the `Init` method be short-circuited if `CoInitialize` fails? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/521 From almatvee at openjdk.java.net Fri May 28 04:56:05 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 28 May 2021 04:56:05 GMT Subject: RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread In-Reply-To: References: Message-ID: On Thu, 27 May 2021 04:18:24 GMT, Alexander Matveev wrote: > JDK-8264737 introduced new code for audio device removal/arrival notifications which calls CoInitialize/CoUninitialize on separate threads. CoInitialize/CoUninitialize should be called on same thread, since initialization is per thread. Doing it on separate thread will result in unloading COM libraries on that thread and if it uses COM libraries it might not work correctly. Fixed by calling it on same thread in same way it is done in dshowwrapper. 1. Yes, I did test it on RDP reconnect for multiple streams. 2. Not really needed. CoCreateInstance() will fails in this case most likely and we will return false from Init(). So, it should be fine if it fails. Also, CoInitialize() can return RPC_E_CHANGED_MODE if someone already initialized thread as multithread apartment (MTA) and in this case CoCreateInstance() should work, so it is better not to fail Init() even if CoInitialize() failed. ------------- PR: https://git.openjdk.java.net/jfx/pull/521 From arapte at openjdk.java.net Fri May 28 06:41:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 28 May 2021 06:41:08 GMT Subject: RFR: 8267892: Add .gitattributes to repo In-Reply-To: References: Message-ID: On Thu, 27 May 2021 22:14:51 GMT, Kevin Rushforth wrote: > This fix adds a `.gitattributes` file to prevent git from replacing line endings if the global `.gitconfig` file on the client system is configured with core.autocrlf = true (which it is by default when using the native Git for Windows). > > This can cause build or test problems with scripts or other files that expect Unix-style line endings. For two recent examples of such problems, see [JDK-8267694](https://bugs.openjdk.java.net/browse/JDK-8267694) and [this comment in PR #518](https://github.com/openjdk/jfx/pull/518#issuecomment-849966053). > > To test this, I set `core.autocrlf = true` in my `$HOME/.gitconfig` and cloned the master branch of the jfx repo into a new local repo. The files all had CRLF line endings. I then cloned the branch with the fix for this PR into a new repo and verified that the line endings are correctly left alone (LF line endings). > > As a second test, here is a failing GHA build of the patch from PR #518 that fails as expected due to this bug: > > https://github.com/kevinrushforth/jfx/actions/runs/883603338 > > Here is a GHA build of that same branch, plus the commit to add `.gitattributes`: > > https://github.com/kevinrushforth/jfx/actions/runs/883620592 Looks good to me. Git documentation which explains the usage : https://git-scm.com/docs/gitattributes#_text ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/523 From pbansal at openjdk.java.net Fri May 28 06:46:05 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 28 May 2021 06:46:05 GMT Subject: RFR: 8267892: Add .gitattributes to repo In-Reply-To: References: Message-ID: On Thu, 27 May 2021 22:14:51 GMT, Kevin Rushforth wrote: > This fix adds a `.gitattributes` file to prevent git from replacing line endings if the global `.gitconfig` file on the client system is configured with core.autocrlf = true (which it is by default when using the native Git for Windows). > > This can cause build or test problems with scripts or other files that expect Unix-style line endings. For two recent examples of such problems, see [JDK-8267694](https://bugs.openjdk.java.net/browse/JDK-8267694) and [this comment in PR #518](https://github.com/openjdk/jfx/pull/518#issuecomment-849966053). > > To test this, I set `core.autocrlf = true` in my `$HOME/.gitconfig` and cloned the master branch of the jfx repo into a new local repo. The files all had CRLF line endings. I then cloned the branch with the fix for this PR into a new repo and verified that the line endings are correctly left alone (LF line endings). > > As a second test, here is a failing GHA build of the patch from PR #518 that fails as expected due to this bug: > > https://github.com/kevinrushforth/jfx/actions/runs/883603338 > > Here is a GHA build of that same branch, plus the commit to add `.gitattributes`: > > https://github.com/kevinrushforth/jfx/actions/runs/883620592 looks good to me ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/523 From fastegal at swingempire.de Fri May 28 10:45:38 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 28 May 2021 12:45:38 +0200 Subject: Tons of gradle warnings Message-ID: <20210528124538.Horde.bdz_ZlUQh3hgPrpWJz6dog1@webmail.df.eu> Hi Experts, yesterday gradle auto-updated to version 7 (?), since then I get many warnings like: Execution optimizations have been disabled for task ':graphics:copyClassFilesWin' to ensure correctness due to the following reasons: - Gradle detected a problem with the following location: 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\modules\javafx.graphics\build\module-classes'. Reason: Task ':graphics:copyClassFilesWin' uses this output of task ':graphics:buildModuleWin' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Looks like it is safe to ignore them, just want to be sure :) Another very minor issue: since the same time, there's an issue with terminal output in that I see the "executing" messages written out like: <=======------> 58% EXECUTING [54s]> :graphics:copyClassFilesWin<=======------> 58% EXECUTING [55s]<=======------> 58% EXECUTING [56s]<=======------> 58% EXECUTING [57s]<=======------> 58% EXECUTING [58s]<=======------> 58% EXECUTING [59s]<=======------> 58% EXECUTING [1m 0s]<=======------> 58% EXECUTING [1m 1s]<=======------> and-so-on-to-the-end Can live with it, but any idea how to get rid off them? -- Jeanette From fastegal at openjdk.java.net Fri May 28 14:24:15 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 28 May 2021 14:24:15 GMT Subject: RFR: 8267094: TreeCell: cancelEvent must return correct editing location Message-ID: the bug is an incorrect edit location (for tree: treeItem) in edit cancel events - expected is the location at the time the cell edit was started, actual was the location of at the time the edit was cancelled. See the report for details. Fixed by storing the edit location in startEdit and use that in cancelEdit. Added tests that failed before and passed after and tests that (accidentally :) passed before and still pass after. ------------- Commit messages: - 8267094: TreeCell: cancelEvent must return correct editing location Changes: https://git.openjdk.java.net/jfx/pull/524/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=524&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267094 Stats: 123 lines in 3 files changed: 98 ins; 22 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/524.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/524/head:pull/524 PR: https://git.openjdk.java.net/jfx/pull/524 From fastegal at openjdk.java.net Fri May 28 14:34:04 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 28 May 2021 14:34:04 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: On Wed, 26 May 2021 15:48:08 GMT, Michael Strau? wrote: > I'm not quite sure I understand what you're getting at. Are you suggesting to apply the changes reported by `selectedIndices` to our copy of the items (`itemsRefList`) while iterating the changeset? If so, I think that doesn't work because crucial `selectedIndices` notifications are missing. > exactly, that's what I meant right from the start (and obviously haven't been clear enough ;) And now I understand what you tried to explain to me, probably also right from the start .. thanks for spelling it out! hmm .. so we are stuck with a severely misbehaving selectedItems that's trying to do its best to compensate for the misbehaviour in selectedIndices (there are not only missing but also badly incorrect, notifications see f.i. [JDK-8267781](https://bugs.openjdk.java.net/browse/JDK-8267781)). There probably should be some documentation to explain that fact. Maybe open a follow-up issue to make sure the selectedItems are revisited? ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From kcr at openjdk.java.net Fri May 28 15:08:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 28 May 2021 15:08:11 GMT Subject: Integrated: 8267892: Add .gitattributes to repo In-Reply-To: References: Message-ID: <7D5xyD2Gp6ICY_ucEaIs_4FiTCBpnuOgYyy36z-OzjA=.7d8426af-8d72-4dc5-93fb-c04fd46b13fa@github.com> On Thu, 27 May 2021 22:14:51 GMT, Kevin Rushforth wrote: > This fix adds a `.gitattributes` file to prevent git from replacing line endings if the global `.gitconfig` file on the client system is configured with core.autocrlf = true (which it is by default when using the native Git for Windows). > > This can cause build or test problems with scripts or other files that expect Unix-style line endings. For two recent examples of such problems, see [JDK-8267694](https://bugs.openjdk.java.net/browse/JDK-8267694) and [this comment in PR #518](https://github.com/openjdk/jfx/pull/518#issuecomment-849966053). > > To test this, I set `core.autocrlf = true` in my `$HOME/.gitconfig` and cloned the master branch of the jfx repo into a new local repo. The files all had CRLF line endings. I then cloned the branch with the fix for this PR into a new repo and verified that the line endings are correctly left alone (LF line endings). > > As a second test, here is a failing GHA build of the patch from PR #518 that fails as expected due to this bug: > > https://github.com/kevinrushforth/jfx/actions/runs/883603338 > > Here is a GHA build of that same branch, plus the commit to add `.gitattributes`: > > https://github.com/kevinrushforth/jfx/actions/runs/883620592 This pull request has now been integrated. Changeset: 5e6d4429 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/5e6d4429159e3fab9ec0aab9720393850d179710 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8267892: Add .gitattributes to repo Reviewed-by: arapte, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/523 From kcr at openjdk.java.net Fri May 28 15:54:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 28 May 2021 15:54:06 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v3] In-Reply-To: <44fYjFVs1OBoJkUdmtHdlAnqJ6vjOyWoIgl6kZGouXE=.e43d636b-052e-4ac0-a438-239bd4994848@github.com> References: <44fYjFVs1OBoJkUdmtHdlAnqJ6vjOyWoIgl6kZGouXE=.e43d636b-052e-4ac0-a438-239bd4994848@github.com> Message-ID: On Thu, 27 May 2021 17:22:35 GMT, Ambarish Rapte wrote: >> `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. >> >> I have tried three approaches and tested with modena.css which is ~134 KB in size. >> Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, >> >> 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : >> - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms >> 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) >> - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms >> 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. >> - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms >> >> >> The time taken by `StyleManager.calculateCheckSum()` with current implementation is, >> - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms >> >> >> Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. >> However we can choose approach#2 also. >> If we choose approach#3 then bug summary should be changed accordingly. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review update Now that PR #523 is integrated, can you merge in the latest changes from master to ensure a clean test run? ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From kevin.rushforth at oracle.com Fri May 28 16:11:30 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 May 2021 09:11:30 -0700 Subject: Result: New OpenJFX Reviewer: Arun Joseph Message-ID: Voting for Arun Joseph [1] to OpenJFX Reviewer [2] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.java.net/census#ajoseph [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-May/030298.html From kevin.rushforth at oracle.com Fri May 28 16:11:38 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 May 2021 09:11:38 -0700 Subject: Result: New OpenJFX Reviewer: Jeanette Winzenburg Message-ID: Voting for Jeanette Winzenburg [1] to OpenJFX Reviewer [2] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.java.net/census#fastegal [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-May/030299.html From github.com+66004280+maran23 at openjdk.java.net Fri May 28 23:13:24 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Fri, 28 May 2021 23:13:24 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Skip sending telemetry to fix "file in use" error Finally had time to test this. I think this is a welcome feature, although we should document it's usage in the [wiki](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows) and where the log file is and what to search for. Regarding my test, I did the following: 1. Changed the following `PATH` variable: `C:\WINDOWS\system32` -> `C:\WINDOWS\system321` 2. run `gradle` 3. Then I got, as expected: > FAIL: WINSDK_DIR not defined Now I struggled a bit. I set `export VSCMD_DEBUG=3` and tried to run `gradle` again. But same error and no logfile. But turns out the whole build folder should be deleted first as otherwise you will get the error again immediately. That's something we should document then as well. After deleting the build folder and rerun `gradle`, I finally had a huge log and after a deep look I found the following: (Note: the `command not found` error is written in german here ??) [DEBUG:winsdk.bat] specified /winsdk= was not found or was incomplete C:\dev\Projects\IdeaProjects\OpenJFX>for /F "tokens=1,2*" %i in ('reg query "HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\VSPerf" /v "CollectionToolsDir"') DO (if "%i" == "CollectionToolsDir" (SET "__collection_tools=%k" ) ) Der Befehl "reg" ist entweder falsch geschrieben oder konnte nicht gefunden werden. C:\dev\Projects\IdeaProjects\OpenJFX>if "" == "" for /F "tokens=1,2*" %i in ('reg query "HKCU\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.1" /v "InstallationFolder"') DO (if "%i" == "InstallationFolder" (SET WindowsSdkDir=%k ) ) Der Befehl "reg" ist entweder falsch geschrieben oder konnte nicht gefunden werden. This looks good to me and is helpful. And after documenting it, I think it will be more clear for everyone including new developers. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From mstrauss at openjdk.java.net Fri May 28 23:35:42 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 28 May 2021 23:35:42 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v7] In-Reply-To: References: Message-ID: > The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. > > `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Ignored tests that fail for a different reason ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/478/files - new: https://git.openjdk.java.net/jfx/pull/478/files/fbe8aa66..950c894a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=05-06 Stats: 25 lines in 1 file changed: 3 ins; 16 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/478.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/478/head:pull/478 PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Fri May 28 23:35:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 28 May 2021 23:35:43 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 14:31:14 GMT, Jeanette Winzenburg wrote: >>> You mean `selectedIndices` not reporting truthfully? >> >> Yes, I meant `selectedIndices`. >> >> I'm not quite sure I understand what you're getting at. Are you suggesting to apply the changes reported by `selectedIndices` to our copy of the items (`itemsRefList`) while iterating the changeset? If so, I think that doesn't work because crucial `selectedIndices` notifications are missing. >> >> For example, `selectedIndices` sometimes doesn't report removed items. By simply iterating over the changeset, `itemsRefList` would soon be out of sync with `selectedIndices`. The only way to correctly sync `itemsRefList` with `selectedIndices` is to discard all items, and collect them again in a bulk operation (like it's done currently). >> >> That alone doesn't make `SelectedItemsReadOnlyObservableList` well-behaved: since its change notifications are generated while iterating over the `selectedIndices` changes, it will also miss some notifications. > >> I'm not quite sure I understand what you're getting at. Are you suggesting to apply the changes reported by `selectedIndices` to our copy of the items (`itemsRefList`) while iterating the changeset? If so, I think that doesn't work because crucial `selectedIndices` notifications are missing. >> > > exactly, that's what I meant right from the start (and obviously haven't been clear enough ;) And now I understand what you tried to explain to me, probably also right from the start .. thanks for spelling it out! > > hmm .. so we are stuck with a severely misbehaving selectedItems that's trying to do its best to compensate for the misbehaviour in selectedIndices (there are not only missing but also badly incorrect, notifications see f.i. [JDK-8267781](https://bugs.openjdk.java.net/browse/JDK-8267781)). There probably should be some documentation to explain that fact. Maybe open a follow-up issue to make sure the selectedItems are revisited? Yes, this should be followed up on. [Here](https://bugs.openjdk.java.net/browse/JDK-8267951)'s the issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Fri May 28 23:35:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 28 May 2021 23:35:43 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: Message-ID: <0vBJPRaZ8eANc1Ql21sbTdv3sNAApu0Rm-gy0Vudadc=.345fe00b-df01-44de-b840-725b9c047349@github.com> On Wed, 26 May 2021 09:14:35 GMT, Jeanette Winzenburg wrote: >> Yes, `selectedItems` is broken. I agree that having an objectively incorrect test pass is fishy, but the alternative would be to not have the test at all, and lose the "free" heads-up if at some point in the future the underlying issue is fixed. Do you think it's better to have the correct test, but ignore it? > > well, false greens are the worst we can have, IMO :). I think the test should concentrate on the isolated selectedItems behavior which __must__ propagate all notifications that it receives (from indices) in terms of items. If it fails to do so, it's a failure of its own implementation and should produce a failing test. > > Consider two scenarios: > > A: indices firing 2 separate changes > > selectedIndices.replaceAll(i -> i == 0 ? 1 : 0); > assertEquals(2, changes.size()); > assertEquals(change(replaced(0, range("foo"), range("bar"))), changes.get(0)); > assertEquals(change(replaced(1, range("bar"), range("foo"))), changes.get(1)); > > B: indices firing a composed change: > > selectedIndices._beginChange(); > selectedIndices.replaceAll(i -> i == 0 ? 1 : 0); > selectedIndices._endChange(); > assertEquals(indicesChanges.size(), changes.size()); > assertEquals(1, changes.size()); > assertEquals(change(replaced(0, range("foo", "bar"), range("bar", "foo"))), changes.get(0)); > > B passes both before and after the fix, A fails both before and after the fix. Whether or not that can be helped currently, is a different story. If can't be solved right now, I would suggest to keep it failing, file an issue about it and ignore the test with the issue id. I disabled the tests until the underlying [issue](https://bugs.openjdk.java.net/browse/JDK-8267951) is fixed. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From github.com+66004280+maran23 at openjdk.java.net Sat May 29 00:26:15 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Sat, 29 May 2021 00:26:15 GMT Subject: RFR: 8267505: {List, Set, Map}PropertyBase::bind should check against identity In-Reply-To: References: Message-ID: On Mon, 24 May 2021 11:56:35 GMT, Jose Pereda wrote: > ListPropertyBase::bind, SetPropertyBase::bind, MapPropertyBase::bind have a check on whether a different instance of the observable is the same, and this PR changes that to check against identity. > > Tests are included. Looks good. Verified tests failing before and succeed after the fix. One side note which might explaing, why equals was used: The super class `ReadOnlyList/Set/MapProperty` have hashcode/equals overridden, where equals accepts the corresponding collection (List/Set/Map), which is then checked against the collection the property has set. This is fine, although it looks a bit weird at first as the equals expects a collection, not a property. But it makes sense as all those classes implements the corresponding collection interface (List/Map/Set). And a quick look in the history is showing, that at first the equals was really checking for a property (and in there: bean and name), which makes `normalList.equals(listProperty)` never work. So maybe this is leftover code from the old implementaation. ------------- Marked as reviewed by Maran23 at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jfx/pull/516 From fastegal at openjdk.java.net Sat May 29 09:25:17 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 29 May 2021 09:25:17 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: <0vBJPRaZ8eANc1Ql21sbTdv3sNAApu0Rm-gy0Vudadc=.345fe00b-df01-44de-b840-725b9c047349@github.com> References: <0vBJPRaZ8eANc1Ql21sbTdv3sNAApu0Rm-gy0Vudadc=.345fe00b-df01-44de-b840-725b9c047349@github.com> Message-ID: On Fri, 28 May 2021 23:30:33 GMT, Michael Strau? wrote: >> well, false greens are the worst we can have, IMO :). I think the test should concentrate on the isolated selectedItems behavior which __must__ propagate all notifications that it receives (from indices) in terms of items. If it fails to do so, it's a failure of its own implementation and should produce a failing test. >> >> Consider two scenarios: >> >> A: indices firing 2 separate changes >> >> selectedIndices.replaceAll(i -> i == 0 ? 1 : 0); >> assertEquals(2, changes.size()); >> assertEquals(change(replaced(0, range("foo"), range("bar"))), changes.get(0)); >> assertEquals(change(replaced(1, range("bar"), range("foo"))), changes.get(1)); >> >> B: indices firing a composed change: >> >> selectedIndices._beginChange(); >> selectedIndices.replaceAll(i -> i == 0 ? 1 : 0); >> selectedIndices._endChange(); >> assertEquals(indicesChanges.size(), changes.size()); >> assertEquals(1, changes.size()); >> assertEquals(change(replaced(0, range("foo", "bar"), range("bar", "foo"))), changes.get(0)); >> >> B passes both before and after the fix, A fails both before and after the fix. Whether or not that can be helped currently, is a different story. If can't be solved right now, I would suggest to keep it failing, file an issue about it and ignore the test with the issue id. > > I disabled the tests until the underlying [issue](https://bugs.openjdk.java.net/browse/JDK-8267951) is fixed. Would suggest to make them correct before ignoring - expected are the exact analogue of those fired by selectedIndices (which is two in the test setup) ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Sat May 29 12:31:33 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 29 May 2021 12:31:33 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v8] In-Reply-To: References: Message-ID: <-OW5RpIHvYQdhtQKgrHtbQ7-M7atcK2c4dN1odz6XOA=.ef13fb52-6f64-4cc4-8637-10fe953e893e@github.com> > The documentation for `ObservableListBase.nextRemove` states that a single change always refers to the current state of the list, which likely means that multiple disjoint removed ranges need to be applied in order, otherwise the next change's `getFrom` doesn't refer to the correct index. > > `SelectedItemsReadOnlyObservableList` doesn't apply removals to `itemsRefList`, which means that subsequent removals will refer to the wrong index when retrieving the removed elements. This PR fixes the calculation of the current index. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fix tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/478/files - new: https://git.openjdk.java.net/jfx/pull/478/files/950c894a..20fdb393 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=478&range=06-07 Stats: 14 lines in 1 file changed: 6 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/478.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/478/head:pull/478 PR: https://git.openjdk.java.net/jfx/pull/478 From mstrauss at openjdk.java.net Sat May 29 12:31:33 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 29 May 2021 12:31:33 GMT Subject: RFR: 8196065: ListChangeListener getRemoved() returns items that were not removed. [v6] In-Reply-To: References: <0vBJPRaZ8eANc1Ql21sbTdv3sNAApu0Rm-gy0Vudadc=.345fe00b-df01-44de-b840-725b9c047349@github.com> Message-ID: On Sat, 29 May 2021 09:22:35 GMT, Jeanette Winzenburg wrote: >> I disabled the tests until the underlying [issue](https://bugs.openjdk.java.net/browse/JDK-8267951) is fixed. > > Would suggest to make them correct before ignoring - expected are the exact analogue of those fired by selectedIndices (which is two in the test setup) Done. ------------- PR: https://git.openjdk.java.net/jfx/pull/478 From github.com+66004280+maran23 at openjdk.java.net Sat May 29 21:01:39 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Sat, 29 May 2021 21:01:39 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v2] In-Reply-To: References: Message-ID: <3MB8Fez2KluwZHdawwNbOMRaOokagWE8cyQZndK4n7w=.fa8800ef-7596-4823-b684-fc3a62f6cb0d@github.com> > ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ > EDIT: Thank you, Kevin. :) > > This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: > - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. > For IntelliJ users: This is the language level shown inside the **Project Structure**. (File -> Project Structure...) > - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize JUnit 4. Also the shims are included/recognized (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Using gradle for the project structure (Loaded Gradle build scripts in IntelliJ) - Merge remote-tracking branch 'openjfx/master' into intellij-ide-fixes - Made IntelliJ build working ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/506/files - new: https://git.openjdk.java.net/jfx/pull/506/files/aecc9e68..763e81e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=506&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=506&range=00-01 Stats: 1076 lines in 37 files changed: 746 ins; 168 del; 162 mod Patch: https://git.openjdk.java.net/jfx/pull/506.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/506/head:pull/506 PR: https://git.openjdk.java.net/jfx/pull/506 From github.com+66004280+maran23 at openjdk.java.net Sat May 29 21:09:33 2021 From: github.com+66004280+maran23 at openjdk.java.net (Marius Hanl) Date: Sat, 29 May 2021 21:09:33 GMT Subject: RFR: 8267418: IntelliJ build and test of JavaFX does not work [v3] In-Reply-To: References: Message-ID: > ~~Question: I was wondering, should I create a ticket for this as well? Given the fact that I don't have an https://bugs.openjdk.java.net account, I need to use the official bug reporting tool, which looked a bit overkill to me since someone needs to check my created ticket, while this PR is only affecting the IntelliJ IDE with OpenJFX and not the JavaFX platform directly.~~ > EDIT: Thank you, Kevin. :) > > This PR fixes the errors you get when cloning and working with OpenJFX in IntelliJ IDE: > - The **.idea/misc.xml** is modified to use **JDK_11** as language level instead of JDK_8. > For IntelliJ users: This is the language level shown inside the **Project Structure**. (File -> Project Structure...) > - The **.idea/base.iml, .idea/controls.iml, .idea/fxml.iml, .idea/web.iml, .idea/graphics.iml** are modified to include/recognize JUnit 4. Also the shims are included/recognized (as test resource, this is very similar to the configuration inside the .classpath file from Eclipse) Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Reverted JUnit4 orderEntry Looks like the gradle settings did the trick. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/506/files - new: https://git.openjdk.java.net/jfx/pull/506/files/763e81e9..e6963285 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=506&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=506&range=01-02 Stats: 50 lines in 5 files changed: 0 ins; 50 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/506.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/506/head:pull/506 PR: https://git.openjdk.java.net/jfx/pull/506 From nlisker at gmail.com Sun May 30 05:05:35 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 30 May 2021 08:05:35 +0300 Subject: .classpath files for Eclipse In-Reply-To: References: <2076b439-9bb2-d07a-77b1-3f9b4f5ce299@bestsolution.at> <20210520125211.Horde.QwaUrG1L61tNBZJcCjaTgg9@webmail.df.eu> Message-ID: I created https://github.com/openjdk/jfx/pull/514 as a WIP, ready to be tested except for tests and apps. On Sat, May 22, 2021 at 8:56 AM Nir Lisker wrote: > There is an open bug report [1] that I created before the transition to > GitHub that fixes BuildSrc and some apps, I will update it for the latest > changes. > > Right now I am waiting to see which folders are still relevant. > > [1] https://bugs.openjdk.java.net/browse/JDK-8221708 > > On Thu, May 20, 2021 at 1:52 PM Jeanette Winzenburg < > fastegal at swingempire.de> wrote: > >> >> Hi Tom, >> >> can't say anything to your questions: being on win only and just >> having Eclipse projects for base, graphics, controls (everything else >> is handled by gradle from the commandline) >> >> -- Jeanette >> >> Zitat von Tom Schindl : >> >> > Hi Nir/Jeannette, >> > >> > As you are both using Eclipse for development I'd like to get your >> > take on the following things. >> > >> > Dealing with OS specific >> > ------------------------ >> > The graphics module has to have different source folders depending >> > on the OS you are developing on: >> > * Windows: build/hlsl/Decora and build/hslPrism >> > * Linux/OS-X: build/gensrc/jsl-decora build/gensrc/jsl-prism >> > >> > So when importing the projects Eclipse does not even build anything >> > until you fix the .classpath file - I'd like to propose to mark >> > those Source-Folders optional. >> > >> > Swing-Project >> > ------------- >> > There the .classpath has a none existing "src/test/java" I wonder >> > where that source is and if not there anymore remove the offending >> > entry from .classpath-File >> > >> > BuildSrc >> > -------- >> > What's the purpose of that project? The classpath is incorrect and >> > does it have to be a Java-Project? >> > >> > >> > Tom >> >> >> >> From nlisker at openjdk.java.net Sun May 30 05:05:12 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 30 May 2021 05:05:12 GMT Subject: RFR: 8234920: Add SpotLight to the selection of 3D light types [v19] In-Reply-To: References: Message-ID: <_2nurMPXTT-4aUq2nhlowFkQHetpemAEbD-ESFdhY3A=.50f97ff2-b0d7-4123-9d64-9175e9617e71@github.com> > Added a SpotLight only to the D3D pipeline currently. > > ### API discussion points > > - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also be a subclass of `PointLight` as it's a point light with direction and extra factors. I saw that `scenario.effect.light.SpotLight` extends its respective `PointLight`, but it's not a perfect analogy. In the end, I think it's a questions of whether `PointLight` will be expanded in a way which doesn't not suit `SpotLight`, and I tend to think that the answer is no. > > - [X] The inner and outer angles are the "diameter angles" as shown [here](https://docs.microsoft.com/en-us/windows/win32/direct3d9/light-typeshttps://docs.microsoft.com/en-us/windows/win32/direct3d9/light-types). I, personally, find it more intuitive that these are the "radius angles", so half these angles, as used in the spotlight factor formula. Do you think I can change this or do you prefer the current definition of the angles? > > - [x] The current implementation uses an ad-hoc direction property (using a `Point3D`). It crossed my mind that we could use the rotation transforms of the node to control the direction instead, just like we use the translation/layout of the node to get the position (there is an internal Affine3D transform for lights, not sure why `AmbientLight` needs it). Wouldn't that make more sense? When I rotate the light I would expect to see a change in direction. > > ### Implementation discussion points > > - [ ] I've gotten advice from a graphics engineer to treat point lights as spot lights with a 360 degrees coverage, which simplifies a few places. We can still try to optimize for a point light by looking at the light parameters: `falloff = 0` and `outerAngle = 180`. These possible optimization exist in `ES2PhongShader.java` and `D3DMeshView.cc`, and in the pixel/fragment shaders in the form of 3 different ways to compute the spotlight factor (the `computeLightN` methods). We need to check which of these give the best results. > > ## Performance > > Testing 3 point lights and comparing this branch with `master` using a 1000 division sphere, 200 meshes, and 5000 meshes. > Using an AMD RX 470 4GB GPU. > > In this branch, there is a possible CPU optimization for checking the light type and using precalculated values (in `D3DMeshView.cc` for d3d and `ES2PhongShader.java` for opengl). On the GPU, I tried 3 ways of computing the spotlight factor contributions (`computeSpotlightFactor`, `computeSpotlightFactor2` and `computeSpotlightFactor3`) trying out different branching and shortcuts. > > ### Results > The CPU "optimizations" made no difference, which is understandable considering it will not be the bottleneck. We can remove these if we want to simplify, though maybe if we allow a large number of lights it could make a difference (I doubt it). I don't have a strong preference either way. > > The sphere 1000 tests always gave max fps (120 on Win and 60 on Ubuntu). > > **Win 10** > Compared with the `master` branch, this patch shows 5-10 fps drop in the mesh 200 test and ~5 in the mesh 5000 test. I repeated the tests on several occasions and got different results in terms of absolute numbers, but the relative performance difference remained more or less the same. Out of the 3 `computeSpotlightFactor` methods, `computeSpotlightFactor3`, which has no "optimizations", gives slightly better performance. > > **Ubuntu 18** > The mesh 200 test always gave 60 fps because it is locked to this fps, so we can't measure the real GPU performance change. > The mesh 5000 test shows 2-6 fps drop from master, with `computeSpotlightFactor` > `computeSpotlightFactor2` > `computeSpotlightFactor3` at in terms of performance (~2 fps difference each). > > **Conclusion**: we can expect a 5 fps drop more or less with 3 point lights. `computeSpotlightFactor3` on d3d and `computeSpotlightFactor` on opengl gave the best performances. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Updated image and docs ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/334/files - new: https://git.openjdk.java.net/jfx/pull/334/files/f3d7c5ce..49171039 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=334&range=17-18 Stats: 1 line in 2 files changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/334.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/334/head:pull/334 PR: https://git.openjdk.java.net/jfx/pull/334 From john at status6.com Sun May 30 22:19:52 2021 From: john at status6.com (John Neffenger) Date: Sun, 30 May 2021 15:19:52 -0700 Subject: Minimum JDK policy for OpenJFX In-Reply-To: References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: On 5/19/21 1:17 PM, Ty Young wrote: > Biggest things for JavaFX that I can think of is jextract, a tool for > generating Java headers from a C header, and having all binding code > written in Java. JavaFX has been doing its own manual form of Project Panama since 2014. Look for the string "extends C.Structure" in the following two files: https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MX6Cursor.java https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDSystem.java In both cases, the technique was used to let JavaFX bypass the header file 'mxcfb.h' from NXP (formerly Freescale). I'm looking forward to replacing those hard-coded offsets with the tools from Project Panama. In fact, I'm hopeful that Project Panama will let me remove all of the native C code from the Monocle EPD platform. John From jgneff at openjdk.java.net Mon May 31 03:13:21 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 31 May 2021 03:13:21 GMT Subject: RFR: 8266396: Save VSCMD_DEBUG output in Windows build [v3] In-Reply-To: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> References: <2NDcHWx988GeKs0bOdlqFoJAX9RJuOzKr1G6idMlOiQ=.540d1b19-e596-4dfa-9718-45d1262ca0d3@github.com> Message-ID: On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio paths and environment variables. The batch files are a black box: any messages they print are discarded. If anything goes wrong, the only signs are a vague Gradle exception and a corrupted properties file. >> >> This has been causing problems for years. There are at least 49 messages on the mailing since 2017 that discuss the exception and ways to work around it. >> >> This pull request lets you enable the batch file messages, shedding light on their internal workings and allowing you to catch any errors at their source. Specifically, it adds the variable `VSCMD_DEBUG` to the environment of `genVSproperties.bat` and documents its use. >> >> ### Before >> >> For example, if your `PATH` environment variable is missing `C:/Windows/System32`, like mine was, you'll see the following errors: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 4s >> >> >> *Me:* What's a `WINSDK_DIR`? The Wiki says, "This means that you will have to define these paths manually." I guess this is normal. ??? >> >> ### After >> >> With this change, you can set the debug level to "3" in the `win.gradle` file and get a better picture of the problem: >> >> >> $ gradle sdk >> Dependency verification is an incubating feature. >> >>> Configure project : >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> 'reg' is not recognized as an internal or external command, >> operable program or batch file. >> >> ? >> >> 'powershell.exe' is not recognized as an internal or external command, >> operable program or batch file. >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 >> >> * What went wrong: >> A problem occurred evaluating script. >>> FAIL: WINSDK_DIR not defined >> >> ? >> >> BUILD FAILED in 3s >> >> >> *Me:* Oh, it's just a "command not found" error. I'll check my `PATH`. ?? > > John Neffenger has updated the pull request incrementally with one additional commit since the last revision: > > Skip sending telemetry to fix "file in use" error Thank you for the review, Marius. > But turns out the whole build folder should be deleted first as otherwise you will get the error again immediately. Yes, that's a good point! If you don't delete the `build` directory after the error, you'll get stuck and even `gradle clean` and `gradle cleanAll` won't let you recover. That's not obvious the first time it happens. > I think it will be more clear for everyone including new developers. :) I hope so, especially considering that the Windows platform is probably our largest source of potential new contributors. I fell into this trap after building JavaFX on Windows for years, though, so it might even help old developers, too. ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/488 From youngty1997 at gmail.com Mon May 31 03:53:38 2021 From: youngty1997 at gmail.com (Ty Young) Date: Sun, 30 May 2021 22:53:38 -0500 Subject: Minimum JDK policy for OpenJFX In-Reply-To: References: <8a4be61e-ca86-f75f-03ed-5bb2b96c587a@oracle.com> Message-ID: <28120f92-d68f-cba8-2f1c-2bd4a52bcfea@gmail.com> On 5/30/21 5:19 PM, John Neffenger wrote: > On 5/19/21 1:17 PM, Ty Young wrote: >> Biggest things for JavaFX that I can think of is jextract, a tool for >> generating Java headers from a C header, and having all binding code >> written in Java. > > JavaFX has been doing its own manual form of Project Panama since > 2014. Look for the string "extends C.Structure" in the following two > files: > > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MX6Cursor.java > > > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDSystem.java > > > In both cases, the technique was used to let JavaFX bypass the header > file 'mxcfb.h' from NXP (formerly Freescale). > > I'm looking forward to replacing those hard-coded offsets with the > tools from Project Panama. In fact, I'm hopeful that Project Panama > will let me remove all of the native C code from the Monocle EPD > platform. Now that you pointed it out, JavaFX uses SecurityManager: https://github.com/openjdk/jfx/blob/5e6d4429159e3fab9ec0aab9720393850d179710/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/C.java#L40 Which is being deprecated. Panama has its own runtime flag to enable native access not tied to SecurityManager. The C class native implementation can be replaced with Panama easily. A MemorySegment can be viewed using a ByteBuffer via: MemorySegment segment = MemorySegment.allocateNative(8, ResourceScope.newImplicitScope()); ByteBuffer buffer = segment.asByteBuffer(); asByteBuffer() doc says it wraps the MemorySegment, so I'm guessing it has a strong reference and memory is freed once the buffer and segment are no longer referenced. If someone wanted to try swapping out JavaFX's native implementation with Panama, this would be a good place to start IMO. > > John From arapte at openjdk.java.net Mon May 31 06:37:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 31 May 2021 06:37:40 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v4] In-Reply-To: References: Message-ID: <4RqUfRekXEnOOyCAOiYGTwG4mz7do5SEPgvNYDL01_E=.6eaaab7d-63df-41b7-9831-3c56af6da53b@github.com> > `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. > > I have tried three approaches and tested with modena.css which is ~134 KB in size. > Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, > > 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : > - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms > 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) > - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms > 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. > - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms > > > The time taken by `StyleManager.calculateCheckSum()` with current implementation is, > - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms > > > Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. > However we can choose approach#2 also. > If we choose approach#3 then bug summary should be changed accordingly. Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into SM_BufferedInputStream_8239138 - review update - minor: format correction - add test - only buffer[4096], similar to NativeLibLoader.calculateCheckSum() - BufferedInputStream + buffer[4096] - use BufferedInputStream ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/518/files - new: https://git.openjdk.java.net/jfx/pull/518/files/e1d6dbd7..16bb1514 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=518&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=518&range=02-03 Stats: 139 lines in 5 files changed: 119 ins; 6 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/518.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/518/head:pull/518 PR: https://git.openjdk.java.net/jfx/pull/518 From arapte at openjdk.java.net Mon May 31 08:18:18 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 31 May 2021 08:18:18 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v3] In-Reply-To: References: <44fYjFVs1OBoJkUdmtHdlAnqJ6vjOyWoIgl6kZGouXE=.e43d636b-052e-4ac0-a438-239bd4994848@github.com> Message-ID: On Fri, 28 May 2021 15:51:23 GMT, Kevin Rushforth wrote: > Now that PR #523 is integrated, can you merge in the latest changes from master to ensure a clean test run? The test passes with #523 integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/518 From pbansal at openjdk.java.net Mon May 31 11:18:23 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Mon, 31 May 2021 11:18:23 GMT Subject: RFR: 8239138: StyleManager should use a BufferedInputStream [v4] In-Reply-To: <4RqUfRekXEnOOyCAOiYGTwG4mz7do5SEPgvNYDL01_E=.6eaaab7d-63df-41b7-9831-3c56af6da53b@github.com> References: <4RqUfRekXEnOOyCAOiYGTwG4mz7do5SEPgvNYDL01_E=.6eaaab7d-63df-41b7-9831-3c56af6da53b@github.com> Message-ID: On Mon, 31 May 2021 06:37:40 GMT, Ambarish Rapte wrote: >> `StyleManager.calculateCheckSum()` uses a raw InputStream as the input to a `DigestInputStream` and reads one byte at a time. This is slower in performance and should be changed, either to use `BufferedInputStream` or read byte buffer of 4096 from the stream or use both. >> >> I have tried three approaches and tested with modena.css which is ~134 KB in size. >> Following are the approaches and time in milliseconds taken by the method StyleManager.calculateCheckSum(), collected from 25 readings, >> >> 1. Use BufferedInputStream and read one byte at a time [commit#1](https://github.com/openjdk/jfx/commit/6cd7d44d0ce1084c6cdb06a698c7aca127a615ef) : >> - Maximum: 53 ms, Minimum: 27 ms, Average: 39 ms >> 2. Use BufferedInputStream and read buffer of 4096 at a time [commit#1+2](https://github.com/openjdk/jfx/pull/518/files/6e0c621ea62691d5402b2bca5951d1012a5b1b91) >> - Maximum: 17 ms, Minimum: 14 ms, Average: 15.58 ms >> 3. Use raw InputStream(current implementation) and read buffer of 4096 at a time [commit#1+2+3](https://github.com/openjdk/jfx/pull/518/files/215e1a183cfb902247f0d48685f7a901cb5fb003), which also similar to `NativeLibLoader.calculateCheckSum()` and looks faster than previous two. >> - Maximum: 16 ms, Minimum: 13 ms, Average: 14.25 ms >> >> >> The time taken by `StyleManager.calculateCheckSum()` with current implementation is, >> - Maximum: 61 ms, Minimum: 38 ms, Average: 50.58 ms >> >> >> Both approaches 2 & 3 show good improvement. I would prefer approach#3 as it is similar to `NativeLibLoader.calculateCheckSum()`. >> However we can choose approach#2 also. >> If we choose approach#3 then bug summary should be changed accordingly. > > Ambarish Rapte has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into SM_BufferedInputStream_8239138 > - review update > - minor: format correction > - add test > - only buffer[4096], similar to NativeLibLoader.calculateCheckSum() > - BufferedInputStream + buffer[4096] > - use BufferedInputStream Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/518