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
