RFR: 8375588: Enhanced property metadata

[Michael Strauß]

On Tue, 20 Jan 2026 22:02:07 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Thank you for clarifications!  
>> 
>> I also suspect I did not get my point across about storing the layout properties in the node vs. the layout container.  What happens when the code moves the node with these properties to another similar container?  Whose responsibility it is to clear the unrelated properties and why is this needed in the first place?  If the property (grid index, growth priority) makes no sense outside of the particular container, why is it stored in the node as opposed to let's say a hashtable within the layout container?  This makes no sense to me, but okay, it's grandfathered like any other weird thing in FX.  But why add more weird code on top of weird code?
>> 
>> So I am not convinced: the use case you mentioned is just too abstract, and nothing tells me that it can't be implemented using existing APIs.  What is the problem you are trying to solve, apart from some unnamed "tools"?  These tools can simply query the `Node.getProperties()` for these properties, given the keys are Strings, can't they?
>
>> Thank you for clarifications!
>> 
>> I also suspect I did not get my point across about storing the layout properties in the node vs. the layout container. What happens when the code moves the node with these properties to another similar container?
> 
> Nothing happens, just like for the past 15 years.  The properties can live on there, until they're needed again when the node becomes part of a layout container.
> 
>> Whose responsibility it is to clear the unrelated properties and why is this needed in the first place? 
> 
> This falls on the user, as they're the ones setting these properties, if they care (they don't stack up, there is a fixed number of them) and leaving them alone doesn't break anything.  So, there is no need to clean them at all.  It's exceedingly rare that a Node is re-used in such a way that this would matter (ie. moving a Node from a HBox to a GridPane, instead of what usually happens, which is just to recreate the Node).
> 
>> If the property (grid index, growth priority) makes no sense outside of the particular container, why is it stored in the node as opposed to let's say a hashtable within the layout container? This makes no sense to me, but okay, it's grandfathered like any other weird thing in FX. But why add more weird code on top of weird code?
> 
> Using a hash table actually makes this worse. Reparenting or temporarily removing a node would mean you also have to move or reconstruct its constraints, or lose them entirely. With attached properties, the metadata naturally travels with the node. In practice this case is rare anyway, so it shouldn’t carry much weight in the design discussion.
> 
> Swing’s choices predate modern UI frameworks, and its designers were involved in creating JavaFX, so they clearly understood the trade-offs. Since then, almost all modern UI frameworks have converged on the attached-property style, including modern web layout via CSS.
> 
> FX already follows this model, which is great as it was conceived over 15 years ago. What’s weird is not that layout metadata lives on the node, but that it’s exposed only through static setters instead of real, styleable, observable properties. Continuing this design would remove some of the weirdness, not add to it.  It would also allow these properties to integrate cleanly with the CSS engine, opening up an entirely new way of controlling layout, where there exists a huge gap now.

> Thank you @hjohn this example makes sense.
> 
> So, if I understand it correctly, the proposal is to add two-tiered styleable properties? Are there limitations as to which attached property is legal for which node, or any attached property (including custom) can be attached to any node?

There can be limitations. For example, `HeaderBar.prefButtonHeight` can only be attached to `Stage`, while layout constraints can only be attached to `Node`. The restriction is indicated by the target parameter of the static accessor, for example:

class HBox {
    public static void setMargin(Node node, Insets value);
}


This proposal formalizes a target-type restriction with the `AttachedProperty` interface:

interface AttachedProperty {
    Class<?> getTargetClass();
}


If you're given a property instance, this allows you to then query the class of objects for which it can be set.

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

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