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

[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

Post by Guillaume Smet
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.
- 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 Smet]

Hi Stephen,

Post by Stephen Colebourne
It had been my hope that we might see a replacement for the java.beans
https://github.com/jodastephen/property-alliance
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.

[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 -----

Envoyé: Mardi 6 Mars 2018 18:45:21
Objet: Re: java.beans package in java.desktop module
Hi Stephen,

Post by Stephen Colebourne
It had been my hope that we might see a replacement for the java.beans
https://github.com/jodastephen/property-alliance
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

[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

Post by 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 -----

Envoyé: Mardi 6 Mars 2018 18:45:21
Objet: Re: java.beans package in java.desktop module
Hi Stephen,

Post by Stephen Colebourne
It had been my hope that we might see a replacement for the java.beans
https://github.com/jodastephen/property-alliance
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

[Remi Forax]

----- Mail original -----

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

Post by 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 -----

Envoyé: Mardi 6 Mars 2018 18:45:21
Objet: Re: java.beans package in java.desktop module
Hi Stephen,

Post by Stephen Colebourne
It had been my hope that we might see a replacement for the java.beans
https://github.com/jodastephen/property-alliance
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

[Alan Bateman]

Post by 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.
- 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.

[Guillaume Smet]

Hi Alan,

Post by Alan Bateman
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.

Post by Alan Bateman
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.