Re: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor

Hi Ramanand, Your fix looks good to me. Thanks, -- Yuka On 2016/03/02 14:34, Ramanand Patil wrote: Hi all, May I request one more review for this bug? [Thank you Masayoshi for your review.] Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Wednesday, February 24,

Re: RFR 8148187 : Remove OS X-specific com.apple.concurrent package

Hello Brent, The build changes look pretty good. Just one nit, in the new LibosxLibraries.gmk, please remove the "include LibCommon.gmk" as that is now handled by Lib-java.desktop.gmk. /Erik On 2016-03-01 22:16, Brent Christian wrote: Hi, A number of internal APIs were carried over into th

RE: RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor

Hi all, May I request one more review for this bug? [Thank you Masayoshi for your review.] Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Wednesday, February 24, 2016 1:46 PM To: Ramanand Patil; i18n-...@openjdk.java.net Cc: core-libs-dev@openjdk.java.net Subject:

Re: RFR 8148187 : Remove OS X-specific com.apple.concurrent package

> On Mar 1, 2016, at 1:16 PM, Brent Christian > wrote: > > Hi, > > A number of internal APIs were carried over into the JDK with the Apple port. > Among them was com.apple.concurrent.Dispatch. > > Supportedness has always been murky here, but Jigsaw necessitates a firmer > stance. Some of

Re: RFR: jsr166 jdk9 integration wave 5

Thanks, Stuart! On Tue, Mar 1, 2016 at 2:40 PM, Stuart Marks wrote: > Hi Martin, > > I'm a bit confused about exactly what pieces need review here. Since you > mentioned me with respect to 8150523, I took a look at the webrev that adds > the timeout factors: > > http://cr.openjdk.java.net/~martin

Re: RFR: jsr166 jdk9 integration wave 5

Hi Martin, I'm a bit confused about exactly what pieces need review here. Since you mentioned me with respect to 8150523, I took a look at the webrev that adds the timeout factors: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/timeoutFactor/ Do other webrevs sti

RFR 8148187 : Remove OS X-specific com.apple.concurrent package

Hi, A number of internal APIs were carried over into the JDK with the Apple port. Among them was com.apple.concurrent.Dispatch. Supportedness has always been murky here, but Jigsaw necessitates a firmer stance. Some of these APIs have already been removed from JDK 9 [1], some will be suppl

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Thank you Martin! On 01.03.2016 21:54, Martin Buchholz wrote: Thanks, Ivan. 135 /** 136 * This method has the same contract as ensureCapacity, but is 137 * never synchronized. 138 */ I'll update this comment to reflect the real behavior of that method. Sincerely you

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

On 1/03/2016 11:39 PM, Dmitry Samersoff wrote: Thomas, We probably can do: if (fdTable[rootArrayIndex] != NULL) { entryTable = fdTable[rootArrayIndex]; } else { // existing code pthread_mutex_lock(&fdTableLock); if (fdTable[rootArrayIndex] == NULL) { } } This is doubl

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

On Mon, Feb 22, 2016 at 11:01 PM, Xueming Shen wrote: > From certain perspective it's a kinda of "regression" that the maximum > capacity for a non-latin1 > buffer/builder is reduced by 2 . But arguably it's really an implementation > detail that how big a > StringBuffer/Builder can really go, as

Re: RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods

+1. -Chris. On 1 Mar 2016, at 18:48, Brian Burkhalter wrote: > Hi Mikael, > > Not a Reviewer here, but it looks OK to me aside from the copyright year in > the template file. > > Nice to see code removed! > > Brian > > On Mar 1, 2016, at 10:29 AM, Mikael Vidstedt > wrote: > >> As part o

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Thanks, Ivan. 135 /** 136 * This method has the same contract as ensureCapacity, but is 137 * never synchronized. 138 */ This comment should be updated, since treatment of negative argument is completely different. Otherwise looks good. On Tue, Mar 1, 2016 at 9:33 AM, Iv

Re: RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods

Hi Mikael, Not a Reviewer here, but it looks OK to me aside from the copyright year in the template file. Nice to see code removed! Brian On Mar 1, 2016, at 10:29 AM, Mikael Vidstedt wrote: > As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, > and the functionality

RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods

As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, and the functionality is instead provided by the VM through j.i.m.Unsafe. The Bits wrapper methods are therefore redundant and can be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8149596 Webrev: http://cr.o

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Hello! I added another regtest to perform some basic sanity checks wrt StringBuilder's capacity. In this test I we only operate on relatively small sizes. A situation when capacity grows large is checked in a separate test, which is ignored by default. Do you think this fix is good to go? B

RFR [9] 8150976: JarFile and MRJAR tests should use the JDK specific Version API

Currently JarFile and MRJAR tests use sun.misc.Version to retrieve the major runtime version. They should be updated to use the new JDK specific Version API. Note: There is an issue, 8144062 [1], to revisit the JDK specific Version API to determine if it should be moved, or even standardized. The

Re: RFR: 8150856 - Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger

> On Feb 29, 2016, at 9:46 AM, Daniel Fuchs wrote: > > --- old/src/java.base/share/classes/java/lang/System.java 2016-02-29 > 18:41:30.0 +0100 > +++ new/src/java.base/share/classes/java/lang/System.java 2016-02-29 > 18:41:30.0 +0100 > @@ -1,5 +1,5 @@ > /* > - * Copyrigh

Re: RFR - 8148820: Missing @since Javadoc tag in Logger.log(Level, Supplier)

+1 On 3/1/2016 8:30 AM, Daniel Fuchs wrote: Hi, Please find below a trivial fix for 8148820: Missing @since Javadoc tag in Logger.log(Level, Supplier) https://bugs.openjdk.java.net/browse/JDK-8148820 This method was added to java.util.logging.Logger in jdk 8, but the @since tag was missing.

Re: [9] RFR: 8150174: Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT)

Hi Lance, Thanks for review! Best Aleksej On 02/29/2016 02:43 PM, Lance Andersen wrote: Hi Alejsej This looks fine Best Lance On Feb 24, 2016, at 5:50 PM, Aleksej Efimov > wrote: Hi, Please, review the bulk update of JAX-WS/B from upstream projects: http:

Re: RFR - 8148820: Missing @since Javadoc tag in Logger.log(Level, Supplier)

+1 -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPhone > On Mar 1, 2016, at 8:30 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a trivial fix for > > 81488

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Dmitry, On Tue, Mar 1, 2016 at 2:49 PM, Dmitry Samersoff < dmitry.samers...@oracle.com> wrote: > Thomas, > > > For fd < 65535, I effectively fall back to a plain array lookup by > > setting the size of the base table to 1. So, for this case the sparse > > array degenerates to a one-dimensional pl

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thomas, > For fd < 65535, I effectively fall back to a plain array lookup by > setting the size of the base table to 1. So, for this case the sparse > array degenerates to a one-dimensional plain array. It might be good to make it more explicit: just allocate a separate array for values less than

RFR(XS): 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop

Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8150953 Webrev: http://cr.openjdk.java.net/~mhaupt/8150953/webrev.00/ The API docs and corresponding JavaDocExampleTest test case for MethodHandles.whileLoop() wrongly used the example for MethodHandles.doWhileLoop(

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thomas, We probably can do: if (fdTable[rootArrayIndex] != NULL) { entryTable = fdTable[rootArrayIndex]; } else { // existing code pthread_mutex_lock(&fdTableLock); if (fdTable[rootArrayIndex] == NULL) { } } -Dmitry On 2016-03-01 16:13, Thomas Stüfe wrote: > Dmitry, Christo

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi Dmitry, On Tue, Mar 1, 2016 at 1:44 PM, Dmitry Samersoff < dmitry.samers...@oracle.com> wrote: > Christoph, > > > Dmitry, I think you are referring to an outdated version of the > > webrev, the current one is this: > > Yes. Sorry! > > You may consider a bit different approach to save memory: >

RFR - 8148820: Missing @since Javadoc tag in Logger.log(Level, Supplier)

Hi, Please find below a trivial fix for 8148820: Missing @since Javadoc tag in Logger.log(Level, Supplier) https://bugs.openjdk.java.net/browse/JDK-8148820 This method was added to java.util.logging.Logger in jdk 8, but the @since tag was missing. -- daniel diff --git a/src/java.logging/shar

Re: JDK 9 RFR of JDK-8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times

On 3/1/16 7:41 PM, Peter Levart wrote: Hi Amy, I think that the following test: 178 if (!(Math.abs(now - start) >= 0L && Math.abs(end - now) >= 0L)) { ...will always be false. Therefore, the test will always succeed. Perhaps you wanted to test the following: assert start <= end; i

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Dmitry, Christoph, I am not 100% sure this would work for weak ordering platforms. If I understand you correctly you suggest the double checking pattern: if (basetable[index] == NULL) { lock if (basetable[index] == NULL) { basetable[index] = calloc(size); } u

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Christoph, > Dmitry, I think you are referring to an outdated version of the > webrev, the current one is this: Yes. Sorry! You may consider a bit different approach to save memory: Allocate multiple baseTables for different ranges of fd's with plain array of 32 * (fdEntry_t*) for simple case.

Re: JDK 9 RFR of JDK-8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times

Hi Amy, I think that the following test: 178 if (!(Math.abs(now - start) >= 0L && Math.abs(end - now) >= 0L)) { ...will always be false. Therefore, the test will always succeed. Perhaps you wanted to test the following: assert start <= end; if (start > now || now > end) { ... Reg

Re: RFR: 8150856 - Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger

On 29/02/16 18:54, Martin Buchholz wrote: You need to delete the orphaned semicolon Thanks Martin! -- daniel On Mon, Feb 29, 2016 at 9:46 AM, Daniel Fuchs wrote: Hi, Please find below a trivial fix for: https://bugs.openjdk.java.net/browse/JDK-8150856 8150856: Inconsistent API documenta

RFR 8131913: jdk/internal/jline/console/StripAnsiTest.java can't run in the background

Hi, I'd like to ask for a review of a patch for JDK-8131913. The fix is to use the "UnsupportedTerminal", which will not try to switch the OS terminal into the raw mode. The proposed patch is here: http://cr.openjdk.java.net/~jlahoda/8131913/webrev.00/index.html Any comments are welcome. Th

RE: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Hi Dmitry, Thomas, Dmitry, I think you are referring to an outdated version of the webrev, the current one is this: http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.01/webrev/ However, I agree - the lock should probably not be taken every time but only in the case w

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Thomas, Sorry for being later. I'm not sure we should take a lock at ll. 131 for each fdTable lookup. As soon as we never deallocate fdTable[base_index] it's safe to try to return value first and then take a slow path (take a lock and check fdTable[base_index] again) -Dmitry On 2016-02-24 20:

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

On 1/03/2016 7:27 PM, Thomas Stüfe wrote: Ping... Could I have reviewer and a sponsor, please? You don't need a sponsor for this JDK change - you are a Committer. :) Cheers, David Thanks you! Thomas On Thu, Feb 25, 2016 at 5:51 PM, Thomas Stüfe wrote: Hi Roger, thank you for the revie

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

Ping... Could I have reviewer and a sponsor, please? Thanks you! Thomas On Thu, Feb 25, 2016 at 5:51 PM, Thomas Stüfe wrote: > Hi Roger, > > thank you for the review! > > New webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.01/webrev/ > > Please find my

Re: RFR(M): 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException

Hi Paul, > Am 29.02.2016 um 14:46 schrieb Paul Sandoz : >> A new webrev with the above changes (save the renaming) is at >> http://cr.openjdk.java.net/~mhaupt/8150635/webrev.01 >> > > +1 thank you. I'll push once CCC approves. Best, Michael -- Dr. Michael Haupt |