RFR 7199353: Allow ConstructorProperties annotation from any package
alex.buckley at oracle.com
Thu Oct 8 19:29:48 UTC 2015
On 10/8/2015 11:56 AM, Alan Bateman wrote:
> On 08/10/2015 19:41, Alex Buckley wrote:
>> Also, this annotation type introduces a new package,
>> javax.management.annotation. I support *.annotation packages in
>> general (e.g. to group a growing number of exciting annotation types
>> related to HotSpot) but JMX is a mature technology which in the past
>> decade has only introduced two annotation types, one of which is
>> MXBean itself. I recommend placing ConstructorProperties alongside
>> MXBean in the existing javax.management package.
> Jaroslav has a draft JEP that proposed to introduce a bunch of new
> so the move into javax.management.annotation is in anticipation that it
> @CP won't be alone.
I had a feeling that claiming JMX is mature, and hence is "done" with
annotation types, would come back to bite me :-)
Still, the new ConstructorProperties annotation type has a tight
relationship with the existing MXBean annotation type. Annotations of
both types play the same role in expressing certain facts explicitly
(MXBean-ness, reconstructible items) rather than letting those facts be
expressed implicitly through idiomatic naming of interfaces, classes,
and methods. I think the longstanding nature of this tight relationship
justifies ConstructorProperties being in the same package.
The six new annotation types for MBean registration are plainly a
cohesive set that supports higher level functionality than
MXBean+ConstructorProperties. I agree a new javax.management.annotation
package makes sense for them.
A similar separation of annotation types can be found in java.lang and
java.lang.annotation. I don't want to spend time here detailing that
separation, but suffice to say that different kinds of functionality
justifies different packages.
P.S. JDK-8044507 mentions a javax.management.annotations package -- the
standard is no 's'. Also, an example uses @NotificationSupport which a)
should be @NotificationInfos and b) is unnecessary in the example
because NotificationInfo should be a repeatable annotation type with
NotificationInfos as its containing annotation type.
More information about the jigsaw-dev