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

[Mandy Chung]

Eamonn,

I filed a RFE that the serviceability team can follow up your suggestion:
    7199353: Allow ConstructorProperties annotation from any package

Alan - I modified the fix to throw InternalError instead of AssertionError.

Thanks for both of your review and I'll only list alanb in the 
Reviewed-by list
per Eamonn's request.

Thanks
Mandy

On 9/16/2012 7:07 PM, Eamonn McManus wrote:
> OK, well if you've managed to align modules on package boundaries
> everywhere else then congratulations, because that can't have been
> easy! Certainly a relatively minor feature like ConstructorProperties
> shouldn't be the only obstacle to completing that split. If we had
> known that this question would arise when we were defining
> ConstructorProperties I feel sure we would have put it somewhere else,
> perhaps a new package on its own like java.beans.annotations, or
> perhaps an existing package like javax.annotation (though I think the
> process for that one would have been very hard).
>
> I do feel that if, at the end of the exercise, it turns out that there
> is a nontrivial number of other split packages then
> ConstructorProperties should be put back the way it was. And,
> regardless, a JMX spec change allowing ConstructorProperties
> annotations from any package, as I suggested earlier, would clarify
> the situation for users. As it is, they are likely to want to avoid
> ConstructorProperties just in case their code might end up on a
> profile that doesn't include it. That would be unfortunate, because
> the code one has to write to achieve the same effect by defining
> from(CompositeData) is nasty.
>
> (Although I have reviewed this change, I would rather not be mentioned
> in the Reviewed-by field.)
>
> Éamonn
>
>
> On 14 September 2012 06:46, Alan Bateman<Alan.Bateman at oracle.com>  wrote:
>> 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.