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

[Kumar Srinivasan]

Alan,

PropMap.java, Nit: typo PropertyChangeListern's similarly in the other.

Nice test, but since it is specific to pack200 and all pack200 tests
are in jdk/test/tools/pack200,  perhaps move it there ?

Besides that I could not find anything else wrong, the
users of these ProperyChangeListeners are the deployment
technologies, though.

Kumar




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