On 10/09/2015 02:07 PM, Jaroslav Bachorik wrote:
On 9.10.2015 13:42, Peter Levart wrote:
Hi,

I don't think it has been mentioned before, but is
@ConstructorProperties still necessary in JDK8+ ? Couldn't the
j.l.r.Constructor#getParameters() be used instead?

This requires the class to be compiled with '-parameters' switch.

Is this too much to ask for in order for such compiled MXBean to be back-and-forth compatible? Couldn't -parameters be a default in JDK9 javac then?


To answer my question: "How is one supposed to compile an MXBean that
would work in JDK8- and at the same time in JDK9+ without java.desktop
in the module graph?"

Annotate the constructor with the both the @j.b.CP and the new @CP. In JDK 9 the new @CP will be picked and in JDK 8 the mapper will utilize @j.b.CP.

In that case, new @CP would have to be backported to JDK8u right?



The MXBean should be compiled by JDK8, it should annotate all public > 0
arg constructors with @java.beans.ConstructorProperties and make sure
those public constructor parameters have the same names as corresponding
bean properties.

If there's no java.desktop in the module graph,
@java.beans.ConstructorProperties are unretrievable and MXBean will use
the rules from #5 above.

Again, you must require the user to compile the class with "-parameters" flag. I am afraid this will lead to confusion when the reconstruction process would fail even though the parameters are named correctly in the source.

Unless -parameters was default in JDK9. Does it increase the .class size so much?

Would it be possible for javac to recognise a class is an MXBean and turn-on -parameters for such classes only by default? Too hacky?

Well, I could live with 8u backported new @CP annotation (doesn't have to backport the new specification, just the annotation?).

Regards, Peter


-JB-




What do you think?


Regards, Peter

On 10/08/2015 01:49 PM, Jaroslav Bachorik wrote:
Please, review the following change

Issue : https://bugs.openjdk.java.net/browse/JDK-7199353
Webrev: http://cr.openjdk.java.net/~jbachorik/7199353/webrev.00/top
http://cr.openjdk.java.net/~jbachorik/7199353/webrev.00/jdk

Issue description:
"MXBean currently supports model-specific types annotated with
java.beans.ConstructorProperties that is tightly coupled with
the client API. A MXBean developer will likely want to avoid
using java.beans.ConstructorProperties if it ends up in the
desktop module that their code doesn't want to pull in. In
that case, the code has to write to achieve the same effort
by defining the from(CompositeData) method."

This patch adds a new annotation
@javax.management.annotation.ConstructorProperties which can be used
in stead of @java.beans.ConstructorProperties. This will allow the
developers to use this convenience feature without introducing a bit
strange dependency on java.desktop.

For the backward compatibility purposes
@java.beans.ConstructorProperties annotation will still be recognized
by the JMX system but
a) A warning will be logged about using a deprecated way to specify
@ConstructorProperties
b) If there is also @javax.management.annotation.ConstructorProperties
annotation present on the same constructor then only this annotation
will be considered.

All the tests exercising the JMX related @ConstructorProperties
functionality have been updated to use
@javax.management.annotation.ConstructorProperties.

Since this change is affecting public APIs the relevant CCC request
has been filed and is in processing now.


Thanks,

-JB-



Reply via email to