Feedback for records: Accessors name() vs. getName()
info at j-kuhn.de
Wed Aug 5 15:08:26 UTC 2020
On 05-Aug-20 15:41, Brian Goetz wrote:
>> 1. java.beans.Introspector not recognizing accessors
> This one was raised on this list before; there's no reason
> Introspector can't learn about records -- all the reflective machinery
> is there to do so. Someone at one point offered to contribute this
> change, but so far I haven't seen it. We would be happy to take back
> such a patch.
While I was not the one who did propose such a thing, I just implemented
It is based on Java 14 and used via --patch-module. (My IDE somewhat
supports developing with --patch-module, so this was the easy path.)
It was easier than anticipated. But before discussing that, I want to
address the elephant in the room:
**Records are not JavaBeans**.
The JavaBeans spec requires that a bean has a public no-args constructor.
After creating the object, it's state is then set using the various setters.
Records on the other hand are immutable - their contents need to be
known at creation. (duh)
While that patch exposes the record components as properties, it can not
be used to gain compatibility w.r.t. creation or modification.
And before I put more work into that (porting it to tip, writing tests,
get rid of spaces vs tabs...), I want to be sure that this kind of risk
About the patch:
For Introspector it needs to be in the JDK itself - if it should work
for all records.
The Introspector has a search path to find additonal BeanInfo for a
Adding a RecordBeanInfo to the default search path is not a working
approach as the record class is not passed to the BeanInfo.
Therefore I had decided to add that hook in the BeanInfoFinder class.
Conceptually, it looks like there is an explicit BeanInfo for every
record class on the default BeanInfo search path.
More information about the amber-dev