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

Reply via email to