RFR: 8375588: Enhanced property metadata

[Michael Strauß]

On Tue, 20 Jan 2026 19:58:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Not going away - possibly. But it does not change the fact that these properties are stored in the wrong place. Adding some sort of band-aid code to help with some use cases seems a bit wrong to me. It does not mean that we don't have the actual problem.

I would say that they are stored exactly where they belong, in the object which which they are associated. From an implementation standpoint, I agree with you that they are stored in the wrong place, namely in the `Node.getProperties()` map, which is user-accessible. An attached property should not disappear because user code calls `Node.getProperties().clear()`, the storage for these properties should be opaque. This is a defect that I plan to address in a future enhancement.

> 
> Perhaps you could describe a couple of use cases where the new API would shine,

I already did:

>> For example, you could decorate arbitrary model objects with context-specific state: an entity could be "valid" as it relates to a specific validator or rule, it could be "selected" in a specific context, or it could carry metadata (constraints, tags, flags) that is only meaningful for a particular framework.

As far as layout constraints go, they are _not_ associated with the container. It doesn't make sense so say that the row index is a property of the grid; it's a property of an object within the grid. Similarly, it doesn't make sense to say that `HeaderBar.prefButtonHeight` is a property of the header bar; it's a property of the stage that is only relevant in relation to the header bar.

> use cases where it is impossible to achieve the goal using the existing APIs.

Demonstrating impossibility is an unreasonable demand.

In general, formalizing attached properties adds nothing conceptually, it merely straightens out rough edges of what's already there and gives a name to convention.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3774971872