> 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.C
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.openj
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
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.
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 pack
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
> 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 lo
> 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.
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 "i
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 i
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
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.ma
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 Composit
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 annota
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 t
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 Comp
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 i
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.
Whe
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 conta
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
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 th
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 ins
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 com
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.
How is one suppo
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
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
On 8.10.2015 21:29, Alex Buckley wrote:
On 10/8/2015 11:56 AM, Alan Bateman wrote:
On 08/10/2015 19:41, Alex Buckley wrote:
Also, this annotation type introduces a new package,
javax.management.annotation. I support *.annotation packages in
general (e.g. to group a growing number of exciting an
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 sub
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 rul
On 10/8/2015 11:56 AM, Alan Bateman wrote:
On 08/10/2015 19:41, Alex Buckley wrote:
Also, this annotation type introduces a new package,
javax.management.annotation. I support *.annotation packages in
general (e.g. to group a growing number of exciting annotation types
related to HotSpot) but JM
On 08/10/2015 19:41, Alex Buckley wrote:
:
Also, this annotation type introduces a new package,
javax.management.annotation. I support *.annotation packages in
general (e.g. to group a growing number of exciting annotation types
related to HotSpot) but JMX is a mature technology which in th
2015/10/8 11:41 -0700, alex.buck...@oracle.com:
> ...
>
> Also, this annotation type introduces a new package,
> javax.management.annotation. I support *.annotation packages in general
> (e.g. to group a growing number of exciting annotation types related to
> HotSpot) but JMX is a mature techn
On 10/8/2015 6:15 AM, Daniel Fuchs wrote:
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 des
Hi, Alan.
> 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.
Correct. For reference, here's the bug:
8136494: Update "@since 1.9" to "@s
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
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 th
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
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/w
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
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
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
41 matches
Mail list logo
