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

(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

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?


Reply via email to