May 2015 - core-libs-dev

setOut() and redirectOutput() together
by Weijun Wang 28 May '15

28 May '15

I am writing something like this ByteArrayOutputStream bout = new ByteArrayOutputStream(); System.setOut(out); System.out.println("Hello"); ProcessBuilder pb1 = new ProcessBuilder("./native-app"); pb1.redirectOutput(ProcessBuilder.Redirect.INHERIT); pb1.start(); Now "Hello" no longer shows on screen, but the output of "native-app" still shows up there. What else shall I do? This is Ubuntu 14.04.2. Thanks Max

3 2

RFR JDK-8028480: (zipfs) NoSuchFileException on creating a file in ZipFileSystem with CREATE and WRITE
by Xueming Shen 28 May '15

28 May '15

Hi, Please help review the changes for JDK-8028480 and JDK-8034773 issues: https://bugs.openjdk.java.net/browse/JDK-8028480 https://bugs.openjdk.java.net/browse/JDK-8034773 webrev: http://cr.openjdk.java.net/~sherman/8028480_8034773/ Thanks, -Sherman

2 3

RFR 9/8: JDK-8081022 : java/time/test/java/time/format/TestZoneTextPrinterParser.java fails by timeout on slow device
by Roger Riggs 27 May '15

27 May '15

Please review this test modification to reduce the running time and to apply the recommended randomness pattern. webrev: http://cr.openjdk.java.net/~rriggs/webrev-random-8081022/ Issue: https://bugs.openjdk.java.net/browse/JDK-8081022 Thanks, Roger

2 1

RFR 9: 8074818: Resolve disabled warnings for libjava
by Roger Riggs 27 May '15

27 May '15

Please review these native code and build changes to clear compilation warnings. Most are due to mixing unsigned types with signed types or providing the correct type to an invoked function. Webrev: http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-fix-all-warnings-807… Issues: 8074818: Resolve disabled warnings for libjava 8080007: Stop ignoring warnings for libjava JPRT in progress for product and fastdebug builds on solaris, linux, macosx, windows, and embedded. Thanks, Roger

7 15

Review Request 8074432: Move jdeps to jdk.compiler module
by Mandy Chung 27 May '15

27 May '15

This will move jdeps to the same module as other langtools javac and javap. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.00/ This is the final change to resolve the open issue JDK-8072601 (Re-examine jdk.runtime and jdk.dev modules) for JEP 200. Mandy

3 7

RFR: 8080803: sun/nio/cs/FindEncoderBugs.java failing intermittently
by Xueming Shen 27 May '15

27 May '15

Martin, Alan, Joe, Would you please help review the change (as a workaround) for this "intermittently" problem? https://bugs.openjdk.java.net/browse/JDK-8080803 http://cr.openjdk.java.net/~sherman/8080803 It appears the trigger might be that ByteBuffer.get(byte[]) fails to get the bytes from the buffer "intermittently". Interestingly this one is always reproducible on my local linux build (very old os), in which I have to update couple hotspot headfile to make the build going recently. I filed the bug#8080904 to let the vm guy take a look. Meanwhile the proposed change here is just to "optimized" the ISO2022 code a little to simple workaround this issue. I hope this can make the "intermittent failure" go away in our nightly build. If have time, we definitely should re-visit the implementation of these ISO2022 :-) Thanks, -Sherman

4 4

RFR JDK-8060161: re-examine sun/nio/cs/Test4200310.sh, test is invalid for modular image
by Xueming Shen 26 May '15

26 May '15

Alan, I agree that we should just remove this old regression test. It does not server an purpose after those jar files are gone. Please help review. issue: https://bugs.openjdk.java.net/browse/JDK-8060161 webrev: http://cr.openjdk.java.net/~sherman/8060161/ -Sherman

3 2

RFR [9] Add blocking bulk read to java.io.InputStream
by Chris Hegarty 26 May '15

26 May '15

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 this addition is provide library support for a common pattern found when reading from input streams. /** * Reads some bytes from the input stream into the given byte array. This * method blocks until {@code len} bytes of input data have been read, or * end of stream is detected. The number of bytes actually read, possibly * zero, is returned. This method does not close the input stream. * * In the case where end of stream is reached before {@code len} bytes * have been read, then the actual number of bytes read will be returned. * When this stream reaches end of stream, further invocations of this * method will return zero. * * If {@code len} is zero, then no bytes are read and {@code 0} is * returned; otherwise, there is an attempt to read up to {@code len} bytes. * * The first byte read is stored into element {@code b[off]}, the next * one in to {@code b[off+1]}, and so on. The number of bytes read is, at * most, equal to {@code len}. Let k be the number of bytes actually * read; these bytes will be stored in elements {@code b[off]} through * {@code b[off+}k{@code -1]}, leaving elements {@code b[off+}k * {@code ]} through {@code b[off+len-1]} unaffected. * * In every case, elements {@code b[0]} through {@code b[off]} and * elements{@code b[off+len]} through {@code b[b.length-1]} are unaffected. * * The behavior for the case where the input stream is asynchronously * closed, or the thread interrupted during the read, is highly input * stream specific, and therefore not specified. * * If an I/O error occurs reading from the input stream, then it may do * so after some bytes have been read. Consequently the input stream may be * in an inconsistent state. It is strongly recommended that the stream be * promptly closed if an I/O error occurs. * * @param b the buffer into which the data is read * @param off the start offset in {@code b} at which the data is written * @param len the maximum number of bytes to read * @return the actual number of bytes read into the buffer * @throws IOException if an I/O error occurs * @throws NullPointerException if {@code b} is {@code null} * @throws IndexOutOfBoundsException If {@code off} is negative, {@code len} * is negative, or {@code len} is greater than {@code b.length - off} * * @since 1.9 */ public int readBytes(byte[] b, int off, int len) throws IOException { Objects.requireNonNull(b); if (off < 0 || len < 0 || len > b.length - off) throw new IndexOutOfBoundsException(); int n = 0; while (n < len) { int count = read(b, off + n, len - n); if (count < 0) break; n += count; } return n; } -Chris.

8 32

RFR [9] 8040147: tidy warnings cleanup for javax.transaction
by alexander stepanov 26 May '15

26 May '15

Hello, Could you please review the fix http://cr.openjdk.java.net/~avstepan/8040147/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8040147 Just a very minor fix of docs markup. Thanks, Alexander

2 5

Protection of RSA from timing and cache-flushing attacks [Was: RFR(L): 8069539: RSA acceleration]
by Andrew Haley 26 May '15

26 May '15

On 05/11/2015 04:37 PM, Florian Weimer wrote: > On 05/08/2015 07:19 PM, Andrew Haley wrote: > >>> Do we want to add side-channel protection as part of this effort >>> (against timing attacks and cache-flushing attacks)? >> >> I wouldn't have thought so. It might make sense to add an optional >> path without key-dependent branches, but not as a part of this effort: >> the goals are completely orthogonal. > > I'm not well-versed in this kind of side-channel protection for RSA > implementations, but my impression that algorithm changes are needed to > mitigate the impact of data-dependent memory fetches (see fixed-width > modular exponentiation). But maybe the necessary changes materialize at > a higher level, beyond the operation which you proposed to intrinsify. By the way: there is quite a bit of code in sun/security/rsa/RSACore.java to protect against timing attacks. In particular, the patch for "8031346: Enhance RSA key handling" looks quite thorough and there is also extra care taken to make padding operations execute in constant time. Andrew.

1 0