Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties

[Alan Bateman]

On 14/09/2012 06:25, Mandy Chung wrote:
>
> :
>> I'm not sure I fully understand. Are there no other cases where
>> packages are split across modules?
>
> Our goal is to remove all split packages.
Yes, as Mandy said, we want to keep things as clean as possible and that 
means aligning the modules on package boundaries. So far this has worked 
out quite well in our prototyping to date. By far the most problematic 
area in the Java SE APIs java.beans, it's just too tied into Applets, 
AWT, Swing, even XML. It's unfortunate that JMX uses it, particularly 
for use-cases such as small environments where one should be able 
install a "management" module to be able to remotely monitor or manage 
applications on the device. If JMX requires JavaBeans then it means 
needing to install a lot of things that might not make sense in that 
environment.

At this point I think our only remaining hard dependency on JavaBeans 
from JMX is the ConstructorProperties annotation, you might remember we 
put in a helper to identify getter methods when the beans Introspector 
is not available. For the JMX Remote API then I think specification 
changes will eventually be required to allow the RMI-IIOP transport be 
optional (this is something you will probably have an opinion on). This 
is another cases where we have a split-package issue, this time due to 
the CORBA stub/tie classes that are in javax.management.remote.rmi 
(something that the IDL Mapping specification requires if I remember 
correctly).

My main observation on ConstructorProperties is that any code that uses 
it will require the module containing ConstructorProperties to be 
present when compiling that code. If the module declaration is setup so 
that the module containing the annotation type is required to be present 
at runtime then I think we are okay and Mandy's changes amount to a 
no-op. If the application is not using the annotation then it doesn't 
matter if ConstructorProperties is present or not and I think the 
proposed changes are benign. So my view is that the onus on anyone using 
ConstructorProperties needs to ensure that they have their module 
declaration right, otherwise their code will not compile or run.

Mandy - I've looked at webrev.01 and the changes look okay to me. The 
only thing is that the value method may throw a RuntimeException or 
Error and it would be good to propagate those rather than throwing an 
AssertionError.

-Alan.