From Alan.Bateman at oracle.com Thu Oct 8 12:15:45 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Oct 2015 13:15:45 +0100 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <5616585A.4060006@oracle.com> References: <5616585A.4060006@oracle.com> Message-ID: <56165E71.3030204@oracle.com> On 08/10/2015 12:49, 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 > I see this patch is against jigsaw/jake but I assume this will go into JDK 9 via jdk9/dev. No need for it to be pushed via the jake forest, right? 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). 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 updates to the javadoc mostly okay. In the paragraph on "For backward compatibility .." then it probably should make clear that this annotations works in exactly the same way as the javax.management.annotation.CS. The webrev makes it looks like the beans @CS has been renamed, is this a hg copy? I see this patch adds a package.html, any reason not to use package-info.java here? I assume LegacyConstructorPropertiesTest's header will be fixed up so that the copyright header is at the top. -Alan From jaroslav.bachorik at oracle.com Thu Oct 8 12:26:21 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 8 Oct 2015 14:26:21 +0200 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <56165E71.3030204@oracle.com> References: <5616585A.4060006@oracle.com> <56165E71.3030204@oracle.com> Message-ID: <561660ED.3050300@oracle.com> On 8.10.2015 14:15, Alan Bateman wrote: > > On 08/10/2015 12:49, 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 >> > I see this patch is against jigsaw/jake but I assume this will go into > JDK 9 via jdk9/dev. No need for it to be pushed via the jake forest, right? 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. > > 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? > > 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. > > The updates to the javadoc mostly okay. In the paragraph on "For > backward compatibility .." then it probably should make clear that this > annotations works in exactly the same way as the > javax.management.annotation.CS. Ok > > The webrev makes it looks like the beans @CS has been renamed, is this a > hg copy? Yep. > > I see this patch adds a package.html, any reason not to use > package-info.java here? Copy/paste :( > > I assume LegacyConstructorPropertiesTest's header will be fixed up so > that the copyright header is at the top. Yep, this one slipped through ... Thanks, -JB- > > -Alan From Alan.Bateman at oracle.com Thu Oct 8 12:41:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Oct 2015 13:41:41 +0100 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561660ED.3050300@oracle.com> References: <5616585A.4060006@oracle.com> <56165E71.3030204@oracle.com> <561660ED.3050300@oracle.com> Message-ID: <56166485.2090707@oracle.com> 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 From mandy.chung at oracle.com Thu Oct 8 20:44:35 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 08 Oct 2015 13:44:35 -0700 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <56166485.2090707@oracle.com> References: <5616585A.4060006@oracle.com> <56165E71.3030204@oracle.com> <561660ED.3050300@oracle.com> <56166485.2090707@oracle.com> Message-ID: <5616D5B3.40906@oracle.com> On 10/08/2015 05:41 AM, Alan Bateman wrote: >>> 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. I also think the warning is not necessary. It'd be interesting to find out how many MXBean and how many of them are annotated with j.b. at CP from Maven Central. I suspect not too many. Definitely we should document the recommendation in the release note and other documents like tutorial and guides. Mandy From Alan.Bateman at oracle.com Fri Oct 9 12:03:23 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Oct 2015 13:03:23 +0100 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <5617A814.5020204@gmail.com> References: <5616585A.4060006@oracle.com> <5617A814.5020204@gmail.com> Message-ID: <5617AD0B.2040302@oracle.com> On 09/10/2015 12: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? > > 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? > Using the method parameters has come up a few times in the context of JMX. Jaroslav is best to talk to that. But just to say that the issue here isn't specific to JDK 9+, it's also an issue with subset Profiles of Java SE 8 too. It's really just a mismatch between the compile-time and run-time environment, a mismatch that is sometimes hard to diagnose because the annotation is ignored when its type doesn't exist at run-time. -Alan. From jaroslav.bachorik at oracle.com Wed Oct 14 09:36:18 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 14 Oct 2015 11:36:18 +0200 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <5616585A.4060006@oracle.com> References: <5616585A.4060006@oracle.com> Message-ID: <561E2212.20809@oracle.com> On 8.10.2015 13:49, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-7199353 Round 2 webrev: http://cr.openjdk.java.net/~jbachorik/7199353/webrev.01 Changes against round 1: * @javax.management.ConstructorProperties (was @javax.management.annotation.ConstructorProperties) * diff is against the current jdk9 (eg. not the jigsaw repo) * removed warning when @j.b.ConstructorProperties is used * changed the wording in the reconstruction rules in @MXBean as recommended * changed the issue synopsis as recommended JDK JMX tests are still passing completely. Thanks, -JB- > 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- From daniel.fuchs at oracle.com Wed Oct 14 13:04:04 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Oct 2015 15:04:04 +0200 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561E2212.20809@oracle.com> References: <5616585A.4060006@oracle.com> <561E2212.20809@oracle.com> Message-ID: <561E52C4.7050009@oracle.com> Hi Jaroslav, This looks good to me. I wonder if @bug 7199353 should be added to some of the existing tests too, given that you modified them to use the new annotation. best regards, -- daniel On 14/10/15 11:36, Jaroslav Bachorik wrote: > On 8.10.2015 13:49, Jaroslav Bachorik wrote: >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-7199353 > > Round 2 webrev: http://cr.openjdk.java.net/~jbachorik/7199353/webrev.01 > > Changes against round 1: > > * @javax.management.ConstructorProperties (was > @javax.management.annotation.ConstructorProperties) > * diff is against the current jdk9 (eg. not the jigsaw repo) > * removed warning when @j.b.ConstructorProperties is used > * changed the wording in the reconstruction rules in @MXBean as recommended > * changed the issue synopsis as recommended > > JDK JMX tests are still passing completely. > > Thanks, > > -JB- From Alan.Bateman at oracle.com Wed Oct 14 13:24:25 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Oct 2015 14:24:25 +0100 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561E219F.9080800@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> Message-ID: <561E5789.2040805@oracle.com> On 14/10/2015 10:34, Jaroslav Bachorik wrote: > > Round 2 webrev: http://cr.openjdk.java.net/~jbachorik/7199353/webrev.01 > > Changes against round 1: > > * @javax.management.ConstructorProperties (was > @javax.management.annotation.ConstructorProperties) > * diff is against the current jdk9 (eg. not the jigsaw repo) > * removed warning when @j.b.ConstructorProperties is used > * changed the wording in the reconstruction rules in @MXBean as > recommended > * changed the issue synopsis as recommended > > JDK JMX tests are still passing completely. Good to see the new @CP in the right place. "When @java.beans.ConstructorProperties is used then rule 2 is not applicable to subset Profiles of Java SE that do not include the java.beans package." I think this needs to say that when @java.beans.ConstructorProperties is present, and @javax.management.ConstructorProperties is not present, then rule 2 is not applicable. I realize ConstructorProperties.java has been copied from the beans ConstructorProperties.java but I think a bit of clean-up is in order. L37 is mis-aligned, the example could use {@code ...}, the comment on the value method could be cleaned up. Also in the javadoc example then shouldn't the getXXX methods be public? One other thing that comes to mind is whether we need any updates to javadoc in the java.beans area. I could imagine someone in the IDE typing ConstructorProperties and accidentally selecting @javax.management.ConstructorProperties and getting confused. I'm mostly wondering if the there should be someone in the java.beans javadoc to make it clear that @javax.management.ConstructorProperties is ignored. -Alan. From jaroslav.bachorik at oracle.com Wed Oct 14 13:38:24 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 14 Oct 2015 15:38:24 +0200 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561E5789.2040805@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> Message-ID: <561E5AD0.7020505@oracle.com> On 14.10.2015 15:24, Alan Bateman wrote: > > > On 14/10/2015 10:34, Jaroslav Bachorik wrote: >> >> Round 2 webrev: http://cr.openjdk.java.net/~jbachorik/7199353/webrev.01 >> >> Changes against round 1: >> >> * @javax.management.ConstructorProperties (was >> @javax.management.annotation.ConstructorProperties) >> * diff is against the current jdk9 (eg. not the jigsaw repo) >> * removed warning when @j.b.ConstructorProperties is used >> * changed the wording in the reconstruction rules in @MXBean as >> recommended >> * changed the issue synopsis as recommended >> >> JDK JMX tests are still passing completely. > > Good to see the new @CP in the right place. > > "When @java.beans.ConstructorProperties is used then rule 2 is not > applicable to subset Profiles of Java SE that do not include the > java.beans package." > > I think this needs to say that when @java.beans.ConstructorProperties is > present, and @javax.management.ConstructorProperties is not present, > then rule 2 is not applicable. Eg. "When only @java.beans.ConstructorProperties is used then rule 2 is not applicable to subset Profiles of Java SE that do not include the java.beans package." ? > > I realize ConstructorProperties.java has been copied from the beans > ConstructorProperties.java but I think a bit of clean-up is in order. > L37 is mis-aligned, the example could use {@code ...}, the comment on > the value method could be cleaned up. > > Also in the javadoc example then shouldn't the getXXX methods be public? > > One other thing that comes to mind is whether we need any updates to > javadoc in the java.beans area. I could imagine someone in the IDE > typing ConstructorProperties and accidentally selecting > @javax.management.ConstructorProperties and getting confused. I'm mostly > wondering if the there should be someone in the java.beans javadoc to > make it clear that @javax.management.ConstructorProperties is ignored. Hm, shouldn't we name the new annotation differently then? @ConstructorMapping ? It is not mandatory that we keep the actual name - we are changing the package anyway ... -JB- > > -Alan. > From Alan.Bateman at oracle.com Wed Oct 14 14:25:01 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Oct 2015 15:25:01 +0100 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561E5AD0.7020505@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> <561E5AD0.7020505@oracle.com> Message-ID: <561E65BD.8020800@oracle.com> On 14/10/2015 14:38, Jaroslav Bachorik wrote: > > Eg. "When only @java.beans.ConstructorProperties is used then rule 2 > is not applicable to subset Profiles of Java SE that do not include > the java.beans package." ? Adding "only" will would work too. You might consider "is present" rather than "is used" as that seems to be prevailing terminology used with annotations (isAnnotationPresent etc.). > Hm, shouldn't we name the new annotation differently then? > @ConstructorMapping ? It is not mandatory that we keep the actual name > - we are changing the package anyway ... This may have been discussed previously, Mandy might know. I think at one point that jmx-dev was thinking about matching on any @CP property and that might have influenced the naming. -Alan From mandy.chung at oracle.com Wed Oct 14 14:52:16 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 14 Oct 2015 07:52:16 -0700 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561E65BD.8020800@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> <561E5AD0.7020505@oracle.com> <561E65BD.8020800@oracle.com> Message-ID: > On Oct 14, 2015, at 7:25 AM, Alan Bateman wrote: > >> Hm, shouldn't we name the new annotation differently then? @ConstructorMapping ? It is not mandatory that we keep the actual name - we are changing the package anyway ... > This may have been discussed previously, Mandy might know. I think at one point that jmx-dev was thinking about matching on any @CP property and that might have influenced the naming. I don?t recall any discussion on the name. The initial suggestion was to match any @CP. One benefit of keeping it @ConstructorProperties is for easy migration from java.beans to javax.management. I don?t have strong opinion if it should be a different name. Mandy From mandy.chung at oracle.com Wed Oct 14 15:06:38 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 14 Oct 2015 08:06:38 -0700 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561E2212.20809@oracle.com> References: <5616585A.4060006@oracle.com> <561E2212.20809@oracle.com> Message-ID: <82DC9C13-A80B-4CF9-A5BA-DA6A28682E21@oracle.com> > On Oct 14, 2015, at 2:36 AM, Jaroslav Bachorik wrote: > > On 8.10.2015 13:49, Jaroslav Bachorik wrote: >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-7199353 > > Round 2 webrev: http://cr.openjdk.java.net/~jbachorik/7199353/webrev.01 That looks good in general. javax/management/ConstructorProperties.java - formatting nits: line 37 - space missing before ?*? line 45-48 - public methods line 60 - missing closing ?}' line 62 - typo s/later/latter/ line 69-73 can you fix them to begin with ?*' Mandy From jaroslav.bachorik at oracle.com Wed Oct 14 15:11:12 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 14 Oct 2015 17:11:12 +0200 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> <561E5AD0.7020505@oracle.com> <561E65BD.8020800@oracle.com> Message-ID: <561E7090.4080006@oracle.com> On 14.10.2015 16:52, Mandy Chung wrote: > >> On Oct 14, 2015, at 7:25 AM, Alan Bateman wrote: >> >>> Hm, shouldn't we name the new annotation differently then? @ConstructorMapping ? It is not mandatory that we keep the actual name - we are changing the package anyway ... >> This may have been discussed previously, Mandy might know. I think at one point that jmx-dev was thinking about matching on any @CP property and that might have influenced the naming. > > I don?t recall any discussion on the name. The initial suggestion was to match any @CP. One benefit of keeping it @ConstructorProperties is for easy migration from java.beans to javax.management. > > I don?t have strong opinion if it should be a different name. Using a different name could prevent any confusion about @j.b.ConstructorProperties IMO, migration should be pretty straight forward with global replace even if we change the annotation name. -JB- > > Mandy > From jaroslav.bachorik at oracle.com Thu Oct 15 15:46:14 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 15 Oct 2015 17:46:14 +0200 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561E7090.4080006@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> <561E5AD0.7020505@oracle.com> <561E65BD.8020800@oracle.com> <561E7090.4080006@oracle.com> Message-ID: <561FCA46.5080709@oracle.com> On 14.10.2015 17:11, Jaroslav Bachorik wrote: > On 14.10.2015 16:52, Mandy Chung wrote: >> >>> On Oct 14, 2015, at 7:25 AM, Alan Bateman >>> wrote: >>> >>>> Hm, shouldn't we name the new annotation differently then? >>>> @ConstructorMapping ? It is not mandatory that we keep the actual >>>> name - we are changing the package anyway ... >>> This may have been discussed previously, Mandy might know. I think at >>> one point that jmx-dev was thinking about matching on any @CP >>> property and that might have influenced the naming. >> >> I don?t recall any discussion on the name. The initial suggestion was >> to match any @CP. One benefit of keeping it @ConstructorProperties >> is for easy migration from java.beans to javax.management. >> >> I don?t have strong opinion if it should be a different name. > > Using a different name could prevent any confusion about > @j.b.ConstructorProperties > > IMO, migration should be pretty straight forward with global replace > even if we change the annotation name. Any objections to changing the annotation name to @ConstructorMapping to make it better distinguishable from @java.beans.ConstructorProperties ? -JB- > > -JB- > >> >> Mandy >> > From jaroslav.bachorik at oracle.com Thu Oct 15 15:55:19 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 15 Oct 2015 17:55:19 +0200 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561E7090.4080006@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> <561E5AD0.7020505@oracle.com> <561E65BD.8020800@oracle.com> <561E7090.4080006@oracle.com> Message-ID: <561FCC67.5020901@oracle.com> On 14.10.2015 17:11, Jaroslav Bachorik wrote: > On 14.10.2015 16:52, Mandy Chung wrote: >> >>> On Oct 14, 2015, at 7:25 AM, Alan Bateman >>> wrote: >>> >>>> Hm, shouldn't we name the new annotation differently then? >>>> @ConstructorMapping ? It is not mandatory that we keep the actual >>>> name - we are changing the package anyway ... >>> This may have been discussed previously, Mandy might know. I think at >>> one point that jmx-dev was thinking about matching on any @CP >>> property and that might have influenced the naming. >> >> I don?t recall any discussion on the name. The initial suggestion was >> to match any @CP. One benefit of keeping it @ConstructorProperties >> is for easy migration from java.beans to javax.management. >> >> I don?t have strong opinion if it should be a different name. > > Using a different name could prevent any confusion about > @j.b.ConstructorProperties > > IMO, migration should be pretty straight forward with global replace > even if we change the annotation name. Any objections to changing the annotation name to @ConstructorMapping to make it better distinguishable from @java.beans.ConstructorProperties ? -JB- > > -JB- > >> >> Mandy >> > From Alan.Bateman at oracle.com Thu Oct 15 19:32:04 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Oct 2015 20:32:04 +0100 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561FCC67.5020901@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> <561E5AD0.7020505@oracle.com> <561E65BD.8020800@oracle.com> <561E7090.4080006@oracle.com> <561FCC67.5020901@oracle.com> Message-ID: <561FFF34.9060106@oracle.com> On 15/10/2015 16:55, Jaroslav Bachorik wrote: > > Any objections to changing the annotation name to @ConstructorMapping > to make it better distinguishable from > @java.beans.ConstructorProperties ? > Not from me. Do you mind updating the webrev so that we can see the updated javadoc? -Alan. From jaroslav.bachorik at oracle.com Fri Oct 16 05:02:09 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 16 Oct 2015 07:02:09 +0200 Subject: jmx-dev RFR 8139725: Backout escaped partial fix for JDK-7199353 Message-ID: <562084D1.7000909@oracle.com> Please, review this critical backout request Issue : https://bugs.openjdk.java.net/browse/JDK-8139725 Webrev: http://cr.openjdk.java.net/~jbachorik/8139725/webrev.00 By mistake a partial fix for JDK-7199353 has been pushed recently. It needs to be backed out ASAP. Thanks, -JB- From Alan.Bateman at oracle.com Fri Oct 16 05:13:07 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Oct 2015 06:13:07 +0100 Subject: jmx-dev RFR 8139725: Backout escaped partial fix for JDK-7199353 In-Reply-To: <562084D1.7000909@oracle.com> References: <562084D1.7000909@oracle.com> Message-ID: <56208763.40906@oracle.com> On 16/10/2015 06:02, Jaroslav Bachorik wrote: > Please, review this critical backout request > > Issue : https://bugs.openjdk.java.net/browse/JDK-8139725 > Webrev: http://cr.openjdk.java.net/~jbachorik/8139725/webrev.00 > > By mistake a partial fix for JDK-7199353 has been pushed recently. It > needs to be backed out ASAP. > Looks okay. -Alan From jaroslav.bachorik at oracle.com Fri Oct 16 05:27:47 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 16 Oct 2015 07:27:47 +0200 Subject: jmx-dev RFR 8139725: Backout escaped partial fix for JDK-7199353 In-Reply-To: <56208763.40906@oracle.com> References: <562084D1.7000909@oracle.com> <56208763.40906@oracle.com> Message-ID: <56208AD3.3030202@oracle.com> On 16.10.2015 07:13, Alan Bateman wrote: > On 16/10/2015 06:02, Jaroslav Bachorik wrote: >> Please, review this critical backout request >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8139725 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8139725/webrev.00 >> >> By mistake a partial fix for JDK-7199353 has been pushed recently. It >> needs to be backed out ASAP. >> > Looks okay. Thanks! Pushing ... -JB- > > -Alan From jaroslav.bachorik at oracle.com Fri Oct 16 12:04:11 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 16 Oct 2015 14:04:11 +0200 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <561FFF34.9060106@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> <561E5AD0.7020505@oracle.com> <561E65BD.8020800@oracle.com> <561E7090.4080006@oracle.com> <561FCC67.5020901@oracle.com> <561FFF34.9060106@oracle.com> Message-ID: <5620E7BB.1070000@oracle.com> On 15.10.2015 21:32, Alan Bateman wrote: > > On 15/10/2015 16:55, Jaroslav Bachorik wrote: >> >> Any objections to changing the annotation name to @ConstructorMapping >> to make it better distinguishable from >> @java.beans.ConstructorProperties ? >> > Not from me. Do you mind updating the webrev so that we can see the > updated javadoc? I have decided for @ConstructorParameters - it is rather close to the original @ConstructorProperties and corresponds to the annotation purpose. I tried to address all the comments gathered in this review. The updated webrev is http://cr.openjdk.java.net/~jbachorik/8139727/webrev.00 The issue number had to be changed due to unlucky escape of the fix in progress into the public repository (which was immediately backed out but the original issue was 'spent'). Though the issue title still contains "ConstructorProperties" - I will change it to "ConstructorParameters" as soon as we agree on this name. Thanks, -JB- > > -Alan. > From jaroslav.bachorik at oracle.com Mon Oct 19 11:37:10 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 19 Oct 2015 13:37:10 +0200 Subject: jmx-dev RFR 8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType Message-ID: <5624D5E6.1080107@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8139870 Webrev: http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00 sun.management.LazyCompositeData.isTypeMatched() method is used to compare two composite types with the backward compatibility in mind. The idea is that when we have two types (type1, type2) type1 is matched by type2 when and only when type2 contains all the items of type1 and their types are in turn matching the item types from type1, recursively. However, this method fails to account for ArrayType type and instead of calling isTypeMatched() recursively on the array type it performs plain Object.equals(). This will cause problems when one tries to safely evolve (only adding items) composite types referred through ArrayType items. The patch adds the missing functionality. In http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00/cleanup there is a followup webrev of code warnings cleanup for s.m.LazyComponentData. Thanks, -JB- From daniel.fuchs at oracle.com Mon Oct 19 12:40:31 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 19 Oct 2015 14:40:31 +0200 Subject: jmx-dev RFR 8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType In-Reply-To: <5624D5E6.1080107@oracle.com> References: <5624D5E6.1080107@oracle.com> Message-ID: <5624E4BF.70204@oracle.com> Hi Jaroslav, This - and the cleanup - look good to me, but it would be nicer if it was accompanied by a unit test :-) best regards, -- daniel On 19/10/15 13:37, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8139870 > Webrev: http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00 > > sun.management.LazyCompositeData.isTypeMatched() method is used to > compare two composite types with the backward compatibility in mind. The > idea is that when we have two types (type1, type2) type1 is matched by > type2 when and only when type2 contains all the items of type1 and their > types are in turn matching the item types from type1, recursively. > > However, this method fails to account for ArrayType type and instead of > calling isTypeMatched() recursively on the array type it performs plain > Object.equals(). This will cause problems when one tries to safely > evolve (only adding items) composite types referred through ArrayType > items. > > The patch adds the missing functionality. > > In http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00/cleanup there > is a followup webrev of code warnings cleanup for s.m.LazyComponentData. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Oct 19 13:36:27 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 19 Oct 2015 15:36:27 +0200 Subject: jmx-dev RFR 8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType In-Reply-To: <5624E4BF.70204@oracle.com> References: <5624D5E6.1080107@oracle.com> <5624E4BF.70204@oracle.com> Message-ID: <5624F1DB.5030301@oracle.com> On 19.10.2015 14:40, Daniel Fuchs wrote: > Hi Jaroslav, > > This - and the cleanup - look good to me, but it would > be nicer if it was accompanied by a unit test :-) This time with test - http://cr.openjdk.java.net/~jbachorik/8139870/webrev.01 Testing *only* the correctness of the newly introduced functionality (eg. the test fails on older JDKs and passes on the build with the fix in place). Providing full coverage for LazyCompositeData is probably out of the scope of this change. -JB- > > best regards, > > -- daniel > > On 19/10/15 13:37, Jaroslav Bachorik wrote: >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8139870 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00 >> >> sun.management.LazyCompositeData.isTypeMatched() method is used to >> compare two composite types with the backward compatibility in mind. The >> idea is that when we have two types (type1, type2) type1 is matched by >> type2 when and only when type2 contains all the items of type1 and their >> types are in turn matching the item types from type1, recursively. >> >> However, this method fails to account for ArrayType type and instead of >> calling isTypeMatched() recursively on the array type it performs plain >> Object.equals(). This will cause problems when one tries to safely >> evolve (only adding items) composite types referred through ArrayType >> items. >> >> The patch adds the missing functionality. >> >> In http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00/cleanup there >> is a followup webrev of code warnings cleanup for s.m.LazyComponentData. >> >> Thanks, >> >> -JB- > From daniel.fuchs at oracle.com Mon Oct 19 14:28:59 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 19 Oct 2015 16:28:59 +0200 Subject: jmx-dev RFR 8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType In-Reply-To: <5624F1DB.5030301@oracle.com> References: <5624D5E6.1080107@oracle.com> <5624E4BF.70204@oracle.com> <5624F1DB.5030301@oracle.com> Message-ID: <5624FE2B.3010905@oracle.com> On 19/10/15 15:36, Jaroslav Bachorik wrote: > On 19.10.2015 14:40, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> This - and the cleanup - look good to me, but it would >> be nicer if it was accompanied by a unit test :-) > > This time with test - > http://cr.openjdk.java.net/~jbachorik/8139870/webrev.01 Thanks for the test Jaroslav! > Testing *only* the correctness of the newly introduced functionality > (eg. the test fails on older JDKs and passes on the build with the fix > in place). Providing full coverage for LazyCompositeData is probably out > of the scope of this change. Yes, I agree. This is fine. BTW - did you verify that the JCK still passes? Otherwise you might need to challenge it... best regards, -- daniel > > -JB- > >> >> best regards, >> >> -- daniel >> >> On 19/10/15 13:37, Jaroslav Bachorik wrote: >>> Please, review the following change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8139870 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00 >>> >>> sun.management.LazyCompositeData.isTypeMatched() method is used to >>> compare two composite types with the backward compatibility in mind. The >>> idea is that when we have two types (type1, type2) type1 is matched by >>> type2 when and only when type2 contains all the items of type1 and their >>> types are in turn matching the item types from type1, recursively. >>> >>> However, this method fails to account for ArrayType type and instead of >>> calling isTypeMatched() recursively on the array type it performs plain >>> Object.equals(). This will cause problems when one tries to safely >>> evolve (only adding items) composite types referred through ArrayType >>> items. >>> >>> The patch adds the missing functionality. >>> >>> In http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00/cleanup there >>> is a followup webrev of code warnings cleanup for s.m.LazyComponentData. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Mon Oct 19 14:31:14 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 19 Oct 2015 16:31:14 +0200 Subject: jmx-dev RFR 8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType In-Reply-To: <5624FE2B.3010905@oracle.com> References: <5624D5E6.1080107@oracle.com> <5624E4BF.70204@oracle.com> <5624F1DB.5030301@oracle.com> <5624FE2B.3010905@oracle.com> Message-ID: <5624FEB2.4060506@oracle.com> On 19.10.2015 16:28, Daniel Fuchs wrote: > On 19/10/15 15:36, Jaroslav Bachorik wrote: >> On 19.10.2015 14:40, Daniel Fuchs wrote: >>> Hi Jaroslav, >>> >>> This - and the cleanup - look good to me, but it would >>> be nicer if it was accompanied by a unit test :-) >> >> This time with test - >> http://cr.openjdk.java.net/~jbachorik/8139870/webrev.01 > > Thanks for the test Jaroslav! > >> Testing *only* the correctness of the newly introduced functionality >> (eg. the test fails on older JDKs and passes on the build with the fix >> in place). Providing full coverage for LazyCompositeData is probably out >> of the scope of this change. > > Yes, I agree. This is fine. > BTW - did you verify that the JCK still passes? > Otherwise you might need to challenge it... Not yet. I really hope it will pass - otherwise it would mean that the incorrect behaviour has been baked in :/ -JB- > > best regards, > > -- daniel > >> >> -JB- >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 19/10/15 13:37, Jaroslav Bachorik wrote: >>>> Please, review the following change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8139870 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00 >>>> >>>> sun.management.LazyCompositeData.isTypeMatched() method is used to >>>> compare two composite types with the backward compatibility in mind. >>>> The >>>> idea is that when we have two types (type1, type2) type1 is matched by >>>> type2 when and only when type2 contains all the items of type1 and >>>> their >>>> types are in turn matching the item types from type1, recursively. >>>> >>>> However, this method fails to account for ArrayType type and instead of >>>> calling isTypeMatched() recursively on the array type it performs plain >>>> Object.equals(). This will cause problems when one tries to safely >>>> evolve (only adding items) composite types referred through ArrayType >>>> items. >>>> >>>> The patch adds the missing functionality. >>>> >>>> In http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00/cleanup >>>> there >>>> is a followup webrev of code warnings cleanup for >>>> s.m.LazyComponentData. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From Alan.Bateman at oracle.com Mon Oct 19 23:37:58 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Oct 2015 00:37:58 +0100 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <5620E7BB.1070000@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> <561E5AD0.7020505@oracle.com> <561E65BD.8020800@oracle.com> <561E7090.4080006@oracle.com> <561FCC67.5020901@oracle.com> <561FFF34.9060106@oracle.com> <5620E7BB.1070000@oracle.com> Message-ID: <56257ED6.70000@oracle.com> On 16/10/2015 13:04, Jaroslav Bachorik wrote: > : > > I have decided for @ConstructorParameters - it is rather close to the > original @ConstructorProperties and corresponds to the annotation > purpose. > > I tried to address all the comments gathered in this review. > The updated webrev is > http://cr.openjdk.java.net/~jbachorik/8139727/webrev.00 > > The issue number had to be changed due to unlucky escape of the fix in > progress into the public repository (which was immediately backed out > but the original issue was 'spent'). > > Though the issue title still contains "ConstructorProperties" - I will > change it to "ConstructorParameters" as soon as we agree on this name. The new proposed name works for me. I looked at the latest webrev, focused mostly on the javadoc changes to MXBean and the @CP and it looks good. -Alan From mandy.chung at oracle.com Mon Oct 19 23:55:05 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Oct 2015 16:55:05 -0700 Subject: jmx-dev RFR 7199353: Allow ConstructorProperties annotation from any package In-Reply-To: <5620E7BB.1070000@oracle.com> References: <5616585A.4060006@oracle.com> <561E219F.9080800@oracle.com> <561E5789.2040805@oracle.com> <561E5AD0.7020505@oracle.com> <561E65BD.8020800@oracle.com> <561E7090.4080006@oracle.com> <561FCC67.5020901@oracle.com> <561FFF34.9060106@oracle.com> <5620E7BB.1070000@oracle.com> Message-ID: > On Oct 16, 2015, at 5:04 AM, Jaroslav Bachorik wrote: > > On 15.10.2015 21:32, Alan Bateman wrote: >> >> On 15/10/2015 16:55, Jaroslav Bachorik wrote: >>> >>> Any objections to changing the annotation name to @ConstructorMapping >>> to make it better distinguishable from >>> @java.beans.ConstructorProperties ? >>> >> Not from me. Do you mind updating the webrev so that we can see the >> updated javadoc? > > I have decided for @ConstructorParameters - it is rather close to the original @ConstructorProperties and corresponds to the annotation purpose. > > I tried to address all the comments gathered in this review. > The updated webrev is http://cr.openjdk.java.net/~jbachorik/8139727/webrev.00 > I like the new name. The change looks good except minor things in ConstructorParameters.java 61 * and {@code @javax.management.annotation.ConstructorParameters} - package name needs mixup. 74 */ - formatting nit - need one more space > The issue number had to be changed due to unlucky escape of the fix in progress into the public repository (which was immediately backed out but the original issue was 'spent'). > > Though the issue title still contains "ConstructorProperties" - I will change it to "ConstructorParameters" as soon as we agree on this name. Thumbs up from me. Mandy From jaroslav.bachorik at oracle.com Tue Oct 20 08:00:36 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 20 Oct 2015 10:00:36 +0200 Subject: jmx-dev RFR 8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType In-Reply-To: <5624FEB2.4060506@oracle.com> References: <5624D5E6.1080107@oracle.com> <5624E4BF.70204@oracle.com> <5624F1DB.5030301@oracle.com> <5624FE2B.3010905@oracle.com> <5624FEB2.4060506@oracle.com> Message-ID: <5625F4A4.90601@oracle.com> On 19.10.2015 16:31, Jaroslav Bachorik wrote: > On 19.10.2015 16:28, Daniel Fuchs wrote: >> On 19/10/15 15:36, Jaroslav Bachorik wrote: >>> On 19.10.2015 14:40, Daniel Fuchs wrote: >>>> Hi Jaroslav, >>>> >>>> This - and the cleanup - look good to me, but it would >>>> be nicer if it was accompanied by a unit test :-) >>> >>> This time with test - >>> http://cr.openjdk.java.net/~jbachorik/8139870/webrev.01 >> >> Thanks for the test Jaroslav! >> >>> Testing *only* the correctness of the newly introduced functionality >>> (eg. the test fails on older JDKs and passes on the build with the fix >>> in place). Providing full coverage for LazyCompositeData is probably out >>> of the scope of this change. >> >> Yes, I agree. This is fine. >> BTW - did you verify that the JCK still passes? >> Otherwise you might need to challenge it... > > Not yet. I really hope it will pass - otherwise it would mean that the > incorrect behaviour has been baked in :/ Ran JCK, just to be sure. It did pass, as expected (I am changing the internal sun.management implementation and not a Java SE API, afterall). -JB- > > -JB- > >> >> best regards, >> >> -- daniel >> >>> >>> -JB- >>> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 19/10/15 13:37, Jaroslav Bachorik wrote: >>>>> Please, review the following change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8139870 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00 >>>>> >>>>> sun.management.LazyCompositeData.isTypeMatched() method is used to >>>>> compare two composite types with the backward compatibility in mind. >>>>> The >>>>> idea is that when we have two types (type1, type2) type1 is matched by >>>>> type2 when and only when type2 contains all the items of type1 and >>>>> their >>>>> types are in turn matching the item types from type1, recursively. >>>>> >>>>> However, this method fails to account for ArrayType type and >>>>> instead of >>>>> calling isTypeMatched() recursively on the array type it performs >>>>> plain >>>>> Object.equals(). This will cause problems when one tries to safely >>>>> evolve (only adding items) composite types referred through ArrayType >>>>> items. >>>>> >>>>> The patch adds the missing functionality. >>>>> >>>>> In http://cr.openjdk.java.net/~jbachorik/8139870/webrev.00/cleanup >>>>> there >>>>> is a followup webrev of code warnings cleanup for >>>>> s.m.LazyComponentData. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From daniel.fuchs at oracle.com Tue Oct 20 08:05:03 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 20 Oct 2015 10:05:03 +0200 Subject: jmx-dev RFR 8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType In-Reply-To: <5625F4A4.90601@oracle.com> References: <5624D5E6.1080107@oracle.com> <5624E4BF.70204@oracle.com> <5624F1DB.5030301@oracle.com> <5624FE2B.3010905@oracle.com> <5624FEB2.4060506@oracle.com> <5625F4A4.90601@oracle.com> Message-ID: <5625F5AF.5010002@oracle.com> On 10/20/15 10:00 AM, Jaroslav Bachorik wrote: > Ran JCK, just to be sure. It did pass, as expected (I am changing the > internal sun.management implementation and not a Java SE API, afterall). Thanks Jaroslav! Looks good to me then :-) -- daniel