What is needed is an abstraction that can work for all sorts of
- classic JavaBeans
- value types
- JSON objects
Its not rocket science as an API, but has been needed for many years
as so many projects have this code duplicated (leading to lots of
The API cannot be based on method handles, as in the HashMap case
there is no property-specific method to call. But there is no reason
why the implementation of the interface for records could not use
method handles internally.
On 7 March 2018 at 11:21, Remi Forax <fo...@univ-mlv.fr> wrote:
> As Stephen said, with the introduction of the Pattern Matching in the near
> future, an API to extract the values from an object (the de-constructor API)
> or at least from a record object will have to be created, but it may be based
> on method handles, so perhaps not using a direct interface.
> ----- Mail original -----
>> De: "Guillaume Smet" <guilla...@hibernate.org>
>> À: "Stephen Colebourne" <scolebou...@joda.org>
>> Cc: "jigsaw-dev" <email@example.com>
>> Envoyé: Mardi 6 Mars 2018 18:45:21
>> Objet: Re: java.beans package in java.desktop module
>> Hi Stephen,
>> On Tue, Mar 6, 2018 at 3:29 PM, Stephen Colebourne <scolebou...@joda.org>
>>> It had been my hope that we might see a replacement for the java.beans
>>> package. I drew up a rough prototype here:
>>> based on previous work in Joda-Beans. More info here:
>>> If an interface-based design were adopted, it could be implemented by
>>> the existing JavaBeans code and also by future language changes such
>>> as records (data classes), while the API could be used far more
>>> broadly, such as in Hibernate or EL.
>>> Sadly, I haven't had the time or energy to progress this, but the need is
>> Thanks for sharing. It indeed sound like something worth pursuing.
>> Having a new API in the JDK indeed seems the only way out for the
>> java.beans issue.