RFR 7199353: Allow ConstructorProperties annotation from any package
Alan.Bateman at oracle.com
Thu Oct 8 12:41:41 UTC 2015
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
More information about the jigsaw-dev