On 9.10.2015 14:21, Peter Levart wrote:
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?
I'm always cautious when the and user must perform some extra activities
in order to use the public API.
I'm afraid that the decision about "-parameters" being a default flag is
for someone else to make, not me.
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?
Nope. As Alan pointed out an annotation with an unrecognized type is
simply ignored. And this would work fine for this purpose - in JDK 8 the
new @CP will be ignored while @j.b.CP will be used to identify the
constructor for reconstruction.
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?
Definitely :) Hacky as heck :)
Well, I could live with 8u backported new @CP annotation (doesn't have
to backport the new specification, just the annotation?).
Can't backport just the annotation - it is in the Java SE public API area :/
Fortunately, it is not necessary to backport it as I wrote before.
Cheers,
-JB-
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-
