Re: RFR [9] Add blocking bulk read to java.io.InputStream

On 04/23/2015 04:50 PM, Chris Hegarty wrote: Peter, Ah, good point. Do we really need a new Exception type for this, is this information really that useful? How can you recover? What if this error condition was better cover in the API. * p If an I/O error occurs reading from the input

Re: [9] RFR (XS): 8059455: LambdaForm.prepare() does unnecessary work for cached LambdaForms

On Apr 23, 2015, at 5:12 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8059455 http://cr.openjdk.java.net/~vlivanov/8059455/webrev.00/ LambdaForm.compileToBytecode() does unnecessary work (constructs invokerType check an assertion)

Re: RFR [9] Add blocking bulk read to java.io.InputStream

Hello, I would use the already established name readFully(byte[]) and readFully(byte[],int,int) to be consistent with DataInputStream. Gruss Bernd

Re: RFR [9] Add blocking bulk read to java.io.InputStream

Right you are, David. So this exception could be reused albeit the cause of interruption can be arbitrary IOException thrown in the midst of two read() calls. But the caller need not care as the outcome is the same. Regards, Peter On 04/23/2015 04:30 PM, David M. Lloyd wrote: I believe this

Re: RFR [9] Add blocking bulk read to java.io.InputStream

On 23/04/2015 13:22, Remi Forax wrote: I think the name readBytes is not very informative and the name is too close to read + an array of bytes, we can not use readFully (from DataInput/DataInputStream) because instead of returning the number of bytes read, it throws a EOFException if the end

Re: RFR [9] Add blocking bulk read to java.io.InputStream

Hi Chris, Currently InputStream guarantees that either some bytes are read *xor* EOF (-1) is returned *xor* IOException is thrown. Even with default implementation of read(byte[], int, int) which is implemented in terms of int read(). This new method can throw IOException after some bytes

Re: RFR [9] Add blocking bulk read to java.io.InputStream

On 23 Apr 2015, at 17:10, Peter Levart peter.lev...@gmail.com wrote: On 04/23/2015 04:50 PM, Chris Hegarty wrote: Peter, Ah, good point. Do we really need a new Exception type for this, is this information really that useful? How can you recover? What if this error condition was better

Re: RFR [9] Add blocking bulk read to java.io.InputStream

Peter, Ah, good point. Do we really need a new Exception type for this, is this information really that useful? How can you recover? What if this error condition was better cover in the API. * p If an I/O error occurs reading from the input stream, then it may do * so after some, but not all,

Re: [8u60] Request for approval: 8073357: schema1.xsd has wrong content. Sequence of the enum values has been changed

Hi Aleksej, The backport looks fine to me. Best, Joe On 4/22/2015 7:12 AM, Aleksej Efimov wrote: Hello, Can I ask for approval of the JDK-8073357 [2] bug fix [1] to JDK8. The original fix contains only test modifications, but the jaxws part was introduced during JAXWS synchronization [3]

Re: RFR [9] Add blocking bulk read to java.io.InputStream

On 04/23/2015 04:41 PM, Alan Bateman wrote: On 23/04/2015 13:22, Remi Forax wrote: I think the name readBytes is not very informative and the name is too close to read + an array of bytes, we can not use readFully (from DataInput/DataInputStream) because instead of returning the number of

Re: RFR (XS): 8030680: 292 cleanup from default method code assessment

Hello again, forgive me; this is the wrong list. Best, Michael Am 23.04.2015 um 21:08 schrieb Michael Haupt michael.ha...@oracle.com: Hello, please review and sponsor this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8030680 Webrev:

Re: RFR [9] Add blocking bulk read to java.io.InputStream

On 04/23/2015 06:21 PM, Chris Hegarty wrote: On 23 Apr 2015, at 16:58, Bernd Eckenfels e...@zusammenkunft.net wrote: Hello, I would use the already established name readFully(byte[]) and readFully(byte[],int,int) to be consistent with DataInputStream. I purposefully stayed away from the

Re: JDK-8074023: Clock.system(ZoneId) could be optimized to always return the same clock for a given zone

Hi Peter, The defaultTimeZone is cached in java.util.TimeZone the first time it is referenced and is not updated after that. See java.util.TimeZone.getDefaultRef(). Regards, Roger On 4/23/2015 4:11 PM, Peter Levart wrote: On 04/23/2015 09:53 PM, nadeesh tv wrote: Hi all, Please review

RFR (XS): 8030680: 292 cleanup from default method code assessment

Hello, please review and sponsor this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8030680 Webrev: http://cr.openjdk.java.net/~mhaupt/8030680/webrev.00/ This is a set of simple changes to increase robustness. Tested locally with jtreg for java.lang.invoke, and with JPRT using the

JDK-8074023: Clock.system(ZoneId) could be optimized to always return the same clock for a given zone

Hi all, Please review this minor change which optimized Clock.systemDefaultZone() and Clock.system(ZoneId) to avoid creating new instance of Clock.SystemClock every time they are called. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8074023 Webrev :

Re: RFR [9] Add blocking bulk read to java.io.InputStream

On 04/23/2015 06:21 PM, Chris Hegarty wrote: On 23 Apr 2015, at 16:58, Bernd Eckenfels e...@zusammenkunft.net wrote: Hello, I would use the already established name readFully(byte[]) and readFully(byte[],int,int) to be consistent with DataInputStream. I purposefully stayed away from the

Re: JDK-8074023: Clock.system(ZoneId) could be optimized to always return the same clock for a given zone

On 04/23/2015 10:33 PM, Roger Riggs wrote: Hi Peter, The defaultTimeZone is cached in java.util.TimeZone the first time it is referenced and is not updated after that. See java.util.TimeZone.getDefaultRef(). Regards, Roger But any code (with enough privilege) can update it: abstract

Re: RFR [9] Add blocking bulk read to java.io.InputStream

Hi Chris, A minor inconsistency about the unmodified contents of b[off]. * p The first byte read is stored into element {@code b[off]} vs. * p In every case, elements {@code b[0]} through {@code b[off *- 1*]} and * elements__{@code b[off+len]} through {@code b[b.length-1]} are

RFR 8078490: Missed submissions in ForkJoinPool

Hi. Please review this patch from Doug that fixes an issue where a submitted task to a f/j pool never gets executed. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8078490-fj-missed-submissions/webrev/ I already counted myself and Alexey as reviewers. The issue manifests itself under certain

RFR [9] Add blocking bulk read to java.io.InputStream

A while back when we added the long overdue java.io.InputStream.transferTo method, there was support for adding a blocking bulk read operation. This has been sitting in a branch in the sandbox since then. I would like to revive it with the intention of bringing it into 9. The motivation for

Re: JDK 9 RFR of JDK-8078467: Update core libraries to use diamond with anonymous classes

On 23/04/2015 02:08, joe darcy wrote: Hello, Earlier in JDK 9, the diamond syntax was expanded to be usable with many cases of anonymous classes. [1] Please review the fix below take advantage of the new syntax (and also take advantage of the original diamond syntax in some cases) in the

Re: RFR [9] Add blocking bulk read to java.io.InputStream

I think the name readBytes is not very informative and the name is too close to read + an array of bytes, we can not use readFully (from DataInput/DataInputStream) because instead of returning the number of bytes read, it throws a EOFException if the end of the stream is reached. so what

Re: RFR 8078490: Missed submissions in ForkJoinPool

Thanks for bringing this in Paul. The change looks ok to me, and suitable for backport. Trivially, the test does not need the Classpath exception in its license header. -Chris. On 23 Apr 2015, at 14:00, Paul Sandoz paul.san...@oracle.com wrote: Hi. Please review this patch from Doug that

Re: RFR 8078490: Missed submissions in ForkJoinPool

On Apr 23, 2015, at 3:23 PM, Chris Hegarty chris.hega...@oracle.com wrote: Thanks for bringing this in Paul. The change looks ok to me, and suitable for backport. Trivially, the test does not need the Classpath exception in its license header. Doh, thanks, updated locally. When i

Re: RFR [9] Add blocking bulk read to java.io.InputStream

Hi Chris, The spec looks good. The only single detail I've noticed is that the an exception is thrown as a possible cause of unblocking the method is missing: --- dev/jdk/src/java.base/share/classes/java/io/InputStream.java (revision ) +++