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.

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.

On line 1161 you could write valueMethod.invoke(a) instead of
valueMethod.invoke(a, new Object[0]).

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.

Éamonn


On 13 September 2012 08:46, Mandy Chung <mandy.chung at oracle.com> wrote:
>
> This is to eliminate the static dependency from JMX to
> java.beans.ConstructorProperties.  Similar work has been
> done in the past [1] and this fix will allow JMX to be used
> without the presence of java.beans.
>
> Webrev at:
>   http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198070/webrev.00/
>
> All tests in jdk_management1 and jdk_management2 passed.
>
> Mandy
> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ced99075109
>