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

[Eamonn McManus]

>> If at all possible, it would be better to split out
>> ConstructorProperties into a separable dependency so that JMX could
>> depend on just that. The idea that a profile with JMX but not
>> JavaBeans is almost but not quite exactly like a profile with both
>> seems rather user-hostile.
> The current jdk modularization is being done that way.  java.beans is
> split between the base module and the desktop module and
> ConstructorProperties is included in the base.  We're working on addressing
> the split package issue so that the platform can be modularized cleanly.
> That's the motivation for this bug fix.

I'm not sure I fully understand. Are there no other cases where
packages are split across modules? I'm wondering how important it is
to avoid this particular split since it seems to me to introduce a
subtle irregularity into JMX that could make things hard for users of
the API.

The cross-version scenarios you describe seem very unlikely since the
MXBean API and @ConstructorProperties were added to the JRE at the
same time.

I don't think it would help much to introduce a new
@javax.management.PropertyNames or whatever, because you would still
have to support existing code that uses @ConstructorProperties.

Éamonn


On 13 September 2012 14:45, Mandy Chung <mandy.chung at oracle.com> wrote:
>
> Hi Eamonn,
>
> Thanks for the review and the information.
>
>
> On 9/13/2012 9:48 AM, Eamonn McManus wrote:
>>
>> If at all possible, it would be better to split out
>> ConstructorProperties into a separable dependency so that JMX could
>> depend on just that. The idea that a profile with JMX but not
>> JavaBeans is almost but not quite exactly like a profile with both
>> seems rather user-hostile.
>
>
> The current jdk modularization is being done that way.  java.beans is
> split between the base module and the desktop module and
> ConstructorProperties is included in the base.  We're working on addressing
> the split package issue so that the platform can be modularized cleanly.
> That's the motivation for this bug fix.
>
>
>>
>> If it is not possible to make that separation then the method
>> CompositeBuilderViaConstructor.applicable should return immediately if
>> constructorPropertiesClass == null, with an explanation string like
>> "@ConstructorProperties annotation not available". That will produce a
>> better exception message than the "no constructor has
>> @ConstructorProperties annotation" that the code will produce as it
>> stands even if constructors do have that annotation.
>
>
> Good idea.  I have fixed that.
>
>> On line 1161 you could write valueMethod.invoke(a) instead of
>> valueMethod.invoke(a, new Object[0]).
>
>
> Fixed and the updated webrev is at:
>    http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198070/webrev.01/
>
>
>> We faced a similar problem in the past where standalone JMX might be
>> running on a Java version that did not have
>> java.beans.ConstructorProperties. At that time we considered
>> specifying that any @ConstructorProperties annotation, regardless of
>> what package it came from, would have the same effect. Since you are
>> accessing the annotation by reflection anyway it might be time to
>> resuscitate this idea. Then users could at least insulate themselves
>> from no-JavaBeans breakage by using their own definition of
>> @ConstructorProperties.
>
>
> I see two scenarios:
> 1. the application being instrumented is running on an older version of
> JRE
> 2. the jmx client accessing the model-specific types from a JVM being
> managed running 2 different versions of JRE
>
> This raises an interesting question - if @CP is part of the standalone JMX
> (e.g. javax.management.PropertyNames), would that issue exist?  Alan and I
> have asked ourselves if we need to bring back javax.management.PropertyNames
> but it wasn't clear to us.  Your feedback and any information/requirement
> info from the past relevant to this will be valuable.  I'll file a separate
> RFE for it once the requirement becomes clear that the jmx/serviceability
> team can follow up.
>
> I'd like to get the fix to eliminate the dependency into jdk8 separated
> from this RFE.
>
> Thanks
> Mandy