Re: [8u-dev] Request for approval: 6545422: TEST BUG: NativeErrors.java uses wrong path name in exec

2014-07-07 Thread Seán Coffey
Approved. regards, Sean. On 01/07/14 22:32, Ivan Gerasimov wrote: Corrected the subject line: I'm requesting an approval to push the fix into jdk8u-dev repo, not jdk8u20 On 02.07.2014 1:29, Ivan Gerasimov wrote: Hello! I'm rerequesting an approval to backport this test fix into jdk8u. To

Re: [8u-dev] Request for approval: 6545422: TEST BUG: NativeErrors.java uses wrong path name in exec

2014-07-07 Thread Ivan Gerasimov
Thanks Seán! On 07.07.2014 13:49, Seán Coffey wrote: Approved. regards, Sean. On 01/07/14 22:32, Ivan Gerasimov wrote: Corrected the subject line: I'm requesting an approval to push the fix into jdk8u-dev repo, not jdk8u20 On 02.07.2014 1:29, Ivan Gerasimov wrote: Hello! I'm rerequesting

Re: RFR 8049220: URL.factory data race

2014-07-07 Thread Peter Levart
Hi Pavel, Alan and Paul, Thanks for reviewing. I accepted the suggestions from Pavel and Paul and created webrev.02: http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.02/ Is this good to go into jdk9-dev? Regards, Peter On 07/04/2014 04:54 PM, Paul Sandoz wrote: On Jul 3,

Re: RFR: 8048020 - Regression on java.util.logging.FileHandler

2014-07-07 Thread Daniel Fuchs
Thanks Alan! Just for the record the 'final' webrev is here: http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.02 I will push this shortly... -- daniel On 7/4/14 8:24 PM, Alan Bateman wrote: On 04/07/2014 19:10, Daniel Fuchs wrote: hmmm. yes - you're right. I should catch that to and

Re: RFR 8049220: URL.factory data race

2014-07-07 Thread Alan Bateman
On 07/07/2014 12:07, Peter Levart wrote: Hi Pavel, Alan and Paul, Thanks for reviewing. I accepted the suggestions from Pavel and Paul and created webrev.02: http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.02/ Is this good to go into jdk9-dev? The comments looks okay to me

Re: RFR 8049220: URL.factory data race

2014-07-07 Thread Paul Sandoz
On Jul 7, 2014, at 1:07 PM, Peter Levart peter.lev...@gmail.com wrote: Hi Pavel, Alan and Paul, Thanks for reviewing. I accepted the suggestions from Pavel and Paul and created webrev.02: http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.02/ Is this good to go into

RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException

2014-07-07 Thread Ivan Gerasimov
Hello! The javadoc says that Pattern.compile(String regex, int flag) will throw IllegalArgumentException, if flag contains an invalid bit set. However, it fails to do so. Would you please help review the simple fix for that? Alternatively, we could just remove the corresponding @throws part,

Re: RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException

2014-07-07 Thread Xueming Shen
On 07/07/2014 10:07 AM, Ivan Gerasimov wrote: Hello! The javadoc says that Pattern.compile(String regex, int flag) will throw IllegalArgumentException, if flag contains an invalid bit set. However, it fails to do so. Would you please help review the simple fix for that? Alternatively, we

Re: Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API

2014-07-07 Thread Mandy Chung
On 7/4/14 11:04 AM, Alan Bateman wrote: On 25/06/2014 21:21, Mandy Chung wrote: This patch is also intended to target for 8u40 backport. It fixes the following issues: JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API JDK-8039007 jdeps incorrectly reports

Re: RFR [8035975] Pattern.compile(String, int) fails to throw IllegalArgumentException

2014-07-07 Thread Ivan Gerasimov
Thanks you Sherman for review! On 07.07.2014 21:38, Xueming Shen wrote: On 07/07/2014 10:07 AM, Ivan Gerasimov wrote: Hello! The javadoc says that Pattern.compile(String regex, int flag) will throw IllegalArgumentException, if flag contains an invalid bit set. However, it fails to do so.

Re: RFR: 8044656: Update JAX-WS RI integration to latest version

2014-07-07 Thread huizhe wang
Hi Miran, In class src/share/jaxws_classes/com/sun/tools/internal/xjc/Options.java: +// hack to force initialization so catalog manager system properties take effect +staticManager.getVerbosity(); Is that necessary? I thought the next call to getCatalog would

Re: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size

2014-07-07 Thread Ivan Gerasimov
On 08.07.2014 4:47, Martin Buchholz wrote: I think this code has an off-by-factor-of-2 bug. +if (expectedMaxSize MAXIMUM_CAPACITY / 3) +return MAXIMUM_CAPACITY; No, even though it looks like a bug. (MAXIMUM_CAPACITY / 3) * (3 / 2) == MAXIMUM_CAPACITY / 2. if expected

Re: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size

2014-07-07 Thread Ivan Gerasimov
Thank you Martin for the enhancement! It's a good idea to get rid of threshold variable! When the table grows large, it will start to try to resize the table on every single put(). Though it shouldn't matter much, as in such situation everything is already slow. On 08.07.2014 4:44, Martin

Re: Draft JEP: Efficient Stack Walking API

2014-07-07 Thread Mandy Chung
Hi Jeremy, Thanks for the feedback and the CallerFinder API you have. On 7/7/2014 9:55 AM, Jeremy Manson wrote: Hey folks, I don't know if Mandy's draft JEP has gotten any love, The JEP process is in transition to 2.0 version. Hope this JEP will come out soon. but this is something that