On Fri, 19 Dec 2025 20:56:27 GMT, Michael Strauß <[email protected]> wrote:
> Implementation of [enhanced property > metadata](https://gist.github.com/mstr2/2fec0303fc440b8eaeb126befc76eb5c). > > ### New API > This PR includes the following API additions: > > 1. `ReadOnlyProperty.getDeclaringClass()` and its default implementation. > 2. The `javafx.beans.property.AttachedProperty` interface. > 3. New constructors for all `Simple<*>Property` and `ReadOnly<*>Wrapper` > classes, accepting the declaring class of the property. > > The declaring class is stored in a new field in the `Simple<*>Property` > classes. If a legacy constructor is used that doesn't specify the declaring > class, the `ReadOnlyProperty.getDeclaringClass()` default implementation is > called the first time the `Simple<*>Property.getDeclaringClass()` method is > called, and its result is stored for future retrieval. > > ### Testing > For testing, this PR also includes the > `test.util.property.PropertyMetadataVerifier` tool. It systematically tests > all public and protected properties of a class, and ensures conformance to > the following rules: > * `ReadOnlyProperty.getBean()` returns the object instance of the enclosing > class, or the target object instance if the property is an attached property. > * `ReadOnlyProperty.getName()` returns the name of the property, which must > correspond to the name of the property getter (excluding the word "Property"). > * `ReadOnlyProperty.getDeclaringClass()` returns the enclosing class of the > property getter. > * The declaring class of a `Simple<*>Property` or `ReadOnly<*>Wrapper` must > be specified in the constructor, not resolved at runtime. > * `getBean()`, `getName()`, and `getDeclaringClass()` must not be overridden > in subclasses of `Simple<*>Property` or `ReadOnly<*>Wrapper`. > * An instance property does not implement `AttachedProperty`. > * An instance property has a parameterless property getter. > * An attached property implements `AttachedProperty`. > * An attached property has a static single-argument property getter that > accepts the target object. > * `AttachedProperty.getTargetClass()` returns the class of the single > parameter of the static property getter. > * A property getter does not return an instance of `ReadOnly<*>Wrapper`, it > returns the result of calling `ReadOnly<*>Wrapper.getReadOnlyProperty()`. > > Many properties in existing JavaFX classes violate the > `PropertyMetadataVerifier` rules in some way or shape. This PR won't address > these issues, this will be done in a future cleanup PR. 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? ------------- PR Comment: https://git.openjdk.org/jfx/pull/2015#issuecomment-3775039635
