Looks fine to me as well.
cheers,
dalibor topic
On 3/3/14 1:21 PM, dmeetry degrave wrote:
Hi all,
I would like to ask someone with a reviewer status in jdk7u project to look
at these changes.
thanks,
dmeetry
On 02/27/2014 05:44 PM, Joel Borggren-Franck wrote:
Hi,
I looked at
Hi all,
I would like to ask someone with a reviewer status in jdk7u project to
look at these changes.
thanks,
dmeetry
On 02/27/2014 05:44 PM, Joel Borggren-Franck wrote:
Hi,
I looked at webrev.1. Looks good.
cheers
/Joel
On 2014-02-25, dmeetry degrave wrote:
Thanks for looking at this,
Hi,
I looked at webrev.1. Looks good.
cheers
/Joel
On 2014-02-25, dmeetry degrave wrote:
Thanks for looking at this, Peter!
On 02/24/2014 04:42 PM, Peter Levart wrote:
Hi Dmeetry,
On 02/22/2014 01:22 PM, dmeetry degrave wrote:
Hi all,
I would like to ask for a review of combined
Hi Dmeetry,
On 02/22/2014 01:22 PM, dmeetry degrave wrote:
Hi all,
I would like to ask for a review of combined back port for
7u-dev/7u80. The main goal is to have a fix for 7122142 in jdk7, it
also integrates the changes from 8005232, 7185456, 8022721
Thanks for looking at this, Peter!
On 02/24/2014 04:42 PM, Peter Levart wrote:
Hi Dmeetry,
On 02/22/2014 01:22 PM, dmeetry degrave wrote:
Hi all,
I would like to ask for a review of combined back port for
7u-dev/7u80. The main goal is to have a fix for 7122142 in jdk7, it
also integrates the
Hi all,
I would like to ask for a review of combined back port for 7u-dev/7u80.
The main goal is to have a fix for 7122142 in jdk7, it also integrates
the changes from 8005232, 7185456, 8022721
https://bugs.openjdk.java.net/browse/JDK-7122142
https://bugs.openjdk.java.net/browse/JDK-8005232
Hi, Peter,
Not a reviewer, and have barely any time to have the careful review, so
just a few nitpicks below:
On 07/09/2013 12:54 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/
AnnotationParser.java:
- Do you want make contains() generic?
Changeset: e4ce6502eac0
Author:plevart
Date: 2013-07-15 10:55 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce6502eac0
7122142: (ann) Race condition between isAnnotationPresent and getAnnotations
Reviewed-by: dholmes, jfranck
! src/share/classes/java/lang/Class.java
Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com
*Subject: **RFR 7122142 : (ann) Race condition between
isAnnotationPresent and getAnnotations*
*Date: *8 juli 2013 22:54:12 CEST
*To: *Joel Borggrén-Franck joel.fra...@oracle.com
mailto:joel.fra...@oracle.com
*Cc: *Alan Bateman alan.bate
On 07/15/2013 11:04 AM, Aleksey Shipilev wrote:
Hi, Peter,
Not a reviewer, and have barely any time to have the careful review, so
just a few nitpicks below:
On 07/09/2013 12:54 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/
7122142 : (ann) Race condition between
isAnnotationPresent and getAnnotations*
*Date: *8 juli 2013 22:54:12 CEST
*To: *Joel Borggrén-Franck joel.fra...@oracle.com
mailto:joel.fra...@oracle.com
*Cc: *Alan Bateman alan.bate...@oracle.com
mailto:alan.bate...@oracle.com, core-libs-dev@openjdk.java.net
On 07/15/2013 04:36 PM, Peter Levart wrote:
I was guided by the Collection.contains() signature:
CollectionT {
boolean contains(Object o);
Dunno. This was done for compatibility with non-generic code. In your
code, you seem always know the type of the argument, it does not bother
me to
).
Thanks,
David
*From: *Peter Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com
*Subject: **RFR 7122142 : (ann) Race condition between
isAnnotationPresent and getAnnotations*
*Date: *8 juli 2013 22:54:12 CEST
*To: *Joel Borggrén-Franck joel.fra...@oracle.com
mailto:joel.fra...@oracle.com
memoization pattern
that installs a Future for the AnnotationType).
Thanks,
David
*From: *Peter Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com
*Subject: **RFR 7122142 : (ann) Race condition between
isAnnotationPresent and getAnnotations*
*Date: *8 juli 2013 22:54:12 CEST
*To: *Joel
Helo,
I need a Reviewer for the following patch:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/
This fixes deadlock situation described in bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122142
The in-depth evaluation of the patch is described in the
On 07/04/2013 07:34 PM, Joel Borggrén-Franck wrote:
Also, can you please explain to me why the update race is safe. I have done
the/some research myself but I would like to know which angles you have covered.
Well, one thing is that AnnotationType class is now effectively final, meaning that
Hi Again,
Sorry, the 4th revision I posted is not rebased to the current tip of
jdk8-tl so it contained some diffs that reverted some things.
Here's the correct patch:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/
Regards, Peter
On 07/05/2013 10:32 AM, Peter
Hi Peter,
Thanks for the quick update!
While I have looked over the changes to j.l.Class and the cas in AnnotationType
I don't think I'm qualified to review that. (FWIW it looked fine to me but my
jmm isn't swapped in at the moment so I won't pretend to know the interactions
between volatile
Hi Alan, Joel,
Thanks to both for taking time to review the patch.
Here's the 3rd revision:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.03/
Answers inline...
On 07/03/2013 04:51 PM, Alan Bateman wrote:
Sorry for the delay getting back to you on this, I've been busy with
Hi Peter,
On 4 jul 2013, at 16:40, Peter Levart peter.lev...@gmail.com wrote:
Answers inline...
There's another usage of AnnotationParser.parseAnnotation in
TypeAnnotationParser that will need to be updated (I only noticed it when I
grabbed your patch to try it).
I rather restored
On 07/04/2013 07:34 PM, Joel Borggrén-Franck wrote:
Also, can you please explain to me why the update race is safe. I have done
the/some research myself but I would like to know which angles you have covered.
Well, one thing is that AnnotationType class is now effectively final, meaning that
On 24/06/2013 19:23, Peter Levart wrote:
Hi Alan,
I have prepared the 2nd revision of the patch:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.02/
There is a little change in AnnotationParser's alternative parsing
method. This time the parser does not assume anything
Hi Peter,
As Alan said, a big thanks for looking into this.
I have been toying with a slightly different approach to breaking the infinite
recursion by pre-construct AnnotationType instances for Retention and
Inherited. While cleaner in some places others became uglier. I'm fine with
this
On 06/19/2013 08:54 PM, Alan Bateman wrote:
Thank you for coming back to this.
I've looked over the webrev and the approach looks good to me. Joel
might want to look at this too. Do you think you could include a test
(as we try to include a test with all fixes if we can)?
It would be good
Hi,
Since the bulk of changes to annotations and reflection have stabilized,
I'm bringing up a re-based batch that I have proposed some months ago:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014203.html
The patch fixes a deadlock situation described in:
On 19/06/2013 15:23, Peter Levart wrote:
Hi,
Since the bulk of changes to annotations and reflection have
stabilized, I'm bringing up a re-based batch that I have proposed some
months ago:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014203.html
:
This patch is
On 06/19/2013 08:54 PM, Alan Bateman wrote:
On 19/06/2013 15:23, Peter Levart wrote:
Hi,
Since the bulk of changes to annotations and reflection have
stabilized, I'm bringing up a re-based batch that I have proposed
some months ago:
27 matches
Mail list logo
