February 2015 - core-libs-dev

RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
by Daniel Fuchs 19 Feb '15

19 Feb '15

Hi, Please find below a patch for: 8072645: java.util.logging should use java.time to get more precise time stamps http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/ specdiff: http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/jav… Overview: --------- The patch is made of the following pieces: - LogRecord uses java.time.Clock's systemClock to get an Instant in the best available resolution. The instant is split into a number of milliseconds (a long) and a nanosecond adjustment (an int). The number of milliseconds is the same than what would have been obtained by calling System.currentTimeMillis(). - LogRecord acquires a new serializable int nanoAdjustement field, which can be used together with the number of milliseconds to reconstruct the instant. - SimpleFormatter is updated to pass a ZoneDateTime instance to String.format, instead of a Date. The effect of that is that the format string can now be configure to print the full instant precision, if needed. - XMLformatter will add a new <nanos> element after the <millis> element - if the value of the nanoAdjustment field is not 0. The <date> string will also contain the nano second adjustment as well as the zone offset as formatted by DateTimeFormatter.ISO_OFFSET_DATE_TIME Compatibility considerations: ----------------------------- - The serial for of log record is backward/forward compatible. I added a test to verify that. - XMLFormatter has acquired a new configurable property '<FQCN>.printNanos' which allows to revert to the old XML format, should the new format cause issues in existing applications. - The logger.dtd will need to be updated, to support the new optional <nanos> element. And for this matter, should we update the logger.dtd or rather define a logger-v2.dtd? See planned modification: <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.fra…> best regards, -- daniel

5 18

RFR(S): JDK-8073175, 8073174: Fix native warnings in libjli and libfdlibm
by Dmitry Samersoff 19 Feb '15

19 Feb '15

(PING) Hi Everyone, It's my $0.02 to the warning cleanup work. Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01 http://cr.openjdk.java.net/~dsamersoff/JDK-8073174/webrev.01 Notes: 1. There are two common ways to cast pointer to int: intptr_t (perfectly safe, more-or-less portable) and size_t (perfectly portable, more-or-less safe) Use intptr_t everywhere but it costs explicit #ifdef __WINDOWS__ in splashscreen_stubs.c 2. I didn't fix "format not a string literal" warnings. It requires to set per-compiler pragmas. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

1 0

Comparators.NullComparator equals/hashCode
by John S. Adair 19 Feb '15

19 Feb '15

I just filed a bug report with Oracle (Review ID: JI-9019070) requesting that Comparators.NullComparator implement equals and hashCode in a manner analogous to Collections.ReverseComparator2. It occurred to me that my bug report failed to mention the (hopefully obvious) behavior regarding the nullsFirst flag. Is this the right place to ask about the likelihood of action being taken on the bug/RFE?

2 1

String.substring when beginIndex is the string's length
by Zoltan Sziladi 19 Feb '15

19 Feb '15

Hi, There are 2 things I do not understand about how substring works, hopefully someone can shed some light on it. 1. When you call substring and you provide the string's length as beginIndex, why does it return an empty string instead of throwing an exception? You are effectively indexing outside of the string: you index a character that is after the last character. Obviously this won't be changed since probably lots of code depend on this already, but still, I just don't get the logic behind it. 2. In this specific case (when beginIndex is the string's length) there seem to be a lot of unnecessary method calls for returning an empty string: String constructor -> Arrays.copyOfRange -> System.arraycopy All of these calls do some checks and in this case pass around 0's a lot, even creating array of 0 length, etc. My question is, would it make sense to include an if so that if subLen == 0, then it would return an empty string? Or it has too much overhead if we consider how often this case occurs and it would be better to lose on performance on these rare occasions while keeping the general case 1 if faster? Thanks in advance! Regards, Zoltan

2 2

RFR: JDK-8055204 - Memory leak in jdk/src/windows/native/java/lang/java_props_md.c
by Mark Sheppard 18 Feb '15

18 Feb '15

Hi please oblige and review the small change http://cr.openjdk.java.net/~msheppar/8055204/webrev/ which addresses the parfait issue raised in https://bugs.openjdk.java.net/browse/JDK-8055204 frees previously allocated memory in an error return path. regards Mark

2 1

RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses
by Andrew Haley 18 Feb '15

18 Feb '15

java.nio.DirectByteBuffer.getXXX is slow for types larger than byte because the runtime does not know that AArch64 can perform unaligned memory accesses. The problem is due to this code in java.nio.Bits.unaligned(): unaligned = arch.equals("i386") || arch.equals("x86") || arch.equals("amd64") || arch.equals("x86_64"); If we add AArch64 to this list code quality is very much improved. http://cr.openjdk.java.net/~aph/8073093/ Thanks, Andrew.

11 41

[9] RFR of 8073347: javadoc of Formattable messed up by JDK-8019857
by Brian Burkhalter 17 Feb '15

17 Feb '15

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8073347 Patch: http://cr.openjdk.java.net/~bpb/8073347/ Note the before and after versions of the HTML. Thanks, Brian

2 4

[PATCH] CipherStream produces new byte array on every update or doFinal operation
by Dai Nakanishi 17 Feb '15

17 Feb '15

Hi, CipherInputStream and CipherOutputStream call the Cipher methods update and doFinal which produce new byte array. It may consume a large amount of memory. The purpose of my patch is to avoid this. Could you review the patch? Thanks, Dai --- old/src/share/classes/javax/crypto/CipherInputStream.java Thu Feb 12 11:55:05 2015 +0900 +++ new/src/share/classes/javax/crypto/CipherInputStream.java Tue Feb 17 17:12:08 2015 +0900 @@ -108,34 +108,50 @@ read = true; if (readin == -1) { done = true; + ensureCapacity(0); try { - obuffer = cipher.doFinal(); - } catch (IllegalBlockSizeException | BadPaddingException e) { + ofinish = cipher.doFinal(obuffer, 0); + } catch (IllegalBlockSizeException | BadPaddingException + | ShortBufferException e) { obuffer = null; throw new IOException(e); } - if (obuffer == null) + if (ofinish == 0) return -1; else { ostart = 0; - ofinish = obuffer.length; return ofinish; } } + ensureCapacity(readin); try { - obuffer = cipher.update(ibuffer, 0, readin); + ofinish = cipher.update(ibuffer, 0, readin, obuffer); } catch (IllegalStateException e) { obuffer = null; throw e; + } catch (ShortBufferException e) { + obuffer = null; + throw new IOException(e); } ostart = 0; - if (obuffer == null) - ofinish = 0; - else ofinish = obuffer.length; return ofinish; } /** + * Ensure the capacity of the output buffer for the next + * update or doFinal operation, given the input length + * <code>inputLen</code> (in bytes) + * + * @param inputLen the input length (in bytes) + */ + private void ensureCapacity(int inputLen) { + int outputLen = cipher.getOutputSize(inputLen); + if (obuffer == null || obuffer.length < outputLen) { + obuffer = new byte[outputLen]; + } + } + + /** * Constructs a CipherInputStream from an InputStream and a * Cipher. * <br>Note: if the specified input stream or cipher is @@ -311,10 +327,12 @@ try { // throw away the unprocessed data if (!done) { - cipher.doFinal(); + ensureCapacity(0); + cipher.doFinal(obuffer, 0); } } - catch (BadPaddingException | IllegalBlockSizeException ex) { + catch (BadPaddingException | IllegalBlockSizeException + | ShortBufferException ex) { /* If no data has been read from the stream to be en/decrypted, we supress any exceptions, and close quietly. */ if (read) { --- old/src/share/classes/javax/crypto/CipherOutputStream.java Thu Feb 12 11:55:05 2015 +0900 +++ new/src/share/classes/javax/crypto/CipherOutputStream.java Tue Feb 17 18:48:01 2015 +0900 @@ -74,6 +74,9 @@ // the buffer holding data ready to be written out private byte[] obuffer; + // the number of bytes stored in the output buffer + private int ostored = 0; + // stream status private boolean closed = false; @@ -118,10 +121,15 @@ */ public void write(int b) throws IOException { ibuffer[0] = (byte) b; - obuffer = cipher.update(ibuffer, 0, 1); - if (obuffer != null) { - output.write(obuffer); - obuffer = null; + ensureCapacity(1); + try { + ostored = cipher.update(ibuffer, 0, 1, obuffer); + } catch (ShortBufferException e) { + throw new IOException(e); + } + if (ostored > 0) { + output.write(obuffer, 0, ostored); + ostored = 0; } }; @@ -155,10 +163,15 @@ * @since JCE1.2 */ public void write(byte b[], int off, int len) throws IOException { - obuffer = cipher.update(b, off, len); - if (obuffer != null) { - output.write(obuffer); - obuffer = null; + ensureCapacity(len); + try { + ostored = cipher.update(b, off, len, obuffer); + } catch (ShortBufferException e) { + throw new IOException(e); + } + if (ostored > 0) { + output.write(obuffer, 0, ostored); + ostored = 0; } } @@ -177,9 +190,9 @@ * @since JCE1.2 */ public void flush() throws IOException { - if (obuffer != null) { - output.write(obuffer); - obuffer = null; + if (obuffer != null && ostored > 0) { + output.write(obuffer, 0, ostored); + ostored = 0; } output.flush(); } @@ -206,14 +219,31 @@ } closed = true; + ensureCapacity(0); try { - obuffer = cipher.doFinal(); - } catch (IllegalBlockSizeException | BadPaddingException e) { + ostored = cipher.doFinal(obuffer, 0); + } catch (IllegalBlockSizeException | BadPaddingException + | ShortBufferException e) { obuffer = null; + ostored = 0; } try { flush(); } catch (IOException ignored) {} out.close(); + } + + /** + * Ensure the capacity of the output buffer for the next + * update or doFinal operation, given the input length + * <code>inputLen</code> (in bytes) + * + * @param inputLen the input length (in bytes) + */ + private void ensureCapacity(int inputLen) { + int outputLen = cipher.getOutputSize(inputLen); + if (obuffer == null || obuffer.length < outputLen) { + obuffer = new byte[outputLen]; + } } }

2 2

[9] RFR of 8073207: javadoc typos in java.nio.channels.Pipe
by Brian Burkhalter 17 Feb '15

17 Feb '15

Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8073207 Patch: http://cr.openjdk.java.net/~bpb/8073207/webrev.00/ Simply implements what the description suggests. Thanks, Brian

2 1

RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system
by Xueming Shen 16 Feb '15

16 Feb '15

Hi, Please help review the changes for JDK-8073152 Issue: https://bugs.openjdk.java.net/browse/JDK-8073152 Webrev: http://cr.openjdk.java.net/~sherman/8073152/webrev/ This change is to re-organize how the "standard" and "extended" charsets repository are built for the jdk/jre images. Before module system, the "standard" charset provider is built into rt.jar and the "extended" charsets provider is in charsets.jar, which is located in the "lib/ext" directory. both are available during the system boot time. In jigsaw, the extended charsets provider is in jdk.charset (vs the "standard" is in java.base) module and might not be "visible" during the early phase of system classes loading, which might cause problem as some of the charsets now in "extended" charsets may needed during the boot stage. The proposed change here is to re-organize the way these two providers are built, and put in the mechanism that enable the build system to configure which group of charsets need to be moved from the "extended" charsets into the "standard" (java.base), based on the target platform, during the jdk build time. The updates are (1) to consolidate the existing configuration files "sbcs", "dbcs", "extsbcs" and "standard-charsets" (and the aliases table originally hardcoded in ExtendeardCharsets.java) into a single configuration file "charsets" to define all supported charsets, with their name, clz name, history name, package name and all aliases http://cr.openjdk.java.net/~sherman/8073152/webrev/make/data/charsetmapping… (2) in addition to the the "standard charsets" provider, now the "extended charsets" provider class is also built during the build time based on the new configuration file "charsets" (3) to add a build-time mechanism to specify individual sun.nio.cs.ext charset to be built into "standard" charsets provider (sun.nio.cs package in java.base module), with os-specific configuration file, such as stdcs-linux, stdcs-windows and stdcs-solaris. (4) to move DoubleByte, HKSCS and DelegatableDecoder classes into sun.nio.cs, so they can be used/referenced by those dbcs classes that might be moved into sun.nio.cs (5) to change some sun.nio.cs.ext implementation java files to be a ".template", so the real .java can be generated during build-time with correct pkg name and aliases info. There are two leftover, gb18030 and euc_tw, these are two charsets with huge mapping table. Might need special update to better fit into sun.nio.cs later. thanks! -Sherman

4 5