----- Mail original ----- > De: "Stephen Colebourne" <scolebou...@joda.org> > À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Mercredi 7 Mars 2018 13:23:10 > Objet: Re: java.beans package in java.desktop module
> 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. you can bind [1] (do partial evaluation of) Map::get with the property name, > But there is no reason why the implementation of the interface for records > could not use > method handles internally. apart if valhalla generics are around, such interface will require to box and unbox values. > > Stephen Rémi > > > 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
