On Wed, 19 Oct 2022 15:02:42 GMT, Johan Vos wrote:
> update javaFX release version to 11.0.18
> Fix for JDK-8295659
Marked as reviewed by kcr (Lead).
-
PR: https://git.openjdk.org/jfx11u/pull/114
On Wed, 19 Oct 2022 14:55:40 GMT, Johan Vos wrote:
> Update JavaFX 17 release version to 17.0.6
> Fix for JDK-8295660
Marked as reviewed by kcr (Lead).
-
PR: https://git.openjdk.org/jfx17u/pull/83
On Wed, 19 Oct 2022 20:37:34 GMT, Andy Goryachev wrote:
> Thank you. You do bring a good point - clearing the map. There is some mild
> language warning about clearing the map in javadoc already, but perhaps
> `Node.getProperties().clear()` should be forbidden (throw an IOE?).
A map can also
> Fixed memory leak by using weak listeners and making sure to undo everything
> that has been done to MenuBar/Skin in dispose().
>
> This PR depends on a new internal class ListenerHelper, a replacement for
> LambdaMultiplePropertyChangeListenerHandler.
> See
> Introduction
>
> There is a number of places where various listeners (strong as well as weak)
> are added, to be later disconnected in one go. For example, Skin
> implementations use dispose() method to clean up the listeners installed in
> the corresponding Control (sometimes using
>
> Fixed memory leak by using weak listeners and making sure to undo everything
> that has been done to MenuBar/Skin in dispose().
>
> This PR depends on a new internal class ListenerHelper, a replacement for
> LambdaMultiplePropertyChangeListenerHandler.
> See
> Introduction
>
> There is a number of places where various listeners (strong as well as weak)
> are added, to be later disconnected in one go. For example, Skin
> implementations use dispose() method to clean up the listeners installed in
> the corresponding Control (sometimes using
>
On Wed, 19 Oct 2022 20:45:41 GMT, Andy Goryachev wrote:
>> I actually like `asLongAs` that was mentioned in another comment, but it
>> looks odd :)
>>
>> Lately, as I was reading some unrelated codebases and I came up with
>> `updateWhile` (or `updateWhen`). The reason is that names like
On Wed, 19 Oct 2022 20:37:46 GMT, Nir Lisker wrote:
>> I like `conditionOn`.
>
> I actually like `asLongAs` that was mentioned in another comment, but it
> looks odd :)
>
> Lately, as I was reading some unrelated codebases and I came up with
> `updateWhile` (or `updateWhen`). The reason is
On Wed, 19 Oct 2022 20:14:18 GMT, Nir Lisker wrote:
>> @mstr2 :
>> `getProperties()` is a perfectly fine way of storing a property instance,
>> especially considering the fact that this property will be called exactly
>> once - during the fluent pipeline setup. Of course, it does not apply
On Fri, 14 Oct 2022 16:19:02 GMT, Andy Goryachev wrote:
>> Changing the documentation for `When` should not be part of this PR I think.
>> What we should do maybe is add a note that this method should not be
>> confused with `Bindings.when`. I'll let others weigh in.
>
> I like `conditionOn`.
On Thu, 29 Sep 2022 15:02:13 GMT, John Hendrikx wrote:
>> This PR adds a new (lazy*) property on `Node` which provides a boolean which
>> indicates whether or not the `Node` is currently part of a `Scene`, which in
>> turn is part of a currently showing `Window`.
>>
>> It also adds a new
On Tue, 18 Oct 2022 18:44:58 GMT, Andy Goryachev wrote:
>>> I'd respectfully disagree: in a large application, there might be hundreds
>>> (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property
>>> (2%), so it's a waste of RAM. One may think it's only 8Kb on a 64 bit
>>>
> Fixed memory leak by using weak listeners and making sure to undo everything
> that has been done to MenuBar/Skin in dispose().
>
> This PR depends on a new internal class ListenerHelper, a replacement for
> LambdaMultiplePropertyChangeListenerHandler.
> See
On Fri, 14 Oct 2022 19:11:08 GMT, Andy Goryachev wrote:
>> Introduction
>>
>> There is a number of places where various listeners (strong as well as weak)
>> are added, to be later disconnected in one go. For example, Skin
>> implementations use dispose() method to clean up the listeners
> Introduction
>
> There is a number of places where various listeners (strong as well as weak)
> are added, to be later disconnected in one go. For example, Skin
> implementations use dispose() method to clean up the listeners installed in
> the corresponding Control (sometimes using
>
update javaFX release version to 11.0.18
Fix for JDK-8295659
-
Commit messages:
- update javaFX release version to 11.0.18
Changes: https://git.openjdk.org/jfx11u/pull/114/files
Webrev: https://webrevs.openjdk.org/?repo=jfx11u=114=00
Issue:
Update JavaFX 17 release version to 17.0.6
Fix for JDK-8295660
-
Commit messages:
- Update JavaFX 17 release version to 17.0.6
Changes: https://git.openjdk.org/jfx17u/pull/83/files
Webrev: https://webrevs.openjdk.org/?repo=jfx17u=83=00
Issue:
On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra wrote:
> This change removes runFinalization calls in ImagePool::pruneCache method.
>
> Finalizers are deprecated in JDK 18 and will be removed soon.
Marked as reviewed by angorya (Author).
-
PR:
On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra wrote:
> This change removes runFinalization calls in ImagePool::pruneCache method.
>
> Finalizers are deprecated in JDK 18 and will be removed soon.
Can you enable GitHub actions testing for your repo? See this comment:
This change removes runFinalization calls in ImagePool::pruneCache method.
Finalizers are deprecated in JDK 18 and will be removed soon.
-
Commit messages:
- 8278426: Remove runFinalization calls in ImagePool::pruneCache
Changes: https://git.openjdk.org/jfx/pull/918/files
Webrev:
On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra wrote:
> This change removes runFinalization calls in ImagePool::pruneCache method.
>
> Finalizers are deprecated in JDK 18 and will be removed soon.
All done! Tests are in progress now.
-
PR: https://git.openjdk.org/jfx/pull/918
On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra wrote:
> This change removes runFinalization calls in ImagePool::pruneCache method.
>
> Finalizers are deprecated in JDK 18 and will be removed soon.
LGTM. approving.
We can integrate once OCA is verified.
The title of the PR should be derived
On Wed, 19 Oct 2022 12:51:21 GMT, Douglas Held wrote:
>> The JavaDoc for equals had a copy/paste error. I normalized the text based
>> on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting
>> in the method signatures of equals(), hashCode() and toString().~~
>>
>> For
On Wed, 19 Oct 2022 12:52:33 GMT, Nir Lisker wrote:
> It's not. I have mentioned this exact case in
> https://bugs.openjdk.org/browse/JDK-8226930. I can assign it to you (or
> self-assign it yourself) if you want to work on it. If not, I will get to it
> at some point (no pun intended). This
On Wed, 19 Oct 2022 12:51:21 GMT, Douglas Held wrote:
>> The JavaDoc for equals had a copy/paste error. I normalized the text based
>> on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting
>> in the method signatures of equals(), hashCode() and toString().~~
>>
>> For
On Wed, 12 Oct 2022 17:28:42 GMT, Douglas Held wrote:
> The JavaDoc for equals had a copy/paste error. I normalized the text based on
> the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in
> the method signatures of equals(), hashCode() and toString().~~
>
> For good
On Wed, 19 Oct 2022 12:46:03 GMT, Douglas Held wrote:
> I think there's something else of quality worth discussing here. Is `==`
> appropriate given the values under comparison are `double`?
It's not. I have mentioned this exact case in
https://bugs.openjdk.org/browse/JDK-8226930. I can
On Wed, 19 Oct 2022 12:38:54 GMT, Douglas Held wrote:
>> modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line 417:
>>
>>> 415: * {@code getX}, {@code getY}, and {@code getZ} methods are equal.
>>> 416: *
>>> 417: * @param {@code obj} the reference object with
On Wed, 19 Oct 2022 12:33:37 GMT, Douglas Held wrote:
> I thought the code tags produced hyperlinks.
Those would be the `@link` tags, or `@linkplain`.
-
PR: https://git.openjdk.org/jfx/pull/913
On Wed, 19 Oct 2022 12:36:30 GMT, Nir Lisker wrote:
>> Douglas Held has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update Point3D.java
>>
>> Per review
>
> modules/javafx.graphics/src/main/java/javafx/geometry/Point3D.java line
On Wed, 19 Oct 2022 12:41:20 GMT, Nir Lisker wrote:
>> Don't use it for `obj` you mean?
>
> Here, yes. The parameter name following `@param` is taken care of
> automatically (a hyphen is also added after it).
and we don't need period `.` at the end of each `param` or `returns` line?
On Wed, 19 Oct 2022 12:34:15 GMT, Douglas Held wrote:
>> The JavaDoc for equals had a copy/paste error. I normalized the text based
>> on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting
>> in the method signatures of equals(), hashCode() and toString().~~
>>
>> For
> The JavaDoc for equals had a copy/paste error. I normalized the text based on
> the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in
> the method signatures of equals(), hashCode() and toString().~~
>
> For good measure, some kind of copy/paste detection should
On Wed, 19 Oct 2022 12:34:15 GMT, Douglas Held wrote:
>> The JavaDoc for equals had a copy/paste error. I normalized the text based
>> on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting
>> in the method signatures of equals(), hashCode() and toString().~~
>>
>> For
On Tue, 18 Oct 2022 22:15:35 GMT, Douglas Held wrote:
>> The JavaDoc for equals had a copy/paste error. I normalized the text based
>> on the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting
>> in the method signatures of equals(), hashCode() and toString().~~
>>
>> For
> The JavaDoc for equals had a copy/paste error. I normalized the text based on
> the JavaDoc for method java.awt.Point#equals. ~~I also changed formatting in
> the method signatures of equals(), hashCode() and toString().~~
>
> For good measure, some kind of copy/paste detection should
37 matches
Mail list logo
