java.beans package in java.desktop module

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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)
- <insert your library here>

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
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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)
> - <insert your library here>
>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: java.beans package in java.desktop module

Alan Bateman
In reply to this post by Guillaume Smet
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)
> - <insert your library here>
>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: java.beans package in java.desktop module

Guillaume Smet
Hi Alan,

On Tue, Mar 6, 2018 at 3:51 PM, Alan Bateman <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: java.beans package in java.desktop module

Guillaume Smet
In reply to this post by Stephen Colebourne
Hi Stephen,

On Tue, Mar 6, 2018 at 3:29 PM, Stephen Colebourne <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]>
> À: "Stephen Colebourne" <[hidden email]>
> Cc: "jigsaw-dev" <[hidden email]>
> 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 <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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" <[hidden email]>
>> À: "Stephen Colebourne" <[hidden email]>
>> Cc: "jigsaw-dev" <[hidden email]>
>> 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 <[hidden email]>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: java.beans package in java.desktop module

Remi Forax


----- Mail original -----
> De: "Stephen Colebourne" <[hidden email]>
> À: "jigsaw-dev" <[hidden email]>
> 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 <[hidden email]> 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" <[hidden email]>
>>> À: "Stephen Colebourne" <[hidden email]>
>>> Cc: "jigsaw-dev" <[hidden email]>
>>> 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 <[hidden email]>
>>> 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