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

[Eamonn McManus]

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.