Re: java.beans package in java.desktop module

[Remi Forax]

- 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

Re: java.beans package in java.desktop module

[Stephen Colebourne]

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

Re: java.beans package in java.desktop module

[Remi Forax]

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

Re: java.beans package in java.desktop module

[Guillaume Smet]

Hi Stephen,

On Tue, Mar 6, 2018 at 3:29 PM, Stephen Colebourne 
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

Re: java.beans package in java.desktop module

[Guillaume Smet]

Hi Alan,

On Tue, Mar 6, 2018 at 3:51 PM, Alan Bateman 
wrote:

> There aren't any concrete proposals on the table at this time but it is
> something that will need to be looked at again.
>

OK. That's what I suspected, unfortunately.

I think we will probably be able to get rid of our Introspector usage at
some point but the javax.el case is definitely something that's bugging me.


> I'm curious why you are bringing it up. Are you looking to deploy on a
> run-time image that doesn't have the java.desktop module?
>

Well, I'm not looking at anything right now. We just wanted to not have our
Hibernate libraries (in this case Hibernate ORM via Introspector and
Hibernate Validator via javax.el) tied up to the java.desktop module so
that our users could try to deploy them on a runtime image that doesn't
have this very module.

Getting rid of the java.desktop module is IMHO one of the nice thing of the
new modular system.

-- 
Guillaume

Re: java.beans package in java.desktop module

[Alan Bateman]

On 06/03/2018 13:52, Guillaume Smet wrote:

Hi,

(Previously sent via an unsubscribed email address, sorry about that)

The java.beans package is part of the java.desktop module which is a bit
unfortunate as the package contains quite a few classes useful to
manipulate beans and dragging all the desktop classes with them is far from
ideal.

Typically, we have:
- javax.el which uses java.beans.FeatureDescriptor (javax.el is the
standard EL implementation used by Bean Validation)
- Hibernate ORM which uses java.beans.Introspector (and thus BeanInfo and
so on)
- 

Is there a plan to get java.beans out of java.desktop? Or should we avoid
its usage?

In our case, we can deal with the Hibernate ORM part but, for javax.el, it
might be a bit more complicated as FeatureDescriptor is unfortunately
included in specified APIs.

The java.beans package is in the desktop module because it contains 
several APIs that tie it to AWT and other areas of java.desktop 
(Beans.getIcon for example). The mistake 20 years ago was to put design 
time APIs for beans in the same package as the APIs to use them at 
run-time. Countless hours went into previous releases looking into 
options but all routes involve pain and incompatible changes. The 
deprecation of the applet API (JEP 289) helps a little bit as it opens 
the potential for the APIs tied to applets (Beans.instaniate for 
example) to be removed but the substantive issue remains.


There aren't any concrete proposals on the table at this time but it is 
something that will need to be looked at again.


I'm curious why you are bringing it up. Are you looking to deploy on a 
run-time image that doesn't have the java.desktop module?


-Alan.

Re: java.beans package in java.desktop module

[Stephen Colebourne]

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.

Stephen


On 6 March 2018 at 13:52, Guillaume Smet  wrote:
> The java.beans package is part of the java.desktop module which is a bit
> unfortunate as the package contains quite a few classes useful to
> manipulate beans and dragging all the desktop classes with them is far from
> ideal.
>
> Typically, we have:
> - javax.el which uses java.beans.FeatureDescriptor (javax.el is the
> standard EL implementation used by Bean Validation)
> - Hibernate ORM which uses java.beans.Introspector (and thus BeanInfo and
> so on)
> - 
>
> Is there a plan to get java.beans out of java.desktop? Or should we avoid
> its usage?
>
> In our case, we can deal with the Hibernate ORM part but, for javax.el, it
> might be a bit more complicated as FeatureDescriptor is unfortunately
> included in specified APIs.
>
> Thanks for the feedback.

java.beans package in java.desktop module

[Guillaume Smet]

Hi,

(Previously sent via an unsubscribed email address, sorry about that)

The java.beans package is part of the java.desktop module which is a bit
unfortunate as the package contains quite a few classes useful to
manipulate beans and dragging all the desktop classes with them is far from
ideal.

Typically, we have:
- javax.el which uses java.beans.FeatureDescriptor (javax.el is the
standard EL implementation used by Bean Validation)
- Hibernate ORM which uses java.beans.Introspector (and thus BeanInfo and
so on)
- 

Is there a plan to get java.beans out of java.desktop? Or should we avoid
its usage?

In our case, we can deal with the Hibernate ORM part but, for javax.el, it
might be a bit more complicated as FeatureDescriptor is unfortunately
included in specified APIs.

Thanks for the feedback.

--
Guillaume