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.
