Please ignore the explanation below it is incorrect (I forgot that
conditional and new observable reference each other).
I've updated the comment on Github, not sure if these edits will show on
the mailinglist.
--John
On 01/09/2022 15:14, John Hendrikx wrote:
On Wed, 31 Aug 2022 17:04:31 GMT, Nir Lisker <nlis...@openjdk.org> wrote:
John Hendrikx has updated the pull request incrementally with one additional
commit since the last revision:
Rename showing property to shown as it is already used in subclasses
modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line
266:
264: * {@code condition} evaluates to {@code true}. This allows this
{@code ObservableValue}
265: * and the conditional {@code ObservableValue} to be garbage collected
if neither is
266: * otherwise strongly referenced when {@code condition} becomes {@code
false}.
What happens if they are GC'd and the conditional becomes `true` later?
There are three objects involved here: the parent observable, the new
observable and the conditional.
What `when` should achieve is to make the new observable easy to garbage
collect when the conditional is `false` (the parent observable is considered to
be long lived so GC doesn't really apply there). The conditional itself is
referred to by the new observable, so it lives at least as long as the new
observable (but possibly longer).
If the new observable is GC'd, then it doesn't matter what conditional is; if
it becomes `true`, it would normally cause new observable to update its value,
but as new observable doesn't exist anymore, and nobody referred to it, nobody
is interested. If it was already `true` then the new observable couldn't have
been GC'd as parent observable would be referring to it.
Strong references look like this when conditional is `true`:
conditional <-- new observable <--> parent observable
When it is `false`:
conditional <-- new observable --> parent observable
In the first case, GC could only happen if new observable and parent observable
are both unreferenced -- as the parent is probably a much longer lived
property, this means a whole window is closed or the application is exiting or
some such.
In the second case, GC of new observable can happen if it is unreferenced; this
could happen when a small piece of UI is replaced with another piece leaving
the old piece (and all its bindings) 'orphaned'. It would not happen if it
simply became invisible, as it would still be a child of the larger UI
involved, and this child would in turn refer to new observable through a
binding.
-------------
PR: https://git.openjdk.org/jfx/pull/830
