What is needed is an abstraction that can work for all sorts of data-like classes
- classic JavaBeans - records - value types - HashMaps - JSON objects - etc 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 subtle differences). 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. Stephen 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. > > Rémi > > ----- Mail original ----- >> De: "Guillaume Smet" <guilla...@hibernate.org> >> À: "Stephen Colebourne" <scolebou...@joda.org> >> Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> >> 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> >> wrote: >> >>> It had been my hope that we might see a replacement for the java.beans >>> package. I drew up a rough prototype here: >>> https://github.com/jodastephen/property-alliance >>> based on previous work in Joda-Beans. More info here: >>> http://jodastephen.github.io/property-alliance/ >>> >>> 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 >>> there. >> >> >> 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. >> >> -- >> Guillaume
