RFR 7199353: Allow ConstructorProperties annotation from any package

[Alex Buckley]

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
> annotations:
>
> https://bugs.openjdk.java.net/browse/JDK-8044507
>
> 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.

Alex

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.