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

[Mandy Chung]

On 9/13/2012 2:59 PM, 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.
> 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.

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

So I probably misunderstand the use cases for allowing any 
@ConstructorProperties annotation, regardless of what package.   Can you 
elaborate on that?

Thanks
Mandy

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