RFR 7199353: Allow ConstructorProperties annotation from any package

[Alan Bateman]

On 08/10/2015 13:26, Jaroslav Bachorik wrote:
>
> The patch is adding a new exported package to java.management - so it 
> would have to be adjusted to the way jdk9 defines modules right now 
> (eg. modules.xml). And then do this again for jigsaw/jake
>
> I would, personally, prefer to do the change only once (in 
> jigsaw/jake) and then just let the change trickle back to jdk9/dev 
> once jigsaw is merged.
I think it's best for this change to go in via jdk9/dev. Only changes 
that are tied to the module system (like needing to use new reflective 
APIs) need to pushed directly to jake. Once your changes get to a 
promoted build then we'll sync up jake and update the module-info.java. 
This has worked well for us so far.


>
>>
>> That said, there is some wording in MXBean that will need adjustments
>> for modules.  Specifically the wording around subset Profiles of Java SE
>> will need to be modernized a bit to cover any Java SE run-time that
>> doesn't have the java.desktop module (or java.beans package).
>
> Should it be done in one change? I mean, it is not really related to 
> @CP changes. Probably a separate RFE for the docs update?
Yes, this has been done separately and this is an javadoc update that 
should go into jake.


>
>>
>> The approach and the new @CS trumping the old looks good. I'm not sure
>> that I agree with logging a warning when
>> java.beans.ConstructorProperties is used. I would be tempted to leave
>> that out.
>
> The idea is that we want users to stop using @j.b.CP for JMX purposes. 
> So we might as well warn them about the suboptimal solution they are 
> using. But I don't insist on the logging.
Ideally the warning would be at compile-time but it's not going to work 
here. I would be tempted to just drop this, others might have different 
opinions.

-Alan