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-
