Alan,
Looks good to me. Duplicating the Beans supporting class is fine as
they will be removed when the deprecated addPropertyChangeListener and
removePropertyChangeListener methods are removed in a future release.
Mandy
On 12/11/12 11:55 AM, Alan Bateman wrote:
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.
