From tsayao at openjdk.java.net Wed Jun 1 00:07:38 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 1 Jun 2022 00:07:38 GMT Subject: Integrated: 8284654: Modal behavior returns to wrong stage In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 19:26:36 GMT, Thiago Milczarek Sayao wrote: > When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 This pull request has now been integrated. Changeset: 864792d8 Author: Thiago Milczarek Sayao URL: https://git.openjdk.java.net/jfx/commit/864792d84811b64815357722be0378397d212408 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8284654: Modal behavior returns to wrong stage Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/784 From aghaisas at openjdk.java.net Wed Jun 1 03:11:42 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 1 Jun 2022 03:11:42 GMT Subject: RFR: 8277756: DatePicker listener might not be added when using second constructor In-Reply-To: References: Message-ID: On Tue, 24 May 2022 21:35:15 GMT, Marius Hanl wrote: > The `valueProperty()` and `chronologyProperty()` listener are now added in the second constructor of `DatePicker` > (`public DatePicker(LocalDate localDate)`) instead of the first one (`public DatePicker()`). > Therefore, both listener are now added no matter which constructor is used. Looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/801 From mhanl at openjdk.java.net Wed Jun 1 06:19:43 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 1 Jun 2022 06:19:43 GMT Subject: Integrated: 8277756: DatePicker listener might not be added when using second constructor In-Reply-To: References: Message-ID: On Tue, 24 May 2022 21:35:15 GMT, Marius Hanl wrote: > The `valueProperty()` and `chronologyProperty()` listener are now added in the second constructor of `DatePicker` > (`public DatePicker(LocalDate localDate)`) instead of the first one (`public DatePicker()`). > Therefore, both listener are now added no matter which constructor is used. This pull request has now been integrated. Changeset: da5bd371 Author: Marius Hanl Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/da5bd3716441f201691377c52abba59ce03bc322 Stats: 116 lines in 2 files changed: 94 ins; 19 del; 3 mod 8277756: DatePicker listener might not be added when using second constructor Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/801 From mennen at openjdk.java.net Wed Jun 1 08:40:38 2022 From: mennen at openjdk.java.net (Michael Ennen) Date: Wed, 1 Jun 2022 08:40:38 GMT Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 19:55:28 GMT, Nir Lisker wrote: >> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier. >> >> Since there are many small changes, I'm giving a full list here: >> >> **Java** >> >> * `NGShape3D.java` >> * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`. >> * Normalized the direction here instead of in the native code. >> * Ambient light is now only set when it exists (and is not black). >> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method). >> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change. >> >> **Native C++** >> >> * Initialized the class members of `D3DLight`, `D3DMeshView` and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). >> * `D3DLight` >> * Commented out unused methods. Were they supposed to be used at some point? >> * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing. >> * `D3DPhongShader.h` >> * Renamed some of the register constants for more clarity. >> * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused. >> * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position. >> * `D3DMeshView.cc` >> * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders. >> * Removed the direction normalization as stated in the change for `NGShape3D.java`. >> * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`. >> >> **Native shaders** >> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera). >> * Commented out many unused functions. I don't know what they are for, so I didn't remove them. >> * `vsConstants` >> * Removed the light color from here since it's unused, only the position is. >> * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead. >> * `vs2ps` >> * Removed the ambient color interpolation, which frees a register (no change in performance). >> * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump?). >> * `Mtl1PS` and `psMath` >> * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity. >> * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`. >> >> No changes in performance were measured and the behavior stayed the same. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused comments, clean constructor modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.h line 95: > 93: > 94: /* > 95: * Computes the light's contribution by using the Phong shading model. A contribution consist of a diffuse component and a Tiny nit: consist => consists ------------- PR: https://git.openjdk.java.net/jfx/pull/789 From lbourges at openjdk.java.net Wed Jun 1 11:27:42 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 1 Jun 2022 11:27:42 GMT Subject: RFR: 8287604: Update MarlinFX to 0.9.4.5 [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Tue, 31 May 2022 22:25:23 GMT, Kevin Rushforth wrote: >> Hi, >> Time is going short before openjfx 19... >> >> 2 options: >> - keep dpqs for corner cases and keep my coding life simple >> - disable or remove dpqs code in marlinFX for openjfx, so my branches will diverge... >> >> Any advice, @kevinrushforth ? > >> keep dpqs for corner cases and keep my coding life simple > > I think this approach is fine. Diverging the code would likely make it less stable, and you answered the question about the provenance of the code, so there's no issue there. We should try to get this in before RDP1 of JavaFX 19 if possible. > > One more thing, as I wrote in my above comment: > >> We should file a new JBS Enhancement issue -- similar to what was done for Marlin 0.9.2 via [JDK-8204621](https://bugs.openjdk.java.net/browse/JDK-8204621) rather than using a narrow bug, since that bug is only part of what's being done. The current bug can either be added to the PR, or else that JBS bug (JDK-8274066) can be closed as a duplicate of the new Enhancement. > > I took the liberty of filing [JDK-8287604](https://bugs.openjdk.java.net/browse/JDK-8287604) for this enhancement. Can you change the title to: > > 8287604: Update MarlinFX to 0.9.4.5 Thx @kevinrushforth I will look at fixing the test with hidpi very soon ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From tobias.oelgarte at gmail.com Tue Jun 7 18:39:21 2022 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Tue, 7 Jun 2022 20:39:21 +0200 Subject: Updating printers while application is running? Message-ID: Is there some way to update the ObservableSet of Printers once the Application is running? Calling Printer.getAllPrinters() always returns the same OberservableSet and it does not change - ever. [1] We have an JavaFx based application running under Windows 10/11 that is used to print on wireless printers, that are not always available. Having to restart the the application every time a printer goes away or comes available is a serious pain for the users. Is there any kind of workaround? I doubt it will be fixed in the near future, since this comment is from 6 years ago [2]: ??? // This is static. Eventually I want it to be dynamic, but first ??? // it needs to be enhanced to only create new instances where ??? // there really has been a change, which will be rare. [1] https://stackoverflow.com/questions/38470568/javafx-doesnt-detect-changes-of-available-printers [2] https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java#L99 From philip.race at oracle.com Tue Jun 7 19:44:08 2022 From: philip.race at oracle.com (Philip Race) Date: Tue, 7 Jun 2022 12:44:08 -0700 Subject: Updating printers while application is running? In-Reply-To: References: Message-ID: <3cc647d4-27d0-b1e3-189a-8518123d7ccf@oracle.com> Ahem .. well .. I guess we (I) forgot to get back to that. Since the current implementation on Windows wraps the Java 2D printing code and it registers with windows to be told about changes in printers then the calls being made in the method with that comment would (well, should) provide the updated printers .. The comment was (I think) referring to the need to know when there was actually a change there to avoid perpetual re-creation. If the 2D side is working as expected I'll see if there's something I can do along the lines of a quick check every time that the number of underlying printers is the same and then if not it is worthwhile, coupled with a refresh every 2 minutes so it should never get too stale. -phil. On 6/7/22 11:39 AM, Tobias Oelgarte wrote: > Is there some way to update the ObservableSet of Printers once the > Application is running? Calling Printer.getAllPrinters() always > returns the same OberservableSet and it does not change - ever. [1] > > We have an JavaFx based application running under Windows 10/11 that > is used to print on wireless printers, that are not always available. > Having to restart the the application every time a printer goes away > or comes available is a serious pain for the users. > > Is there any kind of workaround? > > I doubt it will be fixed in the near future, since this comment is > from 6 years ago [2]: > > ??? // This is static. Eventually I want it to be dynamic, but first > ??? // it needs to be enhanced to only create new instances where > ??? // there really has been a change, which will be rare. > > [1] > https://stackoverflow.com/questions/38470568/javafx-doesnt-detect-changes-of-available-printers > > [2] > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java#L99 From thiago.sayao at gmail.com Tue Jun 7 19:50:01 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 7 Jun 2022 16:50:01 -0300 Subject: Updating printers while application is running? In-Reply-To: References: Message-ID: Hi, I use it through the javax.print API: ObservableList printServices = FXCollections.observableArrayList( PrintServiceLookup.lookupPrintServices(null, null)); Maybe it may help for now, but to me it seems it should not be static. Em ter., 7 de jun. de 2022 ?s 15:39, Tobias Oelgarte < tobias.oelgarte at gmail.com> escreveu: > Is there some way to update the ObservableSet of Printers once the > Application is running? Calling Printer.getAllPrinters() always returns > the same OberservableSet and it does not change - ever. [1] > > We have an JavaFx based application running under Windows 10/11 that is > used to print on wireless printers, that are not always available. > Having to restart the the application every time a printer goes away or > comes available is a serious pain for the users. > > Is there any kind of workaround? > > I doubt it will be fixed in the near future, since this comment is from > 6 years ago [2]: > > // This is static. Eventually I want it to be dynamic, but first > // it needs to be enhanced to only create new instances where > // there really has been a change, which will be rare. > > [1] > > https://stackoverflow.com/questions/38470568/javafx-doesnt-detect-changes-of-available-printers > > [2] > > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java#L99 > From tobias.oelgarte at gmail.com Tue Jun 7 20:14:03 2022 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Tue, 7 Jun 2022 22:14:03 +0200 Subject: Updating printers while application is running? In-Reply-To: References: Message-ID: <3d15003f-ab07-d45b-5fcf-4d808fad3751@gmail.com> I already thought about using PrintServiceLookup. I could use it to show the user the currently available printers, but I can't use it to create a javafx.print.Printer instance without reflective access (JPMS). At the moment I'm stuck with a an unmodifiable OberservableSet that never updates. On 07.06.22 21:50, Thiago Milczarek Say?o wrote: > Hi, > > I use it through?the javax.print API: > > ? ? ? ? ? ? ? ? ObservableList printServices = > FXCollections.observableArrayList( > PrintServiceLookup.lookupPrintServices(null, null)); > > Maybe it may help for now, but to me it seems it should?not be static. > > > Em ter., 7 de jun. de 2022 ?s 15:39, Tobias Oelgarte > escreveu: > > Is there some way to update the ObservableSet of Printers once the > Application is running? Calling Printer.getAllPrinters() always > returns > the same OberservableSet and it does not change - ever. [1] > > We have an JavaFx based application running under Windows 10/11 > that is > used to print on wireless printers, that are not always available. > Having to restart the the application every time a printer goes > away or > comes available is a serious pain for the users. > > Is there any kind of workaround? > > I doubt it will be fixed in the near future, since this comment is > from > 6 years ago [2]: > > ???? // This is static. Eventually I want it to be dynamic, but first > ???? // it needs to be enhanced to only create new instances where > ???? // there really has been a change, which will be rare. > > [1] > https://stackoverflow.com/questions/38470568/javafx-doesnt-detect-changes-of-available-printers > > [2] > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java#L99 > From tobias.oelgarte at gmail.com Wed Jun 8 18:34:29 2022 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Wed, 8 Jun 2022 20:34:29 +0200 Subject: Updating printers while application is running? In-Reply-To: <3cc647d4-27d0-b1e3-189a-8518123d7ccf@oracle.com> References: <3cc647d4-27d0-b1e3-189a-8518123d7ccf@oracle.com> Message-ID: <1357f736-ee1c-c327-88a1-33a793012842@gmail.com> I don't know if there is an common event available in the Java2D backend to detect added/removed printers directly. So far i could not see anything like that. Every PrintService instance should implement the equals() [1] method to determine uniqueness. This could be used to compare/intersect the observable set of printers hold by javafx.print.Printer#getAllPrinters() against the array of PrintService instances exposed by PrintServiceLookup.getPrintServices(...). That way it should be possible to detect if a printer was removed or added. It could also be used to update the default printer property (on access and/or periodically). [1] https://docs.oracle.com/en/java/javase/18/docs/api/java.desktop/javax/print/PrintService.html#equals(java.lang.Object) On 07.06.22 21:44, Philip Race wrote: > Ahem .. well .. I guess we (I) forgot to get back to that. > > Since the current implementation on Windows wraps the Java 2D printing > code > and it registers with windows to be told about changes in printers > then the > calls being made in the method with that comment would (well, should) > provide > the updated printers .. > > The comment was (I think) referring to the need to know when there was > actually > a change there to avoid perpetual re-creation. > > If the 2D side is working as expected I'll see if there's something I > can do along the lines > of a quick check every time that the number of underlying printers is > the same and then if not it is worthwhile, > coupled with a refresh every 2 minutes so it should never get too stale. > > -phil. > > On 6/7/22 11:39 AM, Tobias Oelgarte wrote: >> Is there some way to update the ObservableSet of Printers once the >> Application is running? Calling Printer.getAllPrinters() always >> returns the same OberservableSet and it does not change - ever. [1] >> >> We have an JavaFx based application running under Windows 10/11 that >> is used to print on wireless printers, that are not always available. >> Having to restart the the application every time a printer goes away >> or comes available is a serious pain for the users. >> >> Is there any kind of workaround? >> >> I doubt it will be fixed in the near future, since this comment is >> from 6 years ago [2]: >> >> ??? // This is static. Eventually I want it to be dynamic, but first >> ??? // it needs to be enhanced to only create new instances where >> ??? // there really has been a change, which will be rare. >> >> [1] >> https://stackoverflow.com/questions/38470568/javafx-doesnt-detect-changes-of-available-printers >> >> [2] >> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java#L99 > From philip.race at oracle.com Wed Jun 8 19:14:16 2022 From: philip.race at oracle.com (Philip Race) Date: Wed, 8 Jun 2022 12:14:16 -0700 Subject: Updating printers while application is running? In-Reply-To: <1357f736-ee1c-c327-88a1-33a793012842@gmail.com> References: <3cc647d4-27d0-b1e3-189a-8518123d7ccf@oracle.com> <1357f736-ee1c-c327-88a1-33a793012842@gmail.com> Message-ID: <9117be1a-406f-6d78-2b13-d1ffcea59ddf@oracle.com> On 6/8/22 11:34 AM, Tobias Oelgarte wrote: > > I don't know if there is an common event available in the Java2D > backend to detect added/removed printers directly. So far i could not > see anything like that. > I am referring to windows native code we have in Java 2D. It is completely invisible at the API level of Java 2D. > Every PrintService instance should implement the equals() [1] method > to determine uniqueness. This could be used to compare/intersect the > observable set of printers hold by > javafx.print.Printer#getAllPrinters() against the array of > PrintService instances exposed by > PrintServiceLookup.getPrintServices(...). That way it should be > possible to detect if a printer was removed or added. It could also be > used to update the default printer property (on access and/or > periodically). > Well yes, there's got to be a comparison.? No one said "I don't know what to do here" .. -phil. > [1] > https://docs.oracle.com/en/java/javase/18/docs/api/java.desktop/javax/print/PrintService.html#equals(java.lang.Object) > > On 07.06.22 21:44, Philip Race wrote: >> Ahem .. well .. I guess we (I) forgot to get back to that. >> >> Since the current implementation on Windows wraps the Java 2D >> printing code >> and it registers with windows to be told about changes in printers >> then the >> calls being made in the method with that comment would (well, should) >> provide >> the updated printers .. >> >> The comment was (I think) referring to the need to know when there >> was actually >> a change there to avoid perpetual re-creation. >> >> If the 2D side is working as expected I'll see if there's something I >> can do along the lines >> of a quick check every time that the number of underlying printers is >> the same and then if not it is worthwhile, >> coupled with a refresh every 2 minutes so it should never get too stale. >> >> -phil. >> >> On 6/7/22 11:39 AM, Tobias Oelgarte wrote: >>> Is there some way to update the ObservableSet of Printers once the >>> Application is running? Calling Printer.getAllPrinters() always >>> returns the same OberservableSet and it does not change - ever. [1] >>> >>> We have an JavaFx based application running under Windows 10/11 that >>> is used to print on wireless printers, that are not always >>> available. Having to restart the the application every time a >>> printer goes away or comes available is a serious pain for the users. >>> >>> Is there any kind of workaround? >>> >>> I doubt it will be fixed in the near future, since this comment is >>> from 6 years ago [2]: >>> >>> ??? // This is static. Eventually I want it to be dynamic, but first >>> ??? // it needs to be enhanced to only create new instances where >>> ??? // there really has been a change, which will be rare. >>> >>> [1] >>> https://stackoverflow.com/questions/38470568/javafx-doesnt-detect-changes-of-available-printers >>> >>> [2] >>> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java#L99 >> From tobias.oelgarte at gmail.com Wed Jun 8 23:54:05 2022 From: tobias.oelgarte at gmail.com (Tobias Oelgarte) Date: Thu, 9 Jun 2022 01:54:05 +0200 Subject: Updating printers while application is running? In-Reply-To: <9117be1a-406f-6d78-2b13-d1ffcea59ddf@oracle.com> References: <3cc647d4-27d0-b1e3-189a-8518123d7ccf@oracle.com> <1357f736-ee1c-c327-88a1-33a793012842@gmail.com> <9117be1a-406f-6d78-2b13-d1ffcea59ddf@oracle.com> Message-ID: <633599f7-d56e-fbec-6832-ce53fd576b24@gmail.com> On 08.06.22 21:14, Philip Race wrote: > > I am referring to windows native code we have in Java 2D. > It is completely invisible at the API level of Java 2D. I understand that the public API does not provide this feature. Java 2D itself listens to the events from Windows and updates the array of PrintServices behind PrintServiceLookup accordingly. Sadly it does not expose the events. > Well yes, there's got to be a comparison.? No one said "I don't know > what to do here" .. Sorry! I don't want to tell you, what to do or how to do it. I simply hoped to find an easy solution, which might have been overlooked. From duke at openjdk.java.net Thu Jun 9 07:50:41 2022 From: duke at openjdk.java.net (Christian Heilmann) Date: Thu, 9 Jun 2022 07:50:41 GMT Subject: RFR: 8271395: Fixing crash at printing [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 07:52:31 GMT, Florian Kirmaier wrote: >> This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread. >> I'm open for better solutions on how to fix this Issue. >> Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8271395 > QuantumRenderer is no longer public How to proceed to get this PR reviewed? ------------- PR: https://git.openjdk.java.net/jfx/pull/618 From duke at openjdk.java.net Thu Jun 9 07:50:45 2022 From: duke at openjdk.java.net (Christian Heilmann) Date: Thu, 9 Jun 2022 07:50:45 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v4] In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 19:04:56 GMT, Florian Kirmaier wrote: >> Making the initial listener of the ListProperty weak fixes the problem. >> The same is fixed for Set and Map. >> Due to a smart implementation, this is done without any performance drawback. >> (The trick is to have an object, which is both the WeakReference and the Changelistener) >> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8277848 > Added the 3 requests whitespaces How to proceed to get this PR reviewed? ------------- PR: https://git.openjdk.java.net/jfx/pull/689 From fkirmaier at openjdk.java.net Thu Jun 9 07:55:47 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 9 Jun 2022 07:55:47 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v8] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 17:14:11 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8273485 >> Added check for null when calling initScreens > > modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1349: > >> 1347: [self->nativeFullScreenModeWindow performSelector:@selector(toggleFullScreen:) withObject:nil]; >> 1348: // wait until the operation is complete >> 1349: [GlassApplication enterFullScreenExitingLoop]; > > You will need to restore the call to `toggleFullScreen` in order to support exiting from full-screen. This was further discussed in the discussion below. So this is no longer up to date and therefore resolved. ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From duke at openjdk.java.net Thu Jun 9 07:55:45 2022 From: duke at openjdk.java.net (Christian Heilmann) Date: Thu, 9 Jun 2022 07:55:45 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v8] In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 10:05:10 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273485 > Added check for null when calling initScreens How to proceed to get this PR reviewed? ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From duke at openjdk.java.net Thu Jun 9 07:56:45 2022 From: duke at openjdk.java.net (Christian Heilmann) Date: Thu, 9 Jun 2022 07:56:45 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v5] In-Reply-To: References: Message-ID: On Thu, 27 Jan 2022 14:50:16 GMT, Florian Kirmaier wrote: >> After thinking about this issue for some time, I've now got a solution. >> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. >> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8269907 > Removed the sync methods for the scene, because they don't work when peer is null, and they are not necessary. How to proceed to get this PR reviewed? ------------- PR: https://git.openjdk.java.net/jfx/pull/584 From duke at openjdk.java.net Thu Jun 9 07:57:46 2022 From: duke at openjdk.java.net (Christian Heilmann) Date: Thu, 9 Jun 2022 07:57:46 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v3] In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Mon, 10 Jan 2022 12:29:04 GMT, Florian Kirmaier wrote: >> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. >> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 >> run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK_8256397 > Added a small test-factory, to test more cases How to proceed to get this PR reviewed? ------------- PR: https://git.openjdk.java.net/jfx/pull/353 From duke at openjdk.java.net Thu Jun 9 07:57:49 2022 From: duke at openjdk.java.net (Christian Heilmann) Date: Thu, 9 Jun 2022 07:57:49 GMT Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can cause endless loop/crash and other performance issues [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 15:12:23 GMT, Florian Kirmaier wrote: >> It's "a bit" complicated. >> In some situations, getRuns get's called because listeners on bounds are set. >> This causes TextFlow to layout to compute the runs. >> Afterward, the bounds of the parents get updated. >> This triggers a call to compute bounds - which cascades up to the children. >> When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer. >> The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack) >> >> In the case it happened - it didn't repair and the application kinda crashed. >> This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds. >> It also can cause unpredictable performance issues. >> >> Unit test and example stacktrace are in the ticket. >> >> The suggested fix makes sure that recomputing the geometry of the Text, doesn't trigger the layout of the TextFlow. >> The Textflow should be layouting by the Parent. >> This might change the behavior in some cases, but as far as I've tested it works without issues in TextFlow Heavy applications. >> >> Benefits: >> * Better Tooling Support For ScenicView etc. >> * Fixes complicated but reproducible crashes >> * Might fix some rare crashes, which are hard to reproduce >> * Likely improves performance - might fix some edge cases with unpredictable bad performance > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8269921 > Added a copyright header How to proceed to get this PR reviewed? ------------- PR: https://git.openjdk.java.net/jfx/pull/564 From abhinay_agarwal at live.com Thu Jun 9 11:53:23 2022 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Thu, 9 Jun 2022 11:53:23 +0000 Subject: How to set WM_CLASS for GNOME? In-Reply-To: <1653585625.198711531@f498.i.mail.ru> References: <1653585625.198711531@f498.i.mail.ru> Message-ID: Hi Alex, Do you have the following entry in the .desktop file of your application[1]: StartupWMClass=com.foo.bar.FooApplication -Abhinay [1] https://github.com/gluonhq/scenebuilder/pull/407 ________________________________ From: openjfx-dev on behalf of Alex Orlov Sent: Thursday, May 26, 2022 10:50 PM To: openjfx-dev Subject: How to set WM_CLASS for GNOME? Hello, I develop a JavaFX application for Linux. And on my Ubuntu 20 I have a problem. I do `stage.setTitle("Foo");` and I have a window with title `Foo`, but in Ubuntu top bar I see the name of the class `com.foo.bar.FooApplication`. As I understand I should set correctly WM_CLASS. The only solution I found is this one https://stackoverflow.com/a/54467323/5057736 However, I work in JPMS and I can?t access com.sun.glass.ui.Application. Could anyone say how I can make my JavaFx application show "Foo" instead of class name in Ubuntu top bar? -- Best regards, Alex Orlov From jvos at openjdk.java.net Wed Jun 15 08:34:57 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 15 Jun 2022 08:34:57 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux [v2] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 15:19:02 GMT, Kevin Rushforth wrote: >> This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). >> >> I ran a full build and test, including media and WebKit. > > Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into 8283402-gcc-11.2 > - 8283402: Update to gcc 11.2 on Linux This is working on our build/ci pipeline now, using a dedicated devkit that is very similar to the one produced by https://github.com/openjdk/jdk/tree/master/make/devkit . I think this PR can now be reviewed/integrated. ------------- PR: https://git.openjdk.org/jfx/pull/761 From aghaisas at openjdk.org Fri Jun 17 05:40:01 2022 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 17 Jun 2022 05:40:01 GMT Subject: RFR: 8251483: TableCell: NPE on modifying item's list [v2] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 22:43:58 GMT, Marius Hanl wrote: >> This PR fixes an issue where the item of the table row is null, although the cell itself is not empty (non null value). >> >> The fix is to call `indexChanged(..)` immediately after the index was changed, but before all `indexProperty()` listener are notified. >> The then notified listener in `TableRowSkinBase` will update the underlying cells, which will eventually result in an call to `updateItem(..)`, where the NPE happened (and now not anymore, since the table row is now correctly setup before). >> >> There is one special case: When the index didn't changed at all, we manually call `indexChanged(..)` (just like before) since when a property is not changed, `invalidated()` is not called, but we need to notify subclasses that `updateIndex(..)` was called. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8251483: Updated copyright year Looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.org/jfx/pull/741 From arapte at openjdk.org Fri Jun 17 08:16:21 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 17 Jun 2022 08:16:21 GMT Subject: RFR: 8285253: update boot jdk to 18.0.1 Message-ID: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> Update Boot JDK to 18.0.1 Creating PR to initiate GitHub actions build. Tested locally on Mac OS Catalina. ------------- Commit messages: - update boot jdk to 18.0.1 Changes: https://git.openjdk.org/jfx/pull/792/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=792&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285253 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/792.diff Fetch: git fetch https://git.openjdk.org/jfx pull/792/head:pull/792 PR: https://git.openjdk.org/jfx/pull/792 From jvos at openjdk.org Fri Jun 17 08:16:21 2022 From: jvos at openjdk.org (Johan Vos) Date: Fri, 17 Jun 2022 08:16:21 GMT Subject: RFR: 8285253: update boot jdk to 18.0.1 In-Reply-To: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> References: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> Message-ID: <2dmqa35GgDkYqgJ77E2r_cN87KGBxucMEWfYOEc8_dA=.4a0f42d9-8784-4f43-b065-78b9ef8b6ec2@github.com> On Tue, 10 May 2022 09:50:08 GMT, Ambarish Rapte wrote: > Update Boot JDK to 18.0.1 > Creating PR to initiate GitHub actions build. > Tested locally on Mac OS Catalina. @arapte is there a reason this is in Draft? I think we can review and integrate is, no? ------------- PR: https://git.openjdk.org/jfx/pull/792 From arapte at openjdk.org Fri Jun 17 08:16:21 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 17 Jun 2022 08:16:21 GMT Subject: RFR: 8285253: update boot jdk to 18.0.1 In-Reply-To: <2dmqa35GgDkYqgJ77E2r_cN87KGBxucMEWfYOEc8_dA=.4a0f42d9-8784-4f43-b065-78b9ef8b6ec2@github.com> References: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> <2dmqa35GgDkYqgJ77E2r_cN87KGBxucMEWfYOEc8_dA=.4a0f42d9-8784-4f43-b065-78b9ef8b6ec2@github.com> Message-ID: On Wed, 15 Jun 2022 08:27:46 GMT, Johan Vos wrote: > @arapte is there a reason this is in Draft? I think we can review and integrate is, no? Yes Johan, There were few system tests failing with updated boot jdk. It turns out they fail with earlier boot jdk too(with 17 too). Reported the issue here : [JDK-8288652](https://bugs.openjdk.org/browse/JDK-8288652), which does not seem like a blocker. ------------- PR: https://git.openjdk.org/jfx/pull/792 From thiago.sayao at gmail.com Fri Jun 17 13:37:28 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 17 Jun 2022 10:37:28 -0300 Subject: enableInputMethodEvents Message-ID: Hi, View.java has this method (enableInputMethodEvents) with no documentation. On Linux it uses X input method events. But I can't figure out why exactly it must be enabled. When it's not enabled, there are input method events anyway.... And it seems (at least on Linux) to do the same thing for keyboard events, but using Xlib directly instead of GDK. It seems to touch composition - that is when multiple keypresses are needed to generate a symbol, for example, accented characters. Why does it exist? -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Fri Jun 17 14:30:35 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 17 Jun 2022 11:30:35 -0300 Subject: Xlib backend In-Reply-To: References: <4hzgkqn7my.fsf@qfs.de> Message-ID: Hi, Did some progress on the xlib backend. https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib - Transparent Stages java @build/run.args -cp apps/toys/Hello/dist/Hello.jar hello.HelloTranspStageAnim - On top stages java @build/run.args -cp apps/toys/Hello/dist/Hello.jar hello.HelloStageOnTop gtk is not initialized anymore (still links because there is porting to do). -- Thiago. Em ter., 17 de mai. de 2022 ?s 18:17, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > Did some improvements on my "pure x11" branch: > > - Bitmaps are now handled by cairo which will use Xrender if available > (will be beneficial if there's an alpha channel). > - Configuration using Xsettings (such as double click time) > - Setting the app icon now works > - Custom cursor works > - Mouse button works > - Able to launch Ensemble8 (with random crashes). > > Interesting thing is that there's no need to convert BGRA -> RGBA. Not > sure if it's a big performance improvement. > > It seems the only thing that will be missing to completely ditch gtk are > the "common dialogs" such as file open, etc. > > I'm also investigating Wayland. It's somewhat similar to Xorg when it > comes to events and the use of XDG specs. Probably will replace cairo with > egl. > > -- Thiago. > > > > > > > > > > Em dom., 24 de abr. de 2022 ?s 17:40, Thiago Milczarek Say?o < > thiago.sayao at gmail.com> escreveu: > >> Hi, >> >> Xlib port at: >> https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib >> >> Is able to very poorly run Ensemble8: >> java @build/run.args -jar apps/samples/Ensemble8/dist/Ensemble8.jar >> >> Keyboard events still do not work, mouse clicks are still buggy. >> There will be crashes, but it's progress. >> Window size & positioning is better now. >> >> I am painting directly like this: >> >> void WindowContextBase::paint(void* data, jint width, jint height) { >> Pixmap pixmap = XCreatePixmapFromBitmapData(display, DefaultRootWindow(display), (char *) data, width, height, 0, 0, depth); >> XCopyPlane(display, pixmap, xwindow, DefaultGC(display, DefaultScreen(display)), 0, 0, width, height, 0, 0, 1); >> >> XFlush(display); >> XFreePixmap(display, pixmap); >> } >> >> It does flicker a little, maybe it needs XSync extension to draw together >> with WM, maybe some kind of buffering. >> Using cairo is possible, but it's a final render, not sure if there will >> be advantages. >> >> I am accepting opinions. >> >> >> -- Thiago. >> >> Em ter., 12 de abr. de 2022 ?s 03:22, escreveu: >> >>> >>> Hi Thiago, >>> >>> I wholly agree. >>> >>> If gtk can be taken out of the equation it will reduce dependencies >>> significantly. Like we had with gtk2 vs. 3 in JavaFX/Swing >>> cross-embedding. Moving to gtk3 would start this all over again >>> whereas plain Xlib should remain fully compatible regardless of the >>> gtk version used by Swing (or SWT or whatever). >>> >>> I'll gladly help with testing - just ping me when you've got a >>> version that is reasonably stable. >>> >>> Best regards, >>> Greg >>> >>> Thiago Milczarek Say?o writes: >>> >>> > Kevin, >>> > >>> > Sure, I was hoping for the question. >>> > >>> > "The focus of GTK has moved away from being a ?meta toolkit? that other >>> > toolkits can use as a ?backend?." >>> > >>> > Quoted from >>> > >>> https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4 >>> > >>> > The first attempt I have made is the logical one, gtk4: >>> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground >>> > >>> > Then I have discovered it's not possible to use gtk4 without Xlib and >>> that >>> > many window management functions are gone (see the quotation link). >>> > In addition to this: >>> > - Gtk4 cannot draw directly on the window or set the background without >>> > gtk4 css; >>> > - It cannot even move the window, just tell the compositor it started a >>> > move. >>> > >>> > I also have played plenty with gtk3, it breaks a lot of things thru >>> the 3.x >>> > release cycle, such as DND. >>> > >>> > So, I see no reason to use Gtk if Xlib fits better as a glass backend >>> (has >>> > all the needed functions) and Gtk would use Xlib anyway and hide much >>> > needed functionality. >>> > >>> > Current glass Gtk backend already touches a lot of Xlib. >>> > >>> > Wayland is fully compatible with Xlib, so we can work on "both worlds" >>> with >>> > it. Someday on the future a pure Wayland backend would be nice. >>> > >>> > I'm happy to answer any further questions. >>> > >>> > -- Thiago. >>> > >>> > >>> > >>> > >>> > Em seg., 11 de abr. de 2022 ?s 12:41, Kevin Rushforth < >>> > kevin.rushforth at oracle.com> escreveu: >>> > >>> >> Can you say more about the motivation for doing this? Given the >>> eventual >>> >> direction for Wayland support, even in X11 compatibility mode, I would >>> >> expect more use of gtk and less use of Xlib, not the other way around. >>> >> >>> >> -- Kevin >>> >> >>> >> On 4/10/2022 2:43 PM, Thiago Milczarek Say?o wrote: >>> >> > Hi, >>> >> > >>> >> > I got simple samples running on the pure Xlib port of the Gtk >>> backend. >>> >> > >>> >> > It still has gtk code, but mainly uses Xlib by now. Don't judge the >>> code, >>> >> > I'm porting it gradually. >>> >> > >>> >> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib >>> >> > >>> >> > java @build/run.args -cp apps/toys/Hello/dist/Hello.jar >>> >> hello.HelloCursors >>> >> > >>> >> > Window coordinates and sizes are still off a bit, so you might have >>> to >>> >> > resize the window to redraw. >>> >> > >>> >> > -- Thiago. >>> >> >>> >> >>> >>> -- >>> Gregor Schmid >>> >>> E: gregor.schmid at qfs.de >>> T: +49 8171 38648-11 >>> F: +49 8171 38648-16 >>> >>> Quality First Software GmbH | www.qfs.de >>> B?rgermeister-Graf-Ring 10 | 82538 Geretsried | Germany >>> GF Gregor Schmid, Karlheinz Kellerer >>> HRB M?nchen 140833 >>> >>> The data protection information in accordance with the EU General Data >>> Protection Regulation applies to authorized representatives / >>> authorized representatives of "legal persons" in accordance with Art. >>> 12 ff. DS-GVO >>> https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Sat Jun 18 14:49:04 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 18 Jun 2022 14:49:04 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: Message-ID: <46O6crSZ92SwITGQA-AHiHTHVyg7GIl7a68uhiePcxY=.2231e100-239f-44ab-8395-12c0f7cae6a2@github.com> On Thu, 11 Nov 2021 15:20:35 GMT, Kevin Rushforth wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed undeterministic test failures > > @aghaisas and I will review it. @kevinrushforth Do you think this could be a candidate for 19? ------------- PR: https://git.openjdk.org/jfx/pull/475 From jvos at openjdk.org Mon Jun 20 08:10:13 2022 From: jvos at openjdk.org (Johan Vos) Date: Mon, 20 Jun 2022 08:10:13 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: On Sat, 7 May 2022 04:17:13 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://urldefense.com/v3/__https://reproducible-builds.org/docs/source-date-epoch/__;!!ACWV5N9M2RV99hQ!JuNdzxPGDD7F5prYh4TQ0x1uwc8Ev14ALbhasMCfUyMXqCVIMfY2X4YeEDwUJAtRzzTSgQYf8MvdfMkG_Esx$ >> [2]: https://urldefense.com/v3/__https://salsa.debian.org/reproducible-builds/strip-nondeterminism__;!!ACWV5N9M2RV99hQ!JuNdzxPGDD7F5prYh4TQ0x1uwc8Ev14ALbhasMCfUyMXqCVIMfY2X4YeEDwUJAtRzzTSgQYf8MvdfCRujcWL$ > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Comment out 'jmod --date' until building on JDK 19 > > Support for the 'jmod --date' option was added to JDK 19 starting > with the 19+2 early-access build, and it was backported to JDK 17 > starting with release 17.0.3. It is not available in JDK 18. > - Merge 'master' into allow-reproducible-builds > - Make minimal changes for new '--date' option > - Add new '--date' option to JMOD task > - Add '--source-date' option to JMOD task > - Get build timestamp in UTC and set ZIP timestamps > > Create the build timestamp as a zoned date and time in UTC instead > of a local date and time. If SOURCE_DATE_EPOCH is defined, set the > last modification time of ZIP and JAR entries to the local date and > time in UTC of the instant defined by SOURCE_DATE_EPOCH. > > Add a comment as a reminder to make JMOD files deterministic when > the following enhancements are complete: > > * Enable deterministic file content ordering for Jar and Jmod > https://bugs.openjdk.java.net/browse/JDK-8276764 > https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/6395__;!!ACWV5N9M2RV99hQ!JuNdzxPGDD7F5prYh4TQ0x1uwc8Ev14ALbhasMCfUyMXqCVIMfY2X4YeEDwUJAtRzzTSgQYf8MvdfJNVzMkI$ > > * Enable jar and jmod to produce deterministic timestamped content > https://bugs.openjdk.java.net/browse/JDK-8276766 > https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/6481__;!!ACWV5N9M2RV99hQ!JuNdzxPGDD7F5prYh4TQ0x1uwc8Ev14ALbhasMCfUyMXqCVIMfY2X4YeEDwUJAtRzzTSgQYf8MvdfJHoBGOK$ > - Merge branch 'master' into allow-reproducible-builds > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - ... and 4 more: https://git.openjdk.org/jfx/compare/d69a498c...3fd4449b I am a bit confused by the goal of this PR. If the goal is to allow for reproducible builds on the exact same system, then I think this looks great. But if we want to have reproducibility amongst ephemeral systems, there is lots of other work to be done. >From a previous comment (`The SBOM is the next step in allowing for reproducible builds in any environment, but it's not a part of this pull request.`) I understand that the goal is not reproducibility in any environment though -- so I won't open the can of worms in this PR. It would be good to have confirmation about this goal though? ------------- PR: https://git.openjdk.org/jfx/pull/446 From jgneff at openjdk.org Mon Jun 20 20:06:06 2022 From: jgneff at openjdk.org (John Neffenger) Date: Mon, 20 Jun 2022 20:06:06 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 08:06:33 GMT, Johan Vos wrote: > But if we want to have reproducibility amongst ephemeral systems, there is lots of other work to be done. On the contrary, it's precisely these well-defined ephemeral systems that make it easy to reproducible a build. The only other work to be done is to share the build log. For example, I build JavaFX in a transient container that installs the latest build of Ubuntu 18.04, the current release of OpenJDK, and the following extra packages: `pkg-config`, `libgtk2.0-dev`, `libxtst-dev`, `libgtk-3-dev`, and `libxxf86vm-dev`. With that information, along with the date, the build script, and the JavaFX release tag, anyone can reproduce the build environment. If we allow for reproducible builds, anyone could reproduce the build and get bit-by-bit identical output. The Launchpad build farm I use just happens to produce a software bill of materials. Yet even without the official SBOM, the build log itself works just as well. Any complete build log from a transient system can serve as a software bill of materials and allows anyone to reproduce the build even years later. If parts of your build are proprietary, you could hire someone to verify your build by reproducing it, in the same way you might hire an accountant to audit your business by verifying its financial records. That verification is the best countermeasure against a supply-chain attack, giving you confidence that the packages you release have not been compromised. > From a previous comment ("The SBOM is the next step ...") I understand that the goal is not reproducibility in any environment though ... That previous comment on the SBOM was because Kevin was testing on his own permanent, non-transient development workstation where it's difficult to match all the system libraries that affect the output of a build. (Even Kevin wasn't quite sure how his system was different from the transient CI system.) The CI build, though, if it's done in a transient VM or container, will be completely described by its build log, so it's straightforward to reproduce. There are benefits for the OpenJFX project to have reproducible builds beyond detecting supply-chain attacks. In fact, I think there are still benefits even if it were only possible on the exact same system. Let me know if you need more convincing. ? ------------- PR: https://git.openjdk.org/jfx/pull/446 From jvos at openjdk.org Mon Jun 20 20:22:10 2022 From: jvos at openjdk.org (Johan Vos) Date: Mon, 20 Jun 2022 20:22:10 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 20:02:38 GMT, John Neffenger wrote: > > But if we want to have reproducibility amongst ephemeral systems, there is lots of other work to be done. > > On the contrary, it's precisely these well-defined ephemeral systems that make it easy to reproducible a build. The only other work to be done is to share the build log. In that case, my understanding of "ephemeral system" was wrong :) > For example, I build JavaFX in a transient container that installs the latest build of Ubuntu 18.04, the current release of OpenJDK, and the following extra packages: `pkg-config`, `libgtk2.0-dev`, `libxtst-dev`, `libgtk-3-dev`, and `libxxf86vm-dev`. With that information, along with the date, the build script, and the JavaFX release tag, anyone can reproduce the build environment. If we allow for reproducible builds, anyone could reproduce the build and get bit-by-bit identical output. The work I'm talking about is that an Ubuntu 18.04 is not suited to build/distribute OpenJFX. Over the past months, we've been working to create a devkit that is capable of building binaries and libraries that work on a wide variety of systems/distributions, e.g. from Ubuntu 16.04 to Fedora 36. Especially with media and webkit, this is not trivial. One of the main issues is the dependencies on libc versions (leading to the typical unresolved @GLIBC_X.Y symbol errors at runtime). It's easy to build JavaFX on a single system and run it on more or less similar systems, but it is harder to support this wide range of OS'es and sysroots. Unless you restrict a number of configurations, there is afaik no stock distribution that allows this. The "lots of work" I'm talking about is the reproducible and automated way to create those devkits so that they support a reasonable number of {build/host/target} triplets. ------------- PR: https://git.openjdk.org/jfx/pull/446 From jgneff at openjdk.org Mon Jun 20 21:59:54 2022 From: jgneff at openjdk.org (John Neffenger) Date: Mon, 20 Jun 2022 21:59:54 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 20:19:01 GMT, Johan Vos wrote: > Unless you restrict a number of configurations, there is afaik no stock distribution that allows this. That's why Red Hat has Flatpak and Ubuntu has Snaps (and they each grudingly support the other's solution). Their approach is to let the JavaFX application include its minimal Java runtime (using `jlink`) along with the complete set of its dependencies. That packaging allows it to run as a self-contained application on any Linux system. I'm not aware of projects trying to solve this at the SDK level. > The "lots of work" I'm talking about is the reproducible and automated way to create those devkits so that they support a reasonable number of {build/host/target} triplets. One main goal of this pull request was to allow Linux distribution to be able to create reproducible builds of JavaFX, and they already have automated ways to create their build environments. If you're looking for a more general way to automate the process of reproducing any build and its environment, there are groups working on that, but I think it's still very early days. See, for example, the section "New SPDX team to incorporate build metadata in Software Bill of Materials" in the [Reproducible Builds in May 2022][1] newsletter. Also see the `.buildspec` rebuild instructions used by the [Reproducible Central][2] project. [1]: https://urldefense.com/v3/__https://reproducible-builds.org/reports/2022-05/__;!!ACWV5N9M2RV99hQ!PzSQevdniZYY4SQeqTsfU31VccS_s_gotFwbwL5zfEI5HqItrayeELKq7yC6fgsMSpcOR0Is9LUTMQqhOV1pHig$ [2]: https://urldefense.com/v3/__https://github.com/jvm-repo-rebuild/reproducible-central__;!!ACWV5N9M2RV99hQ!PzSQevdniZYY4SQeqTsfU31VccS_s_gotFwbwL5zfEI5HqItrayeELKq7yC6fgsMSpcOR0Is9LUTMQqhztYK4k4$ ------------- PR: https://git.openjdk.org/jfx/pull/446 From jvos at openjdk.org Tue Jun 21 07:07:10 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 21 Jun 2022 07:07:10 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v7] In-Reply-To: References: Message-ID: <65cgD77O58JsbUWnphA1Vv1qW16oEm6DsYyKLjG_Su0=.3b3872e8-556d-481c-92ed-27ad099918a4@github.com> On Mon, 20 Jun 2022 21:56:47 GMT, John Neffenger wrote: > That's why Red Hat has Flatpak and Ubuntu has Snaps (and they each grudingly support the other's solution). Their approach is to let the JavaFX application include its minimal Java runtime (using `jlink`) along with the complete set of its dependencies. That packaging allows it to run as a self-contained application on any Linux system. I'm not aware of projects trying to solve this at the SDK level. That is a different issue --I'm not talking about OS-dependencies in external libraries. We have to do it (and are doing it) at the SDK level, since the media libs we create (hence not the ones we depend on) can not be created on a stock Ubuntu 18, for instance, and subsequently being used on old RedHat systems -- not because of symbols in dependent libraries, but because of version requirements in the symbols provided by libc. Actually, Ubuntu 18 doesn't even come with a gcc-11 based compiler, which is required for #761 . Most recent versions of linux distributions do contain gcc-11 based compilers and matching sysroots, but those will introduce symbols in our own libs that are version-incompatible with runtimes provided by old linux distributions. That is the main reason we started the work on the devkit, which compiles a gcc-11 compiler that compiles code that can run on this wide range of distributions. Hence, if we want fully reproducible builds (which I want as well), we need a reproducible way to build the compiler and sysroot. The script to build the devkit is at https://urldefense.com/v3/__https://github.com/openjdk/jdk/tree/master/make/devkit__;!!ACWV5N9M2RV99hQ!Ju_gdUdp947n6T1MJ-5EGJpGE5_l0-H1cT7QA3-hXPtOY8b5hYr_mHO830NgFWVY63-zwNfhClWZrl9dtjIe$ but we need additional changes for OpenJFX, as that is even more complex due to more dependencies and also because we do build the media stubs, which are built from sources that have changed location/name between different versions. The buildscript for the devkit we build is being developed in https://urldefense.com/v3/__https://github.com/gluonhq/devtoolskit__;!!ACWV5N9M2RV99hQ!Ju_gdUdp947n6T1MJ-5EGJpGE5_l0-H1cT7QA3-hXPtOY8b5hYr_mHO830NgFWVY63-zwNfhClWZrrpP0kUM$ and as you can see from the latest commit, we're not there yet since we link a few header files from the host OS into the devkit. Don't get me wrong, I totally applaud your work, and I agree reproducible builds are very valuable. My point is that there is more work to be done before we can really create reproducible builds that can be verified. Different compilers will yield different images of eg. libjfxmedia.so and there is no stock-compiler that can do the job. ------------- PR: https://git.openjdk.org/jfx/pull/446 From mstrauss at openjdk.org Tue Jun 21 23:35:01 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 21 Jun 2022 23:35:01 GMT Subject: RFR: 8218826: TableRowSkinBase: horizontal layout broken if row has padding In-Reply-To: References: Message-ID: On Tue, 24 May 2022 21:25:23 GMT, Marius Hanl wrote: > This PR fixes a problem, where the layout is broken when a `(Tree)TableRow` has padding. > As also mentioned in the ticket, the `layoutChildren` method in `TableRowSkinBase` is implemented wrong. > > The `layoutChildren` method is responsible for layouting all the `(Tree)TableCells`. > When the row has padding, it is subtracted on every `(Tree)TableCell` - which is wrong. > > Instead the `x` and `y` from `layoutChildren` should be used. (E.g. if `x` is 10 (=padding left+right = 10), then only the first cell should start at 10 and the other cells follow as usual) > Also the `compute...` methods needs to add the padding as well. > > **Example:** > _Row padding left right 0:_ > [Cell1][Cell2][Cell3] > _Row padding left right 10:_ > [ 10 ][Cell1][Cell2][Cell3][ 10 ] (`compute...` method also needs to account the padding) > _Same for top bottom._ > > When a `fixedCellSize` is set, the padding is currently ignored (also after this PR). > Therefore, `y` in the `layoutChildren` method is set to 0 for `fixedCellSize`. > > This may can be discussed in the mailing list (Could be a follow up). To support padding also when a `fixedCellSize` is set, the `compute...` methods needs to also add the padding when a `fixedCellSize` is set (in the `if` clauses) and the `VirtualFlow` needs to add the padding to every row instead of using the `fixedCellSize` directly (probably at the cost of performance). modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 38: > 36: import javafx.scene.control.TreeTableView; > 37: import javafx.scene.control.cell.TreeItemPropertyValueFactory; > 38: import org.junit.After; Since this is a new file, I suggest using the JUnit5 API. ------------- PR: https://git.openjdk.org/jfx/pull/800 From mstrauss at openjdk.org Wed Jun 22 04:58:56 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 22 Jun 2022 04:58:56 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v4] In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 19:04:56 GMT, Florian Kirmaier wrote: >> Making the initial listener of the ListProperty weak fixes the problem. >> The same is fixed for Set and Map. >> Due to a smart implementation, this is done without any performance drawback. >> (The trick is to have an object, which is both the WeakReference and the Changelistener) >> By implying the same trick to the InvalidationListener, this should even improve the performance of the collection properties. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8277848 > Added the 3 requests whitespaces Fundamentally, the problem does not arise from bindings, but from the fact that `ListPropertyBase` adds a `ListChangeListener` to its wrapped `ObservableList`. Since the added `ListChangeListener` is a capturing lambda, the `ListPropertyBase` is now tied to the lifetime of the wrapped `ObservableList`. This failing test illustrates the problem: JMemoryBuddy.memoryTest(checker -> { ObservableList list = FXCollections.observableArrayList(); ListProperty listProperty = new SimpleListProperty<>(list); checker.setAsReferenced(list); checker.assertCollectable(listProperty); // --> AssertionError: listProperty not collected }); This behavior may or may not be a bug. I'm inclined to think that it is, because I would be astonished to learn that an object contained in a `Property` would hold a strong reference to the property instance itself. ------------- PR: https://git.openjdk.org/jfx/pull/689 From duke at openjdk.org Wed Jun 22 09:38:05 2022 From: duke at openjdk.org (Christian Heilmann) Date: Wed, 22 Jun 2022 09:38:05 GMT Subject: RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v7] In-Reply-To: References: <3pxxCNYM8bV8snXczMxqk-tHu-0zaMHlPrKPkyNVY5A=.1b341450-e4e6-4c1e-b8ed-23c3ef2b91f0@github.com> Message-ID: On Mon, 30 May 2022 08:10:36 GMT, Johan Vos wrote: >> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method. >> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Precalculate size of cells that are likely going to be used in rendering. > This avoid resizing cells after their position has been laid out, leading > to misalignments. > Relaxed some tests that check on the number of invocations on updateItem. > We heavily use the accumcell for calculating sizes, and that cell is released > every time, leading to a call to updateItem as well (but this call should > not do any CPU intensive work) Hi Johan, thanks for the update of the PR. From the "scrollTo" perspective, everything seems to work now. Big thanks. We coming close to the final solution We found now one issue with scrolling down where it jumps to wrong position. After a scrollTo method call, the scrolling behaves very weird. It then goes up, when scrolling down. It feels like, after the first scrolling it jump up have a cell - which is half the screen, if the cells are big. Even after resizing and relayouting, the positions in our applications seems stable and reasonable. After a small scrolling, they tend to jump. Maybe there is a minor fix missing? I attached you a video showing you the bug in the scroll behavior: list-view-scrolling.m4v look at #18 when we scroll down it jumps up to #17. With this you maybe able to find the bug. Hope you find the last remaining glitches. Thanks https://urldefense.com/v3/__https://user-images.githubusercontent.com/24911444/174996092-f8fb840d-195c-483b-9fbe-06316ad0d06b.mp4__;!!ACWV5N9M2RV99hQ!JjYnsRasZbvvvvilVgdNkBtfDDfFKslRf4n9_JlqO57nDY5weq50PqMldD93wwfp5djlCLNcV68ew2tB5Gqj$ ------------- PR: https://git.openjdk.org/jfx/pull/712 From fkirmaier at openjdk.org Wed Jun 22 09:48:14 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 22 Jun 2022 09:48:14 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v4] In-Reply-To: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: > Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. > ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 > run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge remote-tracking branch 'origjfx/master' into JDK-8256397 # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java - JDK_8256397 Added a small test-factory, to test more cases - 8256397 Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. ------------- Changes: https://git.openjdk.org/jfx/pull/353/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=353&range=03 Stats: 29 lines in 2 files changed: 28 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/353.diff Fetch: git fetch https://git.openjdk.org/jfx pull/353/head:pull/353 PR: https://git.openjdk.org/jfx/pull/353 From fkirmaier at openjdk.org Wed Jun 22 09:48:16 2022 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Wed, 22 Jun 2022 09:48:16 GMT Subject: RFR: 8256397: MultipleSelectionModel throws IndexOutOfBoundException [v3] In-Reply-To: References: <6SNcvFoJOSCvURo1ksKVQ8hRIv3Lkh7AvwkbtQo2Jrs=.3fcf083a-4cd6-4e98-b050-da800c5e3761@github.com> Message-ID: On Mon, 10 Jan 2022 12:29:04 GMT, Florian Kirmaier wrote: >> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added a unit-test for it. >> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397 >> run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests "*MultipleSelectionModelImplTest*"` > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK_8256397 > Added a small test-factory, to test more cases I've just merged it with master I hope someone will find time to review this. ------------- PR: https://git.openjdk.org/jfx/pull/353 From jhendrikx at openjdk.org Wed Jun 22 10:26:56 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 22 Jun 2022 10:26:56 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v4] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 04:55:39 GMT, Michael Strau? wrote: > Fundamentally, the problem does not arise from bindings, but from the fact that `ListPropertyBase` adds a `ListChangeListener` to its wrapped `ObservableList`. Yes, I would agree. The cause is the eager setup of listeners on other properties, resulting in the target being tied to the lifecycle of the observed property. The listener itself serves no purpose until the `ListProperty` itself is observed in some fashion. A `ListProperty` could be processing thousands of "changes" to update its internal state, but if it is not observed or called directly, nobody cares. The end result is that the property cannot be garbage collected and is processing every change event, even though everything has lost interest in it. This is basically another case where it is better to only listen (or bind) to other targets when absolutely necessary (when the source itself is being observed) and to remove the listener (or binding) when no longer observed, basically lazy versus eager observation. Lazy observation would completely remove the need for using weak references, simplifying the logic and making the whole system much easier to reason about. ------------- PR: https://git.openjdk.org/jfx/pull/689 From thiago.sayao at gmail.com Wed Jun 22 12:23:21 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 22 Jun 2022 09:23:21 -0300 Subject: Asking for inclusion on 17.0.4 (if the rules permits) In-Reply-To: References: Message-ID: Hi, If possible, it would be nice to see those on 17.0.4: [REDO] Wrong stage gets focused after modal stage creation https://bugs.openjdk.org/browse/JDK-8271054 Modal behavior returns to wrong stage https://bugs.openjdk.org/browse/JDK-8284654 We have an application that runs on Linux and without those two fixes we have random windows popping up or going behind when it should not. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Wed Jun 22 12:50:11 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 22 Jun 2022 12:50:11 GMT Subject: RFR: 8277848 Binding and Unbinding to List leads to memory leak [v4] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 10:23:06 GMT, John Hendrikx wrote: > This is basically another case where it is better to only listen (or bind) to other targets when absolutely necessary (when the source itself is being observed) and to remove the listener (or binding) when no longer observed, basically lazy versus eager observation. Lazy observation would completely remove the need for using weak references, simplifying the logic and making the whole system much easier to reason about. While I agree that lazy observation would be a good improvement, it just shifts the problem one indirection away. You could still have an entire object graph that is needlessly kept alive by the property wrapper, which is a problem. ------------- PR: https://git.openjdk.org/jfx/pull/689 From johan.vos at gluonhq.com Wed Jun 22 13:10:23 2022 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 22 Jun 2022 15:10:23 +0200 Subject: Asking for inclusion on 17.0.4 (if the rules permits) In-Reply-To: References: Message-ID: It makes sense indeed to backport those issues. - Johan On Wed, Jun 22, 2022 at 2:25 PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > > Hi, > > If possible, it would be nice to see those on 17.0.4: > > [REDO] Wrong stage gets focused after modal stage creation > https://bugs.openjdk.org/browse/JDK-8271054 > > Modal behavior returns to wrong stage > https://bugs.openjdk.org/browse/JDK-8284654 > > We have an application that runs on Linux and without those two fixes we > have random windows popping up or going behind when it should not. > > -- Thiago. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Wed Jun 22 18:11:13 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 22 Jun 2022 18:11:13 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v3] In-Reply-To: References: Message-ID: On Sat, 19 Mar 2022 18:19:01 GMT, Marius Hanl wrote: >> This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. >> >> I also added tests which will succeed before and after to verify that nothing got broken by this change. >> Also I made a benchmark test. Results: >> >> | Benchmark | Mode| Cnt | Score | Error | Units >> | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | >> | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s >> | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s >> >> Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. >> ListBenchmark OLD (avg): 21-23ms >> ListBenchmark NEW (avg): 2 ms >> >>
Benchmark code >> >> >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import org.openjdk.jmh.annotations.Benchmark; >> import org.openjdk.jmh.annotations.Scope; >> import org.openjdk.jmh.annotations.Setup; >> import org.openjdk.jmh.annotations.State; >> import org.openjdk.jmh.annotations.TearDown; >> >> import java.util.ArrayList; >> import java.util.List; >> >> @State(Scope.Benchmark) >> public class ListBenchmark { >> >> List strings; >> >> @Setup >> public void setup() { >> strings = new ArrayList<>(); >> for(int i = 0; i< 100000;i++) { >> strings.add("abc: " + i); >> } >> } >> >> @TearDown >> public void tearDown() { >> strings = null; >> } >> >> @Benchmark >> public ObservableList init() { >> return FXCollections.observableArrayList(strings); >> } >> } >> >> >>
> > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8283346: Improved test name modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 351: > 349: public static ObservableList observableArrayList(E... items) { > 350: ObservableList list = observableList(new ArrayList<>(items.length)); > 351: list.addAll(items); You can also skip the generation of a list change event: List list = new ArrayList<>(items.length); list.addAll(items); return observableList(list); ------------- PR: https://git.openjdk.org/jfx/pull/758 From michaelstrau2 at gmail.com Thu Jun 23 00:00:17 2022 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 23 Jun 2022 02:00:17 +0200 Subject: Logical scene graph API Message-ID: A JavaFX scene graph can be traversed with the `Node.getChildrenUnmodifiable()` and `Node.getParent()` methods. However, this doesn't work as intuitively as one might expect: Control skins can modify the scene graph by introducing additional nodes, which makes it hard to reason about the structure of the scene graph. Additionally, users might expect to find objects like `MenuItem` or `Tab` in the scene graph, but since these are not nodes, they are nowhere to be found. Here are examples of the confusion that can arise from these issues: http://www.kware.net/?p=8 https://stackoverflow.com/questions/24126226/javafx-walk-widget-tree The core problem is that the scene graph is not a representation of the logical structure of the JavaFX document, i.e. the structure of controls and nodes that users will create in code or in an FXML file. There are many legitimate reasons for wanting to traverse the logical structure of a JavaFX document, and I think we can support this by introducing the notion of a "logical graph" or "document graph". The logical graph can be traversed by two new methods: `Node.getLogicalChildren()` and `Node.getLogicalParent()`. These methods would have to be implemented by controls to return their logical children: for example, `Labeled` would return its `graphic` node, since that is its only logical child. Before delving into an API discussion, I'd like to collect some feedback on the feature proposal as a whole. Do you think that a "logical graph" concept should be added to JavaFX? From kcr at openjdk.org Fri Jun 24 13:22:33 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 24 Jun 2022 13:22:33 GMT Subject: RFR: 8286774: Replace openjdk.java.net with openjdk.org Message-ID: Simple replacement of `openjdk.java.net` with `openjdk.org` everywhere (except `ASSEMBLY_EXCEPTION`, which is a legal file copied from the mainline `jdk` repo). While doing this I also fixed a few places that were using `http` rather than `https`. ------------- Commit messages: - 8286774: Replace openjdk.java.net with openjdk.org Changes: https://git.openjdk.org/jfx/pull/803/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=803&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286774 Stats: 652 lines in 35 files changed: 0 ins; 0 del; 652 mod Patch: https://git.openjdk.org/jfx/pull/803.diff Fetch: git fetch https://git.openjdk.org/jfx pull/803/head:pull/803 PR: https://git.openjdk.org/jfx/pull/803 From kcr at openjdk.org Sat Jun 25 13:34:07 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 25 Jun 2022 13:34:07 GMT Subject: RFR: 8283402: Update to gcc 11.2 on Linux [v3] In-Reply-To: References: Message-ID: > This patch updates the compiler to gcc 11.2 on Linux, in order to match JDK 17 -- see [JDK-8283057](https://bugs.openjdk.java.net/browse/JDK-8283057). > > I ran a full build and test, including media and WebKit. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8283402-gcc-11.2 - Merge branch 'master' into 8283402-gcc-11.2 - 8283402: Update to gcc 11.2 on Linux ------------- Changes: https://git.openjdk.org/jfx/pull/761/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=761&range=02 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/761.diff Fetch: git fetch https://git.openjdk.org/jfx pull/761/head:pull/761 PR: https://git.openjdk.org/jfx/pull/761 From kcr at openjdk.org Sat Jun 25 17:37:04 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 25 Jun 2022 17:37:04 GMT Subject: RFR: 8285253: update boot jdk to 18.0.1 In-Reply-To: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> References: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> Message-ID: <9uJOlAQpwWuf63p_YsrxnSSQNYZtWr3fvZJJi0k9naY=.ebb87575-a4db-46c4-8c38-1d2c5fd66452@github.com> On Tue, 10 May 2022 09:50:08 GMT, Ambarish Rapte wrote: > Update Boot JDK to 18.0.1 > Creating PR to initiate GitHub actions build. > Tested locally on Mac OS Catalina. Look good to me. The failing tests you are seeing pass for me. They might be caused by a color profile problem on your system. See the comment I added to [JDK-8288652](https://bugs.openjdk.org/browse/JDK-8288652). I noticed that the title of this PR doesn't exactly match the title of the JBS bug -- this PR title is all lower case. I suspect that Skara will flag this, although it would be an interesting test to leave it alone until both approvals are done to see if it will. Please change it before integrating it. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.org/jfx/pull/792 From jvos at openjdk.org Sat Jun 25 18:22:41 2022 From: jvos at openjdk.org (Johan Vos) Date: Sat, 25 Jun 2022 18:22:41 GMT Subject: RFR: 8285253: update boot jdk to 18.0.1 In-Reply-To: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> References: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> Message-ID: On Tue, 10 May 2022 09:50:08 GMT, Ambarish Rapte wrote: > Update Boot JDK to 18.0.1 > Creating PR to initiate GitHub actions build. > Tested locally on Mac OS Catalina. all green for me. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.org/jfx/pull/792 From mstrauss at openjdk.org Sun Jun 26 19:33:56 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 26 Jun 2022 19:33:56 GMT Subject: RFR: 8286774: Replace openjdk.java.net with openjdk.org In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 13:16:40 GMT, Kevin Rushforth wrote: > Simple replacement of `openjdk.java.net` with `openjdk.org` everywhere (except `ASSEMBLY_EXCEPTION`, which is a legal file copied from the mainline `jdk` repo). While doing this I also fixed a few places that were using `http` rather than `https`. Looks good to me. ------------- Marked as reviewed by mstrauss (Author). PR: https://git.openjdk.org/jfx/pull/803 From jvos at openjdk.org Sun Jun 26 19:43:56 2022 From: jvos at openjdk.org (Johan Vos) Date: Sun, 26 Jun 2022 19:43:56 GMT Subject: RFR: 8286774: Replace openjdk.java.net with openjdk.org In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 13:16:40 GMT, Kevin Rushforth wrote: > Simple replacement of `openjdk.java.net` with `openjdk.org` everywhere (except `ASSEMBLY_EXCEPTION`, which is a legal file copied from the mainline `jdk` repo). While doing this I also fixed a few places that were using `http` rather than `https`. I tested most of the links, and they seem to work. Some are a bit outdated, but not incorrect -- and it's not a goal of this PR to deal with that. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.org/jfx/pull/803 From jvos at openjdk.org Mon Jun 27 08:50:48 2022 From: jvos at openjdk.org (Johan Vos) Date: Mon, 27 Jun 2022 08:50:48 GMT Subject: [jfx17u] RFR: 8284654: Modal behavior returns to wrong stage Message-ID: clean backport of 8284654: Modal behavior returns to wrong stage Reviewed-by: arapte, kcr ------------- Commit messages: - 8284654: Modal behavior returns to wrong stage Changes: https://git.openjdk.org/jfx17u/pull/64/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=64&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8284654 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/64.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/64/head:pull/64 PR: https://git.openjdk.org/jfx17u/pull/64 From jvos at openjdk.org Mon Jun 27 08:50:57 2022 From: jvos at openjdk.org (Johan Vos) Date: Mon, 27 Jun 2022 08:50:57 GMT Subject: [jfx17u] RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation Message-ID: <3ZfXyEgmHW-4ty6ZxlN85ZlE2R-9biWytxm77VZhYhU=.b26b46e4-61ca-459e-88ed-5eb9770249bb@github.com> Clean backport of 8271054: [REDO] Wrong stage gets focused after modal stage creation Reviewed-by: kcr, arapte ------------- Commit messages: - 8271054: [REDO] Wrong stage gets focused after modal stage creation Changes: https://git.openjdk.org/jfx17u/pull/63/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=63&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8271054 Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx17u/pull/63.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/63/head:pull/63 PR: https://git.openjdk.org/jfx17u/pull/63 From kcr at openjdk.org Mon Jun 27 13:20:56 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 27 Jun 2022 13:20:56 GMT Subject: Integrated: 8286774: Replace openjdk.java.net with openjdk.org In-Reply-To: References: Message-ID: <3PkbFVFau90Sp2-cqzxmK7dCRxsYYxJp8dLcWXjeKFw=.ade8e819-fb79-406f-a415-cdbca39065af@github.com> On Fri, 24 Jun 2022 13:16:40 GMT, Kevin Rushforth wrote: > Simple replacement of `openjdk.java.net` with `openjdk.org` everywhere (except `ASSEMBLY_EXCEPTION`, which is a legal file copied from the mainline `jdk` repo). While doing this I also fixed a few places that were using `http` rather than `https`. This pull request has now been integrated. Changeset: c7592865 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/c75928654581920867b5d6c655fb7917d43d1093 Stats: 652 lines in 35 files changed: 0 ins; 0 del; 652 mod 8286774: Replace openjdk.java.net with openjdk.org Reviewed-by: mstrauss, jvos ------------- PR: https://git.openjdk.org/jfx/pull/803 From arapte at openjdk.org Mon Jun 27 16:28:51 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 27 Jun 2022 16:28:51 GMT Subject: RFR: 8285253: Update boot JDK to 18.0.1 In-Reply-To: <9uJOlAQpwWuf63p_YsrxnSSQNYZtWr3fvZJJi0k9naY=.ebb87575-a4db-46c4-8c38-1d2c5fd66452@github.com> References: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> <9uJOlAQpwWuf63p_YsrxnSSQNYZtWr3fvZJJi0k9naY=.ebb87575-a4db-46c4-8c38-1d2c5fd66452@github.com> Message-ID: On Sat, 25 Jun 2022 17:30:29 GMT, Kevin Rushforth wrote: > Look good to me. The failing tests you are seeing pass for me. They might be caused by a color profile problem on your system. See the comment I added to [JDK-8288652](https://bugs.openjdk.org/browse/JDK-8288652). Yes, the tests pass when changed color profile. ------------- PR: https://git.openjdk.org/jfx/pull/792 From arapte at openjdk.org Mon Jun 27 16:31:52 2022 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 27 Jun 2022 16:31:52 GMT Subject: Integrated: 8285253: Update boot JDK to 18.0.1 In-Reply-To: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> References: <32u64MeLsyhiTLVmFvwmG9WTF41yAnLYA7xVzytoRqo=.14632448-8a40-4758-9d8a-a83dd305de4b@github.com> Message-ID: <5XHzG9jhgjOjyg-S4boT2EYk4EZelwcMEKyTco3dmVU=.98286db3-0b7a-43fd-9df1-a4b9e3531525@github.com> On Tue, 10 May 2022 09:50:08 GMT, Ambarish Rapte wrote: > Update Boot JDK to 18.0.1 > Creating PR to initiate GitHub actions build. > Tested locally on Mac OS Catalina. This pull request has now been integrated. Changeset: 1f625708 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/1f6257086422cdc3b0cb01de3ef9bbc3137cfa30 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8285253: Update boot JDK to 18.0.1 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.org/jfx/pull/792 From jvos at openjdk.org Tue Jun 28 06:43:53 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 28 Jun 2022 06:43:53 GMT Subject: [jfx17u] Integrated: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: <3ZfXyEgmHW-4ty6ZxlN85ZlE2R-9biWytxm77VZhYhU=.b26b46e4-61ca-459e-88ed-5eb9770249bb@github.com> References: <3ZfXyEgmHW-4ty6ZxlN85ZlE2R-9biWytxm77VZhYhU=.b26b46e4-61ca-459e-88ed-5eb9770249bb@github.com> Message-ID: On Mon, 27 Jun 2022 08:24:02 GMT, Johan Vos wrote: > Clean backport of 8271054: [REDO] Wrong stage gets focused after modal stage creation > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 9156991d Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/9156991d4a86a2efd7a4a7ad4fc3035462c0b2cd Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod 8271054: [REDO] Wrong stage gets focused after modal stage creation Backport-of: c6069d6845df4b90cca226e2b3dff49e3b48d8ac ------------- PR: https://git.openjdk.org/jfx17u/pull/63 From jvos at openjdk.org Tue Jun 28 06:44:51 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 28 Jun 2022 06:44:51 GMT Subject: [jfx17u] Integrated: 8284654: Modal behavior returns to wrong stage In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 08:27:46 GMT, Johan Vos wrote: > clean backport of 8284654: Modal behavior returns to wrong stage > Reviewed-by: arapte, kcr This pull request has now been integrated. Changeset: bb13db27 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/bb13db27960195abe1003b04e4dd6afab1ddf5cf Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8284654: Modal behavior returns to wrong stage Backport-of: 864792d84811b64815357722be0378397d212408 ------------- PR: https://git.openjdk.org/jfx17u/pull/64 From jvos at openjdk.org Tue Jun 28 07:16:19 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 28 Jun 2022 07:16:19 GMT Subject: [jfx17u] RFR: 8282093: LineChart path incorrect when outside lower bound Message-ID: Clean backport of 8282093: LineChart path incorrect when outside lower bound Reviewed-by: aghaisas ------------- Commit messages: - 8282093: LineChart path incorrect when outside lower bound Changes: https://git.openjdk.org/jfx17u/pull/65/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=65&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282093 Stats: 523 lines in 4 files changed: 500 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jfx17u/pull/65.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/65/head:pull/65 PR: https://git.openjdk.org/jfx17u/pull/65 From jvos at openjdk.org Tue Jun 28 07:19:24 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 28 Jun 2022 07:19:24 GMT Subject: [jfx17u] RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected Message-ID: clean backport of 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected Reviewed-by: mstrauss, aghaisas ------------- Commit messages: - 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected Changes: https://git.openjdk.org/jfx17u/pull/66/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=66&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8273336 Stats: 116 lines in 5 files changed: 111 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx17u/pull/66.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/66/head:pull/66 PR: https://git.openjdk.org/jfx17u/pull/66 From kcr at openjdk.org Tue Jun 28 12:37:55 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jun 2022 12:37:55 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: References: Message-ID: On Fri, 13 May 2022 05:34:08 GMT, Tomator wrote: > When I used BlueJ, I found a problem with Chinese display. /javafx.graphics/com/sun/javafx/font/CompositeGlyphMapper.java#getGlyphCode may return a negative number when no font library is specified in Linux,and this could cause java.lang.ArrayIndexOutOfBoundsException error.So javafx.graphics/com/sun/prism/impl/GlyphCache.java#getCachedGlyph shou check the glyphCode. > The crash demo like this: > `import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Menu; > import javafx.scene.control.MenuBar; > import javafx.scene.control.MenuItem; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class MenuExample extends Application { > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) throws Exception { > BorderPane root = new BorderPane(); > Scene scene = new Scene(root,200,300); > MenuBar menubar = new MenuBar(); > Menu FileMenu = new Menu("??"); > MenuItem filemenu1=new MenuItem("??"); > MenuItem filemenu2=new MenuItem("Save"); > MenuItem filemenu3=new MenuItem("Exit"); > Menu EditMenu=new Menu("Edit"); > MenuItem EditMenu1=new MenuItem("Cut"); > MenuItem EditMenu2=new MenuItem("Copy"); > MenuItem EditMenu3=new MenuItem("Paste"); > EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); > root.setTop(menubar); > FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); > menubar.getMenus().addAll(FileMenu,EditMenu); > primaryStage.setScene(scene); > primaryStage.setTitle("TEST"); > primaryStage.show(); > > } > } ` > > the error: > `java.lang.ArrayIndexOutOfBoundsException: Index -25 out of bounds for length 32 > at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) > at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) > at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) > at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) > at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) > at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) > at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) > at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) > ` I left a question and style comment inline. Can you provide an automated test case, or if that's not possible, a manual test case? modules/javafx.graphics/src/main/java/com/sun/prism/impl/GlyphCache.java line 242: > 240: > 241: private GlyphData getCachedGlyph(int glyphCode, int subPixel) { > 242: if (glyphCode < 0) {return null;} Have you ensured that all callers are prepared to deal with a `null` return value? Minor: Please format this according to code conventions: if (glyphCode < 0) { return null; } ------------- PR: https://git.openjdk.org/jfx/pull/795 From kcr at openjdk.org Tue Jun 28 12:39:59 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jun 2022 12:39:59 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v9] In-Reply-To: <9Z3b1Vw8BdqMw_V4fJRZVUtDMgqZyXU33CHkNjfrG5U=.9f8f9c70-a781-4f58-86c5-4ec8ad1dedf0@github.com> References: <9Z3b1Vw8BdqMw_V4fJRZVUtDMgqZyXU33CHkNjfrG5U=.9f8f9c70-a781-4f58-86c5-4ec8ad1dedf0@github.com> Message-ID: On Thu, 19 May 2022 04:03:46 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > 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 23 additional commits since the last revision: > > - Merge branch 'master' into feature/focusvisible > - Updated since tag > - Update copyright headers > - Merge branch 'master' into feature/focusvisible > - fixed undeterministic test failures > - minor wording change > - restart github actions > - Merge branch 'master' of https://github.com/mstr2/jfx into feature/focusvisible > - changes per discussion, added test > - wording > - ... and 13 more: https://git.openjdk.org/jfx/compare/cada6655...0c7d6e72 I'd like to try to get this in for 19, although time is short. ------------- PR: https://git.openjdk.org/jfx/pull/475 From duke at openjdk.org Tue Jun 28 12:44:58 2022 From: duke at openjdk.org (Tomator) Date: Tue, 28 Jun 2022 12:44:58 GMT Subject: RFR: 8286867: Update #getGlyphCode return a negative number In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 12:33:52 GMT, Kevin Rushforth wrote: >> When I used BlueJ, I found a problem with Chinese display. /javafx.graphics/com/sun/javafx/font/CompositeGlyphMapper.java#getGlyphCode may return a negative number when no font library is specified in Linux,and this could cause java.lang.ArrayIndexOutOfBoundsException error.So javafx.graphics/com/sun/prism/impl/GlyphCache.java#getCachedGlyph shou check the glyphCode. >> The crash demo like this: >> `import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Menu; >> import javafx.scene.control.MenuBar; >> import javafx.scene.control.MenuItem; >> import javafx.scene.layout.BorderPane; >> import javafx.stage.Stage; >> >> public class MenuExample extends Application { >> public static void main(String[] args) { >> launch(args); >> } >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> BorderPane root = new BorderPane(); >> Scene scene = new Scene(root,200,300); >> MenuBar menubar = new MenuBar(); >> Menu FileMenu = new Menu("??"); >> MenuItem filemenu1=new MenuItem("??"); >> MenuItem filemenu2=new MenuItem("Save"); >> MenuItem filemenu3=new MenuItem("Exit"); >> Menu EditMenu=new Menu("Edit"); >> MenuItem EditMenu1=new MenuItem("Cut"); >> MenuItem EditMenu2=new MenuItem("Copy"); >> MenuItem EditMenu3=new MenuItem("Paste"); >> EditMenu.getItems().addAll(EditMenu1,EditMenu2,EditMenu3); >> root.setTop(menubar); >> FileMenu.getItems().addAll(filemenu1,filemenu2,filemenu3); >> menubar.getMenus().addAll(FileMenu,EditMenu); >> primaryStage.setScene(scene); >> primaryStage.setTitle("TEST"); >> primaryStage.show(); >> >> } >> } ` >> >> the error: >> `java.lang.ArrayIndexOutOfBoundsException: Index -25 out of bounds for length 32 >> at com.sun.prism.impl.GlyphCache.getCachedGlyph(GlyphCache.java:332) >> at com.sun.prism.impl.GlyphCache.render(GlyphCache.java:148) >> at com.sun.prism.impl.ps.BaseShaderGraphics.drawString(BaseShaderGraphics.java:2101) >> at com.sun.javafx.sg.prism.NGText.renderText(NGText.java:312) >> at com.sun.javafx.sg.prism.NGText.renderContent2D(NGText.java:270) >> at com.sun.javafx.sg.prism.NGShape.renderContent(NGShape.java:261) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) >> at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:578) >> at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) >> at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) >> at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:479) >> at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:328) >> at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) >> ` > > modules/javafx.graphics/src/main/java/com/sun/prism/impl/GlyphCache.java line 242: > >> 240: >> 241: private GlyphData getCachedGlyph(int glyphCode, int subPixel) { >> 242: if (glyphCode < 0) {return null;} > > Have you ensured that all callers are prepared to deal with a `null` return value? > > Minor: Please format this according to code conventions: > > > if (glyphCode < 0) { > return null; > } `if (!packer.add(rect)) { if (PULSE_LOGGING_ENABLED) { PulseLogger.incrementCounter("Font Glyph Cache Cleared"); } // If add fails,clear up the cache. Try add again. clearAll(); if (!packer.add(rect)) { if (PrismSettings.verbose) { System.out.println(rect + " won't fit in GlyphCache"); } return null; } } ` The line 298 also return null,so return nul is ok ------------- PR: https://git.openjdk.org/jfx/pull/795 From mhanl at openjdk.org Tue Jun 28 15:19:50 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 28 Jun 2022 15:19:50 GMT Subject: RFR: 8218826: TableRowSkinBase: horizontal layout broken if row has padding [v2] In-Reply-To: References: Message-ID: > This PR fixes a problem, where the layout is broken when a `(Tree)TableRow` has padding. > As also mentioned in the ticket, the `layoutChildren` method in `TableRowSkinBase` is implemented wrong. > > The `layoutChildren` method is responsible for layouting all the `(Tree)TableCells`. > When the row has padding, it is subtracted on every `(Tree)TableCell` - which is wrong. > > Instead the `x` and `y` from `layoutChildren` should be used. (E.g. if `x` is 10 (=padding left+right = 10), then only the first cell should start at 10 and the other cells follow as usual) > Also the `compute...` methods needs to add the padding as well. > > **Example:** > _Row padding left right 0:_ > [Cell1][Cell2][Cell3] > _Row padding left right 10:_ > [ 10 ][Cell1][Cell2][Cell3][ 10 ] (`compute...` method also needs to account the padding) > _Same for top bottom._ > > When a `fixedCellSize` is set, the padding is currently ignored (also after this PR). > Therefore, `y` in the `layoutChildren` method is set to 0 for `fixedCellSize`. > > This may can be discussed in the mailing list (Could be a follow up). To support padding also when a `fixedCellSize` is set, the `compute...` methods needs to also add the padding when a `fixedCellSize` is set (in the `if` clauses) and the `VirtualFlow` needs to add the padding to every row instead of using the `fixedCellSize` directly (probably at the cost of performance). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8218826: changed test file to use junit5 api ------------- Changes: - all: https://git.openjdk.org/jfx/pull/800/files - new: https://git.openjdk.org/jfx/pull/800/files/cb931627..30082b8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=800&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=800&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/800.diff Fetch: git fetch https://git.openjdk.org/jfx pull/800/head:pull/800 PR: https://git.openjdk.org/jfx/pull/800 From mhanl at openjdk.org Tue Jun 28 15:19:53 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 28 Jun 2022 15:19:53 GMT Subject: RFR: 8218826: TableRowSkinBase: horizontal layout broken if row has padding [v2] In-Reply-To: References: Message-ID: <1rbUnd0r1xQ9uosUQm1oUiSpyPWqgomOXI8wExqS1VQ=.f581f729-4564-49a3-b310-7fbb963bd177@github.com> On Tue, 21 Jun 2022 23:32:02 GMT, Michael Strau? wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8218826: changed test file to use junit5 api > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java line 38: > >> 36: import javafx.scene.control.TreeTableView; >> 37: import javafx.scene.control.cell.TreeItemPropertyValueFactory; >> 38: import org.junit.After; > > Since this is a new file, I suggest using the JUnit5 API. done ------------- PR: https://git.openjdk.org/jfx/pull/800 From mhanl at openjdk.org Tue Jun 28 15:29:41 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 28 Jun 2022 15:29:41 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v4] In-Reply-To: References: Message-ID: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> > This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. > > I also added tests which will succeed before and after to verify that nothing got broken by this change. > Also I made a benchmark test. Results: > > | Benchmark | Mode| Cnt | Score | Error | Units > | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | > | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s > | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s > > Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. > ListBenchmark OLD (avg): 21-23ms > ListBenchmark NEW (avg): 2 ms > >
Benchmark code > > > import javafx.collections.FXCollections; > import javafx.collections.ObservableList; > import org.openjdk.jmh.annotations.Benchmark; > import org.openjdk.jmh.annotations.Scope; > import org.openjdk.jmh.annotations.Setup; > import org.openjdk.jmh.annotations.State; > import org.openjdk.jmh.annotations.TearDown; > > import java.util.ArrayList; > import java.util.List; > > @State(Scope.Benchmark) > public class ListBenchmark { > > List strings; > > @Setup > public void setup() { > strings = new ArrayList<>(); > for(int i = 0; i< 100000;i++) { > strings.add("abc: " + i); > } > } > > @TearDown > public void tearDown() { > strings = null; > } > > @Benchmark > public ObservableList init() { > return FXCollections.observableArrayList(strings); > } > } > > >
Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8283346: add items directly to the backing list to save a change build caused by adding items to the observable list ------------- Changes: - all: https://git.openjdk.org/jfx/pull/758/files - new: https://git.openjdk.org/jfx/pull/758/files/a92e9a01..3f288403 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=758&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=758&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/758.diff Fetch: git fetch https://git.openjdk.org/jfx pull/758/head:pull/758 PR: https://git.openjdk.org/jfx/pull/758 From mhanl at openjdk.org Tue Jun 28 15:29:44 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 28 Jun 2022 15:29:44 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v3] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 18:07:45 GMT, Michael Strau? wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8283346: Improved test name > > modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 351: > >> 349: public static ObservableList observableArrayList(E... items) { >> 350: ObservableList list = observableList(new ArrayList<>(items.length)); >> 351: list.addAll(items); > > You can also skip the generation of a list change event: > > List list = new ArrayList<>(items.length); > list.addAll(items); > return observableList(list); done ------------- PR: https://git.openjdk.org/jfx/pull/758 From nlisker at openjdk.org Tue Jun 28 16:34:36 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 28 Jun 2022 16:34:36 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v4] In-Reply-To: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> References: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> Message-ID: On Tue, 28 Jun 2022 15:29:41 GMT, Marius Hanl wrote: >> This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. >> >> I also added tests which will succeed before and after to verify that nothing got broken by this change. >> Also I made a benchmark test. Results: >> >> | Benchmark | Mode| Cnt | Score | Error | Units >> | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | >> | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s >> | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s >> >> Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. >> ListBenchmark OLD (avg): 21-23ms >> ListBenchmark NEW (avg): 2 ms >> >>
Benchmark code >> >> >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import org.openjdk.jmh.annotations.Benchmark; >> import org.openjdk.jmh.annotations.Scope; >> import org.openjdk.jmh.annotations.Setup; >> import org.openjdk.jmh.annotations.State; >> import org.openjdk.jmh.annotations.TearDown; >> >> import java.util.ArrayList; >> import java.util.List; >> >> @State(Scope.Benchmark) >> public class ListBenchmark { >> >> List strings; >> >> @Setup >> public void setup() { >> strings = new ArrayList<>(); >> for(int i = 0; i< 100000;i++) { >> strings.add("abc: " + i); >> } >> } >> >> @TearDown >> public void tearDown() { >> strings = null; >> } >> >> @Benchmark >> public ObservableList init() { >> return FXCollections.observableArrayList(strings); >> } >> } >> >> >>
> > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8283346: add items directly to the backing list to save a change build caused by adding items to the observable list modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 351: > 349: public static ObservableList observableArrayList(E... items) { > 350: ArrayList backingList = new ArrayList<>(items.length); > 351: backingList.addAll(Arrays.asList(items)); Did you try using `List.of` instead? var backingList = new ArrayList<>(List.of(items)); ------------- PR: https://git.openjdk.org/jfx/pull/758 From mhanl at openjdk.org Tue Jun 28 17:00:14 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 28 Jun 2022 17:00:14 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v4] In-Reply-To: References: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> Message-ID: On Tue, 28 Jun 2022 16:23:57 GMT, Nir Lisker wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8283346: add items directly to the backing list to save a change build caused by adding items to the observable list > > modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 351: > >> 349: public static ObservableList observableArrayList(E... items) { >> 350: ArrayList backingList = new ArrayList<>(items.length); >> 351: backingList.addAll(Arrays.asList(items)); > > Did you try using `List.of` instead? > > var backingList = new ArrayList<>(List.of(items)); No, but `List.of` does not allow `null` values, therefore this would change the existing behaviour as `null` is allowed in an observable arraylist. ------------- PR: https://git.openjdk.org/jfx/pull/758 From mstrauss at openjdk.org Tue Jun 28 17:13:47 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 28 Jun 2022 17:13:47 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v4] In-Reply-To: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> References: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> Message-ID: On Tue, 28 Jun 2022 15:29:41 GMT, Marius Hanl wrote: >> This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. >> >> I also added tests which will succeed before and after to verify that nothing got broken by this change. >> Also I made a benchmark test. Results: >> >> | Benchmark | Mode| Cnt | Score | Error | Units >> | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | >> | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s >> | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s >> >> Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. >> ListBenchmark OLD (avg): 21-23ms >> ListBenchmark NEW (avg): 2 ms >> >>
Benchmark code >> >> >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import org.openjdk.jmh.annotations.Benchmark; >> import org.openjdk.jmh.annotations.Scope; >> import org.openjdk.jmh.annotations.Setup; >> import org.openjdk.jmh.annotations.State; >> import org.openjdk.jmh.annotations.TearDown; >> >> import java.util.ArrayList; >> import java.util.List; >> >> @State(Scope.Benchmark) >> public class ListBenchmark { >> >> List strings; >> >> @Setup >> public void setup() { >> strings = new ArrayList<>(); >> for(int i = 0; i< 100000;i++) { >> strings.add("abc: " + i); >> } >> } >> >> @TearDown >> public void tearDown() { >> strings = null; >> } >> >> @Benchmark >> public ObservableList init() { >> return FXCollections.observableArrayList(strings); >> } >> } >> >> >>
> > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8283346: add items directly to the backing list to save a change build caused by adding items to the observable list Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.org/jfx/pull/758 From mhanl at openjdk.org Tue Jun 28 17:14:12 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 28 Jun 2022 17:14:12 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize Message-ID: Initialize the `(Tree)TableView` when creating the measure row. This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 ------------- Commit messages: - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing Changes: https://git.openjdk.org/jfx/pull/805/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289357 Stats: 154 lines in 5 files changed: 152 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/805.diff Fetch: git fetch https://git.openjdk.org/jfx pull/805/head:pull/805 PR: https://git.openjdk.org/jfx/pull/805 From jvos at openjdk.org Tue Jun 28 17:19:48 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 28 Jun 2022 17:19:48 GMT Subject: [jfx17u] Integrated: 8282093: LineChart path incorrect when outside lower bound In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 07:08:00 GMT, Johan Vos wrote: > Clean backport of 8282093: LineChart path incorrect when outside lower bound > Reviewed-by: aghaisas This pull request has now been integrated. Changeset: 1cf2a200 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/1cf2a200658da7bbb8d9f95650b6fe137fa66f10 Stats: 523 lines in 4 files changed: 500 ins; 0 del; 23 mod 8282093: LineChart path incorrect when outside lower bound Backport-of: d28f3d781a125eae7e89956ff8e37fc7b94646c2 ------------- PR: https://git.openjdk.org/jfx17u/pull/65 From jvos at openjdk.org Tue Jun 28 17:22:46 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 28 Jun 2022 17:22:46 GMT Subject: [jfx17u] Integrated: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 07:10:58 GMT, Johan Vos wrote: > clean backport of 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected > > Reviewed-by: mstrauss, aghaisas This pull request has now been integrated. Changeset: 97fd2cbd Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/97fd2cbd3cf896428888a8a82e33591aeefb08f6 Stats: 116 lines in 5 files changed: 111 ins; 0 del; 5 mod 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected Backport-of: 590033f4cb2b5bbe02261a845c554dd08c7866ff ------------- PR: https://git.openjdk.org/jfx17u/pull/66 From nlisker at openjdk.org Tue Jun 28 17:29:56 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 28 Jun 2022 17:29:56 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v4] In-Reply-To: References: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> Message-ID: On Tue, 28 Jun 2022 16:56:27 GMT, Marius Hanl wrote: >> modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 351: >> >>> 349: public static ObservableList observableArrayList(E... items) { >>> 350: ArrayList backingList = new ArrayList<>(items.length); >>> 351: backingList.addAll(Arrays.asList(items)); >> >> Did you try using `List.of` instead? >> >> var backingList = new ArrayList<>(List.of(items)); > > No, but `List.of` does not allow `null` values, therefore this would change the existing behaviour as `null` is allowed in an observable arraylist. That's a good point. ------------- PR: https://git.openjdk.org/jfx/pull/758 From jvos at openjdk.org Tue Jun 28 18:15:05 2022 From: jvos at openjdk.org (Johan Vos) Date: Tue, 28 Jun 2022 18:15:05 GMT Subject: [jfx17u] RFR: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView Message-ID: clean backport of 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView Reviewed-by: aghaisas ------------- Commit messages: - 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView Changes: https://git.openjdk.org/jfx17u/pull/67/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=67&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8273339 Stats: 148 lines in 5 files changed: 141 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx17u/pull/67.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/67/head:pull/67 PR: https://git.openjdk.org/jfx17u/pull/67 From mhanl at openjdk.org Tue Jun 28 18:46:38 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 28 Jun 2022 18:46:38 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v2] In-Reply-To: References: Message-ID: > Initialize the `(Tree)TableView` when creating the measure row. > This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). > > With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. > I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 > > Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit` is not triggered twice. Some tests catched that (see `test_rt_31015`). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener ------------- Changes: - all: https://git.openjdk.org/jfx/pull/805/files - new: https://git.openjdk.org/jfx/pull/805/files/1c23a030..e3a9545e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/805.diff Fetch: git fetch https://git.openjdk.org/jfx pull/805/head:pull/805 PR: https://git.openjdk.org/jfx/pull/805 From mhanl at openjdk.org Tue Jun 28 19:18:17 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 28 Jun 2022 19:18:17 GMT Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize [v3] In-Reply-To: References: Message-ID: <4nE7eBJDtdy2Br2HZT_PXcqnGFXQw9C0_TGu_yPiazA=.83b190e7-6f1a-4eb0-ae6b-397ca0b23d20@github.com> > Initialize the `(Tree)TableView` when creating the measure row. > This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise). > > With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now. > I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065 > > Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit` is not triggered twice. Some tests catched that (see `test_rt_31015`). Marius Hanl has updated the pull request incrementally with two additional commits since the last revision: - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup ------------- Changes: - all: https://git.openjdk.org/jfx/pull/805/files - new: https://git.openjdk.org/jfx/pull/805/files/e3a9545e..b6dcccdb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=805&range=01-02 Stats: 27 lines in 3 files changed: 25 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/805.diff Fetch: git fetch https://git.openjdk.org/jfx pull/805/head:pull/805 PR: https://git.openjdk.org/jfx/pull/805 From mstrauss at openjdk.org Tue Jun 28 21:00:48 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 28 Jun 2022 21:00:48 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v15] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Sat, 28 May 2022 07:07:01 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API I think that the `Bindings.select` documentation should be updated to point users to `ObservableValue.flatMap`. ------------- PR: https://git.openjdk.org/jfx/pull/675 From mstrauss at openjdk.org Tue Jun 28 21:34:52 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 28 Jun 2022 21:34:52 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v15] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Sat, 28 May 2022 07:07:01 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API Why are the following files in the `javafx.beans.value` package, and not in the `com.sun.javafx.binding` package? `FlatMappedBinding` `LazyObjectBinding` `MappedBinding` `OrElseBinding` modules/javafx.base/src/main/java/javafx/beans/value/LazyObjectBinding.java line 80: > 78: * Called after a listener was added to start observing inputs if they're not observed already. > 79: */ > 80: private void updateSubcriptionAfterAdd() { typo: Subcription modules/javafx.base/src/main/java/javafx/beans/value/LazyObjectBinding.java line 111: > 109: * observing this binding. > 110: */ > 111: private void updateSubcriptionAfterRemove() { typo: Subcription ------------- PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Wed Jun 29 00:08:04 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 29 Jun 2022 00:08:04 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v15] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Tue, 28 Jun 2022 21:30:58 GMT, Michael Strau? wrote: > Why are the following files in the `javafx.beans.value` package, and not in the `com.sun.javafx.binding` package? `FlatMappedBinding` `LazyObjectBinding` `MappedBinding` `OrElseBinding` No specific reason, they are package private at the moment. They can be moved as a group to `com.sun.javafx.binding` if they're made public (so `ObservableValue` can instantiate them). I'm not sure what is preferred since they're not public API in either case. ------------- PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Wed Jun 29 00:19:59 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 29 Jun 2022 00:19:59 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v15] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Tue, 28 Jun 2022 20:57:18 GMT, Michael Strau? wrote: > I think that the `Bindings.select` documentation should be updated to point users to `ObservableValue.flatMap`. Any suggestions what I should add? I can add a `@see` tag, and/or I could add a note in the description, something along the line of "Note: since 19, ObservableValue#flatMap directly supports creating new bindings for JavaFX properties." Note that `Bindings.select` also allows for JavaBeans properties, which are not supported by `flatMap`. ------------- PR: https://git.openjdk.org/jfx/pull/675 From mstrauss at openjdk.org Wed Jun 29 00:56:50 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 29 Jun 2022 00:56:50 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v15] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <_NsGpO0px_mjy5kUb27zAy-Me_8nN1-QyXCMk0GQypc=.52ee8501-6b50-4e30-adb3-8c868837b1f1@github.com> On Wed, 29 Jun 2022 00:04:24 GMT, John Hendrikx wrote: > No specific reason, they are package private at the moment. They can be moved as a group to `com.sun.javafx.binding` if they're made public (so `ObservableValue` can instantiate them). I'm not sure what is preferred since they're not public API in either case. I think it makes sense to move these files to `com.sun.javafx.bindings`, as that's the package that contains all binding implementations (ExpressionHelper, BidirectionalBinding, ContentBinding, etc...), and also that's where `Subscription` is currently located. ------------- PR: https://git.openjdk.org/jfx/pull/675 From mstrauss at openjdk.org Wed Jun 29 01:08:55 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 29 Jun 2022 01:08:55 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v15] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Wed, 29 Jun 2022 00:17:53 GMT, John Hendrikx wrote: > Any suggestions what I should add? > > I can add a `@see` tag, and/or I could add a note in the description, something along the line of "Note: since 19, ObservableValue#flatMap directly supports creating new bindings for JavaFX properties." > > Note that `Bindings.select` also allows for JavaBeans properties, which are not supported by `flatMap`. I think we should not only inform, but advise people to use `flatMap`: "Since 19, it is recommended to use ObservableValue#flatMap to select a nested member of an ObservableValue." ------------- PR: https://git.openjdk.org/jfx/pull/675 From jvos at openjdk.org Wed Jun 29 07:47:50 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 29 Jun 2022 07:47:50 GMT Subject: [jfx17u] Integrated: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 18:05:33 GMT, Johan Vos wrote: > clean backport of 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView > > Reviewed-by: aghaisas This pull request has now been integrated. Changeset: 7d335520 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/7d335520edc8fb344c840810dd649d585bb1d9d3 Stats: 148 lines in 5 files changed: 141 ins; 0 del; 7 mod 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView Backport-of: c55931f662ccbb4cdbb602a31d3d61231ebf79ca ------------- PR: https://git.openjdk.org/jfx17u/pull/67 From jvos at openjdk.org Wed Jun 29 08:08:11 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 29 Jun 2022 08:08:11 GMT Subject: [jfx17u] RFR: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem Message-ID: clean backport of 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem 8187596: TreeView selection incorrectly changes after deleting an unselected row Reviewed-by: aghaisas, kcr ------------- Commit messages: - 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem Changes: https://git.openjdk.org/jfx17u/pull/68/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=68&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8193442 Stats: 193 lines in 5 files changed: 175 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jfx17u/pull/68.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/68/head:pull/68 PR: https://git.openjdk.org/jfx17u/pull/68 From jvos at openjdk.org Wed Jun 29 08:12:08 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 29 Jun 2022 08:12:08 GMT Subject: [jfx17u] RFR: 8244234: MenuButton: NPE on removing from scene with open popup Message-ID: clean backport of 8244234: MenuButton: NPE on removing from scene with open popup Reviewed-by: aghaisas ------------- Commit messages: - 8244234: MenuButton: NPE on removing from scene with open popup Changes: https://git.openjdk.org/jfx17u/pull/69/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=69&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8244234 Stats: 131 lines in 2 files changed: 126 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jfx17u/pull/69.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/69/head:pull/69 PR: https://git.openjdk.org/jfx17u/pull/69 From mhanl at openjdk.org Wed Jun 29 13:40:24 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 29 Jun 2022 13:40:24 GMT Subject: RFR: 8276056: Control.skin.setSkin(Skin) fails to call dispose() on discarded Skin Message-ID: For some reason the `skinProperty` did not allow to set a new skin which is the same class as the previous one. This leads to multiple issues: 1. When creating a new skin (same class as previous), the skin will likely install some children and listener but is then rejected when setting it due to the `skinProperty` class constraint -> Control is in a weird state as the current skin was not disposed since it is still set, although we already and 'set' a new skin 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous -> Just imagine we have the following skin class class MyCustomButtonSkin extends ButtonSkin { public MyCustomButtonSkin(Button button, boolean someFlag) { super(button); ... } } Now if we would change the skin of the Button two times like this: button.setSkin(new MyCustomButtonSkin(button, true)); button.setSkin(new MyCustomButtonSkin(button, false)); The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. ------------- Commit messages: - 8276056: Allow to set a skin with same class (name) as the previous one Changes: https://git.openjdk.org/jfx/pull/806/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=806&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8276056 Stats: 49 lines in 2 files changed: 34 ins; 13 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/806.diff Fetch: git fetch https://git.openjdk.org/jfx pull/806/head:pull/806 PR: https://git.openjdk.org/jfx/pull/806 From duke at openjdk.org Wed Jun 29 15:35:23 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 29 Jun 2022 15:35:23 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files Message-ID: summary of changes: - fixed .classpath files - set UTF-8 encoding in the eclipse project config files - fixed gradlew to use UTF-8 encoding ------------- Commit messages: - Revert "8279297: removed unused Shape.setMode method" - 8279297: removed unused Shape.setMode method - 8289255: reverted gradlew - 8289255: reverted gradlew - 8289255: remove executable flag - 8289255: updated eclipse .classpath and other configuration files Changes: https://git.openjdk.org/jfx/pull/804/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=804&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289255 Stats: 99 lines in 7 files changed: 52 ins; 20 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/804.diff Fetch: git fetch https://git.openjdk.org/jfx pull/804/head:pull/804 PR: https://git.openjdk.org/jfx/pull/804 From nlisker at openjdk.org Wed Jun 29 15:35:24 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 29 Jun 2022 15:35:24 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:19:36 GMT, Andy Goryachev wrote: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files > - fixed gradlew to use UTF-8 encoding There is already an open issue for this in [JDK-8221708](https://bugs.openjdk.org/browse/JDK-8221708). The reason it's pending is because the OpenJFX repo is awaiting [cleanup](https://mail.openjdk.org/pipermail/openjfx-dev/2021-June/030894.html), which will require to redo the Eclipse configuration files. The changes I have pending locally are more comprehensive than those proposed here. We can review these, but it will need to be redone later anyway. By the way, I already filed a PR to fix these previously - https://github.com/openjdk/jfx/pull/514. No one wanted to review it so it just stayed there until until it became irrelevant due to other changes. I think that the latest commit is related to a different branch. ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Wed Jun 29 15:35:24 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 29 Jun 2022 15:35:24 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:58:51 GMT, Nir Lisker wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files >> - fixed gradlew to use UTF-8 encoding > > There is already an open issue for this in [JDK-8221708](https://bugs.openjdk.org/browse/JDK-8221708). The reason it's pending is because the OpenJFX repo is awaiting [cleanup](https://mail.openjdk.org/pipermail/openjfx-dev/2021-June/030894.html), which will require to redo the Eclipse configuration files. The changes I have pending locally are more comprehensive than those proposed here. We can review these, but it will need to be redone later anyway. @nlisker: The goal of this PR is to unblock me for the further fixes in Eclipse, as the project currently does not compile in Eclipse. I am sure there is more work in /apps, but at least it compiles now. > I think that the latest commit is related to a different branch. not sure why the last commit got pushed to this branch, will revert shortly. thanks! ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Wed Jun 29 15:35:23 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jun 2022 15:35:23 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:19:36 GMT, Andy Goryachev wrote: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files > - fixed gradlew to use UTF-8 encoding Once the OCA status has been verified, the review can proceed formally. @nlisker Would you be able to review these changes? I'm not an Eclipse user. @kleopatra your input would be helpful, too, if you are willing to take a look. gradlew line 4: > 2: > 3: # > 4: # Copyright ? 2015-2021 the original authors. The changes in `gradlew` look fine. I'm surprised the file wasn't already UTF-8. gradlew line 4: > 2: > 3: # > 4: # Copyright ? 2015-2021 the original authors. `gradlew` still shows up in the patch with changes. You might need to revert it (e.g., using `git checkout master -- gradlew`) from the command line. ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Wed Jun 29 15:35:24 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 29 Jun 2022 15:35:24 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:19:36 GMT, Andy Goryachev wrote: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files > - fixed gradlew to use UTF-8 encoding Very similar indeed. The latest version 2022-06 (4.24.0) complained more, so this PR touched more files. I wonder if #514 will have zero diffs (save for XML ordering) once this PR is merged (integrated?). I would definitely volunteer to review the remaining changes (once I accumulate enough karma). ------------- PR: https://git.openjdk.org/jfx/pull/804 From nlisker at openjdk.org Wed Jun 29 15:35:24 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 29 Jun 2022 15:35:24 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 00:13:40 GMT, Andy Goryachev wrote: > I would definitely volunteer to review the remaining changes (once I accumulate enough karma). Maybe that's the trick. If I make the changes, it requires another Reviewer to allow me to merge, and there were (are?) no volunteers. If someone else makes the changes, I can count as a Reviewer :) I am on 4.23. I will update to 4.24 and review it. ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Wed Jun 29 15:35:24 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 29 Jun 2022 15:35:24 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:50:51 GMT, Kevin Rushforth wrote: >> summary of changes: >> - fixed .classpath files >> - set UTF-8 encoding in the eclipse project config files >> - fixed gradlew to use UTF-8 encoding > > gradlew line 4: > >> 2: >> 3: # >> 4: # Copyright ? 2015-2021 the original authors. > > The changes in `gradlew` look fine. I'm surprised the file wasn't already UTF-8. I could have left it alone, but these things bother me... > gradlew line 4: > >> 2: >> 3: # >> 4: # Copyright ? 2015-2021 the original authors. > > `gradlew` still shows up in the patch with changes. You might need to revert it (e.g., using `git checkout master -- gradlew`) from the command line. done. ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Wed Jun 29 15:35:25 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 29 Jun 2022 15:35:25 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:54:25 GMT, Kevin Rushforth wrote: >> I could have left it alone, but these things bother me... > > Since this is a 3rd-party file, it's probably best to fix it separately the next time we update it, though. good point. ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Wed Jun 29 15:35:25 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jun 2022 15:35:25 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:56:46 GMT, Andy Goryachev wrote: >> Since this is a 3rd-party file, it's probably best to fix it separately the next time we update it, though. > > good point. So given that this is unrelated, please revert this file. ------------- PR: https://git.openjdk.org/jfx/pull/804 From duke at openjdk.org Wed Jun 29 15:35:25 2022 From: duke at openjdk.org (Andy Goryachev) Date: Wed, 29 Jun 2022 15:35:25 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 11:44:55 GMT, Kevin Rushforth wrote: >> good point. > > So given that this is unrelated, please revert this file. reverted. we do want to fix it, right? ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Wed Jun 29 15:35:25 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jun 2022 15:35:25 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: <27mmuN_kdl7C8uzU-zit41zrwiQPLkyafr9t_W6YBzo=.5961c0e4-fdee-4382-994e-237c4acb976b@github.com> On Tue, 28 Jun 2022 14:55:24 GMT, Andy Goryachev wrote: >> So given that this is unrelated, please revert this file. > > reverted. we do want to fix it, right? Yes, we can do it the next time we update gradle (which will be in the JavaFX 20 time frame). ------------- PR: https://git.openjdk.org/jfx/pull/804 From kcr at openjdk.org Wed Jun 29 15:35:25 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Jun 2022 15:35:25 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:53:00 GMT, Andy Goryachev wrote: >> gradlew line 4: >> >>> 2: >>> 3: # >>> 4: # Copyright ? 2015-2021 the original authors. >> >> The changes in `gradlew` look fine. I'm surprised the file wasn't already UTF-8. > > I could have left it alone, but these things bother me... Since this is a 3rd-party file, it's probably best to fix it separately the next time we update it, though. ------------- PR: https://git.openjdk.org/jfx/pull/804 From thiago.sayao at gmail.com Wed Jun 29 16:40:12 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 29 Jun 2022 13:40:12 -0300 Subject: enableInputMethodEvents In-Reply-To: References: Message-ID: For information, "XIM" got removed from gtk https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1195 I took a look at it, and it's a really odd api as compared to modern options such as Xinput2. There are the original "X input methods", then Xinput then Xinput2, the later supports touch devices and it's "modern". It also explains why some things break on some distros - it may be using older input method handling. It affects mouse (pointer), keyboard and touch events. Xinput2 dates October, 2009. https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt Cheers Em sex., 17 de jun. de 2022 ?s 10:37, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > View.java has this method (enableInputMethodEvents) with no documentation. > > On Linux it uses X input method events. > > But I can't figure out why exactly it must be enabled. When it's not > enabled, there are input method events anyway.... > And it seems (at least on Linux) to do the same thing for keyboard events, > but using Xlib directly instead of GDK. > > It seems to touch composition - that is when multiple keypresses are > needed to generate a symbol, for example, accented characters. > > Why does it exist? > > -- Thiago. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Wed Jun 29 19:34:32 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 29 Jun 2022 19:34:32 GMT Subject: [jfx17u] Integrated: 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 08:00:55 GMT, Johan Vos wrote: > clean backport of 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem > > 8187596: TreeView selection incorrectly changes after deleting an unselected row > > Reviewed-by: aghaisas, kcr This pull request has now been integrated. Changeset: 97a3f7fe Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/97a3f7fefdd8c67b27e2ebd6613a7d53013d51e2 Stats: 193 lines in 5 files changed: 175 ins; 12 del; 6 mod 8193442: Removing TreeItem from a TreeTableView sometime changes selectedItem 8187596: TreeView selection incorrectly changes after deleting an unselected row Backport-of: 3bb2db12a4ae3fe4a26420f0af57c189b2549edb ------------- PR: https://git.openjdk.org/jfx17u/pull/68 From jvos at openjdk.org Wed Jun 29 19:38:54 2022 From: jvos at openjdk.org (Johan Vos) Date: Wed, 29 Jun 2022 19:38:54 GMT Subject: [jfx17u] Integrated: 8244234: MenuButton: NPE on removing from scene with open popup In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 08:02:58 GMT, Johan Vos wrote: > clean backport of 8244234: MenuButton: NPE on removing from scene with open popup > Reviewed-by: aghaisas This pull request has now been integrated. Changeset: f84dac29 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/f84dac2978bc6e1121e8200c3ab19b4832f466cf Stats: 131 lines in 2 files changed: 126 ins; 1 del; 4 mod 8244234: MenuButton: NPE on removing from scene with open popup Backport-of: 6e215263e6fe94099528d386ccda65b22bce3138 ------------- PR: https://git.openjdk.org/jfx17u/pull/69 From mstrauss at openjdk.org Wed Jun 29 23:42:52 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 29 Jun 2022 23:42:52 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v15] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Sat, 28 May 2022 07:07:01 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Expand flatMap javadoc with additional wording from Optional#flatMap > - Add since tags to all new API Please have a look at the following test: JMemoryBuddy.memoryTest(test -> { class ValueHolder { final StringProperty value = new SimpleStringProperty(this, "value"); StringProperty valueProperty() { return value; } } ObjectProperty valueHolderProperty = new SimpleObjectProperty<>(); // Set old ValueHolder instance var oldValueHolder = new ValueHolder(); valueHolderProperty.set(oldValueHolder); // Map the nested property ValueHolder.value ObservableValue mapped = valueHolderProperty.flatMap(ValueHolder::valueProperty); // Observe the mapped binding mapped.addListener(observable -> {}); // Set a new ValueHolder instance, replacing the old instance var newValueHolder = new ValueHolder(); valueHolderProperty.set(newValueHolder); // Now, my assumption is that the mapped binding holds no references // to the old ValueHolder instance test.setAsReferenced(mapped); test.assertCollectable(oldValueHolder); test.assertNotCollectable(newValueHolder); }); This test fails for `assertCollectable(oldValueHolder)`. My assumption is that a mapped binding holds no strong references to objects that are no longer in the mapping chain (i.e. property values that have been replaced by other values). Is this a bug, or is this expected behavior? ------------- PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Thu Jun 30 04:31:48 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 30 Jun 2022 04:31:48 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v15] In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <8oBr4rtmcjN7KRWuq3iO2DOcwNeVlawK_6JbAvlohi4=.5e82ea92-6c63-424d-a2a7-6e80aa37fd47@github.com> On Wed, 29 Jun 2022 23:39:14 GMT, Michael Strau? wrote: > This test fails for `assertCollectable(oldValueHolder)`. > > My assumption is that a mapped binding holds no strong references to objects that are no longer in the mapping chain (i.e. property values that have been replaced by other values). > > Is this a bug, or is this expected behavior? This is indeed a bug, and quite a subtle one, so definitely a good catch! The issue is that the flat mapped binding only switches its subscriptions during the computing of its value. However, since this test avoids querying the actual value, this never happens (no `getValue` is called on `mapped` and the listener involved is only an `InvalidationListener`). Adding `mapped.getValue()` just before the asserts or using a `ChangeListener` makes the issue disappear. The solution is for `FlatMappedBinding` to respond to invalidations by unsubscribing the mapped value it was observing; it normally does this in `computeValue` but it must do this a bit more eagerly. My initial quick fix is to do this in `FlatMappedBinding`: @Override protected void onInvalidating() { mappedSubscription.unsubscribe(); mappedSubscription = Subscription.EMPTY; } I'm seeing if this is the correct solution and adding some extra documentation to the class to more clearly explain what it should be doing. I will also add a test case to `ObservableValueFluentBindingsTest` to catch this one specifically. > By the way, if I move `ObservableValue mapped = ...` before `var oldValueHolder = ...`, the test passes. I couldn't fix the issue with your suggestion of moving the `ObservableValue mapped = ...` line -- perhaps you made some other changes as well that influenced the result. I suspect you also moved the `mapped.addListener(observable -> {});` line to the same location. ------------- PR: https://git.openjdk.org/jfx/pull/675 From jhendrikx at openjdk.org Thu Jun 30 06:57:03 2022 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 30 Jun 2022 06:57:03 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v16] In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <1qQDzVEpKEXbHbLIbogyIxEhdd0by8G47jGVIuvuYiY=.ebb06ac9-acb7-41cb-8c27-a2de8503c2c7@github.com> > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Standard JavaFX + Optional: > label.textProperty().bind(Bindings.createStringBinding( > () -> Optinal.ofNullable(employee.get()) > .map(Employee::getCompany) > .map(Company::getName) > .orElse(""), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: - Move private binding classes to com.sun.javafx.binding package - Add note to Bindings#select to consider ObservableValue#flatMap - Fix bug invalidation bug in FlatMappedBinding Also fixed a secondary issue where the indirect source of the binding was unsubscribed and resubscribed each time its value was recomputed. Add additional comments to clarify how FlatMappedBinding works. Added test cases for these newly discovered issues. - Fix typos in LazyObjectBinding - Rename observeInputs to observeSources ------------- Changes: - all: https://git.openjdk.org/jfx/pull/675/files - new: https://git.openjdk.org/jfx/pull/675/files/c3523903..2c3a9d95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=675&range=15 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=675&range=14-15 Stats: 515 lines in 10 files changed: 393 ins; 75 del; 47 mod Patch: https://git.openjdk.org/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.org/jfx pull/675/head:pull/675 PR: https://git.openjdk.org/jfx/pull/675 From jvos at openjdk.org Thu Jun 30 08:59:15 2022 From: jvos at openjdk.org (Johan Vos) Date: Thu, 30 Jun 2022 08:59:15 GMT Subject: [jfx17u] RFR: 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants Message-ID: <0DKkqNHCqRB_Scpvdpxc1vjbXqZo-oyMF9xxzn5gR80=.d9ecbd3b-3eb3-46b3-ad51-385e24934b4f@github.com> 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants Reviewed-by: aghaisas ------------- Commit messages: - 8286261: Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants Changes: https://git.openjdk.org/jfx17u/pull/70/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=70&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286261 Stats: 179 lines in 5 files changed: 171 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx17u/pull/70.diff Fetch: git fetch https://git.openjdk.org/jfx17u pull/70/head:pull/70 PR: https://git.openjdk.org/jfx17u/pull/70 From mariushanl at web.de Thu Jun 30 09:39:47 2022 From: mariushanl at web.de (Marius Hanl) Date: Thu, 30 Jun 2022 11:39:47 +0200 Subject: Typing space in ComboBox causes expanded list to close Message-ID: An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jun 30 15:30:09 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 30 Jun 2022 15:30:09 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 23:19:36 GMT, Andy Goryachev wrote: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files Please review. This PR is blocking the rest of fixes in [JDK-8289379](https://bugs.openjdk.org/browse/JDK-8289379) ------------- PR: https://git.openjdk.org/jfx/pull/804 From nlisker at openjdk.org Thu Jun 30 15:33:12 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 30 Jun 2022 15:33:12 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: References: Message-ID: <4paFU2AuCO8MFweHEIiBK8mqMIYgpi0RbCrpEkOVSEg=.f8cb11ef-ebc7-437d-a302-ba0df34e7d97@github.com> On Mon, 27 Jun 2022 23:19:36 GMT, Andy Goryachev wrote: > summary of changes: > - fixed .classpath files > - set UTF-8 encoding in the eclipse project config files I scheduled to review this today or tomorrow. ------------- PR: https://git.openjdk.org/jfx/pull/804 From mstrauss at openjdk.org Thu Jun 30 16:00:59 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 30 Jun 2022 16:00:59 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v16] In-Reply-To: <1qQDzVEpKEXbHbLIbogyIxEhdd0by8G47jGVIuvuYiY=.ebb06ac9-acb7-41cb-8c27-a2de8503c2c7@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <1qQDzVEpKEXbHbLIbogyIxEhdd0by8G47jGVIuvuYiY=.ebb06ac9-acb7-41cb-8c27-a2de8503c2c7@github.com> Message-ID: On Thu, 30 Jun 2022 06:57:03 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources Aside from out-of-date copyright headers (`Bindings`, `FlatMappedBinding`), this looks good to me. My code now works as I expect it to. ------------- PR: https://git.openjdk.org/jfx/pull/675 From mstrauss at openjdk.org Thu Jun 30 16:05:10 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 30 Jun 2022 16:05:10 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v16] In-Reply-To: <1qQDzVEpKEXbHbLIbogyIxEhdd0by8G47jGVIuvuYiY=.ebb06ac9-acb7-41cb-8c27-a2de8503c2c7@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <1qQDzVEpKEXbHbLIbogyIxEhdd0by8G47jGVIuvuYiY=.ebb06ac9-acb7-41cb-8c27-a2de8503c2c7@github.com> Message-ID: On Thu, 30 Jun 2022 06:57:03 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.org/jfx/pull/675 From mstrauss at openjdk.org Thu Jun 30 16:19:56 2022 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 30 Jun 2022 16:19:56 GMT Subject: RFR: 8276056: Control.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 13:35:15 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin which is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install some children and listener but is then rejected when setting it due to the `skinProperty` class constraint > -> Control is in a weird state as the current skin was not disposed since it is still set, although we already and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomButtonSkin extends ButtonSkin { > public MyCustomButtonSkin(Button button, boolean someFlag) { super(button); ... } > } > > Now if we would change the skin of the Button two times like this: > > button.setSkin(new MyCustomButtonSkin(button, true)); > button.setSkin(new MyCustomButtonSkin(button, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 241: > 239: > 240: @Override > 241: //This code is basically a kind of optimization that prevents a Skin that is equal but not instance equal. Why was this code here in the first place, considering that switching skins is surely not something that would logically be done repeatedly? Are there performance implications with this change? ------------- PR: https://git.openjdk.org/jfx/pull/806 From duke at openjdk.org Thu Jun 30 16:24:40 2022 From: duke at openjdk.org (Andy Goryachev) Date: Thu, 30 Jun 2022 16:24:40 GMT Subject: RFR: 8289255: update Eclipse .classpath and other configuration files In-Reply-To: <4paFU2AuCO8MFweHEIiBK8mqMIYgpi0RbCrpEkOVSEg=.f8cb11ef-ebc7-437d-a302-ba0df34e7d97@github.com> References: <4paFU2AuCO8MFweHEIiBK8mqMIYgpi0RbCrpEkOVSEg=.f8cb11ef-ebc7-437d-a302-ba0df34e7d97@github.com> Message-ID: <69NmWckU0tzRGCuQqG5uR6Fi8304Qa-zGa0seFCd0yw=.018d9d49-fe35-4733-af80-ba2e01b61bb1@github.com> On Thu, 30 Jun 2022 15:30:56 GMT, Nir Lisker wrote: > I scheduled to review this today or tomorrow. thank you ------------- PR: https://git.openjdk.org/jfx/pull/804 From mhanl at openjdk.org Thu Jun 30 16:33:53 2022 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 30 Jun 2022 16:33:53 GMT Subject: RFR: 8276056: Control.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 16:16:32 GMT, Michael Strau? wrote: >> For some reason the `skinProperty` did not allow to set a new skin which is the same class as the previous one. >> This leads to multiple issues: >> 1. When creating a new skin (same class as previous), the skin will likely install some children and listener but is then rejected when setting it due to the `skinProperty` class constraint >> -> Control is in a weird state as the current skin was not disposed since it is still set, although we already and 'set' a new skin >> 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous >> -> Just imagine we have the following skin class >> >> class MyCustomButtonSkin extends ButtonSkin { >> public MyCustomButtonSkin(Button button, boolean someFlag) { super(button); ... } >> } >> >> Now if we would change the skin of the Button two times like this: >> >> button.setSkin(new MyCustomButtonSkin(button, true)); >> button.setSkin(new MyCustomButtonSkin(button, false)); >> >> The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. > > modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 241: > >> 239: >> 240: @Override >> 241: //This code is basically a kind of optimization that prevents a Skin that is equal but not instance equal. > > Why was this code here in the first place, considering that switching skins is surely not something that would logically be done repeatedly? Are there performance implications with this change? I don't know. I think someone guessed that if a new skin is from the same class it must be the same and can therefore be rejected. While this will probably work 95% the times, it is still not a 100% correct assumption. This has no performance implications. ------------- PR: https://git.openjdk.org/jfx/pull/806 From nlisker at openjdk.org Thu Jun 30 19:39:58 2022 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 30 Jun 2022 19:39:58 GMT Subject: RFR: 8283346: Optimize observable ArrayList creation in FXCollections [v4] In-Reply-To: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> References: <0bgs0QoUoqrObRP1Ch0BewkS7ETnEDL2mnoBMi4bME0=.7e6d5429-b9a5-4759-a99a-e48b4407c356@github.com> Message-ID: On Tue, 28 Jun 2022 15:29:41 GMT, Marius Hanl wrote: >> This simple PR optimizes the observable `ArrayList` creation by using the ArrayList constructor/array size so that the underlying array will be initialized at the correct size which will speed up the creation as the array does not need to grow as a result of the `addAll` call. >> >> I also added tests which will succeed before and after to verify that nothing got broken by this change. >> Also I made a benchmark test. Results: >> >> | Benchmark | Mode| Cnt | Score | Error | Units >> | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | >> | ListBenchmark OLD | thrpt | 25 | 722,842 | ? 26,93 | ops/s >> | ListBenchmark NEW | thrpt | 25 | 29262,274 | ? 2088,712 | ops/s >> >> Edit: I also made a synthetic benchmark by measuring the same code below 100 times with `System.nanoTime`. >> ListBenchmark OLD (avg): 21-23ms >> ListBenchmark NEW (avg): 2 ms >> >>
Benchmark code >> >> >> import javafx.collections.FXCollections; >> import javafx.collections.ObservableList; >> import org.openjdk.jmh.annotations.Benchmark; >> import org.openjdk.jmh.annotations.Scope; >> import org.openjdk.jmh.annotations.Setup; >> import org.openjdk.jmh.annotations.State; >> import org.openjdk.jmh.annotations.TearDown; >> >> import java.util.ArrayList; >> import java.util.List; >> >> @State(Scope.Benchmark) >> public class ListBenchmark { >> >> List strings; >> >> @Setup >> public void setup() { >> strings = new ArrayList<>(); >> for(int i = 0; i< 100000;i++) { >> strings.add("abc: " + i); >> } >> } >> >> @TearDown >> public void tearDown() { >> strings = null; >> } >> >> @Benchmark >> public ObservableList init() { >> return FXCollections.observableArrayList(strings); >> } >> } >> >> >>
> > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8283346: add items directly to the backing list to save a change build caused by adding items to the observable list Looks good. I left a few small comments. I ran some benchmarks and I can reproduce the performance improvement both in the array (varargs) and the collection variants of the method. modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line 351: > 349: public static ObservableList observableArrayList(E... items) { > 350: ArrayList backingList = new ArrayList<>(items.length); > 351: backingList.addAll(Arrays.asList(items)); Unless I'm missing something again, this can be written as `ArrayList backingList = new ArrayList<>(Arrays.asList(items));` I created benchmarks based on yours, and there is no significant difference between these two (their scores are within the error ranges of each other). I don't mind leaving it as is if you think it's clearer, I personally prefer the 1 line variant. modules/javafx.base/src/test/java/test/javafx/collections/FXCollectionsTest.java line 47: > 45: @Test > 46: public void testCreateObservableArrayListFromArray() { > 47: ObservableList observableList = FXCollections.observableArrayList("1", "2", "3"); I would add a `null` element (like `"1", "2", null`) to test that the method accepts `null`s, especially after I fell for it myself. modules/javafx.base/src/test/java/test/javafx/collections/FXCollectionsTest.java line 57: > 55: @Test > 56: public void testCreateObservableArrayListFromCollection() { > 57: List list = List.of("1", "2", "3"); Same here with `null`, only now `Arrays.asList` will be needed instead. ------------- PR: https://git.openjdk.org/jfx/pull/758 From kcr at openjdk.org Thu Jun 30 20:17:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 30 Jun 2022 20:17:01 GMT Subject: RFR: 8276056: Control.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 13:35:15 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin which is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install some children and listener but is then rejected when setting it due to the `skinProperty` class constraint > -> Control is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomButtonSkin extends ButtonSkin { > public MyCustomButtonSkin(Button button, boolean someFlag) { super(button); ... } > } > > Now if we would change the skin of the Button two times like this: > > button.setSkin(new MyCustomButtonSkin(button, true)); > button.setSkin(new MyCustomButtonSkin(button, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. This looks simple enough that a single Reviewer should be sufficient. The remove code looks quite questionable to me, so getting rid of it seems like a good thing. ------------- PR: https://git.openjdk.org/jfx/pull/806 From kcr at openjdk.org Thu Jun 30 23:54:02 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 30 Jun 2022 23:54:02 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v16] In-Reply-To: <1qQDzVEpKEXbHbLIbogyIxEhdd0by8G47jGVIuvuYiY=.ebb06ac9-acb7-41cb-8c27-a2de8503c2c7@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> <1qQDzVEpKEXbHbLIbogyIxEhdd0by8G47jGVIuvuYiY=.ebb06ac9-acb7-41cb-8c27-a2de8503c2c7@github.com> Message-ID: <4SyeeOKmJpOlJV_5pxkAn9fjjjUVLL84t7NYzoA--is=.2f8ca931-cf15-4cd9-a407-a0094373c930@github.com> On Thu, 30 Jun 2022 06:57:03 GMT, John Hendrikx wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Standard JavaFX + Optional: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> Optinal.ofNullable(employee.get()) >> .map(Employee::getCompany) >> .map(Company::getName) >> .orElse(""), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > John Hendrikx has updated the pull request incrementally with five additional commits since the last revision: > > - Move private binding classes to com.sun.javafx.binding package > - Add note to Bindings#select to consider ObservableValue#flatMap > - Fix bug invalidation bug in FlatMappedBinding > > Also fixed a secondary issue where the indirect source of the binding > was unsubscribed and resubscribed each time its value was recomputed. > > Add additional comments to clarify how FlatMappedBinding works. > > Added test cases for these newly discovered issues. > - Fix typos in LazyObjectBinding > - Rename observeInputs to observeSources This looks quite good now. I believe the API is ready to go. I did a little testing and want to do some more tomorrow, and then hope to finish my review. I left a couple comments / questions inline. Two overall comments: 1. The doc changes in Bindings.java should be added to the Specification section in the CSR. 2. The copyright line for each new file should be: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. with a comma after the year. modules/javafx.base/src/main/java/com/sun/javafx/binding/FlatMappedBinding.java line 2: > 1: /* > 2: * Copyright (c) 2021 Oracle and/or its affiliates. All rights reserved. That should be `2022,` with a comma after the year in addition to fixing the year. modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line 90: > 88: */ > 89: static Subscription subscribe(ObservableValue observableValue, Consumer subscriber) { > 90: ChangeListener listener = (obs, old, current) -> subscriber.accept(current); Maybe call `Objects.requireNonNull()` on `observableValue` and `subscriber` before creating the listener? modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line 110: > 108: */ > 109: static Subscription subscribeInvalidations(ObservableValue observableValue, Runnable runnable) { > 110: Objects.requireNonNull(runnable); Maybe also call `Objects.requireNonNull(observableValue)` here? modules/javafx.base/src/main/java/javafx/beans/binding/Bindings.java line 443: > 441: * Since 19, it is recommended to use {@link ObservableValue#flatMap(java.util.function.Function)} > 442: * to select a nested member of an {@link ObservableValue}. > 443: *

This should be added to the CSR. ------------- PR: https://git.openjdk.org/jfx/pull/675