On Aug 17, 2026, at 3:04 PM, Kevin Rushforth <[email protected]> wrote:
That's an interesting question. And one I'll need to drill into when I get to the WebView Java <--> JS bridge implementation. Up until now, I've been assuming that we don't care much about whether value objects leak. For small objects like the boxed primitive classes, that seems a reasonable assumption (what does it mean to "leak" an integer?). However, if a user-defined value object (e.g., a simple value record) contains a large array of integers or a reference to a user-defined identity object, then I think we do care. Right. I think there are three kinds of value objects worth keeping in mind: - Small primitive data wrappers (the common case) - Wrappers around identity pointers (including large strings and arrays, totally reasonable in certain contexts) - Large identity-free trees of value objects (discouraged) Brian talked about holding onto the first category forever, while releasing the second category once the identity object is otherwise unreachable. That would probably be an acceptable outcome in practice, although it leaves the potential for significant memory leaks caused by the third category. But maybe the third category is a “shoot yourself in the foot” situation. On the other hand, if we take seriously the risk of memory leaks caused by value objects, I’m not sure there’s any acceptable solution: a value object that gets pinned forever can cause memory leaks, while a value object that can get released at any future moment, possibly even immediately, cannot be reliably cached—might as well just be left out completely.
