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)
> - <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.