8004874: (profiles) Reduce dependency on java.beans to only add/removePropertyChangeListener

Alan Bateman Alan.Bateman at oracle.com
Tue Dec 11 19:55:57 UTC 2012


Those tracking the work to get us to a modular JDK will know that the 
java.beans package is highly problematic.

For the "core" modules then  j.u.l.LogManager and j.u.jar.Pack200 have 
support for PropertyChangeListener and that means edges in the module 
graph that are highly undesirable. As I've mentioned in other mails 
here, the plan to address this is to deprecate the 
add/removePropertyChangeListener methods defined by these classes in JDK 
8 and remove them outright in JDK 9.

In the mean-time we have Compact Profiles coming in JDK 8 so we need a 
solution that allows the java.util.logging and java.util.jar packages be 
included in the profiles without java.beans. As we are only talking 
about 6 methods in non-mainstream areas then the proposal is that these 
methods are not present in the subset Profiles of Java SE. This may be a 
surprise but it avoids a long of list of complications that would 
otherwise arise if there are references to types that do not exist. In 
implementation terms they will be removed in the build of the profiles, 
that's a minor detail.

The changes proposed are just minor updates to LogManager and the 
Pack200.Packer and Pack200.Unpacker implementations so that the only 
dependencies on PropertyChangeListener and PropertyChangeEvent are in 
the addPropertyChangeListener and removePropertyChangeListener methods. 
Once they get to the profiles forest then we can put changes in to 
remove these methods (and maybe GC the constant pool too).

One other thing to point out is that Packer and Unpacker are interfaces 
and so removing methods means that implementations that compile against 
the subset will not compile when the add/removePropertyChangeListener 
methods are present.  As it should be very rare to implement Packer and 
Unpacker then it's probably not a big deal but we can use default 
methods to eliminate the concern so that implementations that compile 
against compact1 (for example) will also compile on the full platform.

The webrev with the changes is here. Note that only changes to 
LogManager and pack200's PropMap are proposed to be included for now, 
changing the methods to default methods will come later along with 
javadoc updates, perhaps via the profiles forest. One other thing is 
that the Beans supporting class is duplicated between the two, this is 
mostly to avoid it getting used more widely. It will of course be 
removed once these methods are removed from the full platform, as per 
the original plan.

http://cr.openjdk.java.net/~alanb/8004874/webrev/

Thanks,

Alan.



More information about the core-libs-dev mailing list