RFR 7199353: Allow ConstructorProperties annotation from any package

[Jaroslav Bachorik]

On 8.10.2015 21:29, Alex Buckley wrote:
> 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.

Well, if anything the @CP annotation is related to 
javax.management.openmbean package. All the OpenType and CompositeData 
definitions are in this package. @CP annotation is used to influence the 
way a CompositeData instance is reconstructed into an instance of the 
mapped custom type.

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

One of the new annotations is @ManagedService which should, in fact, be 
@MXBean. But couldn't really be used because of the compatibility 
implications with the current semantics of @MXBean.

My biggest concern is that javax.management already is a big dump of not 
tightly related classes:
* MBean metadata
* MBeanServer APIs
* Notifications
* Helper MBean implementations (StandardMBean)
* Query Expression API
* Meta-meta data (Descriptor and gang)

I know we can't really do anything about this since all the classes are 
a part of Java SE spec (but beats me how they did get there). But I 
would prefer not to increase the entropy, if at all possible.

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

java.lang.annotation seems to be mostly concerned with the annotations 
(and support classes) for defining other annotations. Except of @Native 
- which can be used to mark an arbitrary field, much like eg. 
@Deprecated which is in java.lang package.

I really can't say I can spot any system in deciding which package an 
annotation should belong to.

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

Thanks! I've updated the JEP. Unfortunately, it will have to wait for 
JDK 10.

-JB-