RFR 7199353: Allow ConstructorProperties annotation from any package

[Peter Levart]

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