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
