Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Alan Bateman]

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

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Jaroslav Bachorik]

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

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Alan Bateman]

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.

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Jaroslav Bachorik]

On 9.10.2015 17:36, Peter Levart wrote:



On 10/09/2015 02:30 PM, Jaroslav Bachorik wrote:

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.



Sorry, but I must be missing something.

When you compile a class (not an MXBean as Daniel pointed out, but a
data object class) with JDK9, it can't be used on JDK8 because of class
file version.

When you compile a class with JDK8, it can't contain new @CS annotation,
because it is not part of the official Java SE API on the Java 8 platform.


So I still don't see how one could compile a data class so that it could
be used on JDK8 as well as on JDK9 without java.desktop module?


Compile the annotated class using JDK 9 javac and specifying '-target 8 
-source 8'. When running on Java 8 the java.desktop module will be 
required (as is the case now) and when running on Java 9 the new @CP 
will work (and java.desktop will not be required).


-JB-



Regards, Peter

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Jaroslav Bachorik]

On 9.10.2015 20:33, Alex Buckley wrote:

On 10/9/2015 1:03 AM, Jaroslav Bachorik wrote:

Well, if anything the @CP annotation is related to
javax.management.openmbean package. All the OpenType and CompositeData
definitions are in this package. @CP annotation is used to influence the
way a CompositeData instance is reconstructed into an instance of the
mapped custom type.


OK, so if ConstructorProperties is more closely related to CompositeData
than to MXBean per se, then put ConstructorProperties into
javax.management.openmbean. The MXBean spec (i.e. the javadoc) is
obviously completely dependent on that package already.

The desire for a new package seems misplaced to me, given how the real
driver for a new package -- the draft JEP for MBean registration --
isn't going anywhere fast.


The desire is stemming from the fact that once we put this annotation 
into 'javax.management' package we will never move it into 
'javax.management.annotation' package even if we would ever agree it 
would make sense. The same way we really won't be moving @MXBean anywhere.


-JB-



Alex

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Jaroslav Bachorik]

On 9.10.2015 20:50, Mandy Chung wrote:

On 10/09/2015 11:33 AM, Alex Buckley wrote:

On 10/9/2015 1:03 AM, Jaroslav Bachorik wrote:

Well, if anything the @CP annotation is related to
javax.management.openmbean package. All the OpenType and CompositeData
definitions are in this package. @CP annotation is used to influence the
way a CompositeData instance is reconstructed into an instance of the
mapped custom type.


OK, so if ConstructorProperties is more closely related to
CompositeData than to MXBean per se, then put ConstructorProperties
into javax.management.openmbean. The MXBean spec (i.e. the javadoc) is
obviously completely dependent on that package already.



FWIW.  @ConstructorProperties is closely related to MXBean.

MXBean provides an easy way to define and implement your managed mbean
using user-defined types and the MXBean framework converts those types
into the public API and javax.management.openmbean types so that the
client doesn't need the user-defined types to be present.  In other
words, MXBean removes the need to code in javax.management.openmbean.


In ideal world this kind of mapping should be supported by notifications 
and any other parts dealing with transferring user defined data. And the 
custom type <-> open type mapping should be completely transparent for 
the API user. All of this available as an 'open data' module. But we 
don't live in an ideal world.


I still don't think we should further pollute the 'javax.management' 
packages - especially if we have API evolution in mind. The argument 
that it does not make sense to create a new package just for small number> classes probably got us to this situation when 
'javax.management' package contains classes which, in fact, should have 
been separated into cca. 6 different subpackages (according to their 
responsibility).


But, since multiple senior reviewers voiced their opinion that this 
annotation should go to 'javax.management' package I will just buckle 
down and go with '@javax.management.ConstructorProperties'



-JB-



Mandy


The desire for a new package seems misplaced to me, given how the real
driver for a new package -- the draft JEP for MBean registration --
isn't going anywhere fast.

Alex

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

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Daniel Fuchs]

On 09/10/15 14:30, Jaroslav Bachorik wrote:

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


I agree with Jaroslav.

FWIW - The @CP is not used for the MXBean itself, but for the classes
used as return type or parameter type in its management
interface (and recursively).

best regards,

-- daniel

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Peter Levart]

On 10/09/2015 06:54 PM, Alan Bateman wrote:



On 09/10/2015 16:36, Peter Levart wrote:

:


Sorry, but I must be missing something.

When you compile a class (not an MXBean as Daniel pointed out, but a 
data object class) with JDK9, it can't be used on JDK8 because of 
class file version.


When you compile a class with JDK8, it can't contain new @CS 
annotation, because it is not part of the official Java SE API on the 
Java 8 platform.



So I still don't see how one could compile a data class so that it 
could be used on JDK8 as well as on JDK9 without java.desktop module?
I think you have it right as there isn't a @CP that works for this 
scenario. The compiling with JDK 8 and trying to deploy on runtime 
that only has a subset of the standard modules is essentially the 
scenario that is already warned about in the javadoc:


"Rule 2 is not applicable to subset Profiles of Java SE that do not 
include the java.beans package. When targeting a runtime that does not 
include the java.beans package, and where there is a mismatch between 
the compile-time and runtime environment whereby J is compiled with a 
public constructor and the ConstructorProperties annotation, then J is 
not reconstructible unless another rule applies."


A solution that updates Java SE 8 to specify the new @CP or having it 
using method parameters would require doing a MR of Java SE 8 and I 
doubt it's important enough to go justify that.


Possible workarounds are to compile on JDK 8 with "-profile compact3" 
as this should fail if there is code using @beans.CP. Another one 
would to just define a static "from" method.


-Alan.


Another one would be to use yet another hack: add equivalent 
self-written /javax/management/annotation/ConstructorProperties.java 
annotation to the project sources and compile it with data classes that 
use both annotations, using JDK8. Then just package data classes.


Peter

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Alex Buckley]

On 10/9/2015 1:03 AM, Jaroslav Bachorik wrote:

Well, if anything the @CP annotation is related to
javax.management.openmbean package. All the OpenType and CompositeData
definitions are in this package. @CP annotation is used to influence the
way a CompositeData instance is reconstructed into an instance of the
mapped custom type.


OK, so if ConstructorProperties is more closely related to CompositeData 
than to MXBean per se, then put ConstructorProperties into 
javax.management.openmbean. The MXBean spec (i.e. the javadoc) is 
obviously completely dependent on that package already.


The desire for a new package seems misplaced to me, given how the real 
driver for a new package -- the draft JEP for MBean registration -- 
isn't going anywhere fast.


Alex

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Peter Levart]

On 10/09/2015 02:30 PM, Jaroslav Bachorik wrote:

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. 



Sorry, but I must be missing something.

When you compile a class (not an MXBean as Daniel pointed out, but a 
data object class) with JDK9, it can't be used on JDK8 because of class 
file version.


When you compile a class with JDK8, it can't contain new @CS annotation, 
because it is not part of the official Java SE API on the Java 8 platform.



So I still don't see how one could compile a data class so that it could 
be used on JDK8 as well as on JDK9 without java.desktop module?


Regards, Peter

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Daniel Fuchs]

Hi Jaroslav,

I'll look at the code in more details, but doesn't your
webrev miss some modifications to modules.xml?

oh - I see you have module-info.java - are you planning to
push that in jake repo first then?

best regards,

-- daniel

On 08/10/15 13: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

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-

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Jaroslav Bachorik]

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

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

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Alan Bateman]

On 08/10/2015 14:15, Daniel Fuchs wrote:

:

3. I was told recently that @since 1.9 should now be @since 9
   (package-info + new annotation type)
JEP 223 isn't in JDK 9 yet. I've no doubt there will be a s/1.9/9/g when 
it goes in, it will probably need to be done a few times to ensure 
changes in progress at the time of the switch are caught.


-Alan

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Daniel Fuchs]

Hi Jaroslav,

1. I think it would be good to change the synopsis of the issue
   to match what the proposed change does.

   It seems to me that something like:

   Add a new javax.management.annotation.ConstructorProperties
   annotation

   would be a better description.

2. I agree with Alan that logging might not be needed.
   I am not opposed to keeping it but then I'd suggest
   using one of the loggers defined in JmxProperties.java
   rather than creating a new logger object.

3. I was told recently that @since 1.9 should now be @since 9
   (package-info + new annotation type)

4. ConstructorProperties.java: Are you going to annotate MemoryUsage?

5. I see you have updated existing tests to use the new
   annotation. I wonder whether it would have been better to
   clone them instead.
   On the other hand you have added a new test to  test the legacy
   annotation, so maybe that was the right thing to do.
   Unless others object, keep it like that.

Best regards,

-- daniel


On 08/10/15 13: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

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-

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Mandy Chung]

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

Re: RFR 7199353: Allow ConstructorProperties annotation from any package

[Mandy Chung]

On 10/08/2015 04:49 AM, 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 think #2 in the rules listed in "Reconstructing an instance of Java 
type J from a CompositeData" section needs some clarification/rewording.


#2 says if J has at least one public constructor with j.m.@CP
- in fact J has at least one public constructor with either j.m.@CP or 
j.b.@CP


I think it's more appropriate to mention j.m.@CP takes precedence in #2 
instead of adding the "For backward compatibility" paragraph.


What about removing the new "For backward compatibility paragraph," 
and update #2 as something like this:


2. Otherwise, if /J/ has at least one public constructor with either 
j.m.CP or j.b.CP annotation, then one of those constructors be 
called to reconstruct an instance of /J/. If a constructor is annotated 
with both j.m.CP or j.b.CP, j.m.CP will be used and j.b.CP will be 
ignored.  


The existing tests are modified to use 
j.m.annotation.ConstructorProperties.  Can you remove java.desktop from 
@modules list if the test no longer depends on java.desktop.


The new package.html file: should use package-info.java instead.

Mandy