RFR 7199353: Allow ConstructorProperties annotation from any package

[Jaroslav Bachorik]

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