> On Aug 14, 2026, at 12:58 PM, Kevin Rushforth <[email protected]> > wrote: > > On 8/6/2026 2:52 PM, Kevin Rushforth wrote: >> >> On 8/6/2026 1:33 PM, Dan Smith wrote: >>>> On Aug 3, 2026, at 8:34 AM, Kevin Rushforth <[email protected]> >>>> wrote: >>>> >>>> First, some JavaFX UI controls APIs take a list of objects. JavaFX >>>> internally creates a WeakReference to an individual object in some cases. >>>> This is tracked by JDK-8387301 [2]. >>> I was curious about the use cases, and how they might react to different >>> reference-clearing policies, so I dug into the code. >>> >>> For TablePosition (#2 in JDK-8387301), turns out the WeakReference seems to >>> go unused: I can delete the private `itemRef` field and the package-access >>> `getItem` method, and everything still builds fine*. >>> >>> (*Caveat that this is a complicated system, I’ve only built on macOS and >>> haven’t run any tests. Any reason to believe this is a platform-specific >>> dependency?) >>> >>> I’ll keep looking at the other cases, see if they can provide any insight >>> into reference-clearing policies... >> >> Thanks for looking into this. I know we don't rely on any reference clearing >> behavior, but I haven't dug into how we are using those WeakReferences in UI >> controls or whether we still need them at all (unlike the WebView Java <--> >> JS bridge case where I know how and why we are using them). It would be >> interesting to dig deeper to see if they are needed at all for controls. > > The private itemRef in TablePosition that you pointed out is indeed unused > and can be removed. The other three are still needed. > > We don't rely on reference clearing behavior, so a simple wrapper will > suffice for our needs.
I’ve been playing around with SelectedItemsReadOnlyObservableList, again with the goal of finding a use case that could inform our design choices. Here, I’m stuck trying to find a scenario where the WeakReference could get cleared: The idea is that there’s a list of indices of selected items in an ObservableList, and another list that acts as a view of the subset of ObservableList items that are selected. The subset view keeps around a cache of last-seen selected items so that it can create a “removed” change event that shares the no-longer-selected item with listeners. There’s some worry that the cache of last-seen selected items will cause a memory leak, so they are wrapped in WeakReferences. But… if they’re still in the underlying list, they won’t be GC’ed. And when I remove them from the list, the selection always seems to be auto-updated to a new, non-GC'ed selection, without creating any change events referencing the removed object. If there *were* a way to trigger a change event referring to an object that had been GC’ed, then the removal change event would reference ’null’, which would be a different problem. (I experimented with some exotic ObservableLists that have unstable results—e.g., each read allocates a new object—and then all sorts of weird things happen, but this seems outside the intended scope of the API.) As this relates to value objects: - If memory leaks are a problem for identity objects, wouldn’t they also be a problem for value objects (which might, e.g., reference a large array)? Which would call for immediately discarding the value objects—but if that works, why have a cache at all? - If nulls in removal change events are the problem we need to avoid for value objects, then that calls for never releasing the value objects. But wouldn’t that also be a problem for identity objects? In that case, WeakReferences seem like the wrong solution, and the cache should just hold direct references to everything.
