From john_platts at hotmail.com Sun Jul 2 19:22:49 2017 From: john_platts at hotmail.com (John Platts) Date: Sun, 2 Jul 2017 19:22:49 +0000 Subject: Enhancements to the java.lang.StringCoding class Message-ID: I was looking at the OpenJDK 9 code, and I noticed that optimizations for encoding and decoding from UTF-16 text could be added to the java.lang.StringCoding class. Here is how the optimized UTF-16 decoding could be implemented in java.lang.StringCoding: private static void byteSwapUTF16(byte[] arr, int start) { ? ? for(int i = start; i < arr.length; i += 2) { ? ? ? ? byte b1 = arr[i]; ? ? ? ? byte b2 = arr[i + 1]; ? ? ? ? arr[i] = b2; ? ? ? ? arr[i + 1] = b1; ? ? } } static byte[] encodeUTF16BE(byte coder, byte[] val, boolean includeBOM) { ? ? byte[] result; ? ? if(coder == LATIN1) { ? ? ? ? result = new byte[(val.length + (includeBOM ? 1 : 0)) << 1]; ? ? ? ? int resultStartOffset = includeBOM ? 2 : 0; ? ? ? ?? ? ? ? ? if(includeBOM) { ? ? ? ? ? ? result[0] = (byte)0xFE; ? ? ? ? ? ? result[1] = (byte)0xFF; ? ? ? ? } ? ? ? ? for(int i = 0; i < val.length; i++) { ? ? ? ? ? ? result[resultStartOffset + (i << 1) + 1] = val[i]; ? ? ? ? } ? ? } else { ? ? ? ? result = new byte[val.length + (includeBOM ? 2 : 0)]; ? ? ? ? int resultStartOffset = includeBOM ? 2 : 0; ? ? ? ?? ? ? ? ? if(includeBOM) { ? ? ? ? ? ? result[0] = (byte)0xFE; ? ? ? ? ? ? result[1] = (byte)0xFF; ? ? ? ? } ? ? ? ?? ? ? ? ? System.arraycopy(val, 0, result, resultStartOffset, val.length); ? ? ? ?? ? ? ? ? if(StringUTF16.HI_BYTE_SHIFT == 0) { ? ? ? ? ? ? // val is encoded using little-endian UTF-16 ? ? ? ? ? ? // Convert to big-endian UTF-16 from little-endian UTF-16 ? ? ? ? ? ? byteSwapUTF16(result, resultStartOffset); ? ? ? ? } ? ? ? ?? ? ? ? ? for(int i = resultStartOffset; i < result.length; i += 2) { ? ? ? ? ? ? int b1 = Byte.toUnsignedInt(result[i]); ? ? ? ? ? ? int b3 = result.length - i >= 4 ? Byte.toUnsignedInt(result[i + 2]) : -1; ? ? ? ? ? ? if(b1 >= 0xD8 && b1 <= 0xDF) { ? ? ? ? ? ? ? ? if(b1 <= 0xDB && b3 >= 0xDC && b3 <= 0xDF) { ? ? ? ? ? ? ? ? ? ? // UTF-16 surrogate pair encountered ? ? ? ? ? ? ? ? ? ? // Advance i to the position of the low surrogate ? ? ? ? ? ? ? ? ? ? i += 2; ? ? ? ? ? ? ? ? ? ? // Continue the loop past the low surrogate ? ? ? ? ? ? ? ? ? ? continue; ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? ? // Unpaired surrogate character encountered ? ? ? ? ? ? ? ? // Replace unpaired surrogate character with U+FFFD ? ? ? ? ? ? ? ? result[i] = (byte)0xFF; ? ? ? ? ? ? ? ? result[i + 1] = (byte)0xFD; ? ? ? ? ? ? } ? ? ? ? } ? ? } ? ?? ? ? return result; } static byte[] encodeUTF16LE(byte coder, byte[] val) { ? ? byte[] result; ? ? if(coder == LATIN1) { ? ? ? ? result = new byte[val.length << 1]; ? ? ? ? for(int i = 0; i < val.length; i++) { ? ? ? ? ? ? result[i << 1] = val[i]; ? ? ? ? } ? ? } else { ? ? ? ? result = val.clone(); ? ? ? ? if(StringUTF16.LO_BYTE_SHIFT == 0) { ? ? ? ? ? ? // val is encoded using big-endian UTF-16 ? ? ? ? ? ? // Convert result to little-endian UTF-16 from big-endian UTF-16 by byte swapping ? ? ? ? ? ? byteSwapUTF16(result, 0); ? ? ? ? } ? ? ? ? for(int i = 0; i < result.length; i += 2) { ? ? ? ? ? ? int b2 = Byte.toUnsignedInt(result[i + 1]); ? ? ? ? ? ? int b4 = result.length - i >= 4 ? Byte.toUnsignedInt(result[i + 3]) : -1; ? ? ? ? ? ? if(b2 >= 0xD8 && b2 <= 0xDF) { ? ? ? ? ? ? ? ? if(b2 <= 0xDB && b4 >= 0xDC && b4 <= 0xDF) { ? ? ? ? ? ? ? ? ? ? // UTF-16 surrogate pair encountered ? ? ? ? ? ? ? ? ? ? // Advance i to the position of the low surrogate ? ? ? ? ? ? ? ? ? ? i += 2; ? ? ? ? ? ? ? ? ? ? // Continue the loop past the low surrogate ? ? ? ? ? ? ? ? ? ? continue; ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? ? // Unpaired surrogate character encountered ? ? ? ? ? ? ? ? // Replace unpaired surrogate character with U+FFFD ? ? ? ? ? ? ? ? result[i] = (byte)0xFD; ? ? ? ? ? ? ? ? result[i + 1] = (byte)0xFF; ? ? ? ? ? ? } ? ? ? ? } ? ? } ? ? return result; } static Result bomDetectDecodeUTF16(byte[] ba, int off, int len) { ? ? boolean bigEndian = true; ? ?? ? ? if(len >= 2) { ? ? ? ? int b1 = Byte.toUnsignedInt(ba[off]); ? ? ? ? int b2 = Byte.toUnsignedInt(ba[off + 1]); ? ? ? ? if(b1 == 0xFE && b2 == 0xFF) { ? ? ? ? ? ? // Big-endian BOM detected ? ? ? ? ? ? off += 2; ? ? ? ? ? ? len -= 2; ? ? ? ? } else if(b1 == 0xFF && b2 == 0xFE) { ? ? ? ? ? ? // Little-endian BOM detected ? ? ? ? ? ? off += 2; ? ? ? ? ? ? len -= 2; ? ? ? ? ? ? bigEndian = false; ? ? ? ? } ? ? } ? ?? ? ? return decodeUTF16(ba, off, len, bigEndian); } static Result decodeUTF16(byte[] ba, int off, int len, boolean bigEndian) { ? ? Result result = new Result(); ? ?? ? ? if(len == 0) { ? ? ? ? return result.with(); ? ? } ? ?? ? ? byte[] decodedArr; ? ? ? ? if(COMPACT_STRINGS && (len & 1) == 0) { ? ? ? ? // Check for non-Latin1 characters ? ? ? ? boolean containsNonLatin1 = false; ? ? ? ? for(int i = 0; i < len; i += 2) { ? ? ? ? ? ? if(ba[off + i + (bigEndian ? 0 : 1)] != 0) { ? ? ? ? ? ? ? ? containsNonLatin1 = true; ? ? ? ? ? ? ? ? break; ? ? ? ? ? ? } ? ? ? ? } ? ? ? ? // If the input only contains Latin1 characters, copy the source characters ? ? ? ? // to a Latin1-encoded byte array, and return the decoded text. ? ? ? ? if(!containsNonLatin1) { ? ? ? ? ? ? decodedArr = new byte[len >> 1]; ? ? ? ? ? ?? ? ? ? ? ? ? for(int i = 0; i < decodedArr.length; i++) { ? ? ? ? ? ? ? ? decodedArr[i] = ba[off + (i << 1) + (bigEndian ? 1 : 0)]; ? ? ? ? ? ? } ? ? ? ? ? ?? ? ? ? ? ? ? return result.with(decodedArr, LATIN1); ? ? ? ? } ? ? } ? ?? ? ? decodedArr = new byte[len + (len & 1)]; ? ? System.arraycopy(ba, off, decodedArr, 0, len); ? ?? ? ? if(StringUTF16.HI_BYTE_SHIFT != (bigEndian ? 8 : 0)) { ? ? ? ? // Input byte order does not match system byte order ? ? ? ? // Byte swap decodedArr so that decodedArr is in system byte order ? ? ? ? byteSwapUTF16(decodedArr, 0); ? ? } ? ? // decodedArr is now in system byte order ? ? if((len & 1) != 0) { ? ? ? ? // If len is odd, then there is a malformed character at the end. ? ? ? ? // Replace the last character in decodedArr with U+FFFD if this is the case. ? ? ? ? StringUTF16.putChar(decodedArr, (decodedArr.length >> 1) - 1, 0xFFFD); ? ? ? ? // Decrement len by 1 to make len even. ? ? ? ? len--; ? ? } ? ? // len is now even ? ? // charLen is equal to the number of UTF-16 characters in decodedArr ? ? int charLen = len >> 1; ? ?? ? ? // replace the reversed BOM and unpaired surrogates with U+FFFD ? ? for(int i = 0; i < charLen; i++) { ? ? ? ? char ch = StringUTF16.getChar(decodedArr, i); ? ? ? ? if(charLen - i >= 2 && ? ? ? ? ? ? Character.isSurrogatePair(ch, StringUTF16.getChar(decodedArr, i + 1)) { ? ? ? ? ? ? // Surrogate pair detected ? ? ? ? ? ?? ? ? ? ? ? ? // Increment i to the position of the low surrogate ? ? ? ? ? ? i++; ? ? ? ? ? ?? ? ? ? ? ? ? // Continue the loop ? ? ? ? ? ? continue; ? ? ? ? } ? ? ? ? if(ch == (char)0xFFFE || Character.isSurrogate(ch)) { ? ? ? ? ? ? // Reversed BOM or unpaired surrogate encountered ? ? ? ? ? ? // Replace ch with 0xFFFD ? ? ? ? ? ? StringUTF16.putChar(decodedArr, i, (char)0xFFFD); ? ? ? ? } ? ? } ? ?? ? ? // If compact strings are enabled, return a Latin1-encoded result if the result ? ? // does not contain any non-Latin-1 characters. ? ? if(COMPACT_STRINGS) { ? ? ? ? byte[] compressedArr = StringUTF16.compress(decodedArr, 0, decodedArr.len); ? ? ? ? if(compressedArr != null) { ? ? ? ? ? ? return result.with(compressedArr, LATIN1); ? ? ? ? } ? ? } ? ?? ? ? return result.with(decodedArr, UTF16); } private static class StringDecoderUTF_16 extends StringDecoder { StringDecoderUTF_16(Charset cs, String rcn) { super(cs, rcn); } Result decode(byte[] ba, int off, int len) { return bomDetectDecodeUTF16(ba, off, len); } } private static class StringDecoderUTF_16LE extends StringDecoder { StringDecoderUTF_16(Charset cs, String rcn) { super(cs, rcn); } Result decode(byte[] ba, int off, int len) { return decodeUTF16(ba, off, len, false); } } private static class StringDecoderUTF_16BE extends StringDecoder { StringDecoderUTF_16(Charset cs, String rcn) { super(cs, rcn); } Result decode(byte[] ba, int off, int len) { return decodeUTF16(ba, off, len, true); } } static Result decode(String charsetName, byte[] ba, int off, int len) throws UnsupportedEncodingException { StringDecoder sd = deref(decoder); String csn = (charsetName == null) ? "ISO-8859-1" : charsetName; if ((sd == null) || !(csn.equals(sd.requestedCharsetName()) || csn.equals(sd.charsetName()))) { sd = null; try { Charset cs = lookupCharset(csn); if (cs != null) { if (cs == UTF_8) { sd = new StringDecoderUTF8(cs, csn); } else if (cs == ISO_8859_1) { sd = new StringDecoder8859_1(cs, csn); } else if(cs == StandardCharsets.UTF_16) { sd = new StringDecoderUTF_16(cs, csn); } else if(cs == StandardCharsets.UTF_16LE) { sd = new StringDecoderUTF_16LE(cs, csn); } else if(cs == StandardCharsets.UTF_16BE) { sd = new StringDecoderUTF_16BE(cs, csn); } else { sd = new StringDecoder(cs, csn); } } } catch (IllegalCharsetNameException x) {} if (sd == null) throw new UnsupportedEncodingException(csn); set(decoder, sd); } return sd.decode(ba, off, len); } } static byte[] encode(Charset cs, byte coder, byte[] val) { if (cs == UTF_8) { return encodeUTF8(coder, val); } else if (cs == ISO_8859_1) { return encode8859_1(coder, val); } else if (cs == US_ASCII) { return encodeASCII(coder, val); } else if (cs == StandardCharsets.UTF_16 || cs == StandardCharsets.UTF_16BE){ return encodeUTF16BE(coder, val, cs == StandardCharsets.UTF_16); } else if (cs == StandardCharsets.UTF_16LE) { return encodeUTF16LE(coder, val); } CharsetEncoder ce = cs.newEncoder(); // fastpath for ascii compatible if (coder == LATIN1 && (((ce instanceof ArrayEncoder) && ((ArrayEncoder)ce).isASCIICompatible() && !hasNegatives(val, 0, val.length)))) { return Arrays.copyOf(val, val.length); } int len = val.length >> coder; // assume LATIN1=0/UTF16=1; int en = scale(len, ce.maxBytesPerChar()); byte[] ba = new byte[en]; if (len == 0) { return ba; } boolean isTrusted = System.getSecurityManager() == null || cs.getClass().getClassLoader0() == null; ce.onMalformedInput(CodingErrorAction.REPLACE) .onUnmappableCharacter(CodingErrorAction.REPLACE) .reset(); if (ce instanceof ArrayEncoder) { if (!isTrusted) { val = Arrays.copyOf(val, val.length); } int blen = (coder == LATIN1 ) ? ((ArrayEncoder)ce).encodeFromLatin1(val, 0, len, ba) : ((ArrayEncoder)ce).encodeFromUTF16(val, 0, len, ba); if (blen != -1) { return safeTrim(ba, blen, isTrusted); } } char[] ca = (coder == LATIN1 ) ? StringLatin1.toChars(val) : StringUTF16.toChars(val); ByteBuffer bb = ByteBuffer.wrap(ba); CharBuffer cb = CharBuffer.wrap(ca, 0, len); try { CoderResult cr = ce.encode(cb, bb, true); if (!cr.isUnderflow()) cr.throwException(); cr = ce.flush(bb); if (!cr.isUnderflow()) cr.throwException(); } catch (CharacterCodingException x) { throw new Error(x); } return safeTrim(ba, bb.position(), isTrusted); } From martinrb at google.com Sun Jul 2 23:05:03 2017 From: martinrb at google.com (Martin Buchholz) Date: Sun, 2 Jul 2017 16:05:03 -0700 Subject: Enhancements to the java.lang.StringCoding class In-Reply-To: References: Message-ID: Very high level: UTF-16 is not expected to be a popular encoding for text outside the JDK. Everyone is supposed to be migrating to UTF-8 from ISO-8859-1 and other legacy encodings. The fact that people (like you and I) are writing specialized encoders/decoders outside of the "real" charset implementations for better performance suggests that the nio charset API could be rethought. On Sun, Jul 2, 2017 at 12:22 PM, John Platts wrote: > I was looking at the OpenJDK 9 code, and I noticed that optimizations for > encoding and decoding from UTF-16 text could be added to the > java.lang.StringCoding class. > > Here is how the optimized UTF-16 decoding could be implemented in > java.lang.StringCoding: > private static void byteSwapUTF16(byte[] arr, int start) { > for(int i = start; i < arr.length; i += 2) { > byte b1 = arr[i]; > byte b2 = arr[i + 1]; > > > arr[i] = b2; > arr[i + 1] = b1; > } > } > > static byte[] encodeUTF16BE(byte coder, byte[] val, boolean includeBOM) { > byte[] result; > > if(coder == LATIN1) { > result = new byte[(val.length + (includeBOM ? 1 : 0)) << 1]; > int resultStartOffset = includeBOM ? 2 : 0; > > if(includeBOM) { > result[0] = (byte)0xFE; > result[1] = (byte)0xFF; > } > > for(int i = 0; i < val.length; i++) { > result[resultStartOffset + (i << 1) + 1] = val[i]; > } > } else { > result = new byte[val.length + (includeBOM ? 2 : 0)]; > int resultStartOffset = includeBOM ? 2 : 0; > > if(includeBOM) { > result[0] = (byte)0xFE; > result[1] = (byte)0xFF; > } > > System.arraycopy(val, 0, result, resultStartOffset, val.length); > > if(StringUTF16.HI_BYTE_SHIFT == 0) { > // val is encoded using little-endian UTF-16 > // Convert to big-endian UTF-16 from little-endian UTF-16 > byteSwapUTF16(result, resultStartOffset); > } > > for(int i = resultStartOffset; i < result.length; i += 2) { > int b1 = Byte.toUnsignedInt(result[i]); > int b3 = result.length - i >= 4 ? Byte.toUnsignedInt(result[i > + 2]) : -1; > if(b1 >= 0xD8 && b1 <= 0xDF) { > if(b1 <= 0xDB && b3 >= 0xDC && b3 <= 0xDF) { > // UTF-16 surrogate pair encountered > > // Advance i to the position of the low surrogate > i += 2; > > // Continue the loop past the low surrogate > continue; > } > > // Unpaired surrogate character encountered > // Replace unpaired surrogate character with U+FFFD > result[i] = (byte)0xFF; > result[i + 1] = (byte)0xFD; > } > } > } > > return result; > } > > static byte[] encodeUTF16LE(byte coder, byte[] val) { > byte[] result; > > if(coder == LATIN1) { > result = new byte[val.length << 1]; > > for(int i = 0; i < val.length; i++) { > result[i << 1] = val[i]; > } > } else { > result = val.clone(); > > if(StringUTF16.LO_BYTE_SHIFT == 0) { > // val is encoded using big-endian UTF-16 > > // Convert result to little-endian UTF-16 from big-endian > UTF-16 by byte swapping > byteSwapUTF16(result, 0); > } > > for(int i = 0; i < result.length; i += 2) { > int b2 = Byte.toUnsignedInt(result[i + 1]); > int b4 = result.length - i >= 4 ? Byte.toUnsignedInt(result[i > + 3]) : -1; > if(b2 >= 0xD8 && b2 <= 0xDF) { > if(b2 <= 0xDB && b4 >= 0xDC && b4 <= 0xDF) { > // UTF-16 surrogate pair encountered > > // Advance i to the position of the low surrogate > i += 2; > > // Continue the loop past the low surrogate > continue; > } > > // Unpaired surrogate character encountered > // Replace unpaired surrogate character with U+FFFD > result[i] = (byte)0xFD; > result[i + 1] = (byte)0xFF; > } > } > } > > return result; > } > > static Result bomDetectDecodeUTF16(byte[] ba, int off, int len) { > boolean bigEndian = true; > > if(len >= 2) { > int b1 = Byte.toUnsignedInt(ba[off]); > int b2 = Byte.toUnsignedInt(ba[off + 1]); > if(b1 == 0xFE && b2 == 0xFF) { > // Big-endian BOM detected > off += 2; > len -= 2; > } else if(b1 == 0xFF && b2 == 0xFE) { > // Little-endian BOM detected > off += 2; > len -= 2; > bigEndian = false; > } > } > > return decodeUTF16(ba, off, len, bigEndian); > } > > > static Result decodeUTF16(byte[] ba, int off, int len, boolean bigEndian) { > Result result = new Result(); > > if(len == 0) { > return result.with(); > } > > byte[] decodedArr; > if(COMPACT_STRINGS && (len & 1) == 0) { > // Check for non-Latin1 characters > boolean containsNonLatin1 = false; > for(int i = 0; i < len; i += 2) { > if(ba[off + i + (bigEndian ? 0 : 1)] != 0) { > containsNonLatin1 = true; > break; > } > } > > // If the input only contains Latin1 characters, copy the source > characters > // to a Latin1-encoded byte array, and return the decoded text. > if(!containsNonLatin1) { > decodedArr = new byte[len >> 1]; > > for(int i = 0; i < decodedArr.length; i++) { > decodedArr[i] = ba[off + (i << 1) + (bigEndian ? 1 : 0)]; > } > > return result.with(decodedArr, LATIN1); > } > } > > decodedArr = new byte[len + (len & 1)]; > System.arraycopy(ba, off, decodedArr, 0, len); > > if(StringUTF16.HI_BYTE_SHIFT != (bigEndian ? 8 : 0)) { > // Input byte order does not match system byte order > > // Byte swap decodedArr so that decodedArr is in system byte order > byteSwapUTF16(decodedArr, 0); > } > > // decodedArr is now in system byte order > > if((len & 1) != 0) { > // If len is odd, then there is a malformed character at the end. > > // Replace the last character in decodedArr with U+FFFD if this is > the case. > StringUTF16.putChar(decodedArr, (decodedArr.length >> 1) - 1, > 0xFFFD); > > // Decrement len by 1 to make len even. > len--; > } > > // len is now even > > // charLen is equal to the number of UTF-16 characters in decodedArr > int charLen = len >> 1; > > // replace the reversed BOM and unpaired surrogates with U+FFFD > for(int i = 0; i < charLen; i++) { > char ch = StringUTF16.getChar(decodedArr, i); > > if(charLen - i >= 2 && > Character.isSurrogatePair(ch, StringUTF16.getChar(decodedArr, > i + 1)) { > // Surrogate pair detected > > // Increment i to the position of the low surrogate > i++; > > // Continue the loop > continue; > } > > if(ch == (char)0xFFFE || Character.isSurrogate(ch)) { > // Reversed BOM or unpaired surrogate encountered > > // Replace ch with 0xFFFD > StringUTF16.putChar(decodedArr, i, (char)0xFFFD); > } > } > > // If compact strings are enabled, return a Latin1-encoded result if > the result > // does not contain any non-Latin-1 characters. > if(COMPACT_STRINGS) { > byte[] compressedArr = StringUTF16.compress(decodedArr, 0, > decodedArr.len); > if(compressedArr != null) { > return result.with(compressedArr, LATIN1); > } > } > > return result.with(decodedArr, UTF16); > } > > private static class StringDecoderUTF_16 extends StringDecoder { > StringDecoderUTF_16(Charset cs, String rcn) { > super(cs, rcn); > } > Result decode(byte[] ba, int off, int len) { > return bomDetectDecodeUTF16(ba, off, len); > } > } > > private static class StringDecoderUTF_16LE extends StringDecoder { > StringDecoderUTF_16(Charset cs, String rcn) { > super(cs, rcn); > } > Result decode(byte[] ba, int off, int len) { > return decodeUTF16(ba, off, len, false); > } > } > > private static class StringDecoderUTF_16BE extends StringDecoder { > StringDecoderUTF_16(Charset cs, String rcn) { > super(cs, rcn); > } > Result decode(byte[] ba, int off, int len) { > return decodeUTF16(ba, off, len, true); > } > } > > static Result decode(String charsetName, byte[] ba, int off, int len) > throws UnsupportedEncodingException > { > StringDecoder sd = deref(decoder); > String csn = (charsetName == null) ? "ISO-8859-1" : charsetName; > if ((sd == null) || !(csn.equals(sd.requestedCharsetName()) > || csn.equals(sd.charsetName()))) { > sd = null; > try { > Charset cs = lookupCharset(csn); > if (cs != null) { > if (cs == UTF_8) { > sd = new StringDecoderUTF8(cs, csn); > } else if (cs == ISO_8859_1) { > sd = new StringDecoder8859_1(cs, csn); > } else if(cs == StandardCharsets.UTF_16) { > sd = new StringDecoderUTF_16(cs, csn); > } else if(cs == StandardCharsets.UTF_16LE) { > sd = new StringDecoderUTF_16LE(cs, csn); > } else if(cs == StandardCharsets.UTF_16BE) { > sd = new StringDecoderUTF_16BE(cs, csn); > } else { > sd = new StringDecoder(cs, csn); > } > } > } catch (IllegalCharsetNameException x) {} > if (sd == null) > throw new UnsupportedEncodingException(csn); > set(decoder, sd); > } > return sd.decode(ba, off, len); > } > } > > static byte[] encode(Charset cs, byte coder, byte[] val) { > if (cs == UTF_8) { > return encodeUTF8(coder, val); > } else if (cs == ISO_8859_1) { > return encode8859_1(coder, val); > } else if (cs == US_ASCII) { > return encodeASCII(coder, val); > } else if (cs == StandardCharsets.UTF_16 || cs == > StandardCharsets.UTF_16BE){ > return encodeUTF16BE(coder, val, cs == > StandardCharsets.UTF_16); > } else if (cs == StandardCharsets.UTF_16LE) { > return encodeUTF16LE(coder, val); > } > CharsetEncoder ce = cs.newEncoder(); > // fastpath for ascii compatible > if (coder == LATIN1 && (((ce instanceof ArrayEncoder) && > ((ArrayEncoder)ce).isASCIICompatible() && > !hasNegatives(val, 0, val.length)))) { > return Arrays.copyOf(val, val.length); > } > int len = val.length >> coder; // assume LATIN1=0/UTF16=1; > int en = scale(len, ce.maxBytesPerChar()); > byte[] ba = new byte[en]; > if (len == 0) { > return ba; > } > boolean isTrusted = System.getSecurityManager() == null || > cs.getClass().getClassLoader0() == null; > ce.onMalformedInput(CodingErrorAction.REPLACE) > .onUnmappableCharacter(CodingErrorAction.REPLACE) > .reset(); > if (ce instanceof ArrayEncoder) { > if (!isTrusted) { > val = Arrays.copyOf(val, val.length); > } > int blen = (coder == LATIN1 ) ? ((ArrayEncoder)ce).encodeFromLatin1(val, > 0, len, ba) > : ((ArrayEncoder)ce).encodeFromUTF16(val, > 0, len, ba); > if (blen != -1) { > return safeTrim(ba, blen, isTrusted); > } > } > char[] ca = (coder == LATIN1 ) ? StringLatin1.toChars(val) > : StringUTF16.toChars(val); > ByteBuffer bb = ByteBuffer.wrap(ba); > CharBuffer cb = CharBuffer.wrap(ca, 0, len); > try { > CoderResult cr = ce.encode(cb, bb, true); > if (!cr.isUnderflow()) > cr.throwException(); > cr = ce.flush(bb); > if (!cr.isUnderflow()) > cr.throwException(); > } catch (CharacterCodingException x) { > throw new Error(x); > } > return safeTrim(ba, bb.position(), isTrusted); > } From christoph.langer at sap.com Mon Jul 3 08:17:13 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 3 Jul 2017 08:17:13 +0000 Subject: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <3e6fb1a5429549398a98da86f4a3bc49@sap.com> <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Hi, I've pushed to JDK10 now: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7a2bc0a80087 What do you think, shall we try to downport a fix to JDK9 updates and JDK8 updates, which simply removes the volatile as we can't bring this behavior changing fix down? Thanks Christoph > -----Original Message----- > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > Sent: Freitag, 30. Juni 2017 20:31 > To: Se?n Coffey > Cc: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: Re: 8182743: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Sean, > > Thank you for your comments. > > I fixed the copyright and updated webrev: > > http://cr.openjdk.java.net/~horii/8182743/webrev.03/ > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > 8182743 ? > > Yes, they should be 8182743. I fixed both. > > > Regards, > Ogata > > > Se?n Coffey wrote on 2017/06/30 23:57:25: > > > From: Se?n Coffey > > To: Kazunori Ogata , "Langer, Christoph" > > > > Cc: "ppc-aix-port-dev at openjdk.java.net" > dev at openjdk.java.net>, core-libs-dev , > > "nio-dev at openjdk.java.net" > > Date: 2017/06/30 23:57 > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts > > performance of Charset.atBugLevel() > > > > Ogata, > > > > minor comments from me. > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > 8182743 ? > > * The copyright change in Charset-X-Coder.java.template is the wrong > > format. You can simply replace 2013 with 2017. > > > > Regards, > > Sean. > > > > On 29/06/17 19:49, Kazunori Ogata wrote: > > > Hi Christoph, > > > > > > I updated webrev: > http://cr.openjdk.java.net/~horii/8179527/webrev.02/ > > > > > > This one includes changes in tests. I removed all @run and @build > > > directives in the tests because those after removing "@run > main/othervm > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the > default > > > ones. I checked the modified tests passed. > > > > > > I also fixed the copyright lines. > > > > > > > > > Regards, > > > Ogata > > > > > > > > > "Langer, Christoph" wrote on 2017/06/28 > > > 21:04:36: > > > > > >> From: "Langer, Christoph" > > >> To: Kazunori Ogata > > >> Cc: Alan Bateman , Claes Redestad > > >> , core-libs-dev > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > > > >> dev at openjdk.java.net> > > >> Date: 2017/06/28 21:04 > > >> Subject: RE: 8179527: Ineffective use of volatile hurts performance > of > > >> Charset.atBugLevel() > > >> > > >> Hi Ogata, > > >> > > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > >>> How can I do this? Is it sufficient to remove the following line at > > > the > > >>> beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > > >>> EmptyCharsetName" > > >> Yes, this line should be removed. Currently there are two @run > > > directives > > >> which cause running the testcase twice. Once in normal mode and once > > > with > > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed > > > then > > >> the second iteration of the test is obsolete. And then one should > > > probably > > >> remove the whole "compat" handling in the test. > > >> > > >> Best regards > > >> Christoph > > >> > > > > > > From OGATAK at jp.ibm.com Mon Jul 3 08:28:46 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Mon, 3 Jul 2017 17:28:46 +0900 Subject: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <5aa2f1ea-4fec-6b37-bb23-48b276afc292@oracle.com> <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Hi Christoph, Thank you very much for your help! For JDK9 updates and JDK8 updates, it is desirable if we can back port the removal of volatile. What should I do for it? Regards, Ogata From: "Langer, Christoph" To: Kazunori Ogata , "nio-dev at openjdk.java.net" Cc: core-libs-dev Date: 2017/07/03 17:17 Subject: RE: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() Hi, I've pushed to JDK10 now: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7a2bc0a80087 What do you think, shall we try to downport a fix to JDK9 updates and JDK8 updates, which simply removes the volatile as we can't bring this behavior changing fix down? Thanks Christoph > -----Original Message----- > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > Sent: Freitag, 30. Juni 2017 20:31 > To: Se?n Coffey > Cc: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: Re: 8182743: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Sean, > > Thank you for your comments. > > I fixed the copyright and updated webrev: > > http://cr.openjdk.java.net/~horii/8182743/webrev.03/ > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > 8182743 ? > > Yes, they should be 8182743. I fixed both. > > > Regards, > Ogata > > > Se?n Coffey wrote on 2017/06/30 23:57:25: > > > From: Se?n Coffey > > To: Kazunori Ogata , "Langer, Christoph" > > > > Cc: "ppc-aix-port-dev at openjdk.java.net" > dev at openjdk.java.net>, core-libs-dev , > > "nio-dev at openjdk.java.net" > > Date: 2017/06/30 23:57 > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts > > performance of Charset.atBugLevel() > > > > Ogata, > > > > minor comments from me. > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > 8182743 ? > > * The copyright change in Charset-X-Coder.java.template is the wrong > > format. You can simply replace 2013 with 2017. > > > > Regards, > > Sean. > > > > On 29/06/17 19:49, Kazunori Ogata wrote: > > > Hi Christoph, > > > > > > I updated webrev: > http://cr.openjdk.java.net/~horii/8179527/webrev.02/ > > > > > > This one includes changes in tests. I removed all @run and @build > > > directives in the tests because those after removing "@run > main/othervm > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the > default > > > ones. I checked the modified tests passed. > > > > > > I also fixed the copyright lines. > > > > > > > > > Regards, > > > Ogata > > > > > > > > > "Langer, Christoph" wrote on 2017/06/28 > > > 21:04:36: > > > > > >> From: "Langer, Christoph" > > >> To: Kazunori Ogata > > >> Cc: Alan Bateman , Claes Redestad > > >> , core-libs-dev > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > > > >> dev at openjdk.java.net> > > >> Date: 2017/06/28 21:04 > > >> Subject: RE: 8179527: Ineffective use of volatile hurts performance > of > > >> Charset.atBugLevel() > > >> > > >> Hi Ogata, > > >> > > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > >>> How can I do this? Is it sufficient to remove the following line at > > > the > > >>> beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > > >>> EmptyCharsetName" > > >> Yes, this line should be removed. Currently there are two @run > > > directives > > >> which cause running the testcase twice. Once in normal mode and once > > > with > > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed > > > then > > >> the second iteration of the test is obsolete. And then one should > > > probably > > >> remove the whole "compat" handling in the test. > > >> > > >> Best regards > > >> Christoph > > >> > > > > > > From sesuncedu at gmail.com Mon Jul 3 19:05:37 2017 From: sesuncedu at gmail.com (Simon Spero) Date: Mon, 3 Jul 2017 15:05:37 -0400 Subject: Zip Extended Timestamp signedness changed in JDK9 but not JDK8 Message-ID: Tracking down the cause of a JDK 9 test failure for Apache Commons Compress under JDK 9 has revealed a change in JDK 9's handling of ZIP extended timestamps compared to JDK8. The issue is caused by a change in the way that extended timestamps are converted into FileTimes. Previously, the value was handled as a uint32 ; however, in http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/48b296b645bd this was changed to be int32 (with the dos timestamp remaining unsigned). JDK9 behavior is correct (properly supporting ZIP related Y2037 and Y2107 bugs); it's just annoying because Commons Compress had the same issue, and it was difficult to figure out which version is correct (unless you go look at the pkware docs). It is strange that this wasn't backported to jdk8u, since other changes to zip rom around the same time are present. Also, this fix doesn't seem to be mentioned in JIRA or the release notes. Simon [Not as annoying as having finishing up a demo of RSA signed class files right before 1.1 came out. Not that I'm bitter or anything :)] From xueming.shen at oracle.com Mon Jul 3 19:18:01 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 03 Jul 2017 12:18:01 -0700 Subject: [10] RFR: 8160199: Language's script should be reflected in user.script on Mac OS X In-Reply-To: <573ae747-69cd-d4e1-e524-feab5e228242@oracle.com> References: <573ae747-69cd-d4e1-e524-feab5e228242@oracle.com> Message-ID: <595A9869.9080005@oracle.com> +1 On 6/28/17, 3:13 PM, Naoto Sato wrote: > Thanks, Brent! Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8160199/webrev.04/ > > And my comments embedded below: > > On 6/28/17 2:16 PM, Brent Christian wrote: >> Hi, Naoto >> >> This looks quite good. >> >> I will test a bit with some of the trickier locales. BTW, the script >> will now also be reflected in Locale.getScript() and >> Locale.getDisplayScript(). >> >> Just a few comments: >> >> --- >> src/java.base/macosx/native/libjava/java_props_macosx.h >> >> Update copyright year >> >> --- >> src/java.base/unix/native/libjava/locale_str.h >> >> Update copyright year > > Done. > >> >> 214 "Hans", "Hans", >> 215 "Hant", "Hant", >> 216 "Latn", "Latn", >> 217 "Cyrl", "Cyrl", >> 218 "Arab", "Arab", >> >> MacOS 10.12 ("Sierra") has a number of new languages not present in >> 10.11, including a few new scripts. I believe these should also be >> added here: >> >> Deva >> Ethi >> Sund >> Syrc >> Tfng > > Good catch! Added those and tested, except "Syrc" script (could not > find on my machine). > >> >> --- >> src/java.base/macosx/native/libjava/java_props_macosx.c >> >> Similar to the previous code, the call to: >> >> 79 CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), >> 80 localeString, LOCALEIDLENGTH, >> CFStringGetSystemEncoding()); >> >> can be moved inside the if(): >> >> 84 if (hyphenPos == NULL || // languageString contains >> ISO639 only, e.g., "en" >> 85 languageString + langStrLen - hyphenPos == 5) { > > Done. > >> >> >> FWIW, I believe this code path will only be taken for MacOS 10.11 and >> earlier. Per TN2418[1] (and my testing thus far), 10.12 will always >> provide a region to 'languageString'. 10.11 and prior often return >> just a two-character language code. > > Yes. > >> >> >> 134 * lang{_region}{@script}. e.g., >> 135 * for "zh-Hans-US" into "zh_US at Hans" >> >> This comment could fit on one line. >> >> >> 152 char tmp[4]; >> >> Maybe a more descriptive name ("tmpScript" ?) > > Done. > >> >> >> 173 assert((length == 3 || length == 8) && >> ... >> >> Idea: adding another set of ()s grouping: >> >> length 3 or 8 case >> length 4 or 9 case >> length == 5 case >> >> would cause each case to highlight nicely in an IDE. Just a thought. > > I grouped those, but haven't confirmed on an IDE :-) >> >> >> A JDK 10 Reviewer will also need to take a look. > > Sure, wait for another review then. > > Naoto > >> >> Thanks, >> -Brent >> >> 1. >> https://developer.apple.com/library/content/technotes/tn2418/_index.html >> >> >> On 6/28/17 10:51 AM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160199 >>> >>> The fix is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ >>> >>> The gist of the issue was that the script code has not been properly >>> treated in macOS specific code. Since it shares the same code with >>> other Unix, the locale format should follow POSIX, such as >>> az-Cyrl-AZ needing to be az_AZ at Cyrl. >>> >>> Naoto From sesuncedu at gmail.com Mon Jul 3 19:39:48 2017 From: sesuncedu at gmail.com (Simon Spero) Date: Mon, 3 Jul 2017 15:39:48 -0400 Subject: Is there any reason why the MacOS X port doesn't provide a UserDefinedFileAttributeView? Message-ID: It seems like it ought be relatively simple to add, since the API is not too far off of Linux (with NO_FOLLOW as an option to syscall rather than a separate entry point). Also, will trees for 9.x be split repositories, or will the consolidator work his magic? From Alan.Bateman at oracle.com Mon Jul 3 20:05:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Jul 2017 21:05:59 +0100 Subject: Is there any reason why the MacOS X port doesn't provide a UserDefinedFileAttributeView? In-Reply-To: References: Message-ID: On 03/07/2017 20:39, Simon Spero wrote: > It seems like it ought be relatively simple to add, since the API is not > too far off of Linux (with NO_FOLLOW as an option to syscall rather than a > separate entry point). > This has been discussed on nio-dev once or twice. It wasn't in the original port from Apple and just hasn't bubbled to the top of anyone's list. -Alan. From Alan.Bateman at oracle.com Mon Jul 3 20:09:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Jul 2017 21:09:22 +0100 Subject: Zip Extended Timestamp signedness changed in JDK9 but not JDK8 In-Reply-To: References: Message-ID: On 03/07/2017 20:05, Simon Spero wrote: > : > > It is strange that this wasn't backported to jdk8u, since other changes to > zip rom around the same time are present. Also, this fix doesn't seem to > be mentioned in JIRA or the release notes. > There were API changes as part of this update so not appropriate to backport. More generally, the zip code has changed significantly in JDK 9 to replace native implementation. I think the highest priority is to make sure that there aren't any corner cases that were handled in 8 but not handled in 9. -Alan From xueming.shen at oracle.com Mon Jul 3 22:54:25 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 03 Jul 2017 15:54:25 -0700 Subject: Enhancements to the java.lang.StringCoding class In-Reply-To: References: Message-ID: <595ACB21.2090501@oracle.com> As Martin pointed out, the UTF-16 variants probably are not critical enough to have "special" fastpath implementation in StringCoding. If better performance of these UTF-16 charsets is really desired, it might be worth implementing the sun.nio.ArrayDe/Encoder interface in UnicodeDe/Encoder to speed up the String/char[]/byte[] de/encoding. Most frequent-used charsets in jdk repository now have this fastpath enabled. Martin, what's the real use case that forces you to rewrite the charset implementation outside the jdk? To add back convenient de/encoding methods to work with byte[]/char[] directly? (to add public interface/methods similar to sun.nio.ArrayDe/Encoder, for example) Convenient methods doing de/encoding with ByteBuffer/CharBuffer Gathering/Scattering might be something we want to do for 10 ... -Sherman On 7/2/17, 4:05 PM, Martin Buchholz wrote: > Very high level: > > UTF-16 is not expected to be a popular encoding for text outside the JDK. > Everyone is supposed to be migrating to UTF-8 from ISO-8859-1 and other > legacy encodings. > > The fact that people (like you and I) are writing specialized > encoders/decoders outside of the "real" charset implementations for better > performance suggests that the nio charset API could be rethought. > > On Sun, Jul 2, 2017 at 12:22 PM, John Platts > wrote: > >> I was looking at the OpenJDK 9 code, and I noticed that optimizations for >> encoding and decoding from UTF-16 text could be added to the >> java.lang.StringCoding class. >> >> Here is how the optimized UTF-16 decoding could be implemented in >> java.lang.StringCoding: >> private static void byteSwapUTF16(byte[] arr, int start) { >> for(int i = start; i< arr.length; i += 2) { >> byte b1 = arr[i]; >> byte b2 = arr[i + 1]; >> >> >> arr[i] = b2; >> arr[i + 1] = b1; >> } >> } >> >> static byte[] encodeUTF16BE(byte coder, byte[] val, boolean includeBOM) { >> byte[] result; >> >> if(coder == LATIN1) { >> result = new byte[(val.length + (includeBOM ? 1 : 0))<< 1]; >> int resultStartOffset = includeBOM ? 2 : 0; >> >> if(includeBOM) { >> result[0] = (byte)0xFE; >> result[1] = (byte)0xFF; >> } >> >> for(int i = 0; i< val.length; i++) { >> result[resultStartOffset + (i<< 1) + 1] = val[i]; >> } >> } else { >> result = new byte[val.length + (includeBOM ? 2 : 0)]; >> int resultStartOffset = includeBOM ? 2 : 0; >> >> if(includeBOM) { >> result[0] = (byte)0xFE; >> result[1] = (byte)0xFF; >> } >> >> System.arraycopy(val, 0, result, resultStartOffset, val.length); >> >> if(StringUTF16.HI_BYTE_SHIFT == 0) { >> // val is encoded using little-endian UTF-16 >> // Convert to big-endian UTF-16 from little-endian UTF-16 >> byteSwapUTF16(result, resultStartOffset); >> } >> >> for(int i = resultStartOffset; i< result.length; i += 2) { >> int b1 = Byte.toUnsignedInt(result[i]); >> int b3 = result.length - i>= 4 ? Byte.toUnsignedInt(result[i >> + 2]) : -1; >> if(b1>= 0xD8&& b1<= 0xDF) { >> if(b1<= 0xDB&& b3>= 0xDC&& b3<= 0xDF) { >> // UTF-16 surrogate pair encountered >> >> // Advance i to the position of the low surrogate >> i += 2; >> >> // Continue the loop past the low surrogate >> continue; >> } >> >> // Unpaired surrogate character encountered >> // Replace unpaired surrogate character with U+FFFD >> result[i] = (byte)0xFF; >> result[i + 1] = (byte)0xFD; >> } >> } >> } >> >> return result; >> } >> >> static byte[] encodeUTF16LE(byte coder, byte[] val) { >> byte[] result; >> >> if(coder == LATIN1) { >> result = new byte[val.length<< 1]; >> >> for(int i = 0; i< val.length; i++) { >> result[i<< 1] = val[i]; >> } >> } else { >> result = val.clone(); >> >> if(StringUTF16.LO_BYTE_SHIFT == 0) { >> // val is encoded using big-endian UTF-16 >> >> // Convert result to little-endian UTF-16 from big-endian >> UTF-16 by byte swapping >> byteSwapUTF16(result, 0); >> } >> >> for(int i = 0; i< result.length; i += 2) { >> int b2 = Byte.toUnsignedInt(result[i + 1]); >> int b4 = result.length - i>= 4 ? Byte.toUnsignedInt(result[i >> + 3]) : -1; >> if(b2>= 0xD8&& b2<= 0xDF) { >> if(b2<= 0xDB&& b4>= 0xDC&& b4<= 0xDF) { >> // UTF-16 surrogate pair encountered >> >> // Advance i to the position of the low surrogate >> i += 2; >> >> // Continue the loop past the low surrogate >> continue; >> } >> >> // Unpaired surrogate character encountered >> // Replace unpaired surrogate character with U+FFFD >> result[i] = (byte)0xFD; >> result[i + 1] = (byte)0xFF; >> } >> } >> } >> >> return result; >> } >> >> static Result bomDetectDecodeUTF16(byte[] ba, int off, int len) { >> boolean bigEndian = true; >> >> if(len>= 2) { >> int b1 = Byte.toUnsignedInt(ba[off]); >> int b2 = Byte.toUnsignedInt(ba[off + 1]); >> if(b1 == 0xFE&& b2 == 0xFF) { >> // Big-endian BOM detected >> off += 2; >> len -= 2; >> } else if(b1 == 0xFF&& b2 == 0xFE) { >> // Little-endian BOM detected >> off += 2; >> len -= 2; >> bigEndian = false; >> } >> } >> >> return decodeUTF16(ba, off, len, bigEndian); >> } >> >> >> static Result decodeUTF16(byte[] ba, int off, int len, boolean bigEndian) { >> Result result = new Result(); >> >> if(len == 0) { >> return result.with(); >> } >> >> byte[] decodedArr; >> if(COMPACT_STRINGS&& (len& 1) == 0) { >> // Check for non-Latin1 characters >> boolean containsNonLatin1 = false; >> for(int i = 0; i< len; i += 2) { >> if(ba[off + i + (bigEndian ? 0 : 1)] != 0) { >> containsNonLatin1 = true; >> break; >> } >> } >> >> // If the input only contains Latin1 characters, copy the source >> characters >> // to a Latin1-encoded byte array, and return the decoded text. >> if(!containsNonLatin1) { >> decodedArr = new byte[len>> 1]; >> >> for(int i = 0; i< decodedArr.length; i++) { >> decodedArr[i] = ba[off + (i<< 1) + (bigEndian ? 1 : 0)]; >> } >> >> return result.with(decodedArr, LATIN1); >> } >> } >> >> decodedArr = new byte[len + (len& 1)]; >> System.arraycopy(ba, off, decodedArr, 0, len); >> >> if(StringUTF16.HI_BYTE_SHIFT != (bigEndian ? 8 : 0)) { >> // Input byte order does not match system byte order >> >> // Byte swap decodedArr so that decodedArr is in system byte order >> byteSwapUTF16(decodedArr, 0); >> } >> >> // decodedArr is now in system byte order >> >> if((len& 1) != 0) { >> // If len is odd, then there is a malformed character at the end. >> >> // Replace the last character in decodedArr with U+FFFD if this is >> the case. >> StringUTF16.putChar(decodedArr, (decodedArr.length>> 1) - 1, >> 0xFFFD); >> >> // Decrement len by 1 to make len even. >> len--; >> } >> >> // len is now even >> >> // charLen is equal to the number of UTF-16 characters in decodedArr >> int charLen = len>> 1; >> >> // replace the reversed BOM and unpaired surrogates with U+FFFD >> for(int i = 0; i< charLen; i++) { >> char ch = StringUTF16.getChar(decodedArr, i); >> >> if(charLen - i>= 2&& >> Character.isSurrogatePair(ch, StringUTF16.getChar(decodedArr, >> i + 1)) { >> // Surrogate pair detected >> >> // Increment i to the position of the low surrogate >> i++; >> >> // Continue the loop >> continue; >> } >> >> if(ch == (char)0xFFFE || Character.isSurrogate(ch)) { >> // Reversed BOM or unpaired surrogate encountered >> >> // Replace ch with 0xFFFD >> StringUTF16.putChar(decodedArr, i, (char)0xFFFD); >> } >> } >> >> // If compact strings are enabled, return a Latin1-encoded result if >> the result >> // does not contain any non-Latin-1 characters. >> if(COMPACT_STRINGS) { >> byte[] compressedArr = StringUTF16.compress(decodedArr, 0, >> decodedArr.len); >> if(compressedArr != null) { >> return result.with(compressedArr, LATIN1); >> } >> } >> >> return result.with(decodedArr, UTF16); >> } >> >> private static class StringDecoderUTF_16 extends StringDecoder { >> StringDecoderUTF_16(Charset cs, String rcn) { >> super(cs, rcn); >> } >> Result decode(byte[] ba, int off, int len) { >> return bomDetectDecodeUTF16(ba, off, len); >> } >> } >> >> private static class StringDecoderUTF_16LE extends StringDecoder { >> StringDecoderUTF_16(Charset cs, String rcn) { >> super(cs, rcn); >> } >> Result decode(byte[] ba, int off, int len) { >> return decodeUTF16(ba, off, len, false); >> } >> } >> >> private static class StringDecoderUTF_16BE extends StringDecoder { >> StringDecoderUTF_16(Charset cs, String rcn) { >> super(cs, rcn); >> } >> Result decode(byte[] ba, int off, int len) { >> return decodeUTF16(ba, off, len, true); >> } >> } >> >> static Result decode(String charsetName, byte[] ba, int off, int len) >> throws UnsupportedEncodingException >> { >> StringDecoder sd = deref(decoder); >> String csn = (charsetName == null) ? "ISO-8859-1" : charsetName; >> if ((sd == null) || !(csn.equals(sd.requestedCharsetName()) >> || csn.equals(sd.charsetName()))) { >> sd = null; >> try { >> Charset cs = lookupCharset(csn); >> if (cs != null) { >> if (cs == UTF_8) { >> sd = new StringDecoderUTF8(cs, csn); >> } else if (cs == ISO_8859_1) { >> sd = new StringDecoder8859_1(cs, csn); >> } else if(cs == StandardCharsets.UTF_16) { >> sd = new StringDecoderUTF_16(cs, csn); >> } else if(cs == StandardCharsets.UTF_16LE) { >> sd = new StringDecoderUTF_16LE(cs, csn); >> } else if(cs == StandardCharsets.UTF_16BE) { >> sd = new StringDecoderUTF_16BE(cs, csn); >> } else { >> sd = new StringDecoder(cs, csn); >> } >> } >> } catch (IllegalCharsetNameException x) {} >> if (sd == null) >> throw new UnsupportedEncodingException(csn); >> set(decoder, sd); >> } >> return sd.decode(ba, off, len); >> } >> } >> >> static byte[] encode(Charset cs, byte coder, byte[] val) { >> if (cs == UTF_8) { >> return encodeUTF8(coder, val); >> } else if (cs == ISO_8859_1) { >> return encode8859_1(coder, val); >> } else if (cs == US_ASCII) { >> return encodeASCII(coder, val); >> } else if (cs == StandardCharsets.UTF_16 || cs == >> StandardCharsets.UTF_16BE){ >> return encodeUTF16BE(coder, val, cs == >> StandardCharsets.UTF_16); >> } else if (cs == StandardCharsets.UTF_16LE) { >> return encodeUTF16LE(coder, val); >> } >> CharsetEncoder ce = cs.newEncoder(); >> // fastpath for ascii compatible >> if (coder == LATIN1&& (((ce instanceof ArrayEncoder)&& >> ((ArrayEncoder)ce).isASCIICompatible()&& >> !hasNegatives(val, 0, val.length)))) { >> return Arrays.copyOf(val, val.length); >> } >> int len = val.length>> coder; // assume LATIN1=0/UTF16=1; >> int en = scale(len, ce.maxBytesPerChar()); >> byte[] ba = new byte[en]; >> if (len == 0) { >> return ba; >> } >> boolean isTrusted = System.getSecurityManager() == null || >> cs.getClass().getClassLoader0() == null; >> ce.onMalformedInput(CodingErrorAction.REPLACE) >> .onUnmappableCharacter(CodingErrorAction.REPLACE) >> .reset(); >> if (ce instanceof ArrayEncoder) { >> if (!isTrusted) { >> val = Arrays.copyOf(val, val.length); >> } >> int blen = (coder == LATIN1 ) ? ((ArrayEncoder)ce).encodeFromLatin1(val, >> 0, len, ba) >> : ((ArrayEncoder)ce).encodeFromUTF16(val, >> 0, len, ba); >> if (blen != -1) { >> return safeTrim(ba, blen, isTrusted); >> } >> } >> char[] ca = (coder == LATIN1 ) ? StringLatin1.toChars(val) >> : StringUTF16.toChars(val); >> ByteBuffer bb = ByteBuffer.wrap(ba); >> CharBuffer cb = CharBuffer.wrap(ca, 0, len); >> try { >> CoderResult cr = ce.encode(cb, bb, true); >> if (!cr.isUnderflow()) >> cr.throwException(); >> cr = ce.flush(bb); >> if (!cr.isUnderflow()) >> cr.throwException(); >> } catch (CharacterCodingException x) { >> throw new Error(x); >> } >> return safeTrim(ba, bb.position(), isTrusted); >> } From amy.lu at oracle.com Tue Jul 4 02:51:19 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 4 Jul 2017 10:51:19 +0800 Subject: JDK 10 RFR of JDK-8183512: Remove intermittent key from nio test Transfer4GBFile.java TransferTo6GBFile.java and StressLoopback.java In-Reply-To: <48c7b02e-c4a9-ada5-d266-6586d8c8d0c7@oracle.com> References: <48c7b02e-c4a9-ada5-d266-6586d8c8d0c7@oracle.com> Message-ID: Including core-libs-dev On 7/4/17 10:13 AM, Amy Lu wrote: > java/nio/channels/FileChannel/Transfer4GBFile.java > java/nio/channels/FileChannel/TransferTo6GBFile.java > java/nio/channels/AsynchronousSocketChannel/StressLoopback.java > > Tests were failing intermittently and the related bugs (JDK-8176895, > JDK-8177550 and JDK-8171347) have been fixed, no open bugs (no failure > reported). > > This patch is to remove @key intermittent from these tests. > > bug: https://bugs.openjdk.java.net/browse/JDK-8183512 > webrev: http://cr.openjdk.java.net/~amlu/8183512/webrev.00/ > > Thanks, > Amy > > > --- old/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java 2017-07-04 10:05:50.000000000 +0800 > +++ new/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java 2017-07-04 10:05:50.000000000 +0800 > @@ -26,7 +26,7 @@ > * @summary Stress test connections through the loopback interface > * @run main StressLoopback > * @run main/othervm -Djdk.net.useFastTcpLoopback StressLoopback > - * @key randomness intermittent > + * @key randomness > */ > > import java.nio.ByteBuffer; > --- old/test/java/nio/channels/FileChannel/Transfer4GBFile.java 2017-07-04 10:05:51.000000000 +0800 > +++ new/test/java/nio/channels/FileChannel/Transfer4GBFile.java 2017-07-04 10:05:51.000000000 +0800 > @@ -23,7 +23,6 @@ > > /* @test > * @bug 4638365 > - * @key intermittent > * @summary Test FileChannel.transferFrom and transferTo for 4GB files > * @run testng/timeout=300 Transfer4GBFile > */ > --- old/test/java/nio/channels/FileChannel/TransferTo6GBFile.java 2017-07-04 10:05:52.000000000 +0800 > +++ new/test/java/nio/channels/FileChannel/TransferTo6GBFile.java 2017-07-04 10:05:51.000000000 +0800 > @@ -23,7 +23,6 @@ > > /* @test > * @bug 6253145 > - * @key intermittent > * @summary Test FileChannel.transferTo with file positions up to 8GB > * @run testng/timeout=300 TransferTo6GBFile > */ > > From Alan.Bateman at oracle.com Tue Jul 4 05:52:54 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Jul 2017 06:52:54 +0100 Subject: JDK 10 RFR of JDK-8183512: Remove intermittent key from nio test Transfer4GBFile.java TransferTo6GBFile.java and StressLoopback.java In-Reply-To: <48c7b02e-c4a9-ada5-d266-6586d8c8d0c7@oracle.com> References: <48c7b02e-c4a9-ada5-d266-6586d8c8d0c7@oracle.com> Message-ID: <6a49ce4d-5d6a-33b5-7500-d27907cf506e@oracle.com> On 04/07/2017 03:13, Amy Lu wrote: > java/nio/channels/FileChannel/Transfer4GBFile.java > java/nio/channels/FileChannel/TransferTo6GBFile.java > java/nio/channels/AsynchronousSocketChannel/StressLoopback.java > > Tests were failing intermittently and the related bugs (JDK-8176895, > JDK-8177550 and JDK-8171347) have been fixed, no open bugs (no failure > reported). > > This patch is to remove @key intermittent from these tests. > Looks fine. From volker.simonis at gmail.com Tue Jul 4 09:05:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Jul 2017 11:05:18 +0200 Subject: [10] RFR(XS): 8183534: [TEST] Make detection of compilation mode more robust Message-ID: Hi, can you please review the following trivial change which makes the detection of compilation mode for JTreg more robust: http://cr.openjdk.java.net/~simonis/webrevs/2017/8183534/ https://bugs.openjdk.java.net/browse/JDK-8183534 The compilation mode in JTreg is parsed from the "java.vm.info" system property. The current implementation expects that "java.vm.info" contains exactly one of the strings "mixed mode", "compiled mode" or "interpreted mode" otherwise the detection will fail and JTreg will quit with an error. The detection can be done more robust by searching for the substrings "mixed mode", "compiled mode" or "interpreted mode" instead, thus allowing OpenJDK builders to store additional information in the "java.vm.info" system property. Thank you and best regards, Volker From sesuncedu at gmail.com Tue Jul 4 14:25:32 2017 From: sesuncedu at gmail.com (Simon Spero) Date: Tue, 4 Jul 2017 10:25:32 -0400 Subject: Zip Extended Timestamp signedness changed in JDK9 but not JDK8 In-Reply-To: References: Message-ID: There was a fair degree of backporting of zip timestamp code, but the bugfix to (signed vs unsigned) didn't make it. The corner cases that aren't handled are not-handled consistently. On Mon, Jul 3, 2017 at 4:09 PM, Alan Bateman wrote: > > > On 03/07/2017 20:05, Simon Spero wrote: > >> : >> >> It is strange that this wasn't backported to jdk8u, since other changes to >> zip rom around the same time are present. Also, this fix doesn't seem to >> be mentioned in JIRA or the release notes. >> >> There were API changes as part of this update so not appropriate to > backport. More generally, the zip code has changed significantly in JDK 9 > to replace native implementation. I think the highest priority is to make > sure that there aren't any corner cases that were handled in 8 but not > handled in 9. > > -Alan > From xueming.shen at oracle.com Tue Jul 4 20:26:43 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 04 Jul 2017 13:26:43 -0700 Subject: Zip Extended Timestamp signedness changed in JDK9 but not JDK8 In-Reply-To: References: Message-ID: <595BFA03.4000301@oracle.com> Simon, I would assume it's reasonable to believe 2037/2107 problem is NOT going to be a critical issue for jdk8u, given the fact we are talking about the "timestamp" of a zip entry. I meant I'm pretty much sure jdk8u will not be around :-) when we have any real 2037 entry timestamp, sure we do/can have test cases for such issue. That said, I think we can squeeze in a patch to address this issue when we are adding other relatively "critical" patch(s), if such fix is really desired. -Sherman On 7/4/17, 7:25 AM, Simon Spero wrote: > There was a fair degree of backporting of zip timestamp code, but the > bugfix to (signed vs unsigned) didn't make it. > The corner cases that aren't handled are not-handled consistently. > > On Mon, Jul 3, 2017 at 4:09 PM, Alan Bateman > wrote: > >> >> On 03/07/2017 20:05, Simon Spero wrote: >> >>> : >>> >>> It is strange that this wasn't backported to jdk8u, since other changes to >>> zip rom around the same time are present. Also, this fix doesn't seem to >>> be mentioned in JIRA or the release notes. >>> >>> There were API changes as part of this update so not appropriate to >> backport. More generally, the zip code has changed significantly in JDK 9 >> to replace native implementation. I think the highest priority is to make >> sure that there aren't any corner cases that were handled in 8 but not >> handled in 9. >> >> -Alan >> From garydgregory at gmail.com Tue Jul 4 21:05:53 2017 From: garydgregory at gmail.com (Gary Gregory) Date: Tue, 4 Jul 2017 14:05:53 -0700 Subject: Zip Extended Timestamp signedness changed in JDK9 but not JDK8 In-Reply-To: <595BFA03.4000301@oracle.com> References: <595BFA03.4000301@oracle.com> Message-ID: At the end of the day, my experience over at Apache Commons is that these kinds of bugs waste a meaningful amount of time even if they may not become an application level bug in the future. The bug wastes time now... Gary On Jul 4, 2017 13:27, "Xueming Shen" wrote: > Simon, > > I would assume it's reasonable to believe 2037/2107 problem is NOT going > to be a critical issue > for jdk8u, given the fact we are talking about the "timestamp" of a zip > entry. I meant I'm pretty > much sure jdk8u will not be around :-) when we have any real 2037 entry > timestamp, sure we > do/can have test cases for such issue. That said, I think we can squeeze > in a patch to address > this issue when we are adding other relatively "critical" patch(s), if > such fix is really desired. > > -Sherman > > On 7/4/17, 7:25 AM, Simon Spero wrote: > >> There was a fair degree of backporting of zip timestamp code, but the >> bugfix to (signed vs unsigned) didn't make it. >> The corner cases that aren't handled are not-handled consistently. >> >> On Mon, Jul 3, 2017 at 4:09 PM, Alan Bateman >> wrote: >> >> >>> On 03/07/2017 20:05, Simon Spero wrote: >>> >>> : >>>> >>>> It is strange that this wasn't backported to jdk8u, since other changes >>>> to >>>> zip rom around the same time are present. Also, this fix doesn't seem >>>> to >>>> be mentioned in JIRA or the release notes. >>>> >>>> There were API changes as part of this update so not appropriate to >>>> >>> backport. More generally, the zip code has changed significantly in JDK 9 >>> to replace native implementation. I think the highest priority is to make >>> sure that there aren't any corner cases that were handled in 8 but not >>> handled in 9. >>> >>> -Alan >>> >>> > From xueming.shen at oracle.com Tue Jul 4 23:36:47 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 04 Jul 2017 16:36:47 -0700 Subject: Zip Extended Timestamp signedness changed in JDK9 but not JDK8 In-Reply-To: References: <595BFA03.4000301@oracle.com> Message-ID: <595C268F.6070405@oracle.com> There are two issues here. (1) to fix/support the possible unix timestamp year 2038 issue when that extra timestamp(s) is used; (2) to backport the fix to 8u. I would assume the direct trigger of "wasting a meaningful amount of time ..." is (1) ? Sure the root cause is we did not address year 2038 issue at first place when we added the extra timestamp support in jdk8. My apology :-) Btw, the changeset Simon mentioned/sited actually does not fix the issue. It actually will expose the issue on year 2038 with the signed 32-bit int (it now follows the specification, which says the timestamp is an uint32). The real fix is the changeset for #8161942. https://bugs.openjdk.java.net/browse/JDK-8161942 Sure, we can backport it if desired. My original assumption is that this is something can wait, until there is an escalation/real need ... we might have one now :-) Sherman On 7/4/17, 2:05 PM, Gary Gregory wrote: > At the end of the day, my experience over at Apache Commons is that > these kinds of bugs waste a meaningful amount of time even if they may > not become an application level bug in the future. The bug wastes time > now... > > Gary > > On Jul 4, 2017 13:27, "Xueming Shen" > wrote: > > Simon, > > I would assume it's reasonable to believe 2037/2107 problem is NOT > going to be a critical issue > for jdk8u, given the fact we are talking about the "timestamp" of > a zip entry. I meant I'm pretty > much sure jdk8u will not be around :-) when we have any real 2037 > entry timestamp, sure we > do/can have test cases for such issue. That said, I think we can > squeeze in a patch to address > this issue when we are adding other relatively "critical" > patch(s), if such fix is really desired. > > -Sherman > > On 7/4/17, 7:25 AM, Simon Spero wrote: > > There was a fair degree of backporting of zip timestamp code, > but the > bugfix to (signed vs unsigned) didn't make it. > The corner cases that aren't handled are not-handled consistently. > > On Mon, Jul 3, 2017 at 4:09 PM, Alan > Bateman> > wrote: > > > On 03/07/2017 20:05, Simon Spero wrote: > > : > > It is strange that this wasn't backported to jdk8u, > since other changes to > zip rom around the same time are present. Also, this > fix doesn't seem to > be mentioned in JIRA or the release notes. > > There were API changes as part of this update so not > appropriate to > > backport. More generally, the zip code has changed > significantly in JDK 9 > to replace native implementation. I think the highest > priority is to make > sure that there aren't any corner cases that were handled > in 8 but not > handled in 9. > > -Alan > > From Alan.Bateman at oracle.com Wed Jul 5 07:44:23 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Jul 2017 08:44:23 +0100 Subject: 8183536: Update jdk tests to allow for unique test classes directory Message-ID: <790d1102-e20e-bbab-af77-f5b7a48be8f0@oracle.com> jtreg has been updated via CODETOOLS-7902003 [1] to use a unique test.classes directory. This is part of improving the reliability when running tests concurrently. The change exposes issues in a tiny number of tests that use test.classes in odd ways. For the jdk repo then two tests need to be updated. There are a few others in the hotspot [2] and langtools [3] repos that also need to be fixed before the jtreg requiredVersion can be bumped to use a promoted jtreg with the change. While in the area, I also changed a number of recent tests to not use the temporary file system. Tim Bell has created a lot of bugs on this recently, I think because he observed /tmp filling up. The (trivial) patch with the updates to the tests is here: http://cr.openjdk.java.net/~alanb/8183536/webrev/index.html I'd like to get this into jdk10/jdk10 to meet up with the test updates in the other repos. -Alan. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902003 [2] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-July/023841.html [3] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-July/011012.html From christoph.langer at sap.com Wed Jul 5 09:33:03 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 5 Jul 2017 09:33:03 +0000 Subject: [10] RFR(XS): 8183534: [TEST] Make detection of compilation mode more robust In-Reply-To: References: Message-ID: <9ebff9d98af743a29346070a3c8859fa@sap.com> Hi Volker, overall, the change looks good to me. When you create the Exception to print the stack trace (line 129 in the new file), why not add the value of 'java.vm.info' to the message? Also, I don't like the spaces around the '.' before PrintStackTrace() - but maybe that's just my personal taste. ;-) Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Volker Simonis > Sent: Dienstag, 4. Juli 2017 11:05 > To: HotSpot Open Source Developers ; > Java Core Libs > Subject: [10] RFR(XS): 8183534: [TEST] Make detection of compilation mode > more robust > > Hi, > > can you please review the following trivial change which makes the > detection of compilation mode for JTreg more robust: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8183534/ > https://bugs.openjdk.java.net/browse/JDK-8183534 > > The compilation mode in JTreg is parsed from the "java.vm.info" system > property. The current implementation expects that "java.vm.info" > contains exactly one of the strings "mixed mode", "compiled mode" or > "interpreted mode" otherwise the detection will fail and JTreg will > quit with an error. > > The detection can be done more robust by searching for the substrings > "mixed mode", "compiled mode" or "interpreted mode" instead, thus > allowing OpenJDK builders to store additional information in the > "java.vm.info" system property. > > Thank you and best regards, > Volker From lance.andersen at oracle.com Wed Jul 5 10:01:47 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 5 Jul 2017 06:01:47 -0400 Subject: 8183536: Update jdk tests to allow for unique test classes directory In-Reply-To: <790d1102-e20e-bbab-af77-f5b7a48be8f0@oracle.com> References: <790d1102-e20e-bbab-af77-f5b7a48be8f0@oracle.com> Message-ID: <45592BD1-ED0B-48EF-8717-3A41AED58DAB@oracle.com> The changes seem fine Alan Best Lance > On Jul 5, 2017, at 3:44 AM, Alan Bateman wrote: > > jtreg has been updated via CODETOOLS-7902003 [1] to use a unique test.classes directory. This is part of improving the reliability when running tests concurrently. The change exposes issues in a tiny number of tests that use test.classes in odd ways. For the jdk repo then two tests need to be updated. There are a few others in the hotspot [2] and langtools [3] repos that also need to be fixed before the jtreg requiredVersion can be bumped to use a promoted jtreg with the change. > > While in the area, I also changed a number of recent tests to not use the temporary file system. Tim Bell has created a lot of bugs on this recently, I think because he observed /tmp filling up. > > The (trivial) patch with the updates to the tests is here: > http://cr.openjdk.java.net/~alanb/8183536/webrev/index.html > > I'd like to get this into jdk10/jdk10 to meet up with the test updates in the other repos. > > -Alan. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902003 > [2] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-July/023841.html > [3] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-July/011012.html Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From matthias.baesken at sap.com Wed Jul 5 12:30:13 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Jul 2017 12:30:13 +0000 Subject: RFR: 8183286 : Some java/awt and javax/swing tests miss headful jtreg keyword In-Reply-To: <0c3fe6ca1440400587b857d0cb5b8d2d@sap.com> References: <069d902ededa41deaea98b544144c513@sap.com> <0c3fe6ca1440400587b857d0cb5b8d2d@sap.com> Message-ID: Hello all, could I have a review for this small change ? Thanks, Matthias From: Langer, Christoph Sent: Freitag, 30. Juni 2017 23:50 To: Baesken, Matthias ; awt-dev at openjdk.java.net Cc: core-libs-dev at openjdk.java.net; joe.darcy at oracle.com Subject: RE: RFR: 8183286 : Some java/awt and javax/swing tests miss headful jtreg keyword Hi, forwarding this RFR to awt-dev. Please have a look. Thanks Christoph From: Baesken, Matthias Sent: Freitag, 30. Juni 2017 16:59 To: core-libs-dev at openjdk.java.net Cc: Langer, Christoph > Subject: RFR: 8183286 : Some java/awt and javax/swing tests miss headful jtreg keyword Hello all , could you please review the following small change. Some java/awt and javax/swing tests miss the headful jtreg keyword The change JDK-8129822 ( https://bugs.openjdk.java.net/browse/JDK-8129822 ) introduced a jtreg keyword to mark tests as requiring a "headful" (as opposed to "headless") environment to be able to run. But a number of jdk10 jdk jtreg tests from java/awt and javax/swing miss this keyword and run into "headless environment" exceptions and fail when running in a headless environment (has been observed in our internal OpenJDK testing environment at SAP). Suggestion is to add the keyword to the tests missing it to fix this. Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8183286 JDK10 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8183286/ List of jdk tests and exceptions seen : java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java java.awt.HeadlessException at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getScreenDevices(HeadlessGraphicsEnvironment.java:53) at ChoicePopupLocation.main(ChoicePopupLocation.java:49) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) java/awt/Dialog/DialogAboveFrame/DialogAboveFrameTest.java java.lang.RuntimeException: Error: unable to create robot at test.java.awt.regtesthelpers.Util.createRobot(Util.java:91) at DialogAboveFrameTest.main(DialogAboveFrameTest.java:44) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at test.java.awt.regtesthelpers.Util.createRobot(Util.java:87) ... 7 more java/awt/font/TextLayout/ArabicDiacriticTest.java java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at java.desktop/javax.swing.JFrame.(JFrame.java:180) at ArabicDiacriticTest.lambda$showText$0(ArabicDiacriticTest.java:60) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) STATUS:Failed.`main' threw exception: java.awt.HeadlessException java/awt/Frame/NormalToIconified/NormalToIconifiedTest.java java.lang.RuntimeException: Error: unable to create robot at test.java.awt.regtesthelpers.Util.createRobot(Util.java:91) at NormalToIconifiedTest.main(NormalToIconifiedTest.java:46) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at test.java.awt.regtesthelpers.Util.createRobot(Util.java:87) ... 7 more java/awt/Frame/ObscuredFrame/ObscuredFrameTest.java java.lang.RuntimeException: Error: unable to create robot at test.java.awt.regtesthelpers.Util.createRobot(Util.java:91) at ObscuredFrameTest.main(ObscuredFrameTest.java:40) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at test.java.awt.regtesthelpers.Util.createRobot(Util.java:87) ... 7 more java/awt/PopupMenu/PopupMenuLocation.java java.awt.HeadlessException at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getScreenDevices(HeadlessGraphicsEnvironment.java:53) at PopupMenuLocation.main(PopupMenuLocation.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at ScreenCaptureTest.main(ScreenCaptureTest.java:59) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) java/awt/Robot/MultiScreenRobotPosition/MultiScreenRobotPosition.java java.awt.HeadlessException at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getScreenDevices(HeadlessGraphicsEnvironment.java:53) at MultiScreenRobotPosition.main(MultiScreenRobotPosition.java:42) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) java/awt/Window/WindowDeadlockTest/WindowDeadlockTest.java java.lang.RuntimeException: Error: unable to create robot at test.java.awt.regtesthelpers.Util.createRobot(Util.java:91) at WindowDeadlockTest.main(WindowDeadlockTest.java:42) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at test.java.awt.regtesthelpers.Util.createRobot(Util.java:87) ... 7 more javax/accessibility/JList/AccessibleJListChildNPETest.java java.lang.reflect.InvocationTargetException at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1328) at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1303) at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1475) at AccessibleJListChildNPETest.main(AccessibleJListChildNPETest.java:49) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at java.desktop/javax.swing.JFrame.(JFrame.java:180) at AccessibleJListChildNPETest$1.run(AccessibleJListChildNPETest.java:52) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at ScaledFrameBackgroundTest.main(ScaledFrameBackgroundTest.java:46) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) javax/swing/JFrame/AlwaysOnTop/AlwaysOnTopImeTest.java java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at AlwaysOnTopImeTest.main(AlwaysOnTopImeTest.java:52) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) javax/swing/JLightweightFrame/JLightweightFrameRoundTest.java java.lang.reflect.InvocationTargetException at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1328) at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1303) at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1475) at JLightweightFrameRoundTest.main(JLightweightFrameRoundTest.java:39) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at java.desktop/sun.awt.LightweightFrame.(LightweightFrame.java:62) at java.desktop/sun.swing.JLightweightFrame.(JLightweightFrame.java:117) at JLightweightFrameRoundTest.lambda$main$0(JLightweightFrameRoundTest.java:40) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at ButtonGroupFocusTest.main(ButtonGroupFocusTest.java:45) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) javax/swing/JTree/4633594/JTreeFocusTest.java java.lang.reflect.InvocationTargetException at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1328) at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1303) at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1475) at JTreeFocusTest.(JTreeFocusTest.java:85) at JTreeFocusTest.main(JTreeFocusTest.java:66) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/javax.swing.JFrame.(JFrame.java:224) at JTreeFocusTest.lambda$new$1(JTreeFocusTest.java:86) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) javax/swing/plaf/basic/BasicComboPopup/JComboBoxPopupLocation/JComboBoxPopupLocation.java java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at JComboBoxPopupLocation.main(JComboBoxPopupLocation.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) javax/swing/text/html/StyleSheet/bug4936917.java java.lang.reflect.InvocationTargetException at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1328) at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1303) at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1475) at bug4936917.init(bug4936917.java:58) at bug4936917.main(bug4936917.java:119) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at java.desktop/javax.swing.JFrame.(JFrame.java:180) at bug4936917$1.run(bug4936917.java:66) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at bug6432565$EventProcessor.dispatchEvent(bug6432565.java:67) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) From sergey.bylokhov at oracle.com Wed Jul 5 14:31:52 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 5 Jul 2017 07:31:52 -0700 (PDT) Subject: RFR: 8183286 : Some java/awt and javax/swing tests miss headful jtreg keyword Message-ID: Looks fine. ----- matthias.baesken at sap.com wrote: > > > Hello all, could I have a review for this small change ? Thanks, Matthias > From: Langer, Christoph > Sent: Freitag, 30. Juni 2017 23:50 > To: Baesken, Matthias ; awt-dev at openjdk.java.net > Cc: core-libs-dev at openjdk.java.net; joe.darcy at oracle.com > Subject: RE: RFR: 8183286 : Some java/awt and javax/swing tests miss headful jtreg keyword Hi, forwarding this RFR to awt-dev. Please have a look. Thanks Christoph > > From: Baesken, Matthias > Sent: Freitag, 30. Juni 2017 16:59 > To: core-libs-dev at openjdk.java.net > Cc: Langer, Christoph < christoph.langer at sap.com > > Subject: RFR: 8183286 : Some java/awt and javax/swing tests miss headful jtreg keyword Hello all , could you please review the following small change. Some java/awt and javax/swing tests miss the headful jtreg keyword The change JDK-8129822 ( https://bugs.openjdk.java.net/browse/JDK-8129822 ) introduced a jtreg keyword to mark tests as requiring a "headful" (as opposed to "headless") environment to be able to run. But a number of jdk10 jdk jtreg tests from java/awt and javax/swing miss this keyword and run into "headless environment" exceptions and fail when running in a headless environment (has been observed in our internal OpenJDK testing environment at SAP). Suggestion is to add the keyword to the tests missing it to fix this. Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8183286 JDK10 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8183286/ List of jdk tests and exceptions seen : java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java java.awt.HeadlessException at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getScreenDevices(HeadlessGraphicsEnvironment.java:53) at ChoicePopupLocation.main(ChoicePopupLocation.java:49) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) java/awt/Dialog/DialogAboveFrame/DialogAboveFrameTest.java java.lang.RuntimeException: Error: unable to create robot at test.java.awt.regtesthelpers.Util.createRobot(Util.java:91) at DialogAboveFrameTest.main(DialogAboveFrameTest.java:44) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at test.java.awt.regtesthelpers.Util.createRobot(Util.java:87) ... 7 more java/awt/font/TextLayout/ArabicDiacriticTest.java java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at java.desktop/javax.swing.JFrame.(JFrame.java:180) at ArabicDiacriticTest.lambda$showText$0(ArabicDiacriticTest.java:60) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) STATUS:Failed.`main' threw exception: java.awt.HeadlessException java/awt/Frame/NormalToIconified/NormalToIconifiedTest.java java.lang.RuntimeException: Error: unable to create robot at test.java.awt.regtesthelpers.Util.createRobot(Util.java:91) at NormalToIconifiedTest.main(NormalToIconifiedTest.java:46) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at test.java.awt.regtesthelpers.Util.createRobot(Util.java:87) ... 7 more java/awt/Frame/ObscuredFrame/ObscuredFrameTest.java java.lang.RuntimeException: Error: unable to create robot at test.java.awt.regtesthelpers.Util.createRobot(Util.java:91) at ObscuredFrameTest.main(ObscuredFrameTest.java:40) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at test.java.awt.regtesthelpers.Util.createRobot(Util.java:87) ... 7 more java/awt/PopupMenu/PopupMenuLocation.java java.awt.HeadlessException at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getScreenDevices(HeadlessGraphicsEnvironment.java:53) at PopupMenuLocation.main(PopupMenuLocation.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at ScreenCaptureTest.main(ScreenCaptureTest.java:59) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) java/awt/Robot/MultiScreenRobotPosition/MultiScreenRobotPosition.java java.awt.HeadlessException at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getScreenDevices(HeadlessGraphicsEnvironment.java:53) at MultiScreenRobotPosition.main(MultiScreenRobotPosition.java:42) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) java/awt/Window/WindowDeadlockTest/WindowDeadlockTest.java java.lang.RuntimeException: Error: unable to create robot at test.java.awt.regtesthelpers.Util.createRobot(Util.java:91) at WindowDeadlockTest.main(WindowDeadlockTest.java:42) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at test.java.awt.regtesthelpers.Util.createRobot(Util.java:87) ... 7 more javax/accessibility/JList/AccessibleJListChildNPETest.java java.lang.reflect.InvocationTargetException at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1328) at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1303) at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1475) at AccessibleJListChildNPETest.main(AccessibleJListChildNPETest.java:49) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at java.desktop/javax.swing.JFrame.(JFrame.java:180) at AccessibleJListChildNPETest$1.run(AccessibleJListChildNPETest.java:52) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at ScaledFrameBackgroundTest.main(ScaledFrameBackgroundTest.java:46) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) javax/swing/JFrame/AlwaysOnTop/AlwaysOnTopImeTest.java java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at AlwaysOnTopImeTest.main(AlwaysOnTopImeTest.java:52) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) javax/swing/JLightweightFrame/JLightweightFrameRoundTest.java java.lang.reflect.InvocationTargetException at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1328) at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1303) at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1475) at JLightweightFrameRoundTest.main(JLightweightFrameRoundTest.java:39) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at java.desktop/sun.awt.LightweightFrame.(LightweightFrame.java:62) at java.desktop/sun.swing.JLightweightFrame.(JLightweightFrame.java:117) at JLightweightFrameRoundTest.lambda$main$0(JLightweightFrameRoundTest.java:40) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at ButtonGroupFocusTest.main(ButtonGroupFocusTest.java:45) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) javax/swing/JTree/4633594/JTreeFocusTest.java java.lang.reflect.InvocationTargetException at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1328) at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1303) at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1475) at JTreeFocusTest.(JTreeFocusTest.java:85) at JTreeFocusTest.main(JTreeFocusTest.java:66) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/javax.swing.JFrame.(JFrame.java:224) at JTreeFocusTest.lambda$new$1(JTreeFocusTest.java:86) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) javax/swing/plaf/basic/BasicComboPopup/JComboBoxPopupLocation/JComboBoxPopupLocation.java java.awt.AWTException: headless environment at java.desktop/java.awt.Robot.(Robot.java:94) at JComboBoxPopupLocation.main(JComboBoxPopupLocation.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) javax/swing/text/html/StyleSheet/bug4936917.java java.lang.reflect.InvocationTargetException at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1328) at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1303) at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1475) at bug4936917.init(bug4936917.java:58) at bug4936917.main(bug4936917.java:119) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.awt.HeadlessException at java.desktop/java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:202) at java.desktop/java.awt.Window.(Window.java:534) at java.desktop/java.awt.Frame.(Frame.java:423) at java.desktop/java.awt.Frame.(Frame.java:388) at java.desktop/javax.swing.JFrame.(JFrame.java:180) at bug4936917$1.run(bug4936917.java:66) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:303) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764) at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717) at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734) at bug6432565$EventProcessor.dispatchEvent(bug6432565.java:67) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) From volker.simonis at gmail.com Wed Jul 5 14:46:02 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 5 Jul 2017 16:46:02 +0200 Subject: [10] RFR(XS): 8183534: [TEST] Make detection of compilation mode more robust In-Reply-To: <9ebff9d98af743a29346070a3c8859fa@sap.com> References: <9ebff9d98af743a29346070a3c8859fa@sap.com> Message-ID: Hi Christoph, thanks for your review. On Wed, Jul 5, 2017 at 11:33 AM, Langer, Christoph wrote: > Hi Volker, > > overall, the change looks good to me. > > When you create the Exception to print the stack trace (line 129 in the new file), why not add the value of 'java.vm.info' to the message? Good point. I'll do so. > Also, I don't like the spaces around the '.' before PrintStackTrace() - but maybe that's just my personal taste. ;-) You're right. I somehow thought that the spaces are the default "coding style" for OpenJDK but I've checked and you're right that by default we don't use spaces when calling a method right on a 'new' expression. I'll update the change accordingly. Regards, Volker > > Best regards > Christoph > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >> Behalf Of Volker Simonis >> Sent: Dienstag, 4. Juli 2017 11:05 >> To: HotSpot Open Source Developers ; >> Java Core Libs >> Subject: [10] RFR(XS): 8183534: [TEST] Make detection of compilation mode >> more robust >> >> Hi, >> >> can you please review the following trivial change which makes the >> detection of compilation mode for JTreg more robust: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8183534/ >> https://bugs.openjdk.java.net/browse/JDK-8183534 >> >> The compilation mode in JTreg is parsed from the "java.vm.info" system >> property. The current implementation expects that "java.vm.info" >> contains exactly one of the strings "mixed mode", "compiled mode" or >> "interpreted mode" otherwise the detection will fail and JTreg will >> quit with an error. >> >> The detection can be done more robust by searching for the substrings >> "mixed mode", "compiled mode" or "interpreted mode" instead, thus >> allowing OpenJDK builders to store additional information in the >> "java.vm.info" system property. >> >> Thank you and best regards, >> Volker From huizhe.wang at oracle.com Wed Jul 5 18:48:08 2017 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 05 Jul 2017 11:48:08 -0700 Subject: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation Message-ID: <595D3468.20201@oracle.com> Hi, This patch fixes deprecation warnings in the jaxp repo. I'm limiting the changes to deprecation or the 102 classes. The cup-generated classes, XPath*.java, could use some cleanup or even rewrite, but that will be left in future works (JDK-8183580). Most of the changes are straight-forward, but I did have trouble with the replacing clazz.newInstance() with clazz.getDeclaredConstructor().newInstance() since in some cases I got RuntimePermission problems. So for most of such cases, I've replaced them with getConstructor() instead, thanks Alan for the suggestion. For specific cases such as xsltc/compiler/Parser.java, I'm using getDeclaredConstructor() because some of the classes didn't have a public constructor. Again, please bear with me for the cup-generated classes that have super long lines (e.g. XPathParser.java). Please read with Udiffs instead of Sdiffs. Some of the boxing (e.g. Integer.valueOf()) in the BCEL classes may not be necessary, but that's how they look in BCEL to which an update is scheduled in JDK 10. All tests passed. JBS: https://bugs.openjdk.java.net/browse/JDK-8181154 webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev/ Thanks Joe From garydgregory at gmail.com Wed Jul 5 19:08:43 2017 From: garydgregory at gmail.com (Gary Gregory) Date: Wed, 5 Jul 2017 12:08:43 -0700 Subject: Zip Extended Timestamp signedness changed in JDK9 but not JDK8 In-Reply-To: <595C268F.6070405@oracle.com> References: <595BFA03.4000301@oracle.com> <595C268F.6070405@oracle.com> Message-ID: Hi Sherman, Thank you for your reply. My feel and experience around the Apache projects I am involved in is that for Commons and perhaps others there is a sense of doom and frustration around so many changes that are breaking "stuff". Modules break stuff, reflection breaks stuff. Ok, changes are coming. The bottom line is that I would like to be able to run in Java 9 without hacking. In the case of this specific bug and uint32, it would be great if we could get to the point where we could say: Run on Java 8 update X and Java 9 update Y and our code does not have to change and passes our tests. This is my reason for wanting the fix in Java 8. :-) Gary On Jul 4, 2017 16:36, "Xueming Shen" wrote: > There are two issues here. > > (1) to fix/support the possible unix timestamp year 2038 issue when that > extra timestamp(s) is used; > (2) to backport the fix to 8u. > > I would assume the direct trigger of "wasting a meaningful amount of time > ..." is (1) ? > Sure the root cause is we did not address year 2038 issue at first place > when we added the extra > timestamp support in jdk8. My apology :-) > > Btw, the changeset Simon mentioned/sited actually does not fix the issue. > It actually will expose > the issue on year 2038 with the signed 32-bit int (it now follows the > specification, which says the > timestamp is an uint32). The real fix is the changeset for #8161942. > > https://bugs.openjdk.java.net/browse/JDK-8161942 > > Sure, we can backport it if desired. My original assumption is that this > is something can wait, until > there is an escalation/real need ... we might have one now :-) > > Sherman > > On 7/4/17, 2:05 PM, Gary Gregory wrote: > > At the end of the day, my experience over at Apache Commons is that these > kinds of bugs waste a meaningful amount of time even if they may not become > an application level bug in the future. The bug wastes time now... > > Gary > > On Jul 4, 2017 13:27, "Xueming Shen" wrote: > >> Simon, >> >> I would assume it's reasonable to believe 2037/2107 problem is NOT going >> to be a critical issue >> for jdk8u, given the fact we are talking about the "timestamp" of a zip >> entry. I meant I'm pretty >> much sure jdk8u will not be around :-) when we have any real 2037 entry >> timestamp, sure we >> do/can have test cases for such issue. That said, I think we can squeeze >> in a patch to address >> this issue when we are adding other relatively "critical" patch(s), if >> such fix is really desired. >> >> -Sherman >> >> On 7/4/17, 7:25 AM, Simon Spero wrote: >> >>> There was a fair degree of backporting of zip timestamp code, but the >>> bugfix to (signed vs unsigned) didn't make it. >>> The corner cases that aren't handled are not-handled consistently. >>> >>> On Mon, Jul 3, 2017 at 4:09 PM, Alan Bateman >>> wrote: >>> >>> >>>> On 03/07/2017 20:05, Simon Spero wrote: >>>> >>>> : >>>>> >>>>> It is strange that this wasn't backported to jdk8u, since other >>>>> changes to >>>>> zip rom around the same time are present. Also, this fix doesn't >>>>> seem to >>>>> be mentioned in JIRA or the release notes. >>>>> >>>>> There were API changes as part of this update so not appropriate to >>>>> >>>> backport. More generally, the zip code has changed significantly in JDK >>>> 9 >>>> to replace native implementation. I think the highest priority is to >>>> make >>>> sure that there aren't any corner cases that were handled in 8 but not >>>> handled in 9. >>>> >>>> -Alan >>>> >>>> >> > From huizhe.wang at oracle.com Wed Jul 5 21:11:32 2017 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 05 Jul 2017 14:11:32 -0700 Subject: RFR (JDK10/jaxp) 8183583: LSSerializer docs have invalid character Message-ID: <595D5604.2070400@oracle.com> A quick fix as Jon suggested: replacing \u00f1 with ñ --- a/src/java.xml/share/classes/org/w3c/dom/ls/LSSerializer.java +++ b/src/java.xml/share/classes/org/w3c/dom/ls/LSSerializer.java @@ -136,7 +136,7 @@ *

Within markup, but outside of attributes, any occurrence of a character * that cannot be represented in the output character encoding is reported * as a DOMError fatal error. An example would be serializing - * the element <LaCa\u00f1ada/> with encoding="us-ascii". + * the element <LaCañada/> with encoding="us-ascii". * This will result with a generation of a DOMError * "wf-invalid-character-in-node-name" (as proposed in " * well-formed"). Thanks, Joe From lance.andersen at oracle.com Wed Jul 5 21:13:17 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 5 Jul 2017 17:13:17 -0400 Subject: RFR (JDK10/jaxp) 8183583: LSSerializer docs have invalid character In-Reply-To: <595D5604.2070400@oracle.com> References: <595D5604.2070400@oracle.com> Message-ID: looks fine Joe > On Jul 5, 2017, at 5:11 PM, Joe Wang wrote: > > A quick fix as Jon suggested: replacing \u00f1 with ñ > > --- a/src/java.xml/share/classes/org/w3c/dom/ls/LSSerializer.java > +++ b/src/java.xml/share/classes/org/w3c/dom/ls/LSSerializer.java > @@ -136,7 +136,7 @@ > *

Within markup, but outside of attributes, any occurrence of a character > * that cannot be represented in the output character encoding is reported > * as a DOMError fatal error. An example would be serializing > - * the element <LaCa\u00f1ada/> with encoding="us-ascii". > + * the element <LaCañada/> with encoding="us-ascii". > * This will result with a generation of a DOMError > * "wf-invalid-character-in-node-name" (as proposed in " > * well-formed"). > > Thanks, > Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Wed Jul 5 21:42:32 2017 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 05 Jul 2017 14:42:32 -0700 Subject: RFR (JDK10/jaxp) 8183583: LSSerializer docs have invalid character In-Reply-To: References: <595D5604.2070400@oracle.com> Message-ID: <595D5D48.5090103@oracle.com> Thanks Lance! On 7/5/17, 2:13 PM, Lance Andersen wrote: > looks fine Joe >> On Jul 5, 2017, at 5:11 PM, Joe Wang > > wrote: >> >> A quick fix as Jon suggested: replacing \u00f1 with ñ >> >> --- a/src/java.xml/share/classes/org/w3c/dom/ls/LSSerializer.java >> +++ b/src/java.xml/share/classes/org/w3c/dom/ls/LSSerializer.java >> @@ -136,7 +136,7 @@ >> *

Within markup, but outside of attributes, any occurrence of a >> character >> * that cannot be represented in the output character encoding is >> reported >> * as a DOMError fatal error. An example would be >> serializing >> - * the element <LaCa\u00f1ada/> with >> encoding="us-ascii". >> + * the element <LaCañada/> with >> encoding="us-ascii". >> * This will result with a generation of a DOMError >> * "wf-invalid-character-in-node-name" (as proposed in "> href='http://www.w3.org/TR/DOM-Level-3-Core/core.html#parameter-well-formed' >> > >> * well-formed"). >> >> Thanks, >> Joe > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From rob.mckenna at oracle.com Wed Jul 5 22:44:44 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 5 Jul 2017 23:44:44 +0100 Subject: [10] 8177806: ldapContext.unbind not handling ldap entry with esc char Message-ID: <20170705224444.GB5048@vimes> Hi folks, Looking for a review for the following change. NameImpl.java is stripping escape characters unnecessarily: http://cr.openjdk.java.net/~robm/8177806/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8177806 Thanks, -Rob From amy.lu at oracle.com Thu Jul 6 01:47:36 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 6 Jul 2017 09:47:36 +0800 Subject: JDK 10 RFR of JDK-8183378: Refactor java/lang/System/MacEncoding/MacJNUEncoding.sh to java Message-ID: <175e54f2-9eb6-c1b8-6103-1fe4f0196f35@oracle.com> java/lang/System/MacEncoding/MacJNUEncoding.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8183378 webrev: http://cr.openjdk.java.net/~amlu/8183378/webrev.00/ Thanks, Amy From felix.yang at oracle.com Thu Jul 6 02:16:00 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 6 Jul 2017 10:16:00 +0800 Subject: JDK 10 RFR of JDK-8183378: Refactor java/lang/System/MacEncoding/MacJNUEncoding.sh to java In-Reply-To: <175e54f2-9eb6-c1b8-6103-1fe4f0196f35@oracle.com> References: <175e54f2-9eb6-c1b8-6103-1fe4f0196f35@oracle.com> Message-ID: <7fe1f655-3c6d-0b10-cc08-57fe5f781613@oracle.com> Hi Amy, looks fine. Just one comment on sentence below. "LOCALE" looks to be a local variable, though used several times. Switch to usual naming? 50 final String LOCALE = args[2]; -Felix On 2017/7/6 9:47, Amy Lu wrote: > java/lang/System/MacEncoding/MacJNUEncoding.sh > > Please review this patch to refactor the shell test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8183378 > webrev: http://cr.openjdk.java.net/~amlu/8183378/webrev.00/ > > Thanks, > Amy From amy.lu at oracle.com Thu Jul 6 02:23:38 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 6 Jul 2017 10:23:38 +0800 Subject: JDK 10 RFR of JDK-8183378: Refactor java/lang/System/MacEncoding/MacJNUEncoding.sh to java In-Reply-To: <7fe1f655-3c6d-0b10-cc08-57fe5f781613@oracle.com> References: <175e54f2-9eb6-c1b8-6103-1fe4f0196f35@oracle.com> <7fe1f655-3c6d-0b10-cc08-57fe5f781613@oracle.com> Message-ID: Fixed :-) Thanks, Amy On 7/6/17 10:16 AM, Felix Yang wrote: > Hi Amy, > > looks fine. Just one comment on sentence below. "LOCALE" looks to > be a local variable, though used several times. Switch to usual naming? > > 50 final String LOCALE = args[2]; > > -Felix > On 2017/7/6 9:47, Amy Lu wrote: >> java/lang/System/MacEncoding/MacJNUEncoding.sh >> >> Please review this patch to refactor the shell test to java. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8183378 >> webrev: http://cr.openjdk.java.net/~amlu/8183378/webrev.00/ >> >> Thanks, >> Amy > From vyom.tewari at oracle.com Thu Jul 6 08:21:47 2017 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Thu, 6 Jul 2017 13:51:47 +0530 Subject: [10] 8177806: ldapContext.unbind not handling ldap entry with esc char In-Reply-To: <20170705224444.GB5048@vimes> References: <20170705224444.GB5048@vimes> Message-ID: <384fff94-84ec-ae1e-09b0-6da792d2da4a@oracle.com> Hi Rob, Code change looks OK, below are few comments on test case. 1-> Remove System.exit(1) and throw Exception from main if test fails. 2-> Put srv.close() in finally block, in case of exception close will not be called. 3-> Do you need Thread.sleep(500) ?. I think it is not required. 4-> i will suggest you to use below tag order. /** * @test * @bug 8177806 * @summary Test NameImpl escape character processing * @modules java.naming/javax.naming:open * @run main/othervm LdapEscapeTest */ Thanks, Vyom On Thursday 06 July 2017 04:14 AM, Rob McKenna wrote: > Hi folks, > > Looking for a review for the following change. > > NameImpl.java is stripping escape characters unnecessarily: > > http://cr.openjdk.java.net/~robm/8177806/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8177806 > > Thanks, > > -Rob > From weijun.wang at oracle.com Thu Jul 6 09:02:51 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 6 Jul 2017 17:02:51 +0800 Subject: Test after JDK-8181761, the explicit @build actions Message-ID: Hi Igor I?ve about to add a new test that uses jdk.test.lib.SecurityTools and I see in your fix for JDK-8181761 that a lot of seemingly-unrelated classes are added into a @build action. How do I determine what classes are needed? Or shall I just copy it from a test nearby? I remember this was due to a jtreg bug(?). Has it been resolved? Do we need to add the @build action forever? Thanks Max From Alan.Bateman at oracle.com Thu Jul 6 09:45:35 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Jul 2017 10:45:35 +0100 Subject: Test after JDK-8181761, the explicit @build actions In-Reply-To: References: Message-ID: <74edfc7b-4fc1-4ec5-69d8-f15f3dc8a6f3@oracle.com> On 06/07/2017 10:02, Weijun Wang wrote: > Hi Igor > > I?ve about to add a new test that uses jdk.test.lib.SecurityTools and I see in your fix for JDK-8181761 that a lot of seemingly-unrelated classes are added into a @build action. > > How do I determine what classes are needed? Or shall I just copy it from a test nearby? > > I remember this was due to a jtreg bug(?). Has it been resolved? Do we need to add the @build action forever? > Yeah, it's very messy just now. My understanding is that Igor is planning to clean up the dependences in the test infrastructure classes so much of this can go away. Separately, there are changes in flight for jtreg to improve the reliability of tests running with agentvm + concurrency. Jon pushed CODETOOLS-7902003 to the jtreg code a few days ago so that each test gets a unique test.classes. That should avoid a lot of the issues that Igor was initially working around by trying to change the tests to depend on implicit compilation. This change exposes a few issues with the handling of test.classes in a few tests so they have been fixed too. In summary, you might have to temporarily add some annoying @build tags but they will go away, and hopefully soon. -Alan From daniel.fuchs at oracle.com Thu Jul 6 11:03:34 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 6 Jul 2017 12:03:34 +0100 Subject: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation In-Reply-To: <595D3468.20201@oracle.com> References: <595D3468.20201@oracle.com> Message-ID: <0ce69272-1025-a02d-a712-dd5a8c80f5fd@oracle.com> Hi Joe, Waouh, lost of good cleanup! A few comments: #1: com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecordFactory.java: 154 sortRecord = (NodeSortRecord)_class.getConstructor().newInstance(); Maybe it would be good to add a comment to say that NodeSortRecord subclasses are generated with a public empty constructor (which is if I'm not mistaken, what com.sun.org.apache.xalan.internal.xsltc.compiler.Sort::compileInit does). #2: com/sun/org/apache/xalan/internal/xsltc/runtime/Attributes.java: 30 @SuppressWarnings("deprecation") 31 public final class Attributes implements AttributeList { I wonder if the correct thing to do here would be to deprecate this class, since it doesn't seem to be anything but the implementation of a deprecated interface. Or alternatively, change it to implement the org.xml.sax.Attributes interface? Maybe the @SuppresWarnings can be kept as a stop gap solution for now, and a new issue logged to investigate what's the proper thing to do - as I suspect the answer might not be straightforward... #3: com/sun/org/apache/xalan/internal/xsltc/trax/TrAXFilter.java com/sun/org/apache/xalan/internal/xsltc/trax/Util.java com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java com/sun/org/apache/xpath/internal/SourceTreeManager.java 51 @SuppressWarnings("deprecation") //org.xml.sax.helpers.XMLReaderFactory Same here: maybe we should log a further issue to investigate whether javax.xml.parsers.SAXParserFactory could be used instead of the deprecated factory in these classes? #4: com/sun/org/apache/xerces/internal/dom/CoreDOMImplementationImpl.java Is this fixing a different issue? #5: com/sun/org/apache/xerces/internal/dom/PSVIAttrNSImpl.java com/sun/org/apache/xerces/internal/dom/PSVIElementNSImpl.java com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java 114 @SuppressWarnings("deprecation") 115 public String getSchemaDefault() { Use fDeclaration.getValueConstraintValue().getNormalizedValue() instead. 126 @SuppressWarnings("deprecation") 127 public String getSchemaNormalizedValue() { 245 @SuppressWarnings("deprecation") 246 public Object getActualNormalizedValue() { 253 @SuppressWarnings("deprecation") 254 public short getActualNormalizedValueType() { 261 @SuppressWarnings("deprecation") 262 public ShortList getItemValueTypes() { I believe the correct thing to do here instead would be to deprecate these methods - that should get rid of the warnings. #6 com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java An alternative solution would be to use Boolean.TRUE and Boolean.FALSE. Not sure if it matters though. That was just a thought. #7 com/sun/org/apache/xerces/internal/impl/dtd/models/CMLeaf.java Not sure why you converted StringBuffer to StringBuilder in the previous file but not there. #8 com/sun/org/apache/xerces/internal/impl/xs/XSAttributeDecl.java com/sun/org/apache/xerces/internal/impl/xs/XSAttributeUseImpl.java com/sun/org/apache/xerces/internal/impl/xs/XSElementDecl.java 161 @SuppressWarnings("deprecation") 162 public String getConstraintValue() { 198 @SuppressWarnings("deprecation") 199 public Object getActualVC() { 205 @SuppressWarnings("deprecation") 206 public short getActualVCType() { 212 @SuppressWarnings("deprecation") 213 public ShortList getItemValueTypes() { These methods should be marked deprecated since they implement deprecated methods. If I'm not mistaken then this should allow you to remove the @SuppressWarnings("deprecation") from their declaration. #9 com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDComplexTypeTraverser.java - fGlobalStore[fGlobalStorePos++] = new Integer((fDerivedBy << 16) + fFinal); - fGlobalStore[fGlobalStorePos++] = new Integer((fBlock << 16) + fContentType); + fGlobalStore[fGlobalStorePos++] = (fDerivedBy << 16) + fFinal; + fGlobalStore[fGlobalStorePos++] = (fBlock << 16) + fContentType; I wonder if there can be some subtle type conversion side effects here, given that all the operands are shorts, and that we expect an int in the end? #10 com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java 66 @SuppressWarnings("deprecation") Why is this needed? #11 com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java 1166 final public void setYear(BigInteger year) { nit: for consistency you should reorder the keywords to: public final void same file: - BigInteger.valueOf((long) 1) => BigInteger.ONE - new BigDecimal(TWELVE) => introduce a constant DECIMAL_TWELVE? - new BigDecimal(TWENTY_FOUR) => introduce a constant DECIMAL_TWENTY_FOUR? #12 com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java 81 @SuppressWarnings("deprecation") 82 public abstract class AbstractSAXParser 83 extends AbstractXMLDocumentParser 84 implements PSVIProvider, // PSVI 85 Parser, XMLReader // SAX1, SAX2 A better solution would be to deprecate the methods that implement deprecated methods - and avoid using deprecated APIs elsewhere... #13 com/sun/org/apache/xerces/internal/util/AttributesProxy.java 36 @SuppressWarnings("deprecation") 37 public final class AttributesProxy 38 implements AttributeList, Attributes2 { I wonder whether deprecating the methods implementing a deprecated API would allow to remove @SuppressWarnings("deprecation") - maybe not in this case since this class needs to implement a deprecated interface and a non deprecated one (and therefore the class itself can't be deprecated). Anyway it might be good to add the @Deprecated annotations to deprecated methods. #14 com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java if _main use deprecated APIs then maybe _main should be @Deprecated as well. #15 com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java 207 private static Integer m_synch_object = 1; This is not correct! Since this object is only use as a synchronization lock then please change this to: private static Object m_synch_object = new Object(); #16 com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java Can this class be changed to stop using deprecated APIs instead? #17 javax/xml/parsers/SAXParser.java org/xml/sax/helpers/ParserAdapter.java org/xml/sax/helpers/XMLReaderAdapter.java Can these classes be changed to stop using deprecated APIs instead? Or at least a cleanup issue logged for that effect? That's all! best regards, -- daniel On 05/07/2017 19:48, Joe Wang wrote: > Hi, > > This patch fixes deprecation warnings in the jaxp repo. I'm limiting the > changes to deprecation or the 102 classes. The cup-generated classes, > XPath*.java, could use some cleanup or even rewrite, but that will be > left in future works (JDK-8183580). > > Most of the changes are straight-forward, but I did have trouble with > the replacing clazz.newInstance() with > clazz.getDeclaredConstructor().newInstance() since in some cases I got > RuntimePermission problems. So for most of such cases, I've replaced > them with getConstructor() instead, thanks Alan for the suggestion. For > specific cases such as xsltc/compiler/Parser.java, I'm using > getDeclaredConstructor() because some of the classes didn't have a > public constructor. > > Again, please bear with me for the cup-generated classes that have super > long lines (e.g. XPathParser.java). Please read with Udiffs instead of > Sdiffs. > > Some of the boxing (e.g. Integer.valueOf()) in the BCEL classes may not > be necessary, but that's how they look in BCEL to which an update is > scheduled in JDK 10. > > All tests passed. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8181154 > webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev/ > > Thanks > Joe > From volker.simonis at gmail.com Thu Jul 6 14:11:58 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 6 Jul 2017 16:11:58 +0200 Subject: [10] RFR(XS): 8183534: [TEST] Make detection of compilation mode more robust In-Reply-To: References: Message-ID: On Wed, Jul 5, 2017 at 7:36 PM, Thomas St?fe wrote: > Hi Volker, > > this seems fine, but why did you add the error output? None of the other > vmXX() functions seem not to do this. > I didn't wanted to blow up the change but you're probably right so I've updated all the functions which potentially returned 'null' to also print a stack trace in that case: http://cr.openjdk.java.net/~simonis/webrevs/2017/8183534.v1/ The problem is that without error output, JTreg will simply fail with: java.lang.NullPointerException Error: failed to get JDK properties for /sapjvm_9/bin/java ; exit code 1 which gives you no clue where to search for the problem. With my change you'll get a stack trace before the error which clearly indicates the location of the problem: java.lang.Exception: Can't get 'java.vm.info' property at requires.VMProps.nullWithException(VMProps.java:87) at requires.VMProps.vmCompMode(VMProps.java:133) at requires.VMProps.call(VMProps.java:62) at requires.VMProps.call(VMProps.java:48) at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:66) at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:46) java.lang.NullPointerException Error: failed to get JDK properties for /bas/sapjvm/integ/all/gen/optU/linuxx86_64/output/sapjvm_9/bin/java ; exit code 1 Thank you and best regards, Volker > Kind Regards, Thomas > > On Tue, Jul 4, 2017 at 11:05 AM, Volker Simonis > wrote: >> >> Hi, >> >> can you please review the following trivial change which makes the >> detection of compilation mode for JTreg more robust: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8183534/ >> https://bugs.openjdk.java.net/browse/JDK-8183534 >> >> The compilation mode in JTreg is parsed from the "java.vm.info" system >> property. The current implementation expects that "java.vm.info" >> contains exactly one of the strings "mixed mode", "compiled mode" or >> "interpreted mode" otherwise the detection will fail and JTreg will >> quit with an error. >> >> The detection can be done more robust by searching for the substrings >> "mixed mode", "compiled mode" or "interpreted mode" instead, thus >> allowing OpenJDK builders to store additional information in the >> "java.vm.info" system property. >> >> Thank you and best regards, >> Volker > > From jonathan.gibbons at oracle.com Thu Jul 6 14:31:24 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 6 Jul 2017 07:31:24 -0700 Subject: Test after JDK-8181761, the explicit @build actions In-Reply-To: <74edfc7b-4fc1-4ec5-69d8-f15f3dc8a6f3@oracle.com> References: <74edfc7b-4fc1-4ec5-69d8-f15f3dc8a6f3@oracle.com> Message-ID: On 7/6/17 2:45 AM, Alan Bateman wrote: > On 06/07/2017 10:02, Weijun Wang wrote: >> Hi Igor >> >> I?ve about to add a new test that uses jdk.test.lib.SecurityTools and >> I see in your fix for JDK-8181761 that a lot of seemingly-unrelated >> classes are added into a @build action. >> >> How do I determine what classes are needed? Or shall I just copy it >> from a test nearby? >> >> I remember this was due to a jtreg bug(?). Has it been resolved? Do >> we need to add the @build action forever? >> > Yeah, it's very messy just now. My understanding is that Igor is > planning to clean up the dependences in the test infrastructure > classes so much of this can go away. > > Separately, there are changes in flight for jtreg to improve the > reliability of tests running with agentvm + concurrency. Jon pushed > CODETOOLS-7902003 to the jtreg code a few days ago so that each test > gets a unique test.classes. That should avoid a lot of the issues that > Igor was initially working around by trying to change the tests to > depend on implicit compilation. This change exposes a few issues with > the handling of test.classes in a few tests so they have been fixed too. > > In summary, you might have to temporarily add some annoying @build > tags but they will go away, and hopefully soon. > > -Alan It has always been the case that it is recommended to use @build tags for library classes. The recent jtreg work makes jtreg better able to run tests reliably that have insufficient @build tags, but a contributing factor to the issues here has been the growing complexity of the library (test infrastructure) classes. If nothing else, it would be helpful for someone to analyze those library classes (jdeps?) to determine the dependencies that each class has. That would be a good first step to understanding the dependencies, such that they can be eliminated or documented. I note that jtreg does have short forms for @build, such as to compile all the classes in a package or module, that could be used effectively if the library is designed appropriately. -- Jon From christoph.langer at sap.com Thu Jul 6 14:32:35 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 6 Jul 2017 14:32:35 +0000 Subject: [10] RFR(XS): 8183534: [TEST] Make detection of compilation mode more robust In-Reply-To: References: Message-ID: Hi Volker, looks fine, thanks for doing that. Best regards Christoph > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Donnerstag, 6. Juli 2017 16:12 > To: Thomas St?fe > Cc: HotSpot Open Source Developers ; > Java Core Libs ; Langer, Christoph > > Subject: Re: [10] RFR(XS): 8183534: [TEST] Make detection of compilation > mode more robust > > On Wed, Jul 5, 2017 at 7:36 PM, Thomas St?fe > wrote: > > Hi Volker, > > > > this seems fine, but why did you add the error output? None of the other > > vmXX() functions seem not to do this. > > > > I didn't wanted to blow up the change but you're probably right so > I've updated all the functions which potentially returned 'null' to > also print a stack trace in that case: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8183534.v1/ > > The problem is that without error output, JTreg will simply fail with: > > java.lang.NullPointerException > Error: failed to get JDK properties for /sapjvm_9/bin/java ; exit code 1 > > which gives you no clue where to search for the problem. With my > change you'll get a stack trace before the error which clearly > indicates the location of the problem: > > java.lang.Exception: Can't get 'java.vm.info' property > at requires.VMProps.nullWithException(VMProps.java:87) > at requires.VMProps.vmCompMode(VMProps.java:133) > at requires.VMProps.call(VMProps.java:62) > at requires.VMProps.call(VMProps.java:48) > at > com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.jav > a:66) > at > com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.ja > va:46) > java.lang.NullPointerException > Error: failed to get JDK properties for > /bas/sapjvm/integ/all/gen/optU/linuxx86_64/output/sapjvm_9/bin/java ; > exit code 1 > > Thank you and best regards, > Volker > > > Kind Regards, Thomas > > > > On Tue, Jul 4, 2017 at 11:05 AM, Volker Simonis > > > wrote: > >> > >> Hi, > >> > >> can you please review the following trivial change which makes the > >> detection of compilation mode for JTreg more robust: > >> > >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8183534/ > >> https://bugs.openjdk.java.net/browse/JDK-8183534 > >> > >> The compilation mode in JTreg is parsed from the "java.vm.info" system > >> property. The current implementation expects that "java.vm.info" > >> contains exactly one of the strings "mixed mode", "compiled mode" or > >> "interpreted mode" otherwise the detection will fail and JTreg will > >> quit with an error. > >> > >> The detection can be done more robust by searching for the substrings > >> "mixed mode", "compiled mode" or "interpreted mode" instead, thus > >> allowing OpenJDK builders to store additional information in the > >> "java.vm.info" system property. > >> > >> Thank you and best regards, > >> Volker > > > > From rob.mckenna at oracle.com Thu Jul 6 15:57:44 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 6 Jul 2017 16:57:44 +0100 Subject: [10] 8177806: ldapContext.unbind not handling ldap entry with esc char In-Reply-To: <384fff94-84ec-ae1e-09b0-6da792d2da4a@oracle.com> References: <20170705224444.GB5048@vimes> <384fff94-84ec-ae1e-09b0-6da792d2da4a@oracle.com> Message-ID: <20170706155743.GA6054@vimes> Thanks Vyom, updated test at: http://cr.openjdk.java.net/~robm/8177806/webrev.02/ The sleep proved necessary in a similar earlier test so I'll leave it in there. (iirc the request failed as it was sent before the server started accepting connections) -Rob On 06/07/17 01:51, Vyom Tewari wrote: > Hi Rob, > > Code change looks OK, below are few comments on test case. > > 1-> Remove System.exit(1) and throw Exception from main if test fails. > > 2-> Put srv.close() in finally block, in case of exception close will not be > called. > > 3-> Do you need Thread.sleep(500) ?. I think it is not required. > > 4-> i will suggest you to use below tag order. > > /** > * @test > * @bug 8177806 > * @summary Test NameImpl escape character processing > * @modules java.naming/javax.naming:open > * @run main/othervm LdapEscapeTest > */ > > Thanks, > > Vyom > > > On Thursday 06 July 2017 04:14 AM, Rob McKenna wrote: > >Hi folks, > > > >Looking for a review for the following change. > > > >NameImpl.java is stripping escape characters unnecessarily: > > > >http://cr.openjdk.java.net/~robm/8177806/webrev.01/ > >https://bugs.openjdk.java.net/browse/JDK-8177806 > > > >Thanks, > > > > -Rob > > > From brent.christian at oracle.com Thu Jul 6 16:46:53 2017 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 6 Jul 2017 09:46:53 -0700 Subject: JDK 10 RFR of JDK-8183378: Refactor java/lang/System/MacEncoding/MacJNUEncoding.sh to java In-Reply-To: <7fe1f655-3c6d-0b10-cc08-57fe5f781613@oracle.com> References: <175e54f2-9eb6-c1b8-6103-1fe4f0196f35@oracle.com> <7fe1f655-3c6d-0b10-cc08-57fe5f781613@oracle.com> Message-ID: <673fffae-770b-0922-2a74-acbd3f9cd862@oracle.com> Thanks a lot for fixing that, Amy. Looks good. -Brent On 07/05/2017 07:16 PM, Felix Yang wrote: > Hi Amy, > > looks fine. Just one comment on sentence below. "LOCALE" looks to be > a local variable, though used several times. Switch to usual naming? > > 50 final String LOCALE = args[2]; > > -Felix > On 2017/7/6 9:47, Amy Lu wrote: >> java/lang/System/MacEncoding/MacJNUEncoding.sh >> >> Please review this patch to refactor the shell test to java. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8183378 >> webrev: http://cr.openjdk.java.net/~amlu/8183378/webrev.00/ >> >> Thanks, >> Amy > From amy.lu at oracle.com Fri Jul 7 03:11:59 2017 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 7 Jul 2017 11:11:59 +0800 Subject: JDK 10 RFR of JDK-8183989: Mark java/nio/channels/DatagramChannel/Disconnect.java as intermittently failing Message-ID: java/nio/channels/DatagramChannel/Disconnect.java This test is known to fail intermittently (JDK-8154018), this patch is to mark the test accordingly with keyword 'intermittent'. Please review. bug: https://bugs.openjdk.java.net/browse/JDK-8183989 webrev: http://cr.openjdk.java.net/~amlu/8183989/webrev.00/ Thanks, Amy --- old/test/java/nio/channels/DatagramChannel/Disconnect.java 2017-07-07 11:07:32.000000000 +0800 +++ new/test/java/nio/channels/DatagramChannel/Disconnect.java 2017-07-07 11:07:32.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -23,6 +23,7 @@ /* @test * @bug 7132924 + * @key intermittent * @summary Test DatagramChannel.disconnect when DatagramChannel is connected to an IPv4 socket * @run main Disconnect * @run main/othervm -Djava.net.preferIPv4Stack=true Disconnect From huizhe.wang at oracle.com Fri Jul 7 06:34:19 2017 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 6 Jul 2017 23:34:19 -0700 Subject: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation In-Reply-To: <0ce69272-1025-a02d-a712-dd5a8c80f5fd@oracle.com> References: <595D3468.20201@oracle.com> <0ce69272-1025-a02d-a712-dd5a8c80f5fd@oracle.com> Message-ID: <2d78a8bd-2b6a-e52d-e5a1-4eba66e85fe7@oracle.com> On 7/6/17, 4:03 AM, Daniel Fuchs wrote: > Hi Joe, > > Waouh, lost of good cleanup! A few comments: Thanks Daniel! That's a lot of good comments. > > #1: > com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecordFactory.java: > > 154 sortRecord = > (NodeSortRecord)_class.getConstructor().newInstance(); > > Maybe it would be good to add a comment to say that NodeSortRecord > subclasses are generated with a public empty constructor (which is > if I'm not mistaken, what > com.sun.org.apache.xalan.internal.xsltc.compiler.Sort::compileInit > does). Note added. > > #2: > com/sun/org/apache/xalan/internal/xsltc/runtime/Attributes.java: > 30 @SuppressWarnings("deprecation") > 31 public final class Attributes implements AttributeList { > > I wonder if the correct thing to do here would be to deprecate this > class, since it doesn't seem to be anything but the implementation > of a deprecated interface. Or alternatively, change it to implement > the org.xml.sax.Attributes interface? > Maybe the @SuppresWarnings can be kept as a stop gap solution for > now, and a new issue logged to investigate what's the proper thing > to do - as I suspect the answer might not be straightforward... Sounds good, logged: https://bugs.openjdk.java.net/browse/JDK-8183972 It covers #2, #3, #10, #12, #13, #17. > > #3: > com/sun/org/apache/xalan/internal/xsltc/trax/TrAXFilter.java > com/sun/org/apache/xalan/internal/xsltc/trax/Util.java > com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java > com/sun/org/apache/xpath/internal/SourceTreeManager.java > > 51 @SuppressWarnings("deprecation") > //org.xml.sax.helpers.XMLReaderFactory > > Same here: maybe we should log a further issue to investigate > whether javax.xml.parsers.SAXParserFactory could be used instead > of the deprecated factory in these classes? > > #4: > com/sun/org/apache/xerces/internal/dom/CoreDOMImplementationImpl.java > > Is this fixing a different issue? The try-catch only applies to the use of Apache standalone. In the JDK, there's no need for it (fall back to the deprecated one). > > #5: > com/sun/org/apache/xerces/internal/dom/PSVIAttrNSImpl.java > com/sun/org/apache/xerces/internal/dom/PSVIElementNSImpl.java > com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java > com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java > > 114 @SuppressWarnings("deprecation") > 115 public String getSchemaDefault() { > > Use fDeclaration.getValueConstraintValue().getNormalizedValue() instead. That was suggested when it was deprecated. However, as you can see the implementer never followed it through. First of all, the impl of getConstraintValue has an additional type check and then stringValue checks if there's actualValue before returning normalizedValue, while the above methods always return normalizedValue. This is different from ItemPSVI where deprecated method such as getActualNormalizedValue can indeed be replaced, as suggested, by getSchemaValue().getActualValue(). > > 126 @SuppressWarnings("deprecation") > 127 public String getSchemaNormalizedValue() { > 245 @SuppressWarnings("deprecation") > 246 public Object getActualNormalizedValue() { > 253 @SuppressWarnings("deprecation") > 254 public short getActualNormalizedValueType() { > 261 @SuppressWarnings("deprecation") > 262 public ShortList getItemValueTypes() { > > I believe the correct thing to do here instead would be to deprecate > these methods - that should get rid of the warnings. True. My script only knows to add the suppress annotation :-). They can be removed too since they are internal APIs. > > #6 > com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java > com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java > > An alternative solution would be to use Boolean.TRUE and Boolean.FALSE. > Not sure if it matters though. That was just a thought. True, but it won't since it casts to Boolean. The whole process can probably be improved with a static encoding map, but it's not worth the effort. I initially simply want to get rid of warnings, which is why my script just does the unboxing, or in the above cases adds suppress annotation. Many improvement can be made to the old code, but if it doesn't add significant benefit, for example, improving performance, then I would say it's not worth it since we could spend the time on many other things. > > #7 > com/sun/org/apache/xerces/internal/impl/dtd/models/CMLeaf.java > > Not sure why you converted StringBuffer to StringBuilder in the > previous file but not there. Ah, didn't see it, replaced it now. If you search the code, you'll get over 1000 matches. So I made the change when I saw it. Too bad I did a full update on the obsolete lang features for the standalone, but it was not carried over. > > #8 > com/sun/org/apache/xerces/internal/impl/xs/XSAttributeDecl.java > com/sun/org/apache/xerces/internal/impl/xs/XSAttributeUseImpl.java > com/sun/org/apache/xerces/internal/impl/xs/XSElementDecl.java > > 161 @SuppressWarnings("deprecation") > 162 public String getConstraintValue() { > 198 @SuppressWarnings("deprecation") > 199 public Object getActualVC() { > 205 @SuppressWarnings("deprecation") > 206 public short getActualVCType() { > 212 @SuppressWarnings("deprecation") > 213 public ShortList getItemValueTypes() { > > These methods should be marked deprecated since they implement > deprecated methods. If I'm not mistaken then this should allow > you to remove the @SuppressWarnings("deprecation") from their > declaration. Done. > > #9 > com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDComplexTypeTraverser.java > > > - fGlobalStore[fGlobalStorePos++] = new Integer((fDerivedBy << > 16) + fFinal); > - fGlobalStore[fGlobalStorePos++] = new Integer((fBlock << 16) > + fContentType); > + fGlobalStore[fGlobalStorePos++] = (fDerivedBy << 16) + fFinal; > + fGlobalStore[fGlobalStorePos++] = (fBlock << 16) + fContentType; > > I wonder if there can be some subtle type conversion side effects here, > given that all the operands are shorts, and that we expect an int in > the end? These operations resulted in an Integer. They are used that way too (case to Integer). > > #10 > com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java > > 66 @SuppressWarnings("deprecation") > > Why is this needed? > > #11 > com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java > > > 1166 final public void setYear(BigInteger year) { > > nit: for consistency you should reorder the keywords to: > > public final void > > same file: > > - BigInteger.valueOf((long) 1) => BigInteger.ONE > - new BigDecimal(TWELVE) => introduce a constant DECIMAL_TWELVE? > - new BigDecimal(TWENTY_FOUR) => introduce a constant > DECIMAL_TWENTY_FOUR? Reasonable. Will do this and continue on the rest tomorrow. Thanks, Joe > > #12 > com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java > > 81 @SuppressWarnings("deprecation") > 82 public abstract class AbstractSAXParser > 83 extends AbstractXMLDocumentParser > 84 implements PSVIProvider, // PSVI > 85 Parser, XMLReader // SAX1, SAX2 > > A better solution would be to deprecate the methods that implement > deprecated methods - and avoid using deprecated APIs elsewhere... > > #13 > com/sun/org/apache/xerces/internal/util/AttributesProxy.java > > 36 @SuppressWarnings("deprecation") > 37 public final class AttributesProxy > 38 implements AttributeList, Attributes2 { > > I wonder whether deprecating the methods implementing a deprecated > API would allow to remove @SuppressWarnings("deprecation") - maybe not > in this case since this class needs to implement a deprecated interface > and a non deprecated one (and therefore the class itself can't be > deprecated). Anyway it might be good to add the @Deprecated > annotations to deprecated methods. > > #14 > com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java > > if _main use deprecated APIs then maybe _main should be @Deprecated > as well. > > #15 > com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java > > 207 private static Integer m_synch_object = 1; > > This is not correct! Since this object is only use as a synchronization > lock then please change this to: > > private static Object m_synch_object = new Object(); > > #16 > com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java > > Can this class be changed to stop using deprecated APIs instead? > > > #17 > javax/xml/parsers/SAXParser.java > org/xml/sax/helpers/ParserAdapter.java > org/xml/sax/helpers/XMLReaderAdapter.java > > Can these classes be changed to stop using deprecated APIs instead? > Or at least a cleanup issue logged for that effect? > > That's all! > > best regards, > > -- daniel > > On 05/07/2017 19:48, Joe Wang wrote: >> Hi, >> >> This patch fixes deprecation warnings in the jaxp repo. I'm limiting >> the changes to deprecation or the 102 classes. The cup-generated >> classes, XPath*.java, could use some cleanup or even rewrite, but >> that will be left in future works (JDK-8183580). >> >> Most of the changes are straight-forward, but I did have trouble with >> the replacing clazz.newInstance() with >> clazz.getDeclaredConstructor().newInstance() since in some cases I >> got RuntimePermission problems. So for most of such cases, I've >> replaced them with getConstructor() instead, thanks Alan for the >> suggestion. For specific cases such as xsltc/compiler/Parser.java, >> I'm using getDeclaredConstructor() because some of the classes didn't >> have a public constructor. >> >> Again, please bear with me for the cup-generated classes that have >> super long lines (e.g. XPathParser.java). Please read with Udiffs >> instead of Sdiffs. >> >> Some of the boxing (e.g. Integer.valueOf()) in the BCEL classes may >> not be necessary, but that's how they look in BCEL to which an update >> is scheduled in JDK 10. >> >> All tests passed. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8181154 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev/ >> >> Thanks >> Joe >> > From rob.mckenna at oracle.com Fri Jul 7 12:58:25 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 7 Jul 2017 13:58:25 +0100 Subject: [10] 8177806: ldapContext.unbind not handling ldap entry with esc char In-Reply-To: <20170706155743.GA6054@vimes> References: <20170705224444.GB5048@vimes> <384fff94-84ec-ae1e-09b0-6da792d2da4a@oracle.com> <20170706155743.GA6054@vimes> Message-ID: <20170707125825.GC3527@vimes> Further testing has shown the escaping to be necessary. Apologies folks, I'm withdrawing this review. -Rob On 06/07/17 04:57, Rob McKenna wrote: > Thanks Vyom, updated test at: > > http://cr.openjdk.java.net/~robm/8177806/webrev.02/ > > The sleep proved necessary in a similar earlier test so I'll leave it in > there. (iirc the request failed as it was sent before the server started > accepting connections) > > -Rob > > On 06/07/17 01:51, Vyom Tewari wrote: > > Hi Rob, > > > > Code change looks OK, below are few comments on test case. > > > > 1-> Remove System.exit(1) and throw Exception from main if test fails. > > > > 2-> Put srv.close() in finally block, in case of exception close will not be > > called. > > > > 3-> Do you need Thread.sleep(500) ?. I think it is not required. > > > > 4-> i will suggest you to use below tag order. > > > > /** > > * @test > > * @bug 8177806 > > * @summary Test NameImpl escape character processing > > * @modules java.naming/javax.naming:open > > * @run main/othervm LdapEscapeTest > > */ > > > > Thanks, > > > > Vyom > > > > > > On Thursday 06 July 2017 04:14 AM, Rob McKenna wrote: > > >Hi folks, > > > > > >Looking for a review for the following change. > > > > > >NameImpl.java is stripping escape characters unnecessarily: > > > > > >http://cr.openjdk.java.net/~robm/8177806/webrev.01/ > > >https://bugs.openjdk.java.net/browse/JDK-8177806 > > > > > >Thanks, > > > > > > -Rob > > > > > From OGATAK at jp.ibm.com Fri Jul 7 16:58:50 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Sat, 8 Jul 2017 01:58:50 +0900 Subject: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Hi all, Any comment on downporting a fix to JDK9u and JDK8u, which simply removes volatile? Regards, Ogata Kazunori Ogata/Japan/IBM wrote on 2017/07/03 17:28:54: > From: Kazunori Ogata/Japan/IBM > To: "Langer, Christoph" > Cc: core-libs-dev , "nio- > dev at openjdk.java.net" > Date: 2017/07/03 17:28 > Subject: RE: 8182743: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Christoph, > > Thank you very much for your help! > > For JDK9 updates and JDK8 updates, it is desirable if we can back port the > removal of volatile. What should I do for it? > > Regards, > Ogata > > From: "Langer, Christoph" > To: Kazunori Ogata , "nio-dev at openjdk.java.net" dev at openjdk.java.net> > Cc: core-libs-dev > Date: 2017/07/03 17:17 > Subject: RE: 8182743: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi, > > I've pushed to JDK10 now: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/ > 7a2bc0a80087 > > What do you think, shall we try to downport a fix to JDK9 updates and JDK8 > updates, which simply removes the volatile as we can't bring this behavior > changing fix down? > > Thanks > Christoph > > > -----Original Message----- > > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > > Sent: Freitag, 30. Juni 2017 20:31 > > To: Se?n Coffey > > Cc: Langer, Christoph ; core-libs-dev > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > > dev at openjdk.java.net > > Subject: Re: 8182743: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > Hi Sean, > > > > Thank you for your comments. > > > > I fixed the copyright and updated webrev: > > > > http://cr.openjdk.java.net/~horii/8182743/webrev.03/ > > > > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > > 8182743 ? > > > > Yes, they should be 8182743. I fixed both. > > > > > > Regards, > > Ogata > > > > > > Se?n Coffey wrote on 2017/06/30 23:57:25: > > > > > From: Se?n Coffey > > > To: Kazunori Ogata , "Langer, Christoph" > > > > > > Cc: "ppc-aix-port-dev at openjdk.java.net" > > dev at openjdk.java.net>, core-libs-dev , > > > "nio-dev at openjdk.java.net" > > > Date: 2017/06/30 23:57 > > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts > > > performance of Charset.atBugLevel() > > > > > > Ogata, > > > > > > minor comments from me. > > > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > > 8182743 ? > > > * The copyright change in Charset-X-Coder.java.template is the wrong > > > format. You can simply replace 2013 with 2017. > > > > > > Regards, > > > Sean. > > > > > > On 29/06/17 19:49, Kazunori Ogata wrote: > > > > Hi Christoph, > > > > > > > > I updated webrev: > > http://cr.openjdk.java.net/~horii/8179527/webrev.02/ > > > > > > > > This one includes changes in tests. I removed all @run and @build > > > > directives in the tests because those after removing "@run > > main/othervm > > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the > > default > > > > ones. I checked the modified tests passed. > > > > > > > > I also fixed the copyright lines. > > > > > > > > > > > > Regards, > > > > Ogata > > > > > > > > > > > > "Langer, Christoph" wrote on 2017/06/28 > > > > 21:04:36: > > > > > > > >> From: "Langer, Christoph" > > > >> To: Kazunori Ogata > > > >> Cc: Alan Bateman , Claes Redestad > > > >> , core-libs-dev > > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" > > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > > > > > >> dev at openjdk.java.net> > > > >> Date: 2017/06/28 21:04 > > > >> Subject: RE: 8179527: Ineffective use of volatile hurts performance > > of > > > >> Charset.atBugLevel() > > > >> > > > >> Hi Ogata, > > > >> > > > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > > >>> How can I do this? Is it sufficient to remove the following line at > > > > the > > > >>> beginning of the file?: "@run main/othervm -Dsun.nio.cs.bugLevel=1.4 > > > >>> EmptyCharsetName" > > > >> Yes, this line should be removed. Currently there are two @run > > > > directives > > > >> which cause running the testcase twice. Once in normal mode and once > > > > with > > > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be removed > > > > then > > > >> the second iteration of the test is obsolete. And then one should > > > > probably > > > >> remove the whole "compat" handling in the test. > > > >> > > > >> Best regards > > > >> Christoph > > > >> > > > > > > > > > > From paul.sandoz at oracle.com Fri Jul 7 17:05:33 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 7 Jul 2017 10:05:33 -0700 Subject: JDK 10 RFR of JDK-8183989: Mark java/nio/channels/DatagramChannel/Disconnect.java as intermittently failing In-Reply-To: References: Message-ID: +1 Paul. > On 6 Jul 2017, at 20:11, Amy Lu wrote: > > java/nio/channels/DatagramChannel/Disconnect.java > > This test is known to fail intermittently (JDK-8154018), this patch is to mark the test accordingly with keyword 'intermittent'. > > Please review. > > bug: https://bugs.openjdk.java.net/browse/JDK-8183989 > webrev: http://cr.openjdk.java.net/~amlu/8183989/webrev.00/ > > Thanks, > Amy > > --- old/test/java/nio/channels/DatagramChannel/Disconnect.java 2017-07-07 11:07:32.000000000 +0800 > +++ new/test/java/nio/channels/DatagramChannel/Disconnect.java 2017-07-07 11:07:32.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -23,6 +23,7 @@ > /* @test > * @bug 7132924 > + * @key intermittent > * @summary Test DatagramChannel.disconnect when DatagramChannel is connected to an IPv4 socket > * @run main Disconnect > * @run main/othervm -Djava.net.preferIPv4Stack=true Disconnect > From huizhe.wang at oracle.com Fri Jul 7 17:59:59 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 7 Jul 2017 10:59:59 -0700 Subject: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation In-Reply-To: <2d78a8bd-2b6a-e52d-e5a1-4eba66e85fe7@oracle.com> References: <595D3468.20201@oracle.com> <0ce69272-1025-a02d-a712-dd5a8c80f5fd@oracle.com> <2d78a8bd-2b6a-e52d-e5a1-4eba66e85fe7@oracle.com> Message-ID: <13cb85fe-32e0-5ef7-c9ae-502d6f3671d0@oracle.com> >> #11 >> com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java >> >> >> 1166 final public void setYear(BigInteger year) { >> >> nit: for consistency you should reorder the keywords to: >> >> public final void >> >> same file: >> >> - BigInteger.valueOf((long) 1) => BigInteger.ONE >> - new BigDecimal(TWELVE) => introduce a constant DECIMAL_TWELVE? >> - new BigDecimal(TWENTY_FOUR) => introduce a constant >> DECIMAL_TWENTY_FOUR? > Added the two constants. > > >> >> #12 >> com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java >> >> 81 @SuppressWarnings("deprecation") >> 82 public abstract class AbstractSAXParser >> 83 extends AbstractXMLDocumentParser >> 84 implements PSVIProvider, // PSVI >> 85 Parser, XMLReader // SAX1, SAX2 >> >> A better solution would be to deprecate the methods that implement >> deprecated methods - and avoid using deprecated APIs elsewhere... >> >> #13 >> com/sun/org/apache/xerces/internal/util/AttributesProxy.java >> >> 36 @SuppressWarnings("deprecation") >> 37 public final class AttributesProxy >> 38 implements AttributeList, Attributes2 { >> >> I wonder whether deprecating the methods implementing a deprecated >> API would allow to remove @SuppressWarnings("deprecation") - maybe not >> in this case since this class needs to implement a deprecated interface >> and a non deprecated one (and therefore the class itself can't be >> deprecated). Anyway it might be good to add the @Deprecated >> annotations to deprecated methods. We'll take a closer look at this through [1], for both #12 and #13, and #17 as well. AttributesProxy is used quite widely. We'll need to get into the details to see if we can remove the deprecated AttributeList. Since there are import references that are deprecated, the suppress annotation has to be added at the class. [1] https://bugs.openjdk.java.net/browse/JDK-8183972 >> >> #14 >> com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java >> >> if _main use deprecated APIs then maybe _main should be @Deprecated >> as well. Done. >> >> #15 >> com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java >> >> 207 private static Integer m_synch_object = 1; >> >> This is not correct! Since this object is only use as a synchronization >> lock then please change this to: >> >> private static Object m_synch_object = new Object(); Ok, fixed now. But I don't think the sync is necessary, logged https://bugs.openjdk.java.net/browse/JDK-8184019 to take a look later and can also do some cleanups. >> >> #16 >> com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java >> >> Can this class be changed to stop using deprecated APIs instead? It can probably be removed, will do so through https://bugs.openjdk.java.net/browse/JDK-8184020. >> >> >> #17 >> javax/xml/parsers/SAXParser.java >> org/xml/sax/helpers/ParserAdapter.java >> org/xml/sax/helpers/XMLReaderAdapter.java >> >> Can these classes be changed to stop using deprecated APIs instead? >> Or at least a cleanup issue logged for that effect? Most likely we can't since these are public APIs. DocumentHandler for example, is still usable. We can probably add forRemoval and then remove in the next release. >> >> That's all! Thanks for all of that! Best, Joe >> >> best regards, >> >> -- daniel >> >> On 05/07/2017 19:48, Joe Wang wrote: >>> Hi, >>> >>> This patch fixes deprecation warnings in the jaxp repo. I'm limiting >>> the changes to deprecation or the 102 classes. The cup-generated >>> classes, XPath*.java, could use some cleanup or even rewrite, but >>> that will be left in future works (JDK-8183580). >>> >>> Most of the changes are straight-forward, but I did have trouble >>> with the replacing clazz.newInstance() with >>> clazz.getDeclaredConstructor().newInstance() since in some cases I >>> got RuntimePermission problems. So for most of such cases, I've >>> replaced them with getConstructor() instead, thanks Alan for the >>> suggestion. For specific cases such as xsltc/compiler/Parser.java, >>> I'm using getDeclaredConstructor() because some of the classes >>> didn't have a public constructor. >>> >>> Again, please bear with me for the cup-generated classes that have >>> super long lines (e.g. XPathParser.java). Please read with Udiffs >>> instead of Sdiffs. >>> >>> Some of the boxing (e.g. Integer.valueOf()) in the BCEL classes may >>> not be necessary, but that's how they look in BCEL to which an >>> update is scheduled in JDK 10. >>> >>> All tests passed. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181154 >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev/ >>> >>> Thanks >>> Joe >>> >> From jonathan.gibbons at oracle.com Fri Jul 7 18:14:11 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 07 Jul 2017 11:14:11 -0700 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible Message-ID: <595FCF73.80201@oracle.com> Please review the following fixes to the doc comments in the jaxp repo. The primary goal is to fix user-written tables in doc comments for accessibility, either by updating tables to use scope=row|col in header cells for simple tables, or by using the headings attribute in more complex tables. The majority of the changes, to tables using class="striped", were done mechanically, using a custom Java utility. Three tables were fixed up manually. In addition, I removed the use of

tags which introduced empty paragraph. These tags caused warnings when checking the code with the "tidy" program. JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ ----- The following list of comments about the changes is ordered according to the list in the webrev. Catalog: removed empty

CatalogFeatures: first table updated manually (class="plain") removed empty

second table updated with utility CatalogResolver: removed empty

DatatypeFactory, Duration: table updated with utility XMLGregorianCalendar: all tables updated with utility datatype/package-info: table updated with utility NamespaceContext: all tables updated with utility XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: table updated with utility XMLStreamWriter: this is the one table with class="striped" that had to be updated manually, because of the complex headers SchemaFactory: table updated with utility, but table organization could be improved (by spec owner) for example, to split first column into a name and a URI, and/or use the second column as a row header. Validator, XPath, XPathExpression, xpath/package-info: table updated manually (class="plain") Attr table updated with utility table could be improved by removing redundant atributes, like rowspan='1' colspan='1' Document, Node: all tables updated with utility -- Jon From lance.andersen at oracle.com Fri Jul 7 20:33:55 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 7 Jul 2017 16:33:55 -0400 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible In-Reply-To: <595FCF73.80201@oracle.com> References: <595FCF73.80201@oracle.com> Message-ID: <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> Hi Jon, The changes looked good to me. Is the html available by chance to do an extra sanity check? Best Lance > On Jul 7, 2017, at 2:14 PM, Jonathan Gibbons wrote: > > Please review the following fixes to the doc comments in the jaxp repo. > > The primary goal is to fix user-written tables in doc comments for accessibility, either by updating tables to use scope=row|col in header cells for simple tables, or by using the headings attribute in more complex tables. The majority of the changes, to tables using class="striped", were done mechanically, using a custom Java utility. Three tables were fixed up manually. > > In addition, I removed the use of

tags which introduced empty paragraph. These tags caused warnings when checking the code with the "tidy" program. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 > Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ > > ----- > > The following list of comments about the changes is ordered according to the list in the webrev. > > Catalog: > removed empty

> > CatalogFeatures: > first table updated manually (class="plain") > removed empty

> second table updated with utility > > CatalogResolver: > removed empty

> > DatatypeFactory, Duration: > table updated with utility > > XMLGregorianCalendar: > all tables updated with utility > > datatype/package-info: > table updated with utility > > NamespaceContext: > all tables updated with utility > > XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: > table updated with utility > > XMLStreamWriter: > this is the one table with class="striped" that had to be updated > manually, because of the complex headers > > SchemaFactory: > table updated with utility, but table organization could be improved (by spec owner) > for example, to split first column into a name and a URI, and/or use the second > column as a row header. > > Validator, XPath, XPathExpression, xpath/package-info: > table updated manually (class="plain") > > Attr > table updated with utility > table could be improved by removing redundant atributes, like rowspan='1' colspan='1' > > Document, Node: > all tables updated with utility > > -- Jon Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jonathan.gibbons at oracle.com Fri Jul 7 21:53:29 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 07 Jul 2017 14:53:29 -0700 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible In-Reply-To: <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> References: <595FCF73.80201@oracle.com> <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> Message-ID: <596002D9.9000309@oracle.com> Sorry, I meant to include that; will post shortly, beside the webrev. -- Jon On 07/07/2017 01:33 PM, Lance Andersen wrote: > Hi Jon, > > The changes looked good to me. Is the html available by chance to do > an extra sanity check? > > Best > Lance >> On Jul 7, 2017, at 2:14 PM, Jonathan Gibbons >> > wrote: >> >> Please review the following fixes to the doc comments in the jaxp repo. >> >> The primary goal is to fix user-written tables in doc comments for >> accessibility, either by updating tables to use scope=row|col in >> header cells for simple tables, or by using the headings attribute in >> more complex tables. The majority of the changes, to tables using >> class="striped", were done mechanically, using a custom Java utility. >> Three tables were fixed up manually. >> >> In addition, I removed the use of

tags which introduced empty >> paragraph. These tags caused warnings when checking the code with the >> "tidy" program. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 >> Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ >> >> >> ----- >> >> The following list of comments about the changes is ordered according >> to the list in the webrev. >> >> Catalog: >> removed empty

>> >> CatalogFeatures: >> first table updated manually (class="plain") >> removed empty

>> second table updated with utility >> >> CatalogResolver: >> removed empty

>> >> DatatypeFactory, Duration: >> table updated with utility >> >> XMLGregorianCalendar: >> all tables updated with utility >> >> datatype/package-info: >> table updated with utility >> >> NamespaceContext: >> all tables updated with utility >> >> XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: >> table updated with utility >> >> XMLStreamWriter: >> this is the one table with class="striped" that had to be updated >> manually, because of the complex headers >> >> SchemaFactory: >> table updated with utility, but table organization could be >> improved (by spec owner) >> for example, to split first column into a name and a URI, and/or >> use the second >> column as a row header. >> >> Validator, XPath, XPathExpression, xpath/package-info: >> table updated manually (class="plain") >> >> Attr >> table updated with utility >> table could be improved by removing redundant atributes, like >> rowspan='1' colspan='1' >> >> Document, Node: >> all tables updated with utility >> >> -- Jon > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From huizhe.wang at oracle.com Sat Jul 8 00:50:58 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 7 Jul 2017 17:50:58 -0700 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible In-Reply-To: <596002D9.9000309@oracle.com> References: <595FCF73.80201@oracle.com> <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> <596002D9.9000309@oracle.com> Message-ID: <804638cf-20e2-5586-453a-fb2d92291f64@oracle.com> Hi Jon, For the table in CatalogFeatures, the id attribute for Type and Value are not used, may be unnecessary. Instead, scope="col" can be added, is that right? 50 * Type 51 * Value I'm new to accessibility, but it seems to me the following can use scope="colgroup" instead? 46 * Value [2] Since the 1st and 7th columns already have scope="row", if scope="col" can be added to the 8th (Action) column, the cells in the 8th (Action) column then won't need the "headers" attribute, would that be right? 1st column: 74 * PREFER ... 7th column: 81 * {@code system} 8th column: 82 * For the table in XMLStreamWriter, it looks like to me we can avoid the headers for each cell by instead making the following changes: add rowspan="2" to 45 * Method add scope="colgroup" to 46 * {@code isRepairingNamespaces} == true 47 * {@code isRepairingNamespaces} == false remove: 50 * add scope="col" to 51 * namespaceURI bound 52 * namespaceURI unbound 53 * namespaceURI bound 54 * namespaceURI unbound add scope="row" to the first column of the rows in the body. Would that make sense? Thanks, Joe On 7/7/2017 2:53 PM, Jonathan Gibbons wrote: > Sorry, I meant to include that; will post shortly, beside the webrev. > > -- Jon > > On 07/07/2017 01:33 PM, Lance Andersen wrote: >> Hi Jon, >> >> The changes looked good to me. Is the html available by chance to >> do an extra sanity check? >> >> Best >> Lance >>> On Jul 7, 2017, at 2:14 PM, Jonathan Gibbons >>> > >>> wrote: >>> >>> Please review the following fixes to the doc comments in the jaxp repo. >>> >>> The primary goal is to fix user-written tables in doc comments for >>> accessibility, either by updating tables to use scope=row|col in >>> header cells for simple tables, or by using the headings attribute >>> in more complex tables. The majority of the changes, to tables >>> using class="striped", were done mechanically, using a custom Java >>> utility. Three tables were fixed up manually. >>> >>> In addition, I removed the use of

tags which introduced empty >>> paragraph. These tags caused warnings when checking the code with >>> the "tidy" program. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 >>> Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ >>> >>> >>> ----- >>> >>> The following list of comments about the changes is ordered >>> according to the list in the webrev. >>> >>> Catalog: >>> removed empty

>>> >>> CatalogFeatures: >>> first table updated manually (class="plain") >>> removed empty

>>> second table updated with utility >>> >>> CatalogResolver: >>> removed empty

>>> >>> DatatypeFactory, Duration: >>> table updated with utility >>> >>> XMLGregorianCalendar: >>> all tables updated with utility >>> >>> datatype/package-info: >>> table updated with utility >>> >>> NamespaceContext: >>> all tables updated with utility >>> >>> XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: >>> table updated with utility >>> >>> XMLStreamWriter: >>> this is the one table with class="striped" that had to be updated >>> manually, because of the complex headers >>> >>> SchemaFactory: >>> table updated with utility, but table organization could be >>> improved (by spec owner) >>> for example, to split first column into a name and a URI, and/or >>> use the second >>> column as a row header. >>> >>> Validator, XPath, XPathExpression, xpath/package-info: >>> table updated manually (class="plain") >>> >>> Attr >>> table updated with utility >>> table could be improved by removing redundant atributes, like >>> rowspan='1' colspan='1' >>> >>> Document, Node: >>> all tables updated with utility >>> >>> -- Jon >> >> >> >> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > From huizhe.wang at oracle.com Sat Jul 8 00:53:44 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 7 Jul 2017 17:53:44 -0700 Subject: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation In-Reply-To: <13cb85fe-32e0-5ef7-c9ae-502d6f3671d0@oracle.com> References: <595D3468.20201@oracle.com> <0ce69272-1025-a02d-a712-dd5a8c80f5fd@oracle.com> <2d78a8bd-2b6a-e52d-e5a1-4eba66e85fe7@oracle.com> <13cb85fe-32e0-5ef7-c9ae-502d6f3671d0@oracle.com> Message-ID: Here's the updated webrev: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev01/ Thanks, Joe On 7/7/2017 10:59 AM, huizhe wang wrote: > >>> #11 >>> com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java >>> >>> >>> 1166 final public void setYear(BigInteger year) { >>> >>> nit: for consistency you should reorder the keywords to: >>> >>> public final void >>> >>> same file: >>> >>> - BigInteger.valueOf((long) 1) => BigInteger.ONE >>> - new BigDecimal(TWELVE) => introduce a constant DECIMAL_TWELVE? >>> - new BigDecimal(TWENTY_FOUR) => introduce a constant >>> DECIMAL_TWENTY_FOUR? >> > > Added the two constants. > >> >> >>> >>> #12 >>> com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java >>> >>> 81 @SuppressWarnings("deprecation") >>> 82 public abstract class AbstractSAXParser >>> 83 extends AbstractXMLDocumentParser >>> 84 implements PSVIProvider, // PSVI >>> 85 Parser, XMLReader // SAX1, SAX2 >>> >>> A better solution would be to deprecate the methods that implement >>> deprecated methods - and avoid using deprecated APIs elsewhere... >>> >>> #13 >>> com/sun/org/apache/xerces/internal/util/AttributesProxy.java >>> >>> 36 @SuppressWarnings("deprecation") >>> 37 public final class AttributesProxy >>> 38 implements AttributeList, Attributes2 { >>> >>> I wonder whether deprecating the methods implementing a deprecated >>> API would allow to remove @SuppressWarnings("deprecation") - maybe not >>> in this case since this class needs to implement a deprecated interface >>> and a non deprecated one (and therefore the class itself can't be >>> deprecated). Anyway it might be good to add the @Deprecated >>> annotations to deprecated methods. > > We'll take a closer look at this through [1], for both #12 and #13, > and #17 as well. AttributesProxy is used quite widely. We'll need to > get into the details to see if we can remove the deprecated > AttributeList. > > Since there are import references that are deprecated, the suppress > annotation has to be added at the class. > > [1] https://bugs.openjdk.java.net/browse/JDK-8183972 > >>> >>> #14 >>> com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java >>> >>> >>> if _main use deprecated APIs then maybe _main should be @Deprecated >>> as well. > > Done. >>> >>> #15 >>> com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java >>> >>> 207 private static Integer m_synch_object = 1; >>> >>> This is not correct! Since this object is only use as a synchronization >>> lock then please change this to: >>> >>> private static Object m_synch_object = new Object(); > > Ok, fixed now. But I don't think the sync is necessary, logged > https://bugs.openjdk.java.net/browse/JDK-8184019 to take a look later > and can also do some cleanups. > >>> >>> #16 >>> com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java >>> >>> Can this class be changed to stop using deprecated APIs instead? > > It can probably be removed, will do so through > https://bugs.openjdk.java.net/browse/JDK-8184020. > >>> >>> >>> #17 >>> javax/xml/parsers/SAXParser.java >>> org/xml/sax/helpers/ParserAdapter.java >>> org/xml/sax/helpers/XMLReaderAdapter.java >>> >>> Can these classes be changed to stop using deprecated APIs instead? >>> Or at least a cleanup issue logged for that effect? > > Most likely we can't since these are public APIs. DocumentHandler for > example, is still usable. We can probably add forRemoval and then > remove in the next release. > >>> >>> That's all! > > Thanks for all of that! > > Best, > Joe > >>> >>> best regards, >>> >>> -- daniel >>> >>> On 05/07/2017 19:48, Joe Wang wrote: >>>> Hi, >>>> >>>> This patch fixes deprecation warnings in the jaxp repo. I'm >>>> limiting the changes to deprecation or the 102 classes. The >>>> cup-generated classes, XPath*.java, could use some cleanup or even >>>> rewrite, but that will be left in future works (JDK-8183580). >>>> >>>> Most of the changes are straight-forward, but I did have trouble >>>> with the replacing clazz.newInstance() with >>>> clazz.getDeclaredConstructor().newInstance() since in some cases I >>>> got RuntimePermission problems. So for most of such cases, I've >>>> replaced them with getConstructor() instead, thanks Alan for the >>>> suggestion. For specific cases such as xsltc/compiler/Parser.java, >>>> I'm using getDeclaredConstructor() because some of the classes >>>> didn't have a public constructor. >>>> >>>> Again, please bear with me for the cup-generated classes that have >>>> super long lines (e.g. XPathParser.java). Please read with Udiffs >>>> instead of Sdiffs. >>>> >>>> Some of the boxing (e.g. Integer.valueOf()) in the BCEL classes may >>>> not be necessary, but that's how they look in BCEL to which an >>>> update is scheduled in JDK 10. >>>> >>>> All tests passed. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181154 >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev/ >>>> >>>> Thanks >>>> Joe >>>> >>> > From jonathan.gibbons at oracle.com Sat Jul 8 01:02:59 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 7 Jul 2017 18:02:59 -0700 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible In-Reply-To: <804638cf-20e2-5586-453a-fb2d92291f64@oracle.com> References: <595FCF73.80201@oracle.com> <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> <596002D9.9000309@oracle.com> <804638cf-20e2-5586-453a-fb2d92291f64@oracle.com> Message-ID: <136f23d0-f8e5-0148-d94e-e5dc5b3eb39b@oracle.com> On 7/7/17 5:50 PM, huizhe wang wrote: > Hi Jon, > > For the table in CatalogFeatures, the id attribute for Type and Value > are not used, may be unnecessary. Instead, scope="col" can be added, > is that right? > 50 * Type > 51 * Value > > I'm new to accessibility, but it seems to me the following can use > scope="colgroup" instead? By itself, that is not enough. > > 46 * Value [2] > > > Since the 1st and 7th columns already have scope="row", if > scope="col" can be added to the 8th (Action) column, the cells in the > 8th (Action) column then won't need the "headers" attribute, would > that be right? No, the cells in the 8th column need to identify the column, and two row header cells. You can only use "scope=row|col" on simple matrix-like tables ... as soon as you have spanning rows or columns you need to use header cells. > 1st column: 74 * style="font-weight:normal" id="PREFER">PREFER ... > 7th column: 81 * style="font-weight:normal">{@code system} > 8th column: 82 * > > For the table in XMLStreamWriter, it looks like to me we can avoid the > headers for each cell by instead making the following changes: > add rowspan="2" to > 45 * Method > add scope="colgroup" to > 46 * {@code isRepairingNamespaces} == true > 47 * {@code isRepairingNamespaces} == false > remove: > 50 * > > add scope="col" to > 51 * namespaceURI bound > 52 * namespaceURI unbound > 53 * namespaceURI bound > 54 * namespaceURI unbound > > add scope="row" to the first column of the rows in the body. > > Would that make sense? Again, if it's not a simple matrix-like table, you need headers to identify all applicable headers to the data cells. > > Thanks, > Joe > > On 7/7/2017 2:53 PM, Jonathan Gibbons wrote: >> Sorry, I meant to include that; will post shortly, beside the webrev. >> >> -- Jon >> >> On 07/07/2017 01:33 PM, Lance Andersen wrote: >>> Hi Jon, >>> >>> The changes looked good to me. Is the html available by chance to >>> do an extra sanity check? >>> >>> Best >>> Lance >>>> On Jul 7, 2017, at 2:14 PM, Jonathan Gibbons >>>> > >>>> wrote: >>>> >>>> Please review the following fixes to the doc comments in the jaxp >>>> repo. >>>> >>>> The primary goal is to fix user-written tables in doc comments for >>>> accessibility, either by updating tables to use scope=row|col in >>>> header cells for simple tables, or by using the headings attribute >>>> in more complex tables. The majority of the changes, to tables >>>> using class="striped", were done mechanically, using a custom Java >>>> utility. Three tables were fixed up manually. >>>> >>>> In addition, I removed the use of

tags which introduced empty >>>> paragraph. These tags caused warnings when checking the code with >>>> the "tidy" program. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ >>>> >>>> >>>> ----- >>>> >>>> The following list of comments about the changes is ordered >>>> according to the list in the webrev. >>>> >>>> Catalog: >>>> removed empty

>>>> >>>> CatalogFeatures: >>>> first table updated manually (class="plain") >>>> removed empty

>>>> second table updated with utility >>>> >>>> CatalogResolver: >>>> removed empty

>>>> >>>> DatatypeFactory, Duration: >>>> table updated with utility >>>> >>>> XMLGregorianCalendar: >>>> all tables updated with utility >>>> >>>> datatype/package-info: >>>> table updated with utility >>>> >>>> NamespaceContext: >>>> all tables updated with utility >>>> >>>> XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: >>>> table updated with utility >>>> >>>> XMLStreamWriter: >>>> this is the one table with class="striped" that had to be updated >>>> manually, because of the complex headers >>>> >>>> SchemaFactory: >>>> table updated with utility, but table organization could be >>>> improved (by spec owner) >>>> for example, to split first column into a name and a URI, and/or >>>> use the second >>>> column as a row header. >>>> >>>> Validator, XPath, XPathExpression, xpath/package-info: >>>> table updated manually (class="plain") >>>> >>>> Attr >>>> table updated with utility >>>> table could be improved by removing redundant atributes, like >>>> rowspan='1' colspan='1' >>>> >>>> Document, Node: >>>> all tables updated with utility >>>> >>>> -- Jon >>> >>> >>> >>> >>> Lance >>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >> > From jonathan.gibbons at oracle.com Sat Jul 8 16:58:40 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 8 Jul 2017 09:58:40 -0700 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible In-Reply-To: <804638cf-20e2-5586-453a-fb2d92291f64@oracle.com> References: <595FCF73.80201@oracle.com> <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> <596002D9.9000309@oracle.com> <804638cf-20e2-5586-453a-fb2d92291f64@oracle.com> Message-ID: <2be3b88f-5f75-3d38-9ef3-6a08aeae8abe@oracle.com> Joe, Thanks for the feedback. I've done some experiments and it looks like we can indeed simplify the more complex tables to always use scope=row|col. I'll post an amended webrev next week. Thanks for the feedback and suggestion to revisit this issue. -- Jon On 7/7/17 5:50 PM, huizhe wang wrote: > Hi Jon, > > For the table in CatalogFeatures, the id attribute for Type and Value > are not used, may be unnecessary. Instead, scope="col" can be added, > is that right? > 50 * Type > 51 * Value > > I'm new to accessibility, but it seems to me the following can use > scope="colgroup" instead? > > 46 * Value [2] > > > Since the 1st and 7th columns already have scope="row", if > scope="col" can be added to the 8th (Action) column, the cells in the > 8th (Action) column then won't need the "headers" attribute, would > that be right? > 1st column: 74 * style="font-weight:normal" id="PREFER">PREFER ... > 7th column: 81 * style="font-weight:normal">{@code system} > 8th column: 82 * > > For the table in XMLStreamWriter, it looks like to me we can avoid the > headers for each cell by instead making the following changes: > add rowspan="2" to > 45 * Method > add scope="colgroup" to > 46 * {@code isRepairingNamespaces} == true > 47 * {@code isRepairingNamespaces} == false > remove: > 50 * > > add scope="col" to > 51 * namespaceURI bound > 52 * namespaceURI unbound > 53 * namespaceURI bound > 54 * namespaceURI unbound > > add scope="row" to the first column of the rows in the body. > > Would that make sense? > > Thanks, > Joe > > On 7/7/2017 2:53 PM, Jonathan Gibbons wrote: >> Sorry, I meant to include that; will post shortly, beside the webrev. >> >> -- Jon >> >> On 07/07/2017 01:33 PM, Lance Andersen wrote: >>> Hi Jon, >>> >>> The changes looked good to me. Is the html available by chance to >>> do an extra sanity check? >>> >>> Best >>> Lance >>>> On Jul 7, 2017, at 2:14 PM, Jonathan Gibbons >>>> > >>>> wrote: >>>> >>>> Please review the following fixes to the doc comments in the jaxp >>>> repo. >>>> >>>> The primary goal is to fix user-written tables in doc comments for >>>> accessibility, either by updating tables to use scope=row|col in >>>> header cells for simple tables, or by using the headings attribute >>>> in more complex tables. The majority of the changes, to tables >>>> using class="striped", were done mechanically, using a custom Java >>>> utility. Three tables were fixed up manually. >>>> >>>> In addition, I removed the use of

tags which introduced empty >>>> paragraph. These tags caused warnings when checking the code with >>>> the "tidy" program. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ >>>> >>>> >>>> ----- >>>> >>>> The following list of comments about the changes is ordered >>>> according to the list in the webrev. >>>> >>>> Catalog: >>>> removed empty

>>>> >>>> CatalogFeatures: >>>> first table updated manually (class="plain") >>>> removed empty

>>>> second table updated with utility >>>> >>>> CatalogResolver: >>>> removed empty

>>>> >>>> DatatypeFactory, Duration: >>>> table updated with utility >>>> >>>> XMLGregorianCalendar: >>>> all tables updated with utility >>>> >>>> datatype/package-info: >>>> table updated with utility >>>> >>>> NamespaceContext: >>>> all tables updated with utility >>>> >>>> XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: >>>> table updated with utility >>>> >>>> XMLStreamWriter: >>>> this is the one table with class="striped" that had to be updated >>>> manually, because of the complex headers >>>> >>>> SchemaFactory: >>>> table updated with utility, but table organization could be >>>> improved (by spec owner) >>>> for example, to split first column into a name and a URI, and/or >>>> use the second >>>> column as a row header. >>>> >>>> Validator, XPath, XPathExpression, xpath/package-info: >>>> table updated manually (class="plain") >>>> >>>> Attr >>>> table updated with utility >>>> table could be improved by removing redundant atributes, like >>>> rowspan='1' colspan='1' >>>> >>>> Document, Node: >>>> all tables updated with utility >>>> >>>> -- Jon >>> >>> >>> >>> >>> Lance >>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >> > From huaming.li at oracle.com Mon Jul 10 09:17:18 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 10 Jul 2017 17:17:18 +0800 Subject: (10/jaxp) RFR of JDK-8184062: wrong @modules javax.xml at jaxp/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java Message-ID: <21ec6486-e455-ce83-deff-3ba9d26cd1cb@oracle.com> Would you please review below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8184062 webrev: http://cr.openjdk.java.net/~mli/8184062/webrev.00/, also attach diff as below Thank you -Hamlin ------------------------------------------------------------------------ diff -r 18b09cba334b test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java --- a/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java Fri Jul 07 03:13:49 2017 +0000 +++ b/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java Mon Jul 10 02:13:39 2017 -0700 @@ -45,7 +45,7 @@ /* * @test * @bug 8145974 - * @modules javax.xml + * @modules java.xml * @test * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest * @run testng/othervm -DrunSecMngr=true stream.XMLStreamWriterTest.SurrogatesTest From amy.lu at oracle.com Mon Jul 10 09:59:24 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 10 Jul 2017 17:59:24 +0800 Subject: (10/jaxp) RFR of JDK-8184062: wrong @modules javax.xml at jaxp/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java In-Reply-To: <21ec6486-e455-ce83-deff-3ba9d26cd1cb@oracle.com> References: <21ec6486-e455-ce83-deff-3ba9d26cd1cb@oracle.com> Message-ID: <2ac8446b-888b-26e1-4282-c219312dab9d@oracle.com> I noticed the module dependency is declared at test/javax/xml/jaxp/unittest/TEST.properties So @modules in this test file can just be deleted. Moreover, just noticed there are two @test which should be cleaned up. ( Not a reviewer.) Thanks, Amy On 7/10/17 5:17 PM, Hamlin Li wrote: > Would you please review below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8184062 > > webrev: http://cr.openjdk.java.net/~mli/8184062/webrev.00/, also > attach diff as below > > > Thank you > > -Hamlin > > ------------------------------------------------------------------------ > diff -r 18b09cba334b > test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java > --- > a/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java > Fri Jul 07 03:13:49 2017 +0000 > +++ > b/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java > Mon Jul 10 02:13:39 2017 -0700 > @@ -45,7 +45,7 @@ > /* > * @test > * @bug 8145974 > - * @modules javax.xml > + * @modules java.xml > * @test > * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest > * @run testng/othervm -DrunSecMngr=true > stream.XMLStreamWriterTest.SurrogatesTest > > From daniel.fuchs at oracle.com Mon Jul 10 10:10:36 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 10 Jul 2017 11:10:36 +0100 Subject: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation In-Reply-To: References: <595D3468.20201@oracle.com> <0ce69272-1025-a02d-a712-dd5a8c80f5fd@oracle.com> <2d78a8bd-2b6a-e52d-e5a1-4eba66e85fe7@oracle.com> <13cb85fe-32e0-5ef7-c9ae-502d6f3671d0@oracle.com> Message-ID: <291d4b59-eff7-fd0a-d623-4ea710d417fb@oracle.com> Hi Joe, Looks good to me. I have two additional comments, one nit - and one for some later follow-up - so no need for a new webrev. 1. Nit: I think it should be final as well: +++ new/src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java 2017-07-07 21:15:14.418212557 -0700 [...] - private static Integer m_synch_object = new Integer(1); + private static Object m_synch_object = new Object(); 2. Can you also add the following items to the list of things that should be investigated in a followup/cleanup? It bothers me that a non-deprecated method still needs to call a deprecated API: +++ new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIElementNSImpl.java 2017-07-07 21:15:01.881586697 -0700 [...] + @SuppressWarnings("deprecation") public String getSchemaDefault() { return fDeclaration == null ? null : fDeclaration.getConstraintValue(); } +++ new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java 2017-07-07 21:15:04.749729882 -0700 [...] + @SuppressWarnings("deprecation") public String getSchemaDefault() { return fDeclaration == null ? null : fDeclaration.getConstraintValue(); } +++ new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java 2017-07-07 21:15:04.749729882 -0700 [...] + @SuppressWarnings("deprecation") public String getSchemaDefault() { return fDeclaration == null ? null : fDeclaration.getConstraintValue(); } +++ new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java 2017-07-07 21:15:05.077746257 -0700 [...] + @SuppressWarnings("deprecation") public String getSchemaDefault() { return fDeclaration == null ? null : fDeclaration.getConstraintValue(); } cheers, -- daniel On 08/07/2017 01:53, huizhe wang wrote: > Here's the updated webrev: > http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev01/ > > Thanks, > Joe > > On 7/7/2017 10:59 AM, huizhe wang wrote: >> >>>> #11 >>>> com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java >>>> >>>> >>>> 1166 final public void setYear(BigInteger year) { >>>> >>>> nit: for consistency you should reorder the keywords to: >>>> >>>> public final void >>>> >>>> same file: >>>> >>>> - BigInteger.valueOf((long) 1) => BigInteger.ONE >>>> - new BigDecimal(TWELVE) => introduce a constant DECIMAL_TWELVE? >>>> - new BigDecimal(TWENTY_FOUR) => introduce a constant >>>> DECIMAL_TWENTY_FOUR? >>> >> >> Added the two constants. >> >>> >>> >>>> >>>> #12 >>>> com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java >>>> >>>> 81 @SuppressWarnings("deprecation") >>>> 82 public abstract class AbstractSAXParser >>>> 83 extends AbstractXMLDocumentParser >>>> 84 implements PSVIProvider, // PSVI >>>> 85 Parser, XMLReader // SAX1, SAX2 >>>> >>>> A better solution would be to deprecate the methods that implement >>>> deprecated methods - and avoid using deprecated APIs elsewhere... >>>> >>>> #13 >>>> com/sun/org/apache/xerces/internal/util/AttributesProxy.java >>>> >>>> 36 @SuppressWarnings("deprecation") >>>> 37 public final class AttributesProxy >>>> 38 implements AttributeList, Attributes2 { >>>> >>>> I wonder whether deprecating the methods implementing a deprecated >>>> API would allow to remove @SuppressWarnings("deprecation") - maybe not >>>> in this case since this class needs to implement a deprecated interface >>>> and a non deprecated one (and therefore the class itself can't be >>>> deprecated). Anyway it might be good to add the @Deprecated >>>> annotations to deprecated methods. >> >> We'll take a closer look at this through [1], for both #12 and #13, >> and #17 as well. AttributesProxy is used quite widely. We'll need to >> get into the details to see if we can remove the deprecated >> AttributeList. >> >> Since there are import references that are deprecated, the suppress >> annotation has to be added at the class. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8183972 >> >>>> >>>> #14 >>>> com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java >>>> >>>> >>>> if _main use deprecated APIs then maybe _main should be @Deprecated >>>> as well. >> >> Done. >>>> >>>> #15 >>>> com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java >>>> >>>> 207 private static Integer m_synch_object = 1; >>>> >>>> This is not correct! Since this object is only use as a synchronization >>>> lock then please change this to: >>>> >>>> private static Object m_synch_object = new Object(); >> >> Ok, fixed now. But I don't think the sync is necessary, logged >> https://bugs.openjdk.java.net/browse/JDK-8184019 to take a look later >> and can also do some cleanups. >> >>>> >>>> #16 >>>> com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java >>>> >>>> Can this class be changed to stop using deprecated APIs instead? >> >> It can probably be removed, will do so through >> https://bugs.openjdk.java.net/browse/JDK-8184020. >> >>>> >>>> >>>> #17 >>>> javax/xml/parsers/SAXParser.java >>>> org/xml/sax/helpers/ParserAdapter.java >>>> org/xml/sax/helpers/XMLReaderAdapter.java >>>> >>>> Can these classes be changed to stop using deprecated APIs instead? >>>> Or at least a cleanup issue logged for that effect? >> >> Most likely we can't since these are public APIs. DocumentHandler for >> example, is still usable. We can probably add forRemoval and then >> remove in the next release. >> >>>> >>>> That's all! >> >> Thanks for all of that! >> >> Best, >> Joe >> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 05/07/2017 19:48, Joe Wang wrote: >>>>> Hi, >>>>> >>>>> This patch fixes deprecation warnings in the jaxp repo. I'm >>>>> limiting the changes to deprecation or the 102 classes. The >>>>> cup-generated classes, XPath*.java, could use some cleanup or even >>>>> rewrite, but that will be left in future works (JDK-8183580). >>>>> >>>>> Most of the changes are straight-forward, but I did have trouble >>>>> with the replacing clazz.newInstance() with >>>>> clazz.getDeclaredConstructor().newInstance() since in some cases I >>>>> got RuntimePermission problems. So for most of such cases, I've >>>>> replaced them with getConstructor() instead, thanks Alan for the >>>>> suggestion. For specific cases such as xsltc/compiler/Parser.java, >>>>> I'm using getDeclaredConstructor() because some of the classes >>>>> didn't have a public constructor. >>>>> >>>>> Again, please bear with me for the cup-generated classes that have >>>>> super long lines (e.g. XPathParser.java). Please read with Udiffs >>>>> instead of Sdiffs. >>>>> >>>>> Some of the boxing (e.g. Integer.valueOf()) in the BCEL classes may >>>>> not be necessary, but that's how they look in BCEL to which an >>>>> update is scheduled in JDK 10. >>>>> >>>>> All tests passed. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181154 >>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev/ >>>>> >>>>> Thanks >>>>> Joe >>>>> >>>> >> > From lance.andersen at oracle.com Mon Jul 10 12:20:53 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 10 Jul 2017 08:20:53 -0400 Subject: (10/jaxp) RFR of JDK-8184062: wrong @modules javax.xml at jaxp/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java In-Reply-To: <2ac8446b-888b-26e1-4282-c219312dab9d@oracle.com> References: <21ec6486-e455-ce83-deff-3ba9d26cd1cb@oracle.com> <2ac8446b-888b-26e1-4282-c219312dab9d@oracle.com> Message-ID: <0534BBA3-ADFD-4B17-A182-E474D71C6708@oracle.com> Hi Hamilin > On Jul 10, 2017, at 5:59 AM, Amy Lu wrote: > > I noticed the module dependency is declared at test/javax/xml/jaxp/unittest/TEST.properties > So @modules in this test file can just be deleted. > Agree and on a quick scan this is the only test in that directory which includes @modules > Moreover, just noticed there are two @test which should be cleaned up. +1 > > ( Not a reviewer.) > > Thanks, > Amy > > On 7/10/17 5:17 PM, Hamlin Li wrote: >> Would you please review below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8184062 >> >> webrev: http://cr.openjdk.java.net/~mli/8184062/webrev.00/, also attach diff as below >> >> >> Thank you >> >> -Hamlin >> >> ------------------------------------------------------------------------ >> diff -r 18b09cba334b test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java >> --- a/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java Fri Jul 07 03:13:49 2017 +0000 >> +++ b/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java Mon Jul 10 02:13:39 2017 -0700 >> @@ -45,7 +45,7 @@ >> /* >> * @test >> * @bug 8145974 >> - * @modules javax.xml >> + * @modules java.xml >> * @test >> * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest >> * @run testng/othervm -DrunSecMngr=true stream.XMLStreamWriterTest.SurrogatesTest >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Mon Jul 10 14:56:54 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 10 Jul 2017 10:56:54 -0400 Subject: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation In-Reply-To: <291d4b59-eff7-fd0a-d623-4ea710d417fb@oracle.com> References: <595D3468.20201@oracle.com> <0ce69272-1025-a02d-a712-dd5a8c80f5fd@oracle.com> <2d78a8bd-2b6a-e52d-e5a1-4eba66e85fe7@oracle.com> <13cb85fe-32e0-5ef7-c9ae-502d6f3671d0@oracle.com> <291d4b59-eff7-fd0a-d623-4ea710d417fb@oracle.com> Message-ID: <0A5CFD9B-0245-45B9-B486-4E4DE1049806@oracle.com> > On Jul 10, 2017, at 6:10 AM, Daniel Fuchs wrote: > > Hi Joe, > > Looks good to me. I have two additional comments, one nit - and > one for some later follow-up - so no need for a new webrev. > > > 1. Nit: I think it should be final as well: > > +++ new/src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java 2017-07-07 21:15:14.418212557 -0700 > [...] > - private static Integer m_synch_object = new Integer(1); > + private static Object m_synch_object = new Object(); > +1 otherwise looks OK (including Daniel?s comment of course below ;-) ) > > 2. Can you also add the following items to the list of things > that should be investigated in a followup/cleanup? > It bothers me that a non-deprecated method still needs to call > a deprecated API: > > +++ new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIElementNSImpl.java 2017-07-07 21:15:01.881586697 -0700 > [...] > + @SuppressWarnings("deprecation") > public String getSchemaDefault() { > return fDeclaration == null ? null : fDeclaration.getConstraintValue(); > } > > +++ new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java 2017-07-07 21:15:04.749729882 -0700 > [...] > + @SuppressWarnings("deprecation") > public String getSchemaDefault() { > return fDeclaration == null ? null : fDeclaration.getConstraintValue(); > } > > +++ new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java 2017-07-07 21:15:04.749729882 -0700 > [...] > + @SuppressWarnings("deprecation") > public String getSchemaDefault() { > return fDeclaration == null ? null : fDeclaration.getConstraintValue(); > } > > +++ new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java 2017-07-07 21:15:05.077746257 -0700 > [...] > + @SuppressWarnings("deprecation") > public String getSchemaDefault() { > return fDeclaration == null ? null : fDeclaration.getConstraintValue(); > } > > > cheers, > > -- daniel > > On 08/07/2017 01:53, huizhe wang wrote: >> Here's the updated webrev: >> http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev01/ >> Thanks, >> Joe >> On 7/7/2017 10:59 AM, huizhe wang wrote: >>> >>>>> #11 >>>>> com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java >>>>> >>>>> 1166 final public void setYear(BigInteger year) { >>>>> >>>>> nit: for consistency you should reorder the keywords to: >>>>> >>>>> public final void >>>>> >>>>> same file: >>>>> >>>>> - BigInteger.valueOf((long) 1) => BigInteger.ONE >>>>> - new BigDecimal(TWELVE) => introduce a constant DECIMAL_TWELVE? >>>>> - new BigDecimal(TWENTY_FOUR) => introduce a constant DECIMAL_TWENTY_FOUR? >>>> >>> >>> Added the two constants. >>> >>>> >>>> >>>>> >>>>> #12 >>>>> com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java >>>>> >>>>> 81 @SuppressWarnings("deprecation") >>>>> 82 public abstract class AbstractSAXParser >>>>> 83 extends AbstractXMLDocumentParser >>>>> 84 implements PSVIProvider, // PSVI >>>>> 85 Parser, XMLReader // SAX1, SAX2 >>>>> >>>>> A better solution would be to deprecate the methods that implement >>>>> deprecated methods - and avoid using deprecated APIs elsewhere... >>>>> >>>>> #13 >>>>> com/sun/org/apache/xerces/internal/util/AttributesProxy.java >>>>> >>>>> 36 @SuppressWarnings("deprecation") >>>>> 37 public final class AttributesProxy >>>>> 38 implements AttributeList, Attributes2 { >>>>> >>>>> I wonder whether deprecating the methods implementing a deprecated >>>>> API would allow to remove @SuppressWarnings("deprecation") - maybe not >>>>> in this case since this class needs to implement a deprecated interface >>>>> and a non deprecated one (and therefore the class itself can't be >>>>> deprecated). Anyway it might be good to add the @Deprecated >>>>> annotations to deprecated methods. >>> >>> We'll take a closer look at this through [1], for both #12 and #13, and #17 as well. AttributesProxy is used quite widely. We'll need to get into the details to see if we can remove the deprecated AttributeList. >>> >>> Since there are import references that are deprecated, the suppress annotation has to be added at the class. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8183972 >>> >>>>> >>>>> #14 >>>>> com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java >>>>> >>>>> if _main use deprecated APIs then maybe _main should be @Deprecated >>>>> as well. >>> >>> Done. >>>>> >>>>> #15 >>>>> com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java >>>>> >>>>> 207 private static Integer m_synch_object = 1; >>>>> >>>>> This is not correct! Since this object is only use as a synchronization >>>>> lock then please change this to: >>>>> >>>>> private static Object m_synch_object = new Object(); >>> >>> Ok, fixed now. But I don't think the sync is necessary, logged https://bugs.openjdk.java.net/browse/JDK-8184019 to take a look later and can also do some cleanups. >>> >>>>> >>>>> #16 >>>>> com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java >>>>> >>>>> Can this class be changed to stop using deprecated APIs instead? >>> >>> It can probably be removed, will do so through https://bugs.openjdk.java.net/browse/JDK-8184020. >>> >>>>> >>>>> >>>>> #17 >>>>> javax/xml/parsers/SAXParser.java >>>>> org/xml/sax/helpers/ParserAdapter.java >>>>> org/xml/sax/helpers/XMLReaderAdapter.java >>>>> >>>>> Can these classes be changed to stop using deprecated APIs instead? >>>>> Or at least a cleanup issue logged for that effect? >>> >>> Most likely we can't since these are public APIs. DocumentHandler for example, is still usable. We can probably add forRemoval and then remove in the next release. >>> >>>>> >>>>> That's all! >>> >>> Thanks for all of that! >>> >>> Best, >>> Joe >>> >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 05/07/2017 19:48, Joe Wang wrote: >>>>>> Hi, >>>>>> >>>>>> This patch fixes deprecation warnings in the jaxp repo. I'm limiting the changes to deprecation or the 102 classes. The cup-generated classes, XPath*.java, could use some cleanup or even rewrite, but that will be left in future works (JDK-8183580). >>>>>> >>>>>> Most of the changes are straight-forward, but I did have trouble with the replacing clazz.newInstance() with clazz.getDeclaredConstructor().newInstance() since in some cases I got RuntimePermission problems. So for most of such cases, I've replaced them with getConstructor() instead, thanks Alan for the suggestion. For specific cases such as xsltc/compiler/Parser.java, I'm using getDeclaredConstructor() because some of the classes didn't have a public constructor. >>>>>> >>>>>> Again, please bear with me for the cup-generated classes that have super long lines (e.g. XPathParser.java). Please read with Udiffs instead of Sdiffs. >>>>>> >>>>>> Some of the boxing (e.g. Integer.valueOf()) in the BCEL classes may not be necessary, but that's how they look in BCEL to which an update is scheduled in JDK 10. >>>>>> >>>>>> All tests passed. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181154 >>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev/ >>>>>> >>>>>> Thanks >>>>>> Joe >>>>>> >>>>> >>> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Mon Jul 10 16:31:20 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 10 Jul 2017 09:31:20 -0700 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible In-Reply-To: <2be3b88f-5f75-3d38-9ef3-6a08aeae8abe@oracle.com> References: <595FCF73.80201@oracle.com> <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> <596002D9.9000309@oracle.com> <804638cf-20e2-5586-453a-fb2d92291f64@oracle.com> <2be3b88f-5f75-3d38-9ef3-6a08aeae8abe@oracle.com> Message-ID: <56d43d5e-98ef-e5ad-9777-e681ff89a3c5@oracle.com> Jon, Glad to know that works out. Hopefully this exercise with the jaxp repo can be a bit helpful to your effort and utility. Thanks for using the jaxp repo for this exercise! Best, Joe On 7/8/2017 9:58 AM, Jonathan Gibbons wrote: > > Joe, > > Thanks for the feedback. I've done some experiments and it looks like > we can indeed simplify the more complex tables to always use > scope=row|col. > > I'll post an amended webrev next week. > > Thanks for the feedback and suggestion to revisit this issue. > > -- Jon > > > On 7/7/17 5:50 PM, huizhe wang wrote: >> Hi Jon, >> >> For the table in CatalogFeatures, the id attribute for Type and Value >> are not used, may be unnecessary. Instead, scope="col" can be added, >> is that right? >> 50 * Type >> 51 * Value >> >> I'm new to accessibility, but it seems to me the following can use >> scope="colgroup" instead? >> >> 46 * Value [2] >> >> >> Since the 1st and 7th columns already have scope="row", if >> scope="col" can be added to the 8th (Action) column, the cells in the >> 8th (Action) column then won't need the "headers" attribute, would >> that be right? >> 1st column: 74 * > style="font-weight:normal" id="PREFER">PREFER ... >> 7th column: 81 * > style="font-weight:normal">{@code system} >> 8th column: 82 * >> >> For the table in XMLStreamWriter, it looks like to me we can avoid >> the headers for each cell by instead making the following changes: >> add rowspan="2" to >> 45 * Method >> add scope="colgroup" to >> 46 * {@code isRepairingNamespaces} == true >> 47 * {@code isRepairingNamespaces} == false >> remove: >> 50 * >> >> add scope="col" to >> 51 * namespaceURI bound >> 52 * namespaceURI unbound >> 53 * namespaceURI bound >> 54 * namespaceURI unbound >> >> add scope="row" to the first column of the rows in the body. >> >> Would that make sense? >> >> Thanks, >> Joe >> >> On 7/7/2017 2:53 PM, Jonathan Gibbons wrote: >>> Sorry, I meant to include that; will post shortly, beside the webrev. >>> >>> -- Jon >>> >>> On 07/07/2017 01:33 PM, Lance Andersen wrote: >>>> Hi Jon, >>>> >>>> The changes looked good to me. Is the html available by chance to >>>> do an extra sanity check? >>>> >>>> Best >>>> Lance >>>>> On Jul 7, 2017, at 2:14 PM, Jonathan Gibbons >>>>> > >>>>> wrote: >>>>> >>>>> Please review the following fixes to the doc comments in the jaxp >>>>> repo. >>>>> >>>>> The primary goal is to fix user-written tables in doc comments for >>>>> accessibility, either by updating tables to use scope=row|col in >>>>> header cells for simple tables, or by using the headings attribute >>>>> in more complex tables. The majority of the changes, to tables >>>>> using class="striped", were done mechanically, using a custom Java >>>>> utility. Three tables were fixed up manually. >>>>> >>>>> In addition, I removed the use of

tags which introduced empty >>>>> paragraph. These tags caused warnings when checking the code with >>>>> the "tidy" program. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 >>>>> Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ >>>>> >>>>> >>>>> ----- >>>>> >>>>> The following list of comments about the changes is ordered >>>>> according to the list in the webrev. >>>>> >>>>> Catalog: >>>>> removed empty

>>>>> >>>>> CatalogFeatures: >>>>> first table updated manually (class="plain") >>>>> removed empty

>>>>> second table updated with utility >>>>> >>>>> CatalogResolver: >>>>> removed empty

>>>>> >>>>> DatatypeFactory, Duration: >>>>> table updated with utility >>>>> >>>>> XMLGregorianCalendar: >>>>> all tables updated with utility >>>>> >>>>> datatype/package-info: >>>>> table updated with utility >>>>> >>>>> NamespaceContext: >>>>> all tables updated with utility >>>>> >>>>> XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: >>>>> table updated with utility >>>>> >>>>> XMLStreamWriter: >>>>> this is the one table with class="striped" that had to be updated >>>>> manually, because of the complex headers >>>>> >>>>> SchemaFactory: >>>>> table updated with utility, but table organization could be >>>>> improved (by spec owner) >>>>> for example, to split first column into a name and a URI, >>>>> and/or use the second >>>>> column as a row header. >>>>> >>>>> Validator, XPath, XPathExpression, xpath/package-info: >>>>> table updated manually (class="plain") >>>>> >>>>> Attr >>>>> table updated with utility >>>>> table could be improved by removing redundant atributes, like >>>>> rowspan='1' colspan='1' >>>>> >>>>> Document, Node: >>>>> all tables updated with utility >>>>> >>>>> -- Jon >>>> >>>> >>>> >>>> >>>> Lance >>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >>> >> > From huizhe.wang at oracle.com Mon Jul 10 17:40:21 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 10 Jul 2017 10:40:21 -0700 Subject: RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation In-Reply-To: <0A5CFD9B-0245-45B9-B486-4E4DE1049806@oracle.com> References: <595D3468.20201@oracle.com> <0ce69272-1025-a02d-a712-dd5a8c80f5fd@oracle.com> <2d78a8bd-2b6a-e52d-e5a1-4eba66e85fe7@oracle.com> <13cb85fe-32e0-5ef7-c9ae-502d6f3671d0@oracle.com> <291d4b59-eff7-fd0a-d623-4ea710d417fb@oracle.com> <0A5CFD9B-0245-45B9-B486-4E4DE1049806@oracle.com> Message-ID: <78d16da1-e4a4-32f5-fdc0-a6240f80fa6d@oracle.com> Hi Lance, Daniel, I pushed the changeset after adding 'final' to the following, and then logged this issue [1] for investigating the deprecated method. [1] https://bugs.openjdk.java.net/browse/JDK-8184103 Thanks again for the reviews! Joe On 7/10/2017 7:56 AM, Lance Andersen wrote: > >> On Jul 10, 2017, at 6:10 AM, Daniel Fuchs > > wrote: >> >> Hi Joe, >> >> Looks good to me. I have two additional comments, one nit - and >> one for some later follow-up - so no need for a new webrev. >> >> >> 1. Nit: I think it should be final as well: >> >> +++ >> new/src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java >> 2017-07-07 21:15:14.418212557 -0700 >> [...] >> - private static Integer m_synch_object = new Integer(1); >> + private static Object m_synch_object = new Object(); >> > > +1 > > otherwise looks OK (including Daniel?s comment of course below ;-) ) >> >> 2. Can you also add the following items to the list of things >> that should be investigated in a followup/cleanup? >> It bothers me that a non-deprecated method still needs to call >> a deprecated API: >> >> +++ >> new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIElementNSImpl.java >> 2017-07-07 21:15:01.881586697 -0700 >> [...] >> + @SuppressWarnings("deprecation") >> public String getSchemaDefault() { >> return fDeclaration == null ? null : >> fDeclaration.getConstraintValue(); >> } >> >> +++ >> new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java >> 2017-07-07 21:15:04.749729882 -0700 >> [...] >> + @SuppressWarnings("deprecation") >> public String getSchemaDefault() { >> return fDeclaration == null ? null : >> fDeclaration.getConstraintValue(); >> } >> >> +++ >> new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java >> 2017-07-07 21:15:04.749729882 -0700 >> [...] >> + @SuppressWarnings("deprecation") >> public String getSchemaDefault() { >> return fDeclaration == null ? null : >> fDeclaration.getConstraintValue(); >> } >> >> +++ >> new/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java >> 2017-07-07 21:15:05.077746257 -0700 >> [...] >> + @SuppressWarnings("deprecation") >> public String getSchemaDefault() { >> return fDeclaration == null ? null : >> fDeclaration.getConstraintValue(); >> } >> >> >> cheers, >> >> -- daniel >> >> On 08/07/2017 01:53, huizhe wang wrote: >>> Here's the updated webrev: >>> http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev01/ >>> >>> Thanks, >>> Joe >>> On 7/7/2017 10:59 AM, huizhe wang wrote: >>>> >>>>>> #11 >>>>>> com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java >>>>>> >>>>>> >>>>>> 1166 final public void setYear(BigInteger year) { >>>>>> >>>>>> nit: for consistency you should reorder the keywords to: >>>>>> >>>>>> public final void >>>>>> >>>>>> same file: >>>>>> >>>>>> - BigInteger.valueOf((long) 1) => BigInteger.ONE >>>>>> - new BigDecimal(TWELVE) => introduce a constant DECIMAL_TWELVE? >>>>>> - new BigDecimal(TWENTY_FOUR) => introduce a constant >>>>>> DECIMAL_TWENTY_FOUR? >>>>> >>>> >>>> Added the two constants. >>>> >>>>> >>>>> >>>>>> >>>>>> #12 >>>>>> com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java >>>>>> >>>>>> 81 @SuppressWarnings("deprecation") >>>>>> 82 public abstract class AbstractSAXParser >>>>>> 83 extends AbstractXMLDocumentParser >>>>>> 84 implements PSVIProvider, // PSVI >>>>>> 85 Parser, XMLReader // SAX1, SAX2 >>>>>> >>>>>> A better solution would be to deprecate the methods that implement >>>>>> deprecated methods - and avoid using deprecated APIs elsewhere... >>>>>> >>>>>> #13 >>>>>> com/sun/org/apache/xerces/internal/util/AttributesProxy.java >>>>>> >>>>>> 36 @SuppressWarnings("deprecation") >>>>>> 37 public final class AttributesProxy >>>>>> 38 implements AttributeList, Attributes2 { >>>>>> >>>>>> I wonder whether deprecating the methods implementing a deprecated >>>>>> API would allow to remove @SuppressWarnings("deprecation") - >>>>>> maybe not >>>>>> in this case since this class needs to implement a deprecated >>>>>> interface >>>>>> and a non deprecated one (and therefore the class itself can't be >>>>>> deprecated). Anyway it might be good to add the @Deprecated >>>>>> annotations to deprecated methods. >>>> >>>> We'll take a closer look at this through [1], for both #12 and #13, >>>> and #17 as well. AttributesProxy is used quite widely. We'll need >>>> to get into the details to see if we can remove the deprecated >>>> AttributeList. >>>> >>>> Since there are import references that are deprecated, the suppress >>>> annotation has to be added at the class. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8183972 >>>> >>>>>> >>>>>> #14 >>>>>> com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java >>>>>> >>>>>> >>>>>> if _main use deprecated APIs then maybe _main should be @Deprecated >>>>>> as well. >>>> >>>> Done. >>>>>> >>>>>> #15 >>>>>> com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java >>>>>> >>>>>> 207 private static Integer m_synch_object = 1; >>>>>> >>>>>> This is not correct! Since this object is only use as a >>>>>> synchronization >>>>>> lock then please change this to: >>>>>> >>>>>> private static Object m_synch_object = new Object(); >>>> >>>> Ok, fixed now. But I don't think the sync is necessary, logged >>>> https://bugs.openjdk.java.net/browse/JDK-8184019 to take a look >>>> later and can also do some cleanups. >>>> >>>>>> >>>>>> #16 >>>>>> com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java >>>>>> >>>>>> Can this class be changed to stop using deprecated APIs instead? >>>> >>>> It can probably be removed, will do so through >>>> https://bugs.openjdk.java.net/browse/JDK-8184020. >>>> >>>>>> >>>>>> >>>>>> #17 >>>>>> javax/xml/parsers/SAXParser.java >>>>>> org/xml/sax/helpers/ParserAdapter.java >>>>>> org/xml/sax/helpers/XMLReaderAdapter.java >>>>>> >>>>>> Can these classes be changed to stop using deprecated APIs instead? >>>>>> Or at least a cleanup issue logged for that effect? >>>> >>>> Most likely we can't since these are public APIs. DocumentHandler >>>> for example, is still usable. We can probably add forRemoval and >>>> then remove in the next release. >>>> >>>>>> >>>>>> That's all! >>>> >>>> Thanks for all of that! >>>> >>>> Best, >>>> Joe >>>> >>>>>> >>>>>> best regards, >>>>>> >>>>>> -- daniel >>>>>> >>>>>> On 05/07/2017 19:48, Joe Wang wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This patch fixes deprecation warnings in the jaxp repo. I'm >>>>>>> limiting the changes to deprecation or the 102 classes. The >>>>>>> cup-generated classes, XPath*.java, could use some cleanup or >>>>>>> even rewrite, but that will be left in future works (JDK-8183580). >>>>>>> >>>>>>> Most of the changes are straight-forward, but I did have trouble >>>>>>> with the replacing clazz.newInstance() with >>>>>>> clazz.getDeclaredConstructor().newInstance() since in some cases >>>>>>> I got RuntimePermission problems. So for most of such cases, >>>>>>> I've replaced them with getConstructor() instead, thanks Alan >>>>>>> for the suggestion. For specific cases such as >>>>>>> xsltc/compiler/Parser.java, I'm using getDeclaredConstructor() >>>>>>> because some of the classes didn't have a public constructor. >>>>>>> >>>>>>> Again, please bear with me for the cup-generated classes that >>>>>>> have super long lines (e.g. XPathParser.java). Please read with >>>>>>> Udiffs instead of Sdiffs. >>>>>>> >>>>>>> Some of the boxing (e.g. Integer.valueOf()) in the BCEL classes >>>>>>> may not be necessary, but that's how they look in BCEL to which >>>>>>> an update is scheduled in JDK 10. >>>>>>> >>>>>>> All tests passed. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181154 >>>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev/ >>>>>>> >>>>>>> Thanks >>>>>>> Joe >>>>>>> >>>>>> >>>> >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From brian.burkhalter at oracle.com Mon Jul 10 20:24:24 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 10 Jul 2017 13:24:24 -0700 Subject: Is there any reason why the MacOS X port doesn't provide a UserDefinedFileAttributeView? In-Reply-To: References: Message-ID: <49080AA6-4423-4C99-8BF4-8543CDBCA0F5@oracle.com> On Jul 3, 2017, at 1:05 PM, Alan Bateman wrote: > On 03/07/2017 20:39, Simon Spero wrote: >> It seems like it ought be relatively simple to add, since the API is not >> too far off of Linux (with NO_FOLLOW as an option to syscall rather than a >> separate entry point). >> > This has been discussed on nio-dev once or twice. It wasn't in the original port from Apple and just hasn't bubbled to the top of anyone's list. There is an enhancement request on file for this: https://bugs.openjdk.java.net/browse/JDK-8030048 Brian From ecki at zusammenkunft.net Mon Jul 10 22:45:30 2017 From: ecki at zusammenkunft.net (Bernd) Date: Tue, 11 Jul 2017 00:45:30 +0200 Subject: Binding on established (pipe endpoint) ports on Windows Message-ID: Hello, I had the problem in a project that having a number of Pipe Objects (from the default Windows Selector Provider) produced a range of used TCP ports. This is somewhat expected (if you accept the fact it uses Sockets for this): > netstat -nao | findstr 5600 TCP 127.0.0.1:51067 127.0.0.1:51068 HERGESTELLT 5600 TCP 127.0.0.1:51068 127.0.0.1:51067 HERGESTELLT 5600 TCP 127.0.0.1:51069 127.0.0.1:51070 HERGESTELLT 5600 TCP 127.0.0.1:51070 127.0.0.1:51069 HERGESTELLT 5600 Note there are no listening socket. When I now use a ServerSocket/accept on any of the above ports every second fails - if and only if I bind to 0.0.0.0:x but not 127.0.0.1:x (no matter if reuse is specified or not): 51067 accepting ... ServerSocket[addr=0.0.0.0/0.0.0.0,localport=51067] ok 51068 Failed 51068: java.net.BindException: Address already in use: JVM_Bind 51069 accepting ... ServerSocket[addr=0.0.0.0/0.0.0.0,localport=51069] ok 51070 Failed 51070: java.net.BindException: Address already in use: JVM_Bind Any idea what is causing this on Windows. I would not expect the bind to fail on a port from a established socket (but serversocket was closed after accept as Pipe does). Source: https://gist.github.com/ecki/e69bbca3826c838d51d6239901cb681f Tested with Win10 and 8u131 but also seen it with other Windows Versions. Gruss Bernd From jonathan.gibbons at oracle.com Mon Jul 10 22:52:45 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Jul 2017 15:52:45 -0700 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible In-Reply-To: <2be3b88f-5f75-3d38-9ef3-6a08aeae8abe@oracle.com> References: <595FCF73.80201@oracle.com> <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> <596002D9.9000309@oracle.com> <804638cf-20e2-5586-453a-fb2d92291f64@oracle.com> <2be3b88f-5f75-3d38-9ef3-6a08aeae8abe@oracle.com> Message-ID: <5964053D.8060702@oracle.com> Here is the amended webrev for the work on fixing the tables (and other nits) in the jaxp docs. As we discussed, I changed the two manually edited tables, in CatalogFeatures and XMLStreamWriter, to use scope=row/col. There are now no tables in the jaxp repo using headers to identify row and column headers. I found two more tables that needed fixing in /src/java.xml/share/classes/org/xml/sax/package-info.java. I've also fixed a minor doc bug JDK-8183984 in which ! in the first sentence was causing javadoc to generate invalid HTML output. https://bugs.openjdk.java.net/browse/JDK-8183984 Finally, I fixed one more excess

, in XMLReaderFactory. As a result of all this, the java.xml module gets a clean bill of documentary health, for all the checks we are currently tracking. -- Jon On 07/08/2017 09:58 AM, Jonathan Gibbons wrote: > Joe, > > Thanks for the feedback. I've done some experiments and it looks like > we can indeed simplify the more complex tables to always use > scope=row|col. > > I'll post an amended webrev next week. > > Thanks for the feedback and suggestion to revisit this issue. > > -- Jon > > > On 7/7/17 5:50 PM, huizhe wang wrote: >> Hi Jon, >> >> For the table in CatalogFeatures, the id attribute for Type and Value >> are not used, may be unnecessary. Instead, scope="col" can be added, >> is that right? >> 50 * Type >> 51 * Value >> >> I'm new to accessibility, but it seems to me the following can use >> scope="colgroup" instead? >> >> 46 * Value >> [2] >> >> >> Since the 1st and 7th columns already have scope="row", if >> scope="col" can be added to the 8th (Action) column, the cells in the >> 8th (Action) column then won't need the "headers" attribute, would >> that be right? >> 1st column: 74 * > style="font-weight:normal" id="PREFER">PREFER ... >> 7th column: 81 * > style="font-weight:normal">{@code system} >> 8th column: 82 * >> >> For the table in XMLStreamWriter, it looks like to me we can avoid >> the headers for each cell by instead making the following changes: >> add rowspan="2" to >> 45 * Method >> add scope="colgroup" to >> 46 * {@code isRepairingNamespaces} == true >> 47 * {@code isRepairingNamespaces} == false >> remove: >> 50 * >> >> add scope="col" to >> 51 * namespaceURI bound >> 52 * namespaceURI unbound >> 53 * namespaceURI bound >> 54 * namespaceURI unbound >> >> add scope="row" to the first column of the rows in the body. >> >> Would that make sense? >> >> Thanks, >> Joe >> >> On 7/7/2017 2:53 PM, Jonathan Gibbons wrote: >>> Sorry, I meant to include that; will post shortly, beside the webrev. >>> >>> -- Jon >>> >>> On 07/07/2017 01:33 PM, Lance Andersen wrote: >>>> Hi Jon, >>>> >>>> The changes looked good to me. Is the html available by chance to >>>> do an extra sanity check? >>>> >>>> Best >>>> Lance >>>>> On Jul 7, 2017, at 2:14 PM, Jonathan Gibbons >>>>> > >>>>> wrote: >>>>> >>>>> Please review the following fixes to the doc comments in the jaxp >>>>> repo. >>>>> >>>>> The primary goal is to fix user-written tables in doc comments for >>>>> accessibility, either by updating tables to use scope=row|col in >>>>> header cells for simple tables, or by using the headings attribute >>>>> in more complex tables. The majority of the changes, to tables >>>>> using class="striped", were done mechanically, using a custom Java >>>>> utility. Three tables were fixed up manually. >>>>> >>>>> In addition, I removed the use of

tags which introduced empty >>>>> paragraph. These tags caused warnings when checking the code with >>>>> the "tidy" program. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 >>>>> Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ >>>>> >>>>> >>>>> ----- >>>>> >>>>> The following list of comments about the changes is ordered >>>>> according to the list in the webrev. >>>>> >>>>> Catalog: >>>>> removed empty

>>>>> >>>>> CatalogFeatures: >>>>> first table updated manually (class="plain") >>>>> removed empty

>>>>> second table updated with utility >>>>> >>>>> CatalogResolver: >>>>> removed empty

>>>>> >>>>> DatatypeFactory, Duration: >>>>> table updated with utility >>>>> >>>>> XMLGregorianCalendar: >>>>> all tables updated with utility >>>>> >>>>> datatype/package-info: >>>>> table updated with utility >>>>> >>>>> NamespaceContext: >>>>> all tables updated with utility >>>>> >>>>> XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: >>>>> table updated with utility >>>>> >>>>> XMLStreamWriter: >>>>> this is the one table with class="striped" that had to be updated >>>>> manually, because of the complex headers >>>>> >>>>> SchemaFactory: >>>>> table updated with utility, but table organization could be >>>>> improved (by spec owner) >>>>> for example, to split first column into a name and a URI, >>>>> and/or use the second >>>>> column as a row header. >>>>> >>>>> Validator, XPath, XPathExpression, xpath/package-info: >>>>> table updated manually (class="plain") >>>>> >>>>> Attr >>>>> table updated with utility >>>>> table could be improved by removing redundant atributes, like >>>>> rowspan='1' colspan='1' >>>>> >>>>> Document, Node: >>>>> all tables updated with utility >>>>> >>>>> -- Jon >>>> >>>> >>>> >>>> >>>> Lance >>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >>> >> > From huizhe.wang at oracle.com Tue Jul 11 00:40:49 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 10 Jul 2017 17:40:49 -0700 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible In-Reply-To: <5964053D.8060702@oracle.com> References: <595FCF73.80201@oracle.com> <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> <596002D9.9000309@oracle.com> <804638cf-20e2-5586-453a-fb2d92291f64@oracle.com> <2be3b88f-5f75-3d38-9ef3-6a08aeae8abe@oracle.com> <5964053D.8060702@oracle.com> Message-ID: <30a3f12f-7ecd-db10-1374-f77ef616853e@oracle.com> That looks great! Almost all "green"! The only exception is the table in javax/xml/validation/Validator.java where the empty cell resulted in a reported "ERROR". I tried changing to and saw that the tool happily accepted it: - 138 * + 138 * If you decide to adopt the above, no need to re-generate the webrevs. Thanks, Joe On 7/10/2017 3:52 PM, Jonathan Gibbons wrote: > Here is the amended webrev for the work on fixing the tables (and > other nits) in the jaxp docs. > > As we discussed, I changed the two manually edited tables, in > CatalogFeatures and XMLStreamWriter, to use scope=row/col. There are > now no tables in the jaxp repo using headers to identify row and > column headers. > > I found two more tables that needed fixing in > /src/java.xml/share/classes/org/xml/sax/package-info.java. > > I've also fixed a minor doc bug JDK-8183984 in which ! in the first > sentence was causing javadoc to generate invalid HTML output. > https://bugs.openjdk.java.net/browse/JDK-8183984 > > Finally, I fixed one more excess

, in XMLReaderFactory. > > As a result of all this, the java.xml module gets a clean bill of > documentary health, for all the checks we are currently tracking. > > -- Jon > > On 07/08/2017 09:58 AM, Jonathan Gibbons wrote: >> Joe, >> >> Thanks for the feedback. I've done some experiments and it looks >> like we can indeed simplify the more complex tables to always use >> scope=row|col. >> >> I'll post an amended webrev next week. >> >> Thanks for the feedback and suggestion to revisit this issue. >> >> -- Jon >> >> >> On 7/7/17 5:50 PM, huizhe wang wrote: >>> Hi Jon, >>> >>> For the table in CatalogFeatures, the id attribute for Type and >>> Value are not used, may be unnecessary. Instead, scope="col" can be >>> added, is that right? >>> 50 * Type >>> 51 * Value >>> >>> I'm new to accessibility, but it seems to me the following can use >>> scope="colgroup" instead? >>> >>> 46 * Value >>> [2] >>> >>> >>> Since the 1st and 7th columns already have scope="row", if >>> scope="col" can be added to the 8th (Action) column, the cells in >>> the 8th (Action) column then won't need the "headers" attribute, >>> would that be right? >>> 1st column: 74 * >> style="font-weight:normal" id="PREFER">PREFER ... >>> 7th column: 81 * >> style="font-weight:normal">{@code system} >>> 8th column: 82 * >>> >>> For the table in XMLStreamWriter, it looks like to me we can avoid >>> the headers for each cell by instead making the following changes: >>> add rowspan="2" to >>> 45 * Method >>> add scope="colgroup" to >>> 46 * {@code isRepairingNamespaces} == true >>> 47 * {@code isRepairingNamespaces} == false >>> remove: >>> 50 * >>> >>> add scope="col" to >>> 51 * namespaceURI bound >>> 52 * namespaceURI unbound >>> 53 * namespaceURI bound >>> 54 * namespaceURI unbound >>> >>> add scope="row" to the first column of the rows in the body. >>> >>> Would that make sense? >>> >>> Thanks, >>> Joe >>> >>> On 7/7/2017 2:53 PM, Jonathan Gibbons wrote: >>>> Sorry, I meant to include that; will post shortly, beside the webrev. >>>> >>>> -- Jon >>>> >>>> On 07/07/2017 01:33 PM, Lance Andersen wrote: >>>>> Hi Jon, >>>>> >>>>> The changes looked good to me. Is the html available by chance >>>>> to do an extra sanity check? >>>>> >>>>> Best >>>>> Lance >>>>>> On Jul 7, 2017, at 2:14 PM, Jonathan Gibbons >>>>>> >>>>> > wrote: >>>>>> >>>>>> Please review the following fixes to the doc comments in the jaxp >>>>>> repo. >>>>>> >>>>>> The primary goal is to fix user-written tables in doc comments >>>>>> for accessibility, either by updating tables to use scope=row|col >>>>>> in header cells for simple tables, or by using the headings >>>>>> attribute in more complex tables. The majority of the changes, to >>>>>> tables using class="striped", were done mechanically, using a >>>>>> custom Java utility. Three tables were fixed up manually. >>>>>> >>>>>> In addition, I removed the use of

tags which introduced empty >>>>>> paragraph. These tags caused warnings when checking the code with >>>>>> the "tidy" program. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 >>>>>> Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ >>>>>> >>>>>> >>>>>> ----- >>>>>> >>>>>> The following list of comments about the changes is ordered >>>>>> according to the list in the webrev. >>>>>> >>>>>> Catalog: >>>>>> removed empty

>>>>>> >>>>>> CatalogFeatures: >>>>>> first table updated manually (class="plain") >>>>>> removed empty

>>>>>> second table updated with utility >>>>>> >>>>>> CatalogResolver: >>>>>> removed empty

>>>>>> >>>>>> DatatypeFactory, Duration: >>>>>> table updated with utility >>>>>> >>>>>> XMLGregorianCalendar: >>>>>> all tables updated with utility >>>>>> >>>>>> datatype/package-info: >>>>>> table updated with utility >>>>>> >>>>>> NamespaceContext: >>>>>> all tables updated with utility >>>>>> >>>>>> XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: >>>>>> table updated with utility >>>>>> >>>>>> XMLStreamWriter: >>>>>> this is the one table with class="striped" that had to be updated >>>>>> manually, because of the complex headers >>>>>> >>>>>> SchemaFactory: >>>>>> table updated with utility, but table organization could be >>>>>> improved (by spec owner) >>>>>> for example, to split first column into a name and a URI, >>>>>> and/or use the second >>>>>> column as a row header. >>>>>> >>>>>> Validator, XPath, XPathExpression, xpath/package-info: >>>>>> table updated manually (class="plain") >>>>>> >>>>>> Attr >>>>>> table updated with utility >>>>>> table could be improved by removing redundant atributes, like >>>>>> rowspan='1' colspan='1' >>>>>> >>>>>> Document, Node: >>>>>> all tables updated with utility >>>>>> >>>>>> -- Jon >>>>> >>>>> >>>>> >>>>> >>>>> Lance >>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Tue Jul 11 00:46:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Jul 2017 17:46:13 -0700 Subject: RFR: 8184021: Fix tables in jaxp doc comments to be accessible In-Reply-To: <30a3f12f-7ecd-db10-1374-f77ef616853e@oracle.com> References: <595FCF73.80201@oracle.com> <9711A5D0-494E-4478-8710-393CF9C72328@oracle.com> <596002D9.9000309@oracle.com> <804638cf-20e2-5586-453a-fb2d92291f64@oracle.com> <2be3b88f-5f75-3d38-9ef3-6a08aeae8abe@oracle.com> <5964053D.8060702@oracle.com> <30a3f12f-7ecd-db10-1374-f77ef616853e@oracle.com> Message-ID: <59641FD5.9010400@oracle.com> Thanks. I see the ERROR. I'm not sure of the reasoning why your fix works: maybe because the data cell is empty, it doesn't need headers. I'll do more experiments! Anyway, I'm happy to go with the suggested fix. -- Jon On 07/10/2017 05:40 PM, huizhe wang wrote: > That looks great! Almost all "green"! > > The only exception is the table in javax/xml/validation/Validator.java > where the empty cell resulted in a reported "ERROR". I tried changing > to and saw that the tool happily accepted it: > > - 138 * > + 138 * > > If you decide to adopt the above, no need to re-generate the webrevs. > > Thanks, > Joe > > > On 7/10/2017 3:52 PM, Jonathan Gibbons wrote: >> Here is the amended webrev for the work on fixing the tables (and >> other nits) in the jaxp docs. >> >> As we discussed, I changed the two manually edited tables, in >> CatalogFeatures and XMLStreamWriter, to use scope=row/col. There are >> now no tables in the jaxp repo using headers to identify row and >> column headers. >> >> I found two more tables that needed fixing in >> /src/java.xml/share/classes/org/xml/sax/package-info.java. >> >> I've also fixed a minor doc bug JDK-8183984 in which ! in the first >> sentence was causing javadoc to generate invalid HTML output. >> https://bugs.openjdk.java.net/browse/JDK-8183984 >> >> Finally, I fixed one more excess

, in XMLReaderFactory. >> >> As a result of all this, the java.xml module gets a clean bill of >> documentary health, for all the checks we are currently tracking. >> >> -- Jon >> >> On 07/08/2017 09:58 AM, Jonathan Gibbons wrote: >>> Joe, >>> >>> Thanks for the feedback. I've done some experiments and it looks >>> like we can indeed simplify the more complex tables to always use >>> scope=row|col. >>> >>> I'll post an amended webrev next week. >>> >>> Thanks for the feedback and suggestion to revisit this issue. >>> >>> -- Jon >>> >>> >>> On 7/7/17 5:50 PM, huizhe wang wrote: >>>> Hi Jon, >>>> >>>> For the table in CatalogFeatures, the id attribute for Type and >>>> Value are not used, may be unnecessary. Instead, scope="col" can be >>>> added, is that right? >>>> 50 * Type >>>> 51 * Value >>>> >>>> I'm new to accessibility, but it seems to me the following can use >>>> scope="colgroup" instead? >>>> >>>> 46 * Value >>>> [2] >>>> >>>> >>>> Since the 1st and 7th columns already have scope="row", if >>>> scope="col" can be added to the 8th (Action) column, the cells in >>>> the 8th (Action) column then won't need the "headers" attribute, >>>> would that be right? >>>> 1st column: 74 * >>> style="font-weight:normal" id="PREFER">PREFER ... >>>> 7th column: 81 * >>> style="font-weight:normal">{@code system} >>>> 8th column: 82 * >>>> >>>> For the table in XMLStreamWriter, it looks like to me we can avoid >>>> the headers for each cell by instead making the following changes: >>>> add rowspan="2" to >>>> 45 * Method >>>> add scope="colgroup" to >>>> 46 * {@code isRepairingNamespaces} == true >>>> 47 * {@code isRepairingNamespaces} == false >>>> remove: >>>> 50 * >>>> >>>> add scope="col" to >>>> 51 * namespaceURI bound >>>> 52 * namespaceURI unbound >>>> 53 * namespaceURI bound >>>> 54 * namespaceURI unbound >>>> >>>> add scope="row" to the first column of the rows in the body. >>>> >>>> Would that make sense? >>>> >>>> Thanks, >>>> Joe >>>> >>>> On 7/7/2017 2:53 PM, Jonathan Gibbons wrote: >>>>> Sorry, I meant to include that; will post shortly, beside the webrev. >>>>> >>>>> -- Jon >>>>> >>>>> On 07/07/2017 01:33 PM, Lance Andersen wrote: >>>>>> Hi Jon, >>>>>> >>>>>> The changes looked good to me. Is the html available by chance >>>>>> to do an extra sanity check? >>>>>> >>>>>> Best >>>>>> Lance >>>>>>> On Jul 7, 2017, at 2:14 PM, Jonathan Gibbons >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Please review the following fixes to the doc comments in the >>>>>>> jaxp repo. >>>>>>> >>>>>>> The primary goal is to fix user-written tables in doc comments >>>>>>> for accessibility, either by updating tables to use >>>>>>> scope=row|col in header cells for simple tables, or by using the >>>>>>> headings attribute in more complex tables. The majority of the >>>>>>> changes, to tables using class="striped", were done >>>>>>> mechanically, using a custom Java utility. Three tables were >>>>>>> fixed up manually. >>>>>>> >>>>>>> In addition, I removed the use of

tags which introduced >>>>>>> empty paragraph. These tags caused warnings when checking the >>>>>>> code with the "tidy" program. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8184021 >>>>>>> Webrev: http://cr.openjdk.java.net/~jjg/8184021/webrev.00/ >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> >>>>>>> The following list of comments about the changes is ordered >>>>>>> according to the list in the webrev. >>>>>>> >>>>>>> Catalog: >>>>>>> removed empty

>>>>>>> >>>>>>> CatalogFeatures: >>>>>>> first table updated manually (class="plain") >>>>>>> removed empty

>>>>>>> second table updated with utility >>>>>>> >>>>>>> CatalogResolver: >>>>>>> removed empty

>>>>>>> >>>>>>> DatatypeFactory, Duration: >>>>>>> table updated with utility >>>>>>> >>>>>>> XMLGregorianCalendar: >>>>>>> all tables updated with utility >>>>>>> >>>>>>> datatype/package-info: >>>>>>> table updated with utility >>>>>>> >>>>>>> NamespaceContext: >>>>>>> all tables updated with utility >>>>>>> >>>>>>> XMLEventWriter, XMLInputFactory, XMLOutputFactory, XMLStreamReader: >>>>>>> table updated with utility >>>>>>> >>>>>>> XMLStreamWriter: >>>>>>> this is the one table with class="striped" that had to be >>>>>>> updated >>>>>>> manually, because of the complex headers >>>>>>> >>>>>>> SchemaFactory: >>>>>>> table updated with utility, but table organization could be >>>>>>> improved (by spec owner) >>>>>>> for example, to split first column into a name and a URI, >>>>>>> and/or use the second >>>>>>> column as a row header. >>>>>>> >>>>>>> Validator, XPath, XPathExpression, xpath/package-info: >>>>>>> table updated manually (class="plain") >>>>>>> >>>>>>> Attr >>>>>>> table updated with utility >>>>>>> table could be improved by removing redundant atributes, like >>>>>>> rowspan='1' colspan='1' >>>>>>> >>>>>>> Document, Node: >>>>>>> all tables updated with utility >>>>>>> >>>>>>> -- Jon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Lance >>>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>> Oracle Java Engineering >>>>>> 1 Network Drive >>>>>> Burlington, MA 01803 >>>>>> Lance.Andersen at oracle.com >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From huaming.li at oracle.com Tue Jul 11 01:31:15 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 11 Jul 2017 09:31:15 +0800 Subject: (10/jaxp) RFR of JDK-8184062: wrong @modules javax.xml at jaxp/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java In-Reply-To: <0534BBA3-ADFD-4B17-A182-E474D71C6708@oracle.com> References: <21ec6486-e455-ce83-deff-3ba9d26cd1cb@oracle.com> <2ac8446b-888b-26e1-4282-c219312dab9d@oracle.com> <0534BBA3-ADFD-4B17-A182-E474D71C6708@oracle.com> Message-ID: Hi Lance, Amy, As you suggested, deleted @modules and redundant @test in SurrogatesTest.java, the change is pushed. Thank you -Hamlin On 2017/7/10 20:20, Lance Andersen wrote: > Hi Hamilin > >> On Jul 10, 2017, at 5:59 AM, Amy Lu > > wrote: >> >> I noticed the module dependency is declared at >> test/javax/xml/jaxp/unittest/TEST.properties >> So @modules in this test file can just be deleted. >> > > Agree and on a quick scan this is the only test in that directory > which includes @modules > >> Moreover, just noticed there are two @test which should be cleaned up. > +1 >> >> ( Not a reviewer.) >> >> Thanks, >> Amy >> >> On 7/10/17 5:17 PM, Hamlin Li wrote: >>> Would you please review below patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8184062 >>> >>> webrev: http://cr.openjdk.java.net/~mli/8184062/webrev.00/ >>> , also attach >>> diff as below >>> >>> >>> Thank you >>> >>> -Hamlin >>> >>> ------------------------------------------------------------------------ >>> diff -r 18b09cba334b >>> test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java >>> --- >>> a/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java >>> Fri Jul 07 03:13:49 2017 +0000 >>> +++ >>> b/test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java >>> Mon Jul 10 02:13:39 2017 -0700 >>> @@ -45,7 +45,7 @@ >>> /* >>> * @test >>> * @bug 8145974 >>> - * @modules javax.xml >>> + * @modules java.xml >>> * @test >>> * @library /javax/xml/jaxp/libs /javax/xml/jaxp/unittest >>> * @run testng/othervm -DrunSecMngr=true >>> stream.XMLStreamWriterTest.SurrogatesTest >>> >>> >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From paul.sandoz at oracle.com Tue Jul 11 04:04:19 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 10 Jul 2017 21:04:19 -0700 Subject: [9] RFR 8184119 Incorrect return processing for the LF editor of MethodHandles.permuteArguments Message-ID: <6F62CFEA-F167-4E96-A6A5-4AD2031F9F9F@oracle.com> Hi, Please review this small fix to MethodHandle.permuteArguments that causes a VM crash: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8184119-permute-args-return-an-arg/webrev/ https://bugs.openjdk.java.net/browse/JDK-8184119 This will also require back porting to 8. Thanks go to Jackson Davis for finding and reporting this issue. Thanks, Paul. From john.r.rose at oracle.com Tue Jul 11 05:59:19 2017 From: john.r.rose at oracle.com (John Rose) Date: Mon, 10 Jul 2017 22:59:19 -0700 Subject: [9] RFR 8184119 Incorrect return processing for the LF editor of MethodHandles.permuteArguments In-Reply-To: <6F62CFEA-F167-4E96-A6A5-4AD2031F9F9F@oracle.com> References: <6F62CFEA-F167-4E96-A6A5-4AD2031F9F9F@oracle.com> Message-ID: On Jul 10, 2017, at 9:04 PM, Paul Sandoz wrote: > > Please review this small fix to MethodHandle.permuteArguments that causes a VM crash: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8184119-permute-args-return-an-arg/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8184119 > > This will also require back porting to 8. > > Thanks go to Jackson Davis for finding and reporting this issue. Reviewed. Somebody was playing the oboe there, none too sweetly. ? John (oboe = Off By One Error) From vladimir.x.ivanov at oracle.com Tue Jul 11 06:55:57 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 11 Jul 2017 09:55:57 +0300 Subject: [9] RFR 8184119 Incorrect return processing for the LF editor of MethodHandles.permuteArguments In-Reply-To: <6F62CFEA-F167-4E96-A6A5-4AD2031F9F9F@oracle.com> References: <6F62CFEA-F167-4E96-A6A5-4AD2031F9F9F@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 7/11/17 7:04 AM, Paul Sandoz wrote: > Hi, > > Please review this small fix to MethodHandle.permuteArguments that causes a VM crash: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8184119-permute-args-return-an-arg/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8184119 > > This will also require back porting to 8. > > Thanks go to Jackson Davis for finding and reporting this issue. > > Thanks, > Paul. > From jonathan.gibbons at oracle.com Tue Jul 11 21:39:08 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Jul 2017 14:39:08 -0700 Subject: RFR: 8184208: update class="striped" tables for accessibility Message-ID: <5965457C.7030607@oracle.com> Please review this auto-generated update to improve the accessibility of many of the tables in the API docs for the java.base module. The changes are just to the HTML markup for selected tables; there is no change to the wording of any documentation. This update was generated by a utility program that looks for tables using the CSS style class "striped", and updates those tables as follows: * header cells () in the now declare scope="col" * the first data cell () in each row in the are changed to and declare scope="row". Although these cells are changed from to , the CSS still uses font-weight-normal for these cells. The changes are in line with HTML 5 and WCAG 2.0. This update does not include the following tables, which will be done separately (manually) * tables with CSS class "borderless" (18), "plain" (37), or no class (6) * tables in java.time.chrono (5): although these table use "striped", the first column does not contain unique values, and is therefore unsuited for the automated update All the modifiied tables have been visually checked with an accessibility checker. JBS: https://bugs.openjdk.java.net/browse/JDK-8184208 Webrev: http://cr.openjdk.java.net/~jjg/8184208/webrev.00/ API: http://cr.openjdk.java.net/~jjg/8184208/api.00/ -- Jon From brian.burkhalter at oracle.com Tue Jul 11 23:02:32 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 11 Jul 2017 16:02:32 -0700 Subject: RFR: 8184208: update class="striped" tables for accessibility In-Reply-To: <5965457C.7030607@oracle.com> References: <5965457C.7030607@oracle.com> Message-ID: On Jul 11, 2017, at 2:39 PM, Jonathan Gibbons wrote: > Please review this auto-generated update to improve the accessibility of many of the tables > in the API docs for the java.base module. Looks all right to me. > All the modifiied tables have been visually checked with an accessibility checker. There does not however appear to be a visual difference between the JDK 9 javadoc and the javadoc generated in a JDK 10 clone with this patch applied. Brian From jonathan.gibbons at oracle.com Tue Jul 11 23:18:11 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Jul 2017 16:18:11 -0700 Subject: RFR: 8184208: update class="striped" tables for accessibility In-Reply-To: References: <5965457C.7030607@oracle.com> Message-ID: <59655CB3.5020706@oracle.com> On 07/11/2017 04:02 PM, Brian Burkhalter wrote: > On Jul 11, 2017, at 2:39 PM, Jonathan Gibbons > > wrote: > >> Please review this auto-generated update to improve the accessibility >> of many of the tables >> in the API docs for the java.base module. > > Looks all right to me. > >> All the modifiied tables have been visually checked with an >> accessibility checker. > > There does not however appear to be a visual difference between the > JDK 9 javadoc and the javadoc generated in a JDK 10 clone with this > patch applied. > > Brian Brian, Yes, the differences will show up when using a screen reader or some form of accessibility checker. There should not be any noticeable difference for most users. -- Jon From lance.andersen at oracle.com Wed Jul 12 17:41:59 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 12 Jul 2017 13:41:59 -0400 Subject: RFR: 8184208: update class="striped" tables for accessibility In-Reply-To: <5965457C.7030607@oracle.com> References: <5965457C.7030607@oracle.com> Message-ID: <7B440653-F8F4-4710-9DDB-0009A70BFF0A@oracle.com> Looks good Jon. > On Jul 11, 2017, at 5:39 PM, Jonathan Gibbons wrote: > > Please review this auto-generated update to improve the accessibility of many of the tables > in the API docs for the java.base module. > > The changes are just to the HTML markup for selected tables; > there is no change to the wording of any documentation. > > This update was generated by a utility program that looks for tables using the > CSS style class "striped", and updates those tables as follows: > > * header cells () in the now declare scope="col" > * the first data cell () in each row in the are changed to > and declare scope="row". > Although these cells are changed from to , the CSS still uses font-weight-normal for > these cells. > > The changes are in line with HTML 5 and WCAG 2.0. > > This update does not include the following tables, which will be done separately (manually) > > * tables with CSS class "borderless" (18), "plain" (37), or no class (6) > * tables in java.time.chrono (5): although these table use "striped", > the first column does not contain unique values, and is therefore unsuited for the > automated update > > All the modifiied tables have been visually checked with an accessibility checker. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184208 > Webrev: http://cr.openjdk.java.net/~jjg/8184208/webrev.00/ > API: http://cr.openjdk.java.net/~jjg/8184208/api.00/ > > -- Jon > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jonathan.gibbons at oracle.com Wed Jul 12 21:00:26 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Jul 2017 14:00:26 -0700 Subject: RFR: 8184304: make tables in jdk.sctp module accessible Message-ID: <59668DEA.1010806@oracle.com> Continuing the work to improve the accessibility and markup of our docs, please review a small update to make the tables in the jdk.sctp module accessible. JBS: https://bugs.openjdk.java.net/browse/JDK-8184304 Webrev: http://cr.openjdk.java.net/~jjg/8184304/webrev.00/index.html API: http://cr.openjdk.java.net/~jjg/8184304/api.00/overview-summary.html -- Jon From Alan.Bateman at oracle.com Wed Jul 12 21:04:30 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Jul 2017 22:04:30 +0100 Subject: RFR: 8184304: make tables in jdk.sctp module accessible In-Reply-To: <59668DEA.1010806@oracle.com> References: <59668DEA.1010806@oracle.com> Message-ID: <52b6f33c-5cfb-362b-c013-9ef4818a0b91@oracle.com> On 12/07/2017 22:00, Jonathan Gibbons wrote: > Continuing the work to improve the accessibility and markup of our docs, > please review a small update to make the tables in the jdk.sctp module > accessible. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184304 > Webrev: http://cr.openjdk.java.net/~jjg/8184304/webrev.00/index.html > API: http://cr.openjdk.java.net/~jjg/8184304/api.00/overview-summary.html This looks okay to me. -Alan From vladimir.kozlov at oracle.com Wed Jul 12 21:20:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Jul 2017 14:20:52 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean Message-ID: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8182701 webrev: http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ Contributed by Jaroslav Tulach. JDK itself contains quite a lot of platform MBeans which get registered "on demand". Graal compiler (jdk.internal.vm.compiler) provides its own MBean(s) - however currently there is no way to register it "on demand". JDK9 already contains support for collecting platform MBeans from various modules. We just need to expose Graal MBean through JVMCI. Thanks, Vladimir From Alan.Bateman at oracle.com Wed Jul 12 21:29:28 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Jul 2017 22:29:28 +0100 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> Message-ID: <4b1cf33a-db04-87d7-0045-0fceed8b6acd@oracle.com> On 12/07/2017 22:20, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8182701 > webrev: > http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ > http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ > > Contributed by Jaroslav Tulach. > > JDK itself contains quite a lot of platform MBeans which get > registered "on demand". Graal compiler (jdk.internal.vm.compiler) > provides its own MBean(s) - however currently there is no way to > register it "on demand". JDK9 already contains support for collecting > platform MBeans from various modules. We just need to expose Graal > MBean through JVMCI. Just to say that using services, by having jdk.internal.vm.ci declare that it `provides` an implementation of PlatformMBeanProvider is the right way to do this (and the qualified export to get access to the service type is correct too). -Alan From chris.hegarty at oracle.com Wed Jul 12 21:49:43 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 12 Jul 2017 22:49:43 +0100 Subject: RFR: 8184304: make tables in jdk.sctp module accessible In-Reply-To: <59668DEA.1010806@oracle.com> References: <59668DEA.1010806@oracle.com> Message-ID: <7AB2FB1D-FB7C-4E4A-9D66-3AD1C777B8E0@oracle.com> Thanks Jon. Looks good. -Chris > On 12 Jul 2017, at 22:00, Jonathan Gibbons wrote: > > Continuing the work to improve the accessibility and markup of our docs, > please review a small update to make the tables in the jdk.sctp module accessible. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184304 > Webrev: http://cr.openjdk.java.net/~jjg/8184304/webrev.00/index.html > API: http://cr.openjdk.java.net/~jjg/8184304/api.00/overview-summary.html > > -- Jon From xueming.shen at oracle.com Wed Jul 12 23:06:02 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 12 Jul 2017 16:06:02 -0700 Subject: [9] JDK-8184306: zlib 1.2.11 upgrade triggers j.u.zip.Deflater regression Message-ID: <5966AB5A.80208@oracle.com> Hi, Please help review the change for #8184306. issue: https://bugs.openjdk.java.net/browse/JDK-8184306 webrev: http://cr.openjdk.java.net/~sherman/8184306/ Background: It appears the basic compression functionality of j.u.Deflater is broken when (1) the deflater's compression level/strategy is changed (to new value) AND (2) reset() which is a normal combination/use scenario when the deflater is being cached and reused. My reading of the 1.2.11 changes suggests the root cause is that the internal state "deflate_state.high_water" is not being reset correctly/appropriately (to 0?) in deflateReset/deflateResetKeep/lm_init(). AND the change of one of the conditions in deflate.c/deflateParams(), from "strm->total_in!=0" to "s->high_water" (in the "Flush last buffer" branch) as showed below, obvious triggers the regression from 1.2.8 to 1.2.11, in the scenario that the "strategy/levle is changed" AND a followup "reset()" is called (with the assumption that everything should be reset back to initial state and we start a new compression circle, with the new level and strategy. This is how it works in 1.2.8 and early releases). from (1.2.8's) if ((strategy != s->strategy || func != configuration_table[level].func) && strm->total_in != 0) { <---------------- /* Flush the last buffer: */ err = deflate(strm, Z_BLOCK); if (err == Z_BUF_ERROR && s->pending == 0) err = Z_OK; } to (1.2.11's) if ((strategy != s->strategy || func != configuration_table[level].func) && s->high_water) { <----------------- /* Flush the last buffer: */ int err = deflate(strm, Z_BLOCK); if (err == Z_STREAM_ERROR) return err; if (strm->avail_out == 0) return Z_BUF_ERROR; } With this change (in 1.2.11), now if there is any compression operation that leaves the "s->high_water" > 0, even after the "reset()" has been called, the next compression/deflateParam() will always "try to flush the last buffer" with the old state, which appears to be wrong. Given the nature of "reset" it appears reasonable to assume the "high_water" should be reset to 0, its initial value as well, inside either deflateResetKeep() or lm_init(). I have logged an issue at https://github.com/madler/zlib/issues/275 Jdk9 has been changed to use the system zlib for all platforms except the windows, this one currently only fails on windows. But I would assume if the underlying zlib is 1.2.11, the deflater/compression will be broken as well. Have not verified this yet. Anyone has a zlib 1.2.11 installed and trying jdk9 on it (on a non-Windows system) ? Instead of backout the 1.2.11 completely and reset back to 1.2.8, here I'm proposing to add the suggested one-line change to "fix" this issue for now and waiting for any official fix from zlib. The change seems easy and safe for me. It does fix the failure we are experiencing now. Thanks, Sherman From andrey.x.nazarov at oracle.com Thu Jul 13 00:19:18 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 12 Jul 2017 17:19:18 -0700 Subject: RFR 8174692: New MultiReleaseJarTest.java tests fail in JDK 10 Message-ID: <91E23B53-3A13-4F06-9C84-A2082A9B00F3@oracle.com> Hi, please review simple one line test fix http://cr.openjdk.java.net/~anazarov/JDK-8174692/webrev.00/webrev/ https://bugs.openjdk.java.net/browse/JDK-8174692 ?Andrei From jonathan.gibbons at oracle.com Thu Jul 13 02:06:23 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Jul 2017 19:06:23 -0700 Subject: RFR: 8184311: Update java.sql and java.sql.rowset API docs for accessibility Message-ID: <5966D59F.6040307@oracle.com> Please review ... More noreg-doc API cleanup for accessibility, etc. This time for java.sql and java.sql.rowset. One of the tables ought to be restructured a bit, because there is no single unique column to use for a rowheader, but that is a bigger change than I want to do in this round of updates. JBS: https://bugs.openjdk.java.net/browse/JDK-8184311 Webrev: http://cr.openjdk.java.net/~jjg/8184311/webrev.00/ API: http://cr.openjdk.java.net/~jjg/8184311/api.00/ -- Jon From Alan.Bateman at oracle.com Thu Jul 13 06:10:38 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Jul 2017 07:10:38 +0100 Subject: RFR 8174692: New MultiReleaseJarTest.java tests fail in JDK 10 In-Reply-To: <91E23B53-3A13-4F06-9C84-A2082A9B00F3@oracle.com> References: <91E23B53-3A13-4F06-9C84-A2082A9B00F3@oracle.com> Message-ID: <2db959e6-8e43-6af7-9638-c1f2001ae0ea@oracle.com> On 13/07/2017 01:19, Andrey Nazarov wrote: > Hi, > > please review simple one line test fix > > http://cr.openjdk.java.net/~anazarov/JDK-8174692/webrev.00/webrev/ > > https://bugs.openjdk.java.net/browse/JDK-8174692 > Looks okay to me. -Alan From Alan.Bateman at oracle.com Thu Jul 13 06:52:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Jul 2017 07:52:05 +0100 Subject: [9] JDK-8184306: zlib 1.2.11 upgrade triggers j.u.zip.Deflater regression In-Reply-To: <5966AB5A.80208@oracle.com> References: <5966AB5A.80208@oracle.com> Message-ID: <519bfa33-bc5f-f2d2-fd57-0d3b885ed170@oracle.com> On 13/07/2017 00:06, Xueming Shen wrote: > : > > My reading of the 1.2.11 changes suggests the root cause is that the > internal > state "deflate_state.high_water" is not being reset > correctly/appropriately (to 0?) > in deflateReset/deflateResetKeep/lm_init(). > > AND the change of one of the conditions in deflate.c/deflateParams(), > from > "strm->total_in!=0" to "s->high_water" (in the "Flush last buffer" > branch) as showed > below, obvious triggers the regression from 1.2.8 to 1.2.11, in the > scenario that > the "strategy/levle is changed" AND a followup "reset()" is called > (with the > assumption that everything should be reset back to initial state and > we start a > new compression circle, with the new level and strategy. This is how > it works > in 1.2.8 and early releases). This is good sleuthing and I think you have identified the regression. The fix looks right although it would be good to get confirmation from the zlib maintainers (no comments on zlib/issues/275 so far). As this is a P1 showstopper issue then additional eyes are welcome, esp. if we patch zlib rather than go back to an older version. -Alan From amy.lu at oracle.com Thu Jul 13 09:14:55 2017 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 13 Jul 2017 17:14:55 +0800 Subject: JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java Message-ID: java/lang/ClassLoader/deadlock/TestCrossDelegate.sh java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh Please review this patch to refactor the shell tests to java. bug: https://bugs.openjdk.java.net/browse/JDK-8183377 http://cr.openjdk.java.net/~amlu/8183377/webrev.00/ Thanks, Amy From lance.andersen at oracle.com Thu Jul 13 10:20:24 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 13 Jul 2017 06:20:24 -0400 Subject: RFR: 8184311: Update java.sql and java.sql.rowset API docs for accessibility In-Reply-To: <5966D59F.6040307@oracle.com> References: <5966D59F.6040307@oracle.com> Message-ID: looks fine Jon > On Jul 12, 2017, at 10:06 PM, Jonathan Gibbons wrote: > > Please review ... > > More noreg-doc API cleanup for accessibility, etc. This time for java.sql and java.sql.rowset. > One of the tables ought to be restructured a bit, because there is no single unique column > to use for a rowheader, but that is a bigger change than I want to do in this round of updates. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184311 > Webrev: http://cr.openjdk.java.net/~jjg/8184311/webrev.00/ > API: http://cr.openjdk.java.net/~jjg/8184311/api.00/ > > -- Jon > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From christoph.langer at sap.com Thu Jul 13 10:32:32 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 13 Jul 2017 10:32:32 +0000 Subject: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: References: <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: <2281d88b48db4f8baaf5c82ffe016539@sap.com> Hi Ogata, I'll take care of backporting a fix to remove the "volatile" qualifier for both, JDK-8182743 and JDK-8184330. Best regards Christoph > -----Original Message----- > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > Sent: Freitag, 7. Juli 2017 18:59 > To: core-libs-dev ; nio- > dev at openjdk.java.net > Cc: Langer, Christoph > Subject: RE: 8182743: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi all, > > Any comment on downporting a fix to JDK9u and JDK8u, which simply > removes > volatile? > > > Regards, > Ogata > > Kazunori Ogata/Japan/IBM wrote on 2017/07/03 17:28:54: > > > From: Kazunori Ogata/Japan/IBM > > To: "Langer, Christoph" > > Cc: core-libs-dev , "nio- > > dev at openjdk.java.net" > > Date: 2017/07/03 17:28 > > Subject: RE: 8182743: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > Hi Christoph, > > > > Thank you very much for your help! > > > > For JDK9 updates and JDK8 updates, it is desirable if we can back port > the > > removal of volatile. What should I do for it? > > > > Regards, > > Ogata > > > > From: "Langer, Christoph" > > To: Kazunori Ogata , "nio-dev at openjdk.java.net" > > dev at openjdk.java.net> > > Cc: core-libs-dev > > Date: 2017/07/03 17:17 > > Subject: RE: 8182743: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > Hi, > > > > I've pushed to JDK10 now: > http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/ > > 7a2bc0a80087 > > > > What do you think, shall we try to downport a fix to JDK9 updates and > JDK8 > > updates, which simply removes the volatile as we can't bring this > behavior > > changing fix down? > > > > Thanks > > Christoph > > > > > -----Original Message----- > > > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > > > Sent: Freitag, 30. Juni 2017 20:31 > > > To: Se?n Coffey > > > Cc: Langer, Christoph ; core-libs-dev > > > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > > > dev at openjdk.java.net > > > Subject: Re: 8182743: Ineffective use of volatile hurts performance of > > > Charset.atBugLevel() > > > > > > Hi Sean, > > > > > > Thank you for your comments. > > > > > > I fixed the copyright and updated webrev: > > > > > > http://cr.openjdk.java.net/~horii/8182743/webrev.03/ > > > > > > > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > > > 8182743 ? > > > > > > Yes, they should be 8182743. I fixed both. > > > > > > > > > Regards, > > > Ogata > > > > > > > > > Se?n Coffey wrote on 2017/06/30 23:57:25: > > > > > > > From: Se?n Coffey > > > > To: Kazunori Ogata , "Langer, Christoph" > > > > > > > > Cc: "ppc-aix-port-dev at openjdk.java.net" > > > dev at openjdk.java.net>, core-libs-dev > , > > > > "nio-dev at openjdk.java.net" > > > > Date: 2017/06/30 23:57 > > > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts > > > > performance of Charset.atBugLevel() > > > > > > > > Ogata, > > > > > > > > minor comments from me. > > > > > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > > > 8182743 ? > > > > * The copyright change in Charset-X-Coder.java.template is the wrong > > > > format. You can simply replace 2013 with 2017. > > > > > > > > Regards, > > > > Sean. > > > > > > > > On 29/06/17 19:49, Kazunori Ogata wrote: > > > > > Hi Christoph, > > > > > > > > > > I updated webrev: > > > http://cr.openjdk.java.net/~horii/8179527/webrev.02/ > > > > > > > > > > This one includes changes in tests. I removed all @run and @build > > > > > directives in the tests because those after removing "@run > > > main/othervm > > > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the > > > default > > > > > ones. I checked the modified tests passed. > > > > > > > > > > I also fixed the copyright lines. > > > > > > > > > > > > > > > Regards, > > > > > Ogata > > > > > > > > > > > > > > > "Langer, Christoph" wrote on > 2017/06/28 > > > > > 21:04:36: > > > > > > > > > >> From: "Langer, Christoph" > > > > >> To: Kazunori Ogata > > > > >> Cc: Alan Bateman , Claes Redestad > > > > >> , core-libs-dev > > > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" > > > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > > > > > > > >> dev at openjdk.java.net> > > > > >> Date: 2017/06/28 21:04 > > > > >> Subject: RE: 8179527: Ineffective use of volatile hurts > performance > > > of > > > > >> Charset.atBugLevel() > > > > >> > > > > >> Hi Ogata, > > > > >> > > > > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > > > >>> How can I do this? Is it sufficient to remove the following > line at > > > > > the > > > > >>> beginning of the file?: "@run main/othervm > -Dsun.nio.cs.bugLevel=1.4 > > > > >>> EmptyCharsetName" > > > > >> Yes, this line should be removed. Currently there are two @run > > > > > directives > > > > >> which cause running the testcase twice. Once in normal mode and > once > > > > > with > > > > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be > removed > > > > > then > > > > >> the second iteration of the test is obsolete. And then one should > > > > > probably > > > > >> remove the whole "compat" handling in the test. > > > > >> > > > > >> Best regards > > > > >> Christoph > > > > >> > > > > > > > > > > > > > > > From OGATAK at jp.ibm.com Thu Jul 13 10:49:58 2017 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Thu, 13 Jul 2017 19:49:58 +0900 Subject: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel() In-Reply-To: <2281d88b48db4f8baaf5c82ffe016539@sap.com> References: <1b23f0e5-8c91-fec7-009a-495057c739d4@oracle.com> <9a235816b1544dd587a1e6d2268e6407@sap.com> <43cce7ea-0037-3013-ead5-05542de5d69a@oracle.com> <254e340e1a084a57bd77c1a99884ce1b@sap.com> Message-ID: Hi Christoph, Thank you for your help! Regards, Ogata "Langer, Christoph" wrote on 2017/07/13 19:32:32: > From: "Langer, Christoph" > To: Kazunori Ogata > Cc: core-libs-dev , "nio- > dev at openjdk.java.net" > Date: 2017/07/13 19:32 > Subject: RE: 8182743: Ineffective use of volatile hurts performance of > Charset.atBugLevel() > > Hi Ogata, > > I'll take care of backporting a fix to remove the "volatile" qualifier for > both, JDK-8182743 and JDK-8184330. > > Best regards > Christoph > > > -----Original Message----- > > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > > Sent: Freitag, 7. Juli 2017 18:59 > > To: core-libs-dev ; nio- > > dev at openjdk.java.net > > Cc: Langer, Christoph > > Subject: RE: 8182743: Ineffective use of volatile hurts performance of > > Charset.atBugLevel() > > > > Hi all, > > > > Any comment on downporting a fix to JDK9u and JDK8u, which simply > > removes > > volatile? > > > > > > Regards, > > Ogata > > > > Kazunori Ogata/Japan/IBM wrote on 2017/07/03 17:28:54: > > > > > From: Kazunori Ogata/Japan/IBM > > > To: "Langer, Christoph" > > > Cc: core-libs-dev , "nio- > > > dev at openjdk.java.net" > > > Date: 2017/07/03 17:28 > > > Subject: RE: 8182743: Ineffective use of volatile hurts performance of > > > Charset.atBugLevel() > > > > > > Hi Christoph, > > > > > > Thank you very much for your help! > > > > > > For JDK9 updates and JDK8 updates, it is desirable if we can back port > > the > > > removal of volatile. What should I do for it? > > > > > > Regards, > > > Ogata > > > > > > From: "Langer, Christoph" > > > To: Kazunori Ogata , "nio-dev at openjdk.java.net" > > > > dev at openjdk.java.net> > > > Cc: core-libs-dev > > > Date: 2017/07/03 17:17 > > > Subject: RE: 8182743: Ineffective use of volatile hurts performance of > > > Charset.atBugLevel() > > > > > > Hi, > > > > > > I've pushed to JDK10 now: > > http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/ > > > 7a2bc0a80087 > > > > > > What do you think, shall we try to downport a fix to JDK9 updates and > > JDK8 > > > updates, which simply removes the volatile as we can't bring this > > behavior > > > changing fix down? > > > > > > Thanks > > > Christoph > > > > > > > -----Original Message----- > > > > From: Kazunori Ogata [mailto:OGATAK at jp.ibm.com] > > > > Sent: Freitag, 30. Juni 2017 20:31 > > > > To: Se?n Coffey > > > > Cc: Langer, Christoph ; core-libs-dev > > > > > dev at openjdk.java.net>; nio-dev at openjdk.java.net; ppc-aix-port- > > > > dev at openjdk.java.net > > > > Subject: Re: 8182743: Ineffective use of volatile hurts performance of > > > > Charset.atBugLevel() > > > > > > > > Hi Sean, > > > > > > > > Thank you for your comments. > > > > > > > > I fixed the copyright and updated webrev: > > > > > > > > http://cr.openjdk.java.net/~horii/8182743/webrev.03/ > > > > > > > > > > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > > > > 8182743 ? > > > > > > > > Yes, they should be 8182743. I fixed both. > > > > > > > > > > > > Regards, > > > > Ogata > > > > > > > > > > > > Se?n Coffey wrote on 2017/06/30 23:57:25: > > > > > > > > > From: Se?n Coffey > > > > > To: Kazunori Ogata , "Langer, Christoph" > > > > > > > > > > Cc: "ppc-aix-port-dev at openjdk.java.net" > > > > dev at openjdk.java.net>, core-libs-dev > > , > > > > > "nio-dev at openjdk.java.net" > > > > > Date: 2017/06/30 23:57 > > > > > Subject: Re: 8179527:(8182743?) Ineffective use of volatile hurts > > > > > performance of Charset.atBugLevel() > > > > > > > > > > Ogata, > > > > > > > > > > minor comments from me. > > > > > > > > > > * The bug ID referenced in mail/webrev links is wrong. It should be > > > > > 8182743 ? > > > > > * The copyright change in Charset-X-Coder.java.template is the wrong > > > > > format. You can simply replace 2013 with 2017. > > > > > > > > > > Regards, > > > > > Sean. > > > > > > > > > > On 29/06/17 19:49, Kazunori Ogata wrote: > > > > > > Hi Christoph, > > > > > > > > > > > > I updated webrev: > > > > http://cr.openjdk.java.net/~horii/8179527/webrev.02/ > > > > > > > > > > > > This one includes changes in tests. I removed all @run and @build > > > > > > directives in the tests because those after removing "@run > > > > main/othervm > > > > > > -Dsun.nio.cs.bugLevel=1.4 EmptyCharsetName" are the same as the > > > > default > > > > > > ones. I checked the modified tests passed. > > > > > > > > > > > > I also fixed the copyright lines. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Ogata > > > > > > > > > > > > > > > > > > "Langer, Christoph" wrote on > > 2017/06/28 > > > > > > 21:04:36: > > > > > > > > > > > >> From: "Langer, Christoph" > > > > > >> To: Kazunori Ogata > > > > > >> Cc: Alan Bateman , Claes Redestad > > > > > >> , core-libs-dev > > > > >> dev at openjdk.java.net>, "nio-dev at openjdk.java.net" > > > > >> dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" > > > > > > > > > > >> dev at openjdk.java.net> > > > > > >> Date: 2017/06/28 21:04 > > > > > >> Subject: RE: 8179527: Ineffective use of volatile hurts > > performance > > > > of > > > > > >> Charset.atBugLevel() > > > > > >> > > > > > >> Hi Ogata, > > > > > >> > > > > > >>>> remove the second run with -Dsun.nio.cs.bugLevel=1.4 > > > > > >>> How can I do this? Is it sufficient to remove the following > > line at > > > > > > the > > > > > >>> beginning of the file?: "@run main/othervm > > -Dsun.nio.cs.bugLevel=1.4 > > > > > >>> EmptyCharsetName" > > > > > >> Yes, this line should be removed. Currently there are two @run > > > > > > directives > > > > > >> which cause running the testcase twice. Once in normal mode and > > once > > > > > > with > > > > > >> bugLevel set to 1.4. So, if "sun.nio.cs.bugLevel" ought to be > > removed > > > > > > then > > > > > >> the second iteration of the test is obsolete. And then one should > > > > > > probably > > > > > >> remove the whole "compat" handling in the test. > > > > > >> > > > > > >> Best regards > > > > > >> Christoph > > > > > >> > > > > > > > > > > > > > > > > > > > > > From jonathan.gibbons at oracle.com Thu Jul 13 15:20:19 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 13 Jul 2017 08:20:19 -0700 Subject: RFR: 8184311: Update java.sql and java.sql.rowset API docs for accessibility In-Reply-To: References: <5966D59F.6040307@oracle.com> Message-ID: <78aa816e-ef2e-4e5d-42ed-91ac89a43e8f@oracle.com> Thanks, Lance -- Jon On 7/13/17 3:20 AM, Lance Andersen wrote: > looks fine Jon > >> On Jul 12, 2017, at 10:06 PM, Jonathan Gibbons >> > wrote: >> >> Please review ... >> >> More noreg-doc API cleanup for accessibility, etc. This time for >> java.sql and java.sql.rowset. >> One of the tables ought to be restructured a bit, because there is no >> single unique column >> to use for a rowheader, but that is a bigger change than I want to do >> in this round of updates. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8184311 >> Webrev: http://cr.openjdk.java.net/~jjg/8184311/webrev.00/ >> >> API: http://cr.openjdk.java.net/~jjg/8184311/api.00/ >> >> >> -- Jon >> >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From hohensee at amazon.com Thu Jul 13 17:07:04 2017 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 13 Jul 2017 17:07:04 +0000 Subject: java.util.Pair Message-ID: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273. At Amazon, many projects depend on JavaFX to get only a single class, namely javafx.util.Pair. That means that we must distribute OpenJFX along with our internal OpenJDK distribution, or split javafx.util.Pair out into a separate package, both of which we?d like to avoid in the future. So, are there any plans to add java.util.Pair to JDK10? Thanks, Paul From martinrb at google.com Thu Jul 13 17:08:55 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 13 Jul 2017 10:08:55 -0700 Subject: [9] JDK-8184306: zlib 1.2.11 upgrade triggers j.u.zip.Deflater regression In-Reply-To: <5966AB5A.80208@oracle.com> References: <5966AB5A.80208@oracle.com> Message-ID: Random drive-by comments. - consider adding a link to the JDK bug to the zlib bug. - configure on linux reports: --with-zlib use zlib from build system or OpenJDK source (system, bundled) [bundled] Does this need updating to "system" ? From joe.darcy at oracle.com Thu Jul 13 17:22:19 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 13 Jul 2017 10:22:19 -0700 Subject: java.util.Pair In-Reply-To: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> Message-ID: <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> Hi Paul, See the discussion in thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html In short, no current plans to add java.util.Pair. -Joe On 7/13/2017 10:07 AM, Hohensee, Paul wrote: > See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273. > > At Amazon, many projects depend on JavaFX to get only a single class, namely javafx.util.Pair. That means that we must distribute OpenJFX along with our internal OpenJDK distribution, or split javafx.util.Pair out into a separate package, both of which we?d like to avoid in the future. So, are there any plans to add java.util.Pair to JDK10? > > Thanks, > > Paul > From maurizio.cimadamore at oracle.com Thu Jul 13 17:29:38 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 13 Jul 2017 18:29:38 +0100 Subject: java.util.Pair In-Reply-To: <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> Message-ID: <9ea0cd11-210c-9159-3f37-925d42bf0abf@oracle.com> Maybe automatic refactoring to Map.Entry ? With the new static method added in 9, creating one is also very fluent (but I know that Entry doesn't convey same meaning as Pair in method signatures/fields) http://download.java.net/java/jdk9/docs/api/java/util/Map.html#entry-K-V- Cheers Maurizio On 13/07/17 18:22, joe darcy wrote: > Hi Paul, > > See the discussion in thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html > > > In short, no current plans to add java.util.Pair. > > -Joe > > > On 7/13/2017 10:07 AM, Hohensee, Paul wrote: >> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273. >> >> At Amazon, many projects depend on JavaFX to get only a single class, >> namely javafx.util.Pair. That means that we must distribute OpenJFX >> along with our internal OpenJDK distribution, or split >> javafx.util.Pair out into a separate package, both of which we?d like >> to avoid in the future. So, are there any plans to add java.util.Pair >> to JDK10? >> >> Thanks, >> >> Paul >> > From hohensee at amazon.com Thu Jul 13 18:24:47 2017 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 13 Jul 2017 18:24:47 +0000 Subject: java.util.Pair In-Reply-To: <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> Message-ID: <7BD3B593-62E8-4BF2-9CF0-36E678905F82@amazon.com> Thanks for the immediate response. Having read the thread, I understand the argument against including Pair in the JDK and personally agree with the sw engineering argument. But, it got into javafx.util somehow and is now effectively part of the JDK anyway, so that ship has sailed. Thus, it seemed reasonable me to just copy it from there into java.util, though there would be a maintenance headache if it were desired to keep them sync?ed. I suppose also that there?s a pov that having it in javafx.util indirectly encourages JavaFX adoption. ( Anyhow, thanks for the explanation. Paul On 7/13/17, 10:22 AM, "joe darcy" wrote: Hi Paul, See the discussion in thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html In short, no current plans to add java.util.Pair. -Joe On 7/13/2017 10:07 AM, Hohensee, Paul wrote: > See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273. > > At Amazon, many projects depend on JavaFX to get only a single class, namely javafx.util.Pair. That means that we must distribute OpenJFX along with our internal OpenJDK distribution, or split javafx.util.Pair out into a separate package, both of which we?d like to avoid in the future. So, are there any plans to add java.util.Pair to JDK10? > > Thanks, > > Paul > From hohensee at amazon.com Thu Jul 13 18:25:51 2017 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 13 Jul 2017 18:25:51 +0000 Subject: java.util.Pair In-Reply-To: <9ea0cd11-210c-9159-3f37-925d42bf0abf@oracle.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> <9ea0cd11-210c-9159-3f37-925d42bf0abf@oracle.com> Message-ID: That?s a possibility. We could recommend that as an alternative. Thanks, Paul On 7/13/17, 10:29 AM, "Maurizio Cimadamore" wrote: Maybe automatic refactoring to Map.Entry ? With the new static method added in 9, creating one is also very fluent (but I know that Entry doesn't convey same meaning as Pair in method signatures/fields) http://download.java.net/java/jdk9/docs/api/java/util/Map.html#entry-K-V- Cheers Maurizio On 13/07/17 18:22, joe darcy wrote: > Hi Paul, > > See the discussion in thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html > > > In short, no current plans to add java.util.Pair. > > -Joe > > > On 7/13/2017 10:07 AM, Hohensee, Paul wrote: >> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273. >> >> At Amazon, many projects depend on JavaFX to get only a single class, >> namely javafx.util.Pair. That means that we must distribute OpenJFX >> along with our internal OpenJDK distribution, or split >> javafx.util.Pair out into a separate package, both of which we?d like >> to avoid in the future. So, are there any plans to add java.util.Pair >> to JDK10? >> >> Thanks, >> >> Paul >> > From garydgregory at gmail.com Thu Jul 13 18:31:06 2017 From: garydgregory at gmail.com (Gary Gregory) Date: Thu, 13 Jul 2017 11:31:06 -0700 Subject: java.util.Pair In-Reply-To: <7BD3B593-62E8-4BF2-9CF0-36E678905F82@amazon.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> <7BD3B593-62E8-4BF2-9CF0-36E678905F82@amazon.com> Message-ID: Hi All, FYI: We added a couple of classes in Apache Commons Lang to deal with pairs and triples. This is definitely for the pragmatic programmer... https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/Pair.html https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/ImmutablePair.html https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/MutablePair.html https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/Triple.html https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/ImmutableTriple.html https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/MutableTriple.html Gary On Thu, Jul 13, 2017 at 11:24 AM, Hohensee, Paul wrote: > Thanks for the immediate response. > > Having read the thread, I understand the argument against including Pair > in the JDK and personally agree with the sw engineering argument. But, it > got into javafx.util somehow and is now effectively part of the JDK anyway, > so that ship has sailed. Thus, it seemed reasonable me to just copy it from > there into java.util, though there would be a maintenance headache if it > were desired to keep them sync?ed. > > I suppose also that there?s a pov that having it in javafx.util indirectly > encourages JavaFX adoption. ( > > Anyhow, thanks for the explanation. > > Paul > > On 7/13/17, 10:22 AM, "joe darcy" wrote: > > Hi Paul, > > See the discussion in thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010- > March/003973.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010- > April/thread.html > > In short, no current plans to add java.util.Pair. > > -Joe > > > On 7/13/2017 10:07 AM, Hohensee, Paul wrote: > > See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273. > > > > At Amazon, many projects depend on JavaFX to get only a single > class, namely javafx.util.Pair. That means that we must distribute OpenJFX > along with our internal OpenJDK distribution, or split javafx.util.Pair out > into a separate package, both of which we?d like to avoid in the future. > So, are there any plans to add java.util.Pair to JDK10? > > > > Thanks, > > > > Paul > > > > > > From vitalyd at gmail.com Thu Jul 13 19:35:38 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 13 Jul 2017 19:35:38 +0000 Subject: java.util.Pair In-Reply-To: <9ea0cd11-210c-9159-3f37-925d42bf0abf@oracle.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> <9ea0cd11-210c-9159-3f37-925d42bf0abf@oracle.com> Message-ID: Similarly, I've used https://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.SimpleEntry.html and https://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.SimpleImmutableEntry.html in these circumstances. On Thu, Jul 13, 2017 at 1:29 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Maybe automatic refactoring to Map.Entry ? With the new static method > added in 9, creating one is also very fluent (but I know that Entry > doesn't convey same meaning as Pair in method signatures/fields) > > http://download.java.net/java/jdk9/docs/api/java/util/Map.html#entry-K-V- > > Cheers > Maurizio > > > On 13/07/17 18:22, joe darcy wrote: > > Hi Paul, > > > > See the discussion in thread: > > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html > > > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html > > > > > > In short, no current plans to add java.util.Pair. > > > > -Joe > > > > > > On 7/13/2017 10:07 AM, Hohensee, Paul wrote: > >> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273. > >> > >> At Amazon, many projects depend on JavaFX to get only a single class, > >> namely javafx.util.Pair. That means that we must distribute OpenJFX > >> along with our internal OpenJDK distribution, or split > >> javafx.util.Pair out into a separate package, both of which we?d like > >> to avoid in the future. So, are there any plans to add java.util.Pair > >> to JDK10? > >> > >> Thanks, > >> > >> Paul > >> > > > > -- Sent from my phone From john.r.rose at oracle.com Thu Jul 13 20:25:31 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Jul 2017 13:25:31 -0700 Subject: java.util.Pair In-Reply-To: <9ea0cd11-210c-9159-3f37-925d42bf0abf@oracle.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> <9ea0cd11-210c-9159-3f37-925d42bf0abf@oracle.com> Message-ID: On Jul 13, 2017, at 10:29 AM, Maurizio Cimadamore wrote: > > Maybe automatic refactoring to Map.Entry ? With the new static method added in 9, creating one is also very fluent (but I > know that Entry doesn't convey same meaning as Pair in method signatures/fields) The JavaFX Pair Paul is asking for has key and value components, just like an Entry. Sounds like "Map.entry" should be in the running as a good-enough replacement for "new Pair". One problem with "just give me (x,y)" is that there are too many ways to express a pair of values in an O-O language, and even more after adding primitives and mutability. (Pure functional languages with complete polymorphism have an easier time.) The bug report JDK-4947273 very frankly offers five alternative versions, thereby undermining the reporter's case for "a standard Pair class" (where a=1). It *may* be that the Amber project, after introduces some sort of simplified class for simple data structures, could help us gravitate toward a (yes, a=1) standard Pair class, that would be one of those simplified things. Maybe. It is much more likely that the Valhalla project, when that grows mature, will give us enough polymorphism and functional data structures to put us in the same place as languages like Haskell, where it will be economical to define a single Pair type. (I'm hoping for an arity-polymorphic Tuple type, but that would be a stretch goal.) ? John From forax at univ-mlv.fr Thu Jul 13 20:39:48 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 13 Jul 2017 22:39:48 +0200 (CEST) Subject: java.util.Pair In-Reply-To: <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> Message-ID: <231186441.1177524.1499978388049.JavaMail.zimbra@u-pem.fr> Tuples are like an array of value types parameterized by a constant integer so it will be interesting to revisit this issue when we will have a clear idea about what value types are and how to parameterized a class. cheers, R?mi ----- Mail original ----- > De: "joe darcy" > ?: "Hohensee, Paul" , core-libs-dev at openjdk.java.net > Envoy?: Jeudi 13 Juillet 2017 19:22:19 > Objet: Re: java.util.Pair > Hi Paul, > > See the discussion in thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html > > In short, no current plans to add java.util.Pair. > > -Joe > > > On 7/13/2017 10:07 AM, Hohensee, Paul wrote: >> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273. >> >> At Amazon, many projects depend on JavaFX to get only a single class, namely >> javafx.util.Pair. That means that we must distribute OpenJFX along with our >> internal OpenJDK distribution, or split javafx.util.Pair out into a separate >> package, both of which we?d like to avoid in the future. So, are there any >> plans to add java.util.Pair to JDK10? >> >> Thanks, >> >> Paul From john.r.rose at oracle.com Thu Jul 13 21:05:14 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Jul 2017 14:05:14 -0700 Subject: java.util.Pair In-Reply-To: <231186441.1177524.1499978388049.JavaMail.zimbra@u-pem.fr> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> <231186441.1177524.1499978388049.JavaMail.zimbra@u-pem.fr> Message-ID: <53EB809A-39E7-4E2A-B22E-7626EDFD9B72@oracle.com> On Jul 13, 2017, at 1:39 PM, Remi Forax wrote: > > Tuples are like an array of value types parameterized by a constant integer The homogeneous case is pretty simple; most of what you need is to allow a generic type to be parameterized by an integer. C++ templates have had that for a long time. What's harder is to have a two-step process for type instantiation: First, tell me the arity N, and second, for each position under that arity, tell me the type T[i], i References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> <231186441.1177524.1499978388049.JavaMail.zimbra@u-pem.fr> <53EB809A-39E7-4E2A-B22E-7626EDFD9B72@oracle.com> Message-ID: <1122534738.1193949.1499982076283.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "R?mi Forax" > Cc: "joe darcy" , "core-libs-dev" > > Envoy?: Jeudi 13 Juillet 2017 23:05:14 > Objet: Re: java.util.Pair > On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> Tuples are like an array of value types parameterized by a constant integer > The homogeneous case is pretty simple; most of what you need is > to allow a generic type to be parameterized by an integer. C++ templates > have had that for a long time. > What's harder is to have a two-step process for type instantiation: > First, tell me the arity N, and second, for each position under that arity, > tell me the type T[i], i the most Java-like way to handle it might be type-functions that overload > alongside generic types. But there are many, many ways to slice it. or use a recursive definition like in Ceylon https://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/module-doc/Tuple.type.html and the fact that value types are flatten to specify the rest, i.e a Tuple contains a T first and a Tuple rest. > C++ templates can express heterogeneous tuples: > [ http://en.cppreference.com/w/cpp/utility/tuple | > http://en.cppreference.com/w/cpp/utility/tuple ] > Typically there is a small limit to C++ tuple size, because the underlying > template implementation has its size set to the arity limit. > ? John R?mi From dbrosius at mebigfatguy.com Thu Jul 13 23:24:48 2017 From: dbrosius at mebigfatguy.com (Dave Brosius) Date: Thu, 13 Jul 2017 19:24:48 -0400 Subject: java.util.Pair In-Reply-To: <1122534738.1193949.1499982076283.JavaMail.zimbra@u-pem.fr> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> <231186441.1177524.1499978388049.JavaMail.zimbra@u-pem.fr> <53EB809A-39E7-4E2A-B22E-7626EDFD9B72@oracle.com> <1122534738.1193949.1499982076283.JavaMail.zimbra@u-pem.fr> Message-ID: <8f3e2a95-d50e-482e-ceed-d6d0acc3249e@mebigfatguy.com> I would avoid Pair and Entry like the plague. They are devoid of meaning and are just there to save your fingers. If that is your main impetus, i'd just turn to using lombok and have true bean classes, that are finger-cost free. On 07/13/2017 05:41 PM, forax at univ-mlv.fr wrote: >> De: "John Rose" >> ?: "R?mi Forax" >> Cc: "joe darcy" , "core-libs-dev" >> >> Envoy?: Jeudi 13 Juillet 2017 23:05:14 >> Objet: Re: java.util.Pair >> On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | >> forax at univ-mlv.fr ] > wrote: >>> Tuples are like an array of value types parameterized by a constant integer >> The homogeneous case is pretty simple; most of what you need is >> to allow a generic type to be parameterized by an integer. C++ templates >> have had that for a long time. >> What's harder is to have a two-step process for type instantiation: >> First, tell me the arity N, and second, for each position under that arity, >> tell me the type T[i], i> the most Java-like way to handle it might be type-functions that overload >> alongside generic types. But there are many, many ways to slice it. > or use a recursive definition like in Ceylon > https://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/module-doc/Tuple.type.html > and the fact that value types are flatten to specify the rest, i.e a Tuple contains a T first and a Tuple rest. > >> C++ templates can express heterogeneous tuples: >> [ http://en.cppreference.com/w/cpp/utility/tuple | >> http://en.cppreference.com/w/cpp/utility/tuple ] >> Typically there is a small limit to C++ tuple size, because the underlying >> template implementation has its size set to the arity limit. >> ? John > R?mi > From brian.burkhalter at oracle.com Thu Jul 13 23:29:47 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 13 Jul 2017 16:29:47 -0700 Subject: [9] JDK-8184306: zlib 1.2.11 upgrade triggers j.u.zip.Deflater regression In-Reply-To: <519bfa33-bc5f-f2d2-fd57-0d3b885ed170@oracle.com> References: <5966AB5A.80208@oracle.com> <519bfa33-bc5f-f2d2-fd57-0d3b885ed170@oracle.com> Message-ID: On Jul 12, 2017, at 11:52 PM, Alan Bateman wrote: > On 13/07/2017 00:06, Xueming Shen wrote: >> : >> >> My reading of the 1.2.11 changes suggests the root cause is that the internal >> state "deflate_state.high_water" is not being reset correctly/appropriately (to 0?) >> in deflateReset/deflateResetKeep/lm_init(). >> >> AND the change of one of the conditions in deflate.c/deflateParams(), from >> "strm->total_in!=0" to "s->high_water" (in the "Flush last buffer" branch) as showed >> below, obvious triggers the regression from 1.2.8 to 1.2.11, in the scenario that >> the "strategy/levle is changed" AND a followup "reset()" is called (with the >> assumption that everything should be reset back to initial state and we start a >> new compression circle, with the new level and strategy. This is how it works >> in 1.2.8 and early releases). > This is good sleuthing and I think you have identified the regression. The fix looks right although it would be good to get confirmation from the zlib maintainers (no comments on zlib/issues/275 so far). > > As this is a P1 showstopper issue then additional eyes are welcome, esp. if we patch zlib rather than go back to an older version. I concur with Alan: good detective work figuring this one out. It looks good to me. As a sanity check, on Windows I ran the new version of the DeInflate test without and with the deflate.c change applied and it failed and passed, respectively, as expected. Brian From kedar.mhaswade at gmail.com Fri Jul 14 04:50:07 2017 From: kedar.mhaswade at gmail.com (kedar mhaswade) Date: Thu, 13 Jul 2017 21:50:07 -0700 Subject: java.util.Pair In-Reply-To: <8f3e2a95-d50e-482e-ceed-d6d0acc3249e@mebigfatguy.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> <231186441.1177524.1499978388049.JavaMail.zimbra@u-pem.fr> <53EB809A-39E7-4E2A-B22E-7626EDFD9B72@oracle.com> <1122534738.1193949.1499982076283.JavaMail.zimbra@u-pem.fr> <8f3e2a95-d50e-482e-ceed-d6d0acc3249e@mebigfatguy.com> Message-ID: On Thu, Jul 13, 2017 at 4:24 PM, Dave Brosius wrote: > I would avoid Pair and Entry like the plague. They are devoid of meaning > and are just there to save your fingers. The only difference is that the latter is already available in java.util. And perhaps it is (should be?) more attractive to a typical Java developer to use Entry than depend upon JavaFX (is that available in headless environment?) If that is your main impetus, i'd just turn to using lombok and have true > bean classes, that are finger-cost free. > > > > On 07/13/2017 05:41 PM, forax at univ-mlv.fr wrote: > >> De: "John Rose" >>> ?: "R?mi Forax" >>> Cc: "joe darcy" , "core-libs-dev" >>> >>> Envoy?: Jeudi 13 Juillet 2017 23:05:14 >>> Objet: Re: java.util.Pair >>> On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | >>> forax at univ-mlv.fr ] > wrote: >>> >>>> Tuples are like an array of value types parameterized by a constant >>>> integer >>>> >>> The homogeneous case is pretty simple; most of what you need is >>> to allow a generic type to be parameterized by an integer. C++ templates >>> have had that for a long time. >>> What's harder is to have a two-step process for type instantiation: >>> First, tell me the arity N, and second, for each position under that >>> arity, >>> tell me the type T[i], i>> the most Java-like way to handle it might be type-functions that overload >>> alongside generic types. But there are many, many ways to slice it. >>> >> or use a recursive definition like in Ceylon >> https://modules.ceylon-lang.org/repo/1/ceylon/language/1.0. >> 0/module-doc/Tuple.type.html >> and the fact that value types are flatten to specify the rest, i.e a >> Tuple contains a T first and a Tuple rest. >> >> C++ templates can express heterogeneous tuples: >>> [ http://en.cppreference.com/w/cpp/utility/tuple | >>> http://en.cppreference.com/w/cpp/utility/tuple ] >>> Typically there is a small limit to C++ tuple size, because the >>> underlying >>> template implementation has its size set to the arity limit. >>> ? John >>> >> R?mi >> >> > From mandy.chung at oracle.com Fri Jul 14 08:23:08 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 14 Jul 2017 16:23:08 +0800 Subject: JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java In-Reply-To: References: Message-ID: <846D7A40-148A-4BCB-99FE-0744DE198A6D@oracle.com> > On Jul 13, 2017, at 5:14 PM, Amy Lu wrote: > > java/lang/ClassLoader/deadlock/TestCrossDelegate.sh > java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh > > Please review this patch to refactor the shell tests to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8183377 > http://cr.openjdk.java.net/~amlu/8183377/webrev.00/ I suggest to use the scratch directory instead of user.dir so that the files will be cleaned up. An alternative to SetupLoader class would be use the testlibray CompileUtils to compile the classes in the specified destination. Mandy From weijun.wang at oracle.com Fri Jul 14 08:26:55 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Jul 2017 16:26:55 +0800 Subject: JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java In-Reply-To: <846D7A40-148A-4BCB-99FE-0744DE198A6D@oracle.com> References: <846D7A40-148A-4BCB-99FE-0744DE198A6D@oracle.com> Message-ID: > On Jul 14, 2017, at 4:23 PM, Mandy Chung wrote: > > >> On Jul 13, 2017, at 5:14 PM, Amy Lu wrote: >> >> java/lang/ClassLoader/deadlock/TestCrossDelegate.sh >> java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh >> >> Please review this patch to refactor the shell tests to java. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8183377 >> http://cr.openjdk.java.net/~amlu/8183377/webrev.00/ > > I suggest to use the scratch directory instead of user.dir so that the files will be cleaned up. I haven?t reviewed the code but aren?t scratch and ${user.dir} the same thing? --Max > > An alternative to SetupLoader class would be use the testlibray CompileUtils to compile the classes in the specified destination. > > Mandy From mandy.chung at oracle.com Fri Jul 14 08:41:01 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 14 Jul 2017 16:41:01 +0800 Subject: JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java In-Reply-To: References: <846D7A40-148A-4BCB-99FE-0744DE198A6D@oracle.com> Message-ID: > On Jul 14, 2017, at 4:26 PM, Weijun Wang wrote: > > >> On Jul 14, 2017, at 4:23 PM, Mandy Chung wrote: >> >> >>> On Jul 13, 2017, at 5:14 PM, Amy Lu wrote: >>> >>> java/lang/ClassLoader/deadlock/TestCrossDelegate.sh >>> java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh >>> >>> Please review this patch to refactor the shell tests to java. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8183377 >>> http://cr.openjdk.java.net/~amlu/8183377/webrev.00/ >> >> I suggest to use the scratch directory instead of user.dir so that the files will be cleaned up. > > I haven?t reviewed the code but aren?t scratch and ${user.dir} the same thing? Good catch. I mis-read it as ?user.home?. Then that part is okay. I think compiling the other classes to a destination explicitly to replace: 29 * @build Alice Bob SupAlice SupBob 30 * @run driver SetupLoader will make the test clearer. It?d be good to make that change. Mandy From claes.redestad at oracle.com Fri Jul 14 12:19:26 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 14:19:26 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible Message-ID: Hi, as a small startup optimization, we could make some setup in ObjectStreamField lazier by calculating the signature field at first use. Bug: https://bugs.openjdk.java.net/browse/JDK-8184603 Webrev: http://cr.openjdk.java.net/~redestad/8184603/jdk.00/ Thanks! /Claes From chris.hegarty at oracle.com Fri Jul 14 12:32:03 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 14 Jul 2017 13:32:03 +0100 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: Message-ID: > On 14 Jul 2017, at 13:19, Claes Redestad wrote: > > Hi, > > as a small startup optimization, we could make some setup in ObjectStreamField > lazier by calculating the signature field at first use. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184603 > Webrev: http://cr.openjdk.java.net/~redestad/8184603/jdk.00/ I think this is ok. Should toString also use getSignature? For extra points remove the superfluous null assignment of `signature` and `field` ( as well as `offset` ). -Chris. From claes.redestad at oracle.com Fri Jul 14 12:47:03 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 14:47:03 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: Message-ID: On 2017-07-14 14:32, Chris Hegarty wrote: >> On 14 Jul 2017, at 13:19, Claes Redestad wrote: >> >> Hi, >> >> as a small startup optimization, we could make some setup in ObjectStreamField >> lazier by calculating the signature field at first use. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8184603 >> Webrev: http://cr.openjdk.java.net/~redestad/8184603/jdk.00/ > I think this is ok. Should toString also use getSignature? Yes, I thought I'd done that already. > > For extra points remove the superfluous null assignment of > `signature` and `field` ( as well as `offset` ). 'field' is final so that'd make javac cry bloody murder, but I fixed the rest and cleaned up a bit for consistency: http://cr.openjdk.java.net/~redestad/8184603/jdk.01/ Thanks! &Claes From claes.redestad at oracle.com Fri Jul 14 12:52:55 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 14:52:55 +0200 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets Message-ID: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> Hi, by special-casing the three Charsets we always load on startup in the Charset constructor we can avoid some superfluous checks and get a tiny startup improvement (~7k less bytecode executed, which is fast approaching 1% of total on minimal startup tests). Webrev: http://cr.openjdk.java.net/~redestad/8184665/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8184665 Thanks! /Claes From Alan.Bateman at oracle.com Fri Jul 14 13:04:15 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Jul 2017 14:04:15 +0100 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: Message-ID: <4bb23008-c81a-628a-d25e-de1ba4422eda@oracle.com> On 14/07/2017 13:47, Claes Redestad wrote: > : > >> >> For extra points remove the superfluous null assignment of >> `signature` and `field` ( as well as `offset` ). > > 'field' is final so that'd make javac cry bloody murder, but I fixed the > rest and cleaned up a bit for consistency: > > http://cr.openjdk.java.net/~redestad/8184603/jdk.01/ The updated version looks okay. I would probably do "signature = sig = getClassSignature(...)" but it shouldn't make a difference. -Alan From shade at redhat.com Fri Jul 14 13:25:54 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jul 2017 15:25:54 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: Message-ID: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> On 07/14/2017 02:47 PM, Claes Redestad wrote: >> For extra points remove the superfluous null assignment of >> `signature` and `field` ( as well as `offset` ). > > 'field' is final so that'd make javac cry bloody murder, but I fixed the > rest and cleaned up a bit for consistency: > > http://cr.openjdk.java.net/~redestad/8184603/jdk.01/ Can you also not do $signature field "volatile", for the sake on non-x86 platforms? I think getSignature() has a benign race then, which is safe. Thanks, -Aleksey From shade at redhat.com Fri Jul 14 13:33:56 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jul 2017 15:33:56 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> Message-ID: <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> On 07/14/2017 03:25 PM, Aleksey Shipilev wrote: > On 07/14/2017 02:47 PM, Claes Redestad wrote: >>> For extra points remove the superfluous null assignment of >>> `signature` and `field` ( as well as `offset` ). >> >> 'field' is final so that'd make javac cry bloody murder, but I fixed the >> rest and cleaned up a bit for consistency: >> >> http://cr.openjdk.java.net/~redestad/8184603/jdk.01/ > > Can you also not do $signature field "volatile", for the sake on non-x86 > platforms? I think getSignature() has a benign race then, which is safe. Hm, there is ObjectStreamField(String name, String signature, boolean unshared) constructor that passes naked signature. There are two issues here: a) getSignature() would now ignore the signature passed via that constructor, because it will redo the signature from $type field, which is initialized to Object.class for references; b) neither volatile nor blank qualifier would help to survive the racy read of OSF.signature field if OSF was initialized with that private constructor. I guess careful inspection of that constructor uses would tame these problems. -Aleksey From claes.redestad at oracle.com Fri Jul 14 13:40:05 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 15:40:05 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> Message-ID: <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> Hi Aleksey, On 2017-07-14 15:33, Aleksey Shipilev wrote: > On 07/14/2017 03:25 PM, Aleksey Shipilev wrote: >> On 07/14/2017 02:47 PM, Claes Redestad wrote: >>>> For extra points remove the superfluous null assignment of >>>> `signature` and `field` ( as well as `offset` ). >>> 'field' is final so that'd make javac cry bloody murder, but I fixed the >>> rest and cleaned up a bit for consistency: >>> >>> http://cr.openjdk.java.net/~redestad/8184603/jdk.01/ >> Can you also not do $signature field "volatile", for the sake on non-x86 >> platforms? I think getSignature() has a benign race then, which is safe. > Hm, there is ObjectStreamField(String name, String signature, boolean unshared) > constructor that passes naked signature. > > There are two issues here: > a) getSignature() would now ignore the signature passed via that constructor, > because it will redo the signature from $type field, which is initialized to > Object.class for references; > b) neither volatile nor blank qualifier would help to survive the racy read of > OSF.signature field if OSF was initialized with that private constructor. > > I guess careful inspection of that constructor uses would tame these problems. > > -Aleksey signature is already made volatile in this patch, deliberately to ensure that for the private constructors we keep correctness: in these private constructors, the signature field is initialized in the constructor (we can assert that it's non-null) to a value that would not match getClassSignature(type), but since the field is volatile it will never be observed as null by a call to getSignature() on an object created with these constructors (unless I'm mistaken, and we *do* need an added synchonization point here). /Claes From claes.redestad at oracle.com Fri Jul 14 13:44:01 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 15:44:01 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: <4bb23008-c81a-628a-d25e-de1ba4422eda@oracle.com> References: <4bb23008-c81a-628a-d25e-de1ba4422eda@oracle.com> Message-ID: <9ecc77ed-8484-b063-e5fc-0d289e9b17cd@oracle.com> On 2017-07-14 15:04, Alan Bateman wrote: > > > On 14/07/2017 13:47, Claes Redestad wrote: >> http://cr.openjdk.java.net/~redestad/8184603/jdk.01/ > The updated version looks okay. I would probably do "signature = sig = > getClassSignature(...)" but it shouldn't make a difference. Thanks Alan, I believe I got things mixed up and that the ordering you proposed is the idiomatic pattern for this, so I updated it in-place. /Claes From shade at redhat.com Fri Jul 14 13:46:43 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jul 2017 15:46:43 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> Message-ID: On 07/14/2017 03:40 PM, Claes Redestad wrote: > signature is already made volatile in this patch, deliberately to ensure that > for the private constructors we keep correctness: > > in these private constructors, the signature field is initialized in the > constructor (we can assert that it's non-null) to a value that would not > match getClassSignature(type), but since the field is volatile it will never > be observed as null by a call to getSignature() on an object created with > these constructors (unless I'm mistaken, and we *do* need an added > synchonization point here). Thing is, "volatile" is not as strong as "final" for racy initializations: https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals If that is not a concern -- e.g. if private constructor is never used to make shared OSFs -- then "volatile" is superfluous. If it is a concern, then "volatile" is not enough, and you have to keep "final". The hair-pull scenario under the race would be like this: OSF gets constructed with Ljava/lol/ConcurrencyIsHard, published, another thread calls getSignature() on it, eads null from $signature, regenerates it from Object $type, returns Ljava/lang/Object as signature. Something fails not expecting j/l/Object in signature, you go debug it, and see getSignature() returns Ljava/lol/ConcurrencyIsHard, as if nothing had happened. Thanks, -Aleksey From claes.redestad at oracle.com Fri Jul 14 14:12:08 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 16:12:08 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> Message-ID: On 2017-07-14 15:46, Aleksey Shipilev wrote: > On 07/14/2017 03:40 PM, Claes Redestad wrote: >> signature is already made volatile in this patch, deliberately to ensure that >> for the private constructors we keep correctness: >> >> in these private constructors, the signature field is initialized in the >> constructor (we can assert that it's non-null) to a value that would not >> match getClassSignature(type), but since the field is volatile it will never >> be observed as null by a call to getSignature() on an object created with >> these constructors (unless I'm mistaken, and we *do* need an added >> synchonization point here). > Thing is, "volatile" is not as strong as "final" for racy initializations: > > https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals > > If that is not a concern -- e.g. if private constructor is never used to make > shared OSFs -- then "volatile" is superfluous. If it is a concern, then > "volatile" is not enough, and you have to keep "final". Gosh! Seeing how it's possible to lookup ObjectStreamClass and get at ObjectStreamField's that might have been created from the internal constructors, I think it *is* a concern. Thus the only viable option that allows us to be correct *and* lazy might be to add a new field that is lazily initialized only when using the public constructors: http://cr.openjdk.java.net/~redestad/8184603/jdk.02/ WDYT? Adding a field is of course a possible footprint increase, but ObjectStreamField is a rare object in most applications so footprint risk is minimal to begin with, and since the signature String will now be created lazily this is likely still a net footprint win for many (most?) applications. Thanks! /Claes > > The hair-pull scenario under the race would be like this: OSF gets constructed > with Ljava/lol/ConcurrencyIsHard, published, another thread calls getSignature() > on it, eads null from $signature, regenerates it from Object $type, returns > Ljava/lang/Object as signature. Something fails not expecting j/l/Object in > signature, you go debug it, and see getSignature() returns > Ljava/lol/ConcurrencyIsHard, as if nothing had happened. > > Thanks, > -Aleksey > From bob.vandette at oracle.com Fri Jul 14 14:22:26 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 14 Jul 2017 10:22:26 -0400 Subject: JEP [DRAFT]: Container aware Java Message-ID: I?d like to propose the following JEP that will enhance the Java runtime to be more container aware. This will allow the Java runtime to performance better ergonomics and provide better execution time statistics when running in a container. JEP Issue: https://bugs.openjdk.java.net/browse/JDK-8182070 Here?s a Text dump of the JEP contents for your convenience: Summary ------- Container aware Java runtime Goals ----- Enhance the JVM and Core libraries to detect running in a container and adapt to the system resources available to it. This JEP will only support Docker on Linux-x64 although the design should be flexible enough to allow support for other platforms and container technologies. The initial focus will be on Linux low level container technology such as cgroups so that we will be able to easily support other container technologies running on Linux in addition to Docker. Non-Goals --------- It is not a goal of this JEP to support any platform other than Docker container technology running on Linux x64. Success Metrics --------------- Success will be measured by the improved efficiency of running multiple Java containers on a host system with out of the box options. Motivation ---------- Container technology is becoming more and more prevalent in Cloud based applications. This technology provides process isolation and allows the platform vendor to specify limits and alter the behavior of a process running inside a container that the Java runtime is not aware of. This causes the Java runtime to potentially attempt to use more system resources than are available to it causing performance degradation or even termination. Description ----------- This enhancement will be made up of the following work items: A. Detecting if Java is running in a container. The Java runtime, as well as any tests that we might write for this feature, will need to be able to detect that the current Java process is running in a container. I propose that we add a new JVM_ native function that returns a boolean true value if we are running inside a container. JVM_InContainer will return true if the currently running process is running in a container, otherwise false will be returned. B. Exposing container resource limits and configuration. There are several configuration options and limits that can be imposed upon a running container. Not all of these are important to a running Java process. We clearly want to be able to detect how many CPUs have been allocated to our process along with the maximum amount of memory that we be allocated but there are other options that we might want to base runtime decisions on. In addition, since Container typically impose limits on system resources, they also provide the ability to easily access the amount of consumption of these resources. I intent on providing this information in addition to the configuration data. I propose adding a new jdk.internal.Platform class that will allow access to this information. Since some of this information is needed during the startup of the VM, I propose that much of the implementation of the methods in the Platform class be done in the VM and exposed as JVM_xxxxxx functions. In hotspot, the JVM_xxxxxx function will be implemented via the os.hpp interface. Here are the categories of configuration and consumption statistics that will be made available (The exact API is TBD): isContainerized Memory Limit Total Memory Limit Soft Memory Limit Max Memory Usage Current Memory Usage Maximum Kernel Memory CPU Shares CPU Period CPU Quote Number of CPUs CPU Sets CPU Set Memory Nodes CPU Usage CPU Usage Per CPU Block I/O Weight Block I/O Device Weight Device I/O Read Rate Device I/O Write Rate OOM Kill Enabled OOM Score Adjustment Memory Swappiness Shared Memory Size TODO: 1. Need to specify the exact arguments and return format for these accessor functions. C. Adjusting Java runtime configuration based on limits. Java startup normally queries the operating system in order to setup runtime defaults for things such as the number of GC threads and default memory limits. When running in a container, the operating system functions used provide information about the host and does not include the containers configuration and limits. The VM and core libraries will be modified as part of this JEP to first determine if the current running process is running in a container. It will then cause the runtime to use the container values rather than the general operating system functions for configuring and managing the Java process. There have been a few attempts to correct some of these issue in the VM but they are not complete. The CPU detection in the VM currently only handles a container that limits cpu usage via CPU sets. If the Docker --cpu or --cpu-period along with --cpu-quota options are specified, it currently has no effect on the VMs configuration. The experimental memory detection that has been implemented only impacts the Heap selection and does not apply to the os::physical_memory or os::available_memory low level functions. This leaves other parts of the VM and core libraries to believe there is more memory available than there actually is. The Numa support available in the VM is also not correct when running in a container. The number of available memory nodes and enabled nodes as reported by the libnuma library does not take into account the impact of the Docker --cpuset-mems option which restricts which memory nodes the container can use. Inside the container, the file /proc/{pid}/self does report the correct Cpus_allowed and Mems_Allowed but libnuma doesn't respect this. This has been verified via the numactl utility. To correct these shortcomings and make this support more robust, here's a list of the current cgroup subsystems that we be examined in order to update the internal VM and core library configuration. **Number of CPUs** Use a combination of number_of_cpus() and cpu_sets() in order to determine how many processors are available to the process and adjust the JVMs os::active_processor_count appropriately. The number_of_cpus() will be calculated based on the cpu_quota() and cpu_period() using this formula: number_of_cpus() = cpu_quota() / cpu_period(). Since it's not currently possible to understand the relative weight of the running container against all other containers, altering the cpu_shares of a running container will have no affect on altering Java's configuration. **Total available memory** Use the memory_limit() value from the cgroup file system to initialize the os::physical_memory() value in the VM. This value will propagate to all other parts of the Java runtime. We might also consider examining the soft_memory_limit and total_memory_limit in addition to the memory_limit during the ergonomics startup processing in order to fine tuning some of the other VM settings. **CPU Memory Nodes** Use cpu_set_memory_nodes() to configure the os::numa support. **Memory usage** Use memory_usage_in_bytes() for providing os::available_memory() by subtracting the usage from the total available memory allocated to the container. D. Adding container configuration to error crash logs. As as troubleshooting aid, we will dump any available container statistics to the hotspot error log. E. Adding a startup flag to enable/disable this support. Add a -XX:+UseContainerSupport VM option that will be used to enable this support. The default will be off until this feature is proven. Alternatives ------------ There are a few existing RFE's filed that could be used to enhance the current experimental implementation rather than taking the JEP route. Testing ------- Docker/container specific tests should be added in order to validate the functionality being provided with this JEP. Risks and Assumptions --------------------- Docker is currently based on cgroups v1. Cgroups v2 is also available but is incomplete and not yet supported by Docker. It's possible that v2 could replace v1 in an incompatible way rendering this work unusable until it is upgraded. Dependencies ----------- None at this time. From shade at redhat.com Fri Jul 14 14:22:45 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jul 2017 16:22:45 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> Message-ID: <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> On 07/14/2017 04:12 PM, Claes Redestad wrote: >> Thing is, "volatile" is not as strong as "final" for racy initializations: >> >> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals >> >> >> If that is not a concern -- e.g. if private constructor is never used to make >> shared OSFs -- then "volatile" is superfluous. If it is a concern, then >> "volatile" is not enough, and you have to keep "final". > > Gosh! > > Seeing how it's possible to lookup ObjectStreamClass and get at > ObjectStreamField's that might have been created from the internal > constructors, I think it *is* a concern. > > Thus the only viable option that allows us to be correct *and* lazy might be to > add a new field that is lazily initialized only when using the public constructors: > > http://cr.openjdk.java.net/~redestad/8184603/jdk.02/ I think this is fine from concurrency standpoint. Not sure how safe it is to increase OSF footprint, that's your call! I also think the largest improvement would be from avoiding the intern() call in constructor -- I frequently observed it on the OSF hot paths. I would trade excess field for avoiding String.intern() any day. As Doug Lea mentions offlist, another alternative would be to do fullFence at the end of OSF private constructor. But, this is low-level, and relies on hardware that handles data-dependent loads fine on reader side (which is true for all arches OpenJDK targets, I think). If there is no pressing need to keep OSF footprint minimal, I'd avoid doing explicit fences. Thanks, -Aleksey From claes.redestad at oracle.com Fri Jul 14 15:24:02 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 17:24:02 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> Message-ID: On 2017-07-14 16:22, Aleksey Shipilev wrote: > On 07/14/2017 04:12 PM, Claes Redestad wrote: >>> Thing is, "volatile" is not as strong as "final" for racy initializations: >>> >>> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals >>> >>> >>> If that is not a concern -- e.g. if private constructor is never used to make >>> shared OSFs -- then "volatile" is superfluous. If it is a concern, then >>> "volatile" is not enough, and you have to keep "final". >> Gosh! >> >> Seeing how it's possible to lookup ObjectStreamClass and get at >> ObjectStreamField's that might have been created from the internal >> constructors, I think it*is* a concern. >> >> Thus the only viable option that allows us to be correct*and* lazy might be to >> add a new field that is lazily initialized only when using the public constructors: >> >> http://cr.openjdk.java.net/~redestad/8184603/jdk.02/ > I think this is fine from concurrency standpoint. Not sure how safe it is to > increase OSF footprint, that's your call! I also think the largest improvement > would be from avoiding the intern() call in constructor -- I frequently observed > it on the OSF hot paths. I would trade excess field for avoiding String.intern() > any day. Maybe I'm not being imaginative enough, but I've not seen any heap dumps where #OSFs are anywhere near problematic quantities. For 64-bit VMs with compressed oops then it appears the change is footprint neutral due to padding (according to JOL estimates), and if we had to really optimize for applications with a huge number of OSFs then it appears there are other things we could examine to do as well.. > > As Doug Lea mentions offlist, another alternative would be to do fullFence at > the end of OSF private constructor. But, this is low-level, and relies on > hardware that handles data-dependent loads fine on reader side (which is true > for all arches OpenJDK targets, I think). If there is no pressing need to keep > OSF footprint minimal, I'd avoid doing explicit fences. Interesting, but I think we can keep that solution in mind for if and when there's a real need to trim down footprint. /Claes From chris.hegarty at oracle.com Fri Jul 14 15:26:11 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 14 Jul 2017 16:26:11 +0100 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> Message-ID: <49F34FED-D456-48BD-B5FB-DD1BA02B2397@oracle.com> > On 14 Jul 2017, at 15:12, Claes Redestad wrote: > > On 2017-07-14 15:46, Aleksey Shipilev wrote: >> On 07/14/2017 03:40 PM, Claes Redestad wrote: >>> signature is already made volatile in this patch, deliberately to ensure that >>> for the private constructors we keep correctness: >>> >>> in these private constructors, the signature field is initialized in the >>> constructor (we can assert that it's non-null) to a value that would not >>> match getClassSignature(type), but since the field is volatile it will never >>> be observed as null by a call to getSignature() on an object created with >>> these constructors (unless I'm mistaken, and we *do* need an added >>> synchonization point here). >> Thing is, "volatile" is not as strong as "final" for racy initializations: >> >> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals >> >> If that is not a concern -- e.g. if private constructor is never used to make >> shared OSFs -- then "volatile" is superfluous. If it is a concern, then >> "volatile" is not enough, and you have to keep "final". > > Gosh! Indeed! > Seeing how it's possible to lookup ObjectStreamClass and get at > ObjectStreamField's that might have been created from the internal > constructors, I think it *is* a concern. > > Thus the only viable option that allows us to be correct *and* lazy might be to > add a new field that is lazily initialized only when using the public constructors: > > http://cr.openjdk.java.net/~redestad/8184603/jdk.02/ This version looks good to me. Can you please add a link to this review thread to the bug ( for future archaeologists ). -Chris. From shade at redhat.com Fri Jul 14 15:30:32 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jul 2017 17:30:32 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> Message-ID: On 07/14/2017 05:24 PM, Claes Redestad wrote: >>> http://cr.openjdk.java.net/~redestad/8184603/jdk.02/ >> I think this is fine from concurrency standpoint. Not sure how safe it is to >> increase OSF footprint, that's your call! I also think the largest improvement >> would be from avoiding the intern() call in constructor -- I frequently observed >> it on the OSF hot paths. I would trade excess field for avoiding String.intern() >> any day. > > Maybe I'm not being imaginative enough, but I've not seen any heap > dumps where #OSFs are anywhere near problematic quantities. > > For 64-bit VMs with compressed oops then it appears the change is > footprint neutral due to padding (according to JOL estimates), and if we > had to really optimize for applications with a huge number of OSFs then > it appears there are other things we could examine to do as well.. OK then! Having no impact on 64-bit COOPs VM is good enough for me today. Maybe we should drop "null" stores in constructors, and instead rely on default values for them, since we are talking startup performance here where optimizing compilers have not yet got their chance. -Aleksey From claes.redestad at oracle.com Fri Jul 14 15:34:58 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 17:34:58 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: <49F34FED-D456-48BD-B5FB-DD1BA02B2397@oracle.com> References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <49F34FED-D456-48BD-B5FB-DD1BA02B2397@oracle.com> Message-ID: On 2017-07-14 17:26, Chris Hegarty wrote: >> http://cr.openjdk.java.net/~redestad/8184603/jdk.02/ > This version looks good to me. Thanks, Chris! > > Can you please add a link to this review thread to the bug ( for future archaeologists ). Done. /Claes From shade at redhat.com Fri Jul 14 15:35:11 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Jul 2017 17:35:11 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> Message-ID: <549c47bf-f4e1-aa52-0265-02f43d081757@redhat.com> On 07/14/2017 05:30 PM, Aleksey Shipilev wrote: > Maybe we should drop "null" stores in constructors, and instead rely on default > values for them, since we are talking startup performance here where optimizing > compilers have not yet got their chance. Sorry, those are the stores to final fields, they are needed. Nevermind me. -Aleksey From Roger.Riggs at Oracle.com Fri Jul 14 15:57:03 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 14 Jul 2017 11:57:03 -0400 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <49F34FED-D456-48BD-B5FB-DD1BA02B2397@oracle.com> Message-ID: Hi, Looks fine to me also. Thanks, Roger On 7/14/2017 11:34 AM, Claes Redestad wrote: > > > On 2017-07-14 17:26, Chris Hegarty wrote: >>> http://cr.openjdk.java.net/~redestad/8184603/jdk.02/ >> This version looks good to me. > > Thanks, Chris! > >> >> Can you please add a link to this review thread to the bug ( for >> future archaeologists ). > > Done. > > /Claes From claes.redestad at oracle.com Fri Jul 14 15:59:33 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 17:59:33 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <49F34FED-D456-48BD-B5FB-DD1BA02B2397@oracle.com> Message-ID: <741f08ca-a0fb-5a49-4a6d-7caf4c225a0c@oracle.com> On 2017-07-14 17:57, Roger Riggs wrote: > Hi, > > Looks fine to me also. Thanks, Roger! /Claes From volker.simonis at gmail.com Fri Jul 14 16:15:24 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 14 Jul 2017 18:15:24 +0200 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: References: Message-ID: Hi Bob, thanks for starting this JEP. I think it is long overdue and will be very helpful for many people. That said, I don't see any mentioning of the targeted Java release. As JEPs usually go into the development version first, I suppose the work for this JEP will be done in JDK10. However, taking into account the current release cycles, the usefulness of this JEP for the Java community will significantly depend on the its availability in Java 9 (at least) and Java 8 (hopefully?). Any thoughts on this? You also mention that this JEP is only about Docker support on Linux/x86_64. I'd argue that we should at least address at least all Docker supported Linux platforms. I'm pretty sure our colleagues from IBM would like to support this on Linux/ppc64 and Linux/s390 as well. Moreover, the suggested API and the new JVM_xxxxxx functions should be at least designed in such a way that other virtualisation environment such as VMWare/VirtualBox/Xen/KVM can take advantage of it. I'm also not sure if a completely new API solely for Docker containers is making sense and is worth the effort? I understand that containers and virtualisation are two different things, but they both impose similar restrictions to the VM (i.e. virtualisation may present a huge number of CPUs to the OS/VM which in reality are mapped to a single, physical CPU) so maybe we should design the new API in such a way that it can be used to tackle both problems. Finally, you mention in section D. that all the information should be logged the to error crash logs. That's good but maybe you could add that all the detection and all the findings should also be made available through the new Unified JVM Logging facility (JEP 158)? Regards, Volker On Fri, Jul 14, 2017 at 4:22 PM, Bob Vandette wrote: > I?d like to propose the following JEP that will enhance the Java runtime to be more container aware. > This will allow the Java runtime to performance better ergonomics and provide better > execution time statistics when running in a container. > > > JEP Issue: > > https://bugs.openjdk.java.net/browse/JDK-8182070 > > Here?s a Text dump of the JEP contents for your convenience: > > > Summary > ------- > > Container aware Java runtime > > Goals > ----- > > Enhance the JVM and Core libraries to detect running in a container and adapt to the system resources available to it. This JEP will only support Docker on Linux-x64 although the design should be flexible enough to allow support for other platforms and container technologies. The initial focus will be on Linux low level container technology such as cgroups so that we will be able to easily support other container technologies running on Linux in addition to Docker. > > Non-Goals > --------- > > It is not a goal of this JEP to support any platform other than Docker container technology running on Linux x64. > > Success Metrics > --------------- > > Success will be measured by the improved efficiency of running multiple Java containers on a host system with out of the box options. > > Motivation > ---------- > > Container technology is becoming more and more prevalent in Cloud based applications. This technology provides process isolation and allows the platform vendor to specify limits and alter the behavior of a process running inside a container that the Java runtime is not aware of. This causes the Java runtime to potentially attempt to use more system resources than are available to it causing performance degradation or even termination. > > > Description > ----------- > > This enhancement will be made up of the following work items: > > A. Detecting if Java is running in a container. > > The Java runtime, as well as any tests that we might write for this feature, will need to be able to detect that the current Java process is running in a container. I propose that we add a new JVM_ native function that returns a boolean true value if we are running inside a container. > > JVM_InContainer will return true if the currently running process is running in a container, otherwise false will be returned. > > B. Exposing container resource limits and configuration. > > There are several configuration options and limits that can be imposed upon a running container. Not all of these > are important to a running Java process. We clearly want to be able to detect how many CPUs have been allocated to our process along with the maximum amount of memory that we be allocated but there are other options that we might want to base runtime decisions on. > > In addition, since Container typically impose limits on system resources, they also provide the ability to easily access the amount of consumption of these resources. I intent on providing this information in addition to the configuration data. > > I propose adding a new jdk.internal.Platform class that will allow access to this information. Since some of this information is needed during the startup of the VM, I propose that much of the implementation of the methods in the Platform class be done in the VM and exposed as JVM_xxxxxx functions. In hotspot, the JVM_xxxxxx function will be implemented via the os.hpp interface. > > Here are the categories of configuration and consumption statistics that will be made available (The exact API is TBD): > > isContainerized > Memory Limit > Total Memory Limit > Soft Memory Limit > Max Memory Usage > Current Memory Usage > Maximum Kernel Memory > CPU Shares > CPU Period > CPU Quote > Number of CPUs > CPU Sets > CPU Set Memory Nodes > CPU Usage > CPU Usage Per CPU > Block I/O Weight > Block I/O Device Weight > Device I/O Read Rate > Device I/O Write Rate > OOM Kill Enabled > OOM Score Adjustment > Memory Swappiness > Shared Memory Size > > TODO: > 1. Need to specify the exact arguments and return format for these accessor functions. > > C. Adjusting Java runtime configuration based on limits. > > Java startup normally queries the operating system in order to setup runtime defaults for things such as the number of GC threads and default memory limits. When running in a container, the operating system functions used provide information about the host and does not include the containers configuration and limits. The VM and core libraries will be modified as part of this JEP to first determine if the current running process is running in a container. It will then cause the runtime to use the container values rather than the general operating system functions for configuring and managing the Java process. There have been a few attempts to correct some of these issue in the VM but they are not complete. The CPU detection in the VM currently only handles a container that limits cpu usage via CPU sets. If the Docker --cpu or --cpu-period along with --cpu-quota options are specified, it currently has no effect on the VMs configuration. > > The experimental memory detection that has been implemented only impacts the Heap selection and does not apply to the os::physical_memory or os::available_memory low level functions. This leaves other parts of the VM and > core libraries to believe there is more memory available than there actually is. > > The Numa support available in the VM is also not correct when running in a container. The number of available memory nodes and enabled nodes as reported by the libnuma library does not take into account the impact of the Docker --cpuset-mems option which restricts which memory nodes the container can use. Inside the container, the file /proc/{pid}/self does report the correct Cpus_allowed and Mems_Allowed but libnuma doesn't respect this. This has been verified via the numactl utility. > > To correct these shortcomings and make this support more robust, here's a list of the current cgroup subsystems that we be examined in order to update the internal VM and core library configuration. > > **Number of CPUs** > > Use a combination of number_of_cpus() and cpu_sets() in order to determine how many processors are available to the process and adjust the JVMs os::active_processor_count appropriately. The number_of_cpus() will be calculated based on the cpu_quota() and cpu_period() using this formula: number_of_cpus() = cpu_quota() / cpu_period(). Since it's not currently possible to understand the relative weight of the running container against all other containers, altering the cpu_shares of a running container will have no affect on altering Java's configuration. > > **Total available memory** > > Use the memory_limit() value from the cgroup file system to initialize the os::physical_memory() value in the VM. This value will propagate to all other parts of the Java runtime. > > We might also consider examining the soft_memory_limit and total_memory_limit in addition to the memory_limit during the ergonomics startup processing in order to fine tuning some of the other VM settings. > > **CPU Memory Nodes** > > Use cpu_set_memory_nodes() to configure the os::numa support. > > **Memory usage** > > Use memory_usage_in_bytes() for providing os::available_memory() by subtracting the usage from the total available memory allocated to the container. > > D. Adding container configuration to error crash logs. > > As as troubleshooting aid, we will dump any available container statistics to the hotspot error log. > > E. Adding a startup flag to enable/disable this support. > > Add a -XX:+UseContainerSupport VM option that will be used to enable this support. The default will be off until this feature is proven. > > Alternatives > ------------ > > There are a few existing RFE's filed that could be used to enhance the current experimental implementation rather than taking the JEP route. > > Testing > ------- > > Docker/container specific tests should be added in order to validate the functionality being provided with this JEP. > > Risks and Assumptions > --------------------- > > Docker is currently based on cgroups v1. Cgroups v2 is also available but is incomplete and not yet supported by Docker. It's possible that v2 could replace v1 in an incompatible way rendering this work unusable until it is upgraded. > > Dependencies > ----------- > > None at this time. > From Roger.Riggs at Oracle.com Fri Jul 14 16:25:38 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 14 Jul 2017 12:25:38 -0400 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> Message-ID: Hi Claes, Using == with references always looks a bit suspicious in the source code, especially strings. Since the first thing in equals() is the identity check, I'd suggest using .equals for the comparisons. Roger On 7/14/2017 8:52 AM, Claes Redestad wrote: > Hi, > > by special-casing the three Charsets we always load on startup in the > Charset > constructor we can avoid some superfluous checks and get a tiny startup > improvement (~7k less bytecode executed, which is fast approaching 1% > of total > on minimal startup tests). > > Webrev: http://cr.openjdk.java.net/~redestad/8184665/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8184665 > > Thanks! > > /Claes From bob.vandette at oracle.com Fri Jul 14 16:54:36 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 14 Jul 2017 12:54:36 -0400 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: References: Message-ID: > On Jul 14, 2017, at 12:15 PM, Volker Simonis wrote: > > Hi Bob, > > thanks for starting this JEP. I think it is long overdue and will be > very helpful for many people. > Thanks for taking a look at the JEP. > That said, I don't see any mentioning of the targeted Java release. As > JEPs usually go into the development version first, I suppose the work > for this JEP will be done in JDK10. However, taking into account the > current release cycles, the usefulness of this JEP for the Java > community will significantly depend on the its availability in Java 9 > (at least) and Java 8 (hopefully?). Any thoughts on this? I am certainly going to do my best to try to get this feature into JDK10 and I understand your concern about supporting Java 8 and 9. The decision to backport this feature will have to be done based on the usual criteria (complexity, usefulness, resource availability and compatibility). It may be possible to add some subset of this functionality in a backport but we?ll have to wait until the design is further along. > > You also mention that this JEP is only about Docker support on > Linux/x86_64. I'd argue that we should at least address at least all > Docker supported Linux platforms. I'm pretty sure our colleagues from > IBM would like to support this on Linux/ppc64 and Linux/s390 as well. Right now I don?t expect to have to write CPU specific logic. Therefore supporting ppc64, s390 or even aarch64 should boil down to testing. > > Moreover, the suggested API and the new JVM_xxxxxx functions should be > at least designed in such a way that other virtualisation environment > such as VMWare/VirtualBox/Xen/KVM can take advantage of it. I'm also > not sure if a completely new API solely for Docker containers is > making sense and is worth the effort? I understand that containers and > virtualisation are two different things, but they both impose similar > restrictions to the VM (i.e. virtualisation may present a huge number > of CPUs to the OS/VM which in reality are mapped to a single, physical > CPU) so maybe we should design the new API in such a way that it can > be used to tackle both problems. I will try to keep that in mind. I will have to look into the feasibility of accessing host configuration from within a container or virtual machine. For containers, it seems to me that would break the intent of isolation. I know that host information does leak into containers through the proc file system but I suspect this was done for simplicity and compatibility reasons. > > Finally, you mention in section D. that all the information should be > logged the to error crash logs. That's good but maybe you could add > that all the detection and all the findings should also be made > available through the new Unified JVM Logging facility (JEP 158)? That?s a good idea. I will add that to the JEP. Thanks, Bob. > > Regards, > Volker > > > On Fri, Jul 14, 2017 at 4:22 PM, Bob Vandette wrote: >> I?d like to propose the following JEP that will enhance the Java runtime to be more container aware. >> This will allow the Java runtime to performance better ergonomics and provide better >> execution time statistics when running in a container. >> >> >> JEP Issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8182070 >> >> Here?s a Text dump of the JEP contents for your convenience: >> >> >> Summary >> ------- >> >> Container aware Java runtime >> >> Goals >> ----- >> >> Enhance the JVM and Core libraries to detect running in a container and adapt to the system resources available to it. This JEP will only support Docker on Linux-x64 although the design should be flexible enough to allow support for other platforms and container technologies. The initial focus will be on Linux low level container technology such as cgroups so that we will be able to easily support other container technologies running on Linux in addition to Docker. >> >> Non-Goals >> --------- >> >> It is not a goal of this JEP to support any platform other than Docker container technology running on Linux x64. >> >> Success Metrics >> --------------- >> >> Success will be measured by the improved efficiency of running multiple Java containers on a host system with out of the box options. >> >> Motivation >> ---------- >> >> Container technology is becoming more and more prevalent in Cloud based applications. This technology provides process isolation and allows the platform vendor to specify limits and alter the behavior of a process running inside a container that the Java runtime is not aware of. This causes the Java runtime to potentially attempt to use more system resources than are available to it causing performance degradation or even termination. >> >> >> Description >> ----------- >> >> This enhancement will be made up of the following work items: >> >> A. Detecting if Java is running in a container. >> >> The Java runtime, as well as any tests that we might write for this feature, will need to be able to detect that the current Java process is running in a container. I propose that we add a new JVM_ native function that returns a boolean true value if we are running inside a container. >> >> JVM_InContainer will return true if the currently running process is running in a container, otherwise false will be returned. >> >> B. Exposing container resource limits and configuration. >> >> There are several configuration options and limits that can be imposed upon a running container. Not all of these >> are important to a running Java process. We clearly want to be able to detect how many CPUs have been allocated to our process along with the maximum amount of memory that we be allocated but there are other options that we might want to base runtime decisions on. >> >> In addition, since Container typically impose limits on system resources, they also provide the ability to easily access the amount of consumption of these resources. I intent on providing this information in addition to the configuration data. >> >> I propose adding a new jdk.internal.Platform class that will allow access to this information. Since some of this information is needed during the startup of the VM, I propose that much of the implementation of the methods in the Platform class be done in the VM and exposed as JVM_xxxxxx functions. In hotspot, the JVM_xxxxxx function will be implemented via the os.hpp interface. >> >> Here are the categories of configuration and consumption statistics that will be made available (The exact API is TBD): >> >> isContainerized >> Memory Limit >> Total Memory Limit >> Soft Memory Limit >> Max Memory Usage >> Current Memory Usage >> Maximum Kernel Memory >> CPU Shares >> CPU Period >> CPU Quote >> Number of CPUs >> CPU Sets >> CPU Set Memory Nodes >> CPU Usage >> CPU Usage Per CPU >> Block I/O Weight >> Block I/O Device Weight >> Device I/O Read Rate >> Device I/O Write Rate >> OOM Kill Enabled >> OOM Score Adjustment >> Memory Swappiness >> Shared Memory Size >> >> TODO: >> 1. Need to specify the exact arguments and return format for these accessor functions. >> >> C. Adjusting Java runtime configuration based on limits. >> >> Java startup normally queries the operating system in order to setup runtime defaults for things such as the number of GC threads and default memory limits. When running in a container, the operating system functions used provide information about the host and does not include the containers configuration and limits. The VM and core libraries will be modified as part of this JEP to first determine if the current running process is running in a container. It will then cause the runtime to use the container values rather than the general operating system functions for configuring and managing the Java process. There have been a few attempts to correct some of these issue in the VM but they are not complete. The CPU detection in the VM currently only handles a container that limits cpu usage via CPU sets. If the Docker --cpu or --cpu-period along with --cpu-quota options are specified, it currently has no effect on the VMs configuration. >> >> The experimental memory detection that has been implemented only impacts the Heap selection and does not apply to the os::physical_memory or os::available_memory low level functions. This leaves other parts of the VM and >> core libraries to believe there is more memory available than there actually is. >> >> The Numa support available in the VM is also not correct when running in a container. The number of available memory nodes and enabled nodes as reported by the libnuma library does not take into account the impact of the Docker --cpuset-mems option which restricts which memory nodes the container can use. Inside the container, the file /proc/{pid}/self does report the correct Cpus_allowed and Mems_Allowed but libnuma doesn't respect this. This has been verified via the numactl utility. >> >> To correct these shortcomings and make this support more robust, here's a list of the current cgroup subsystems that we be examined in order to update the internal VM and core library configuration. >> >> **Number of CPUs** >> >> Use a combination of number_of_cpus() and cpu_sets() in order to determine how many processors are available to the process and adjust the JVMs os::active_processor_count appropriately. The number_of_cpus() will be calculated based on the cpu_quota() and cpu_period() using this formula: number_of_cpus() = cpu_quota() / cpu_period(). Since it's not currently possible to understand the relative weight of the running container against all other containers, altering the cpu_shares of a running container will have no affect on altering Java's configuration. >> >> **Total available memory** >> >> Use the memory_limit() value from the cgroup file system to initialize the os::physical_memory() value in the VM. This value will propagate to all other parts of the Java runtime. >> >> We might also consider examining the soft_memory_limit and total_memory_limit in addition to the memory_limit during the ergonomics startup processing in order to fine tuning some of the other VM settings. >> >> **CPU Memory Nodes** >> >> Use cpu_set_memory_nodes() to configure the os::numa support. >> >> **Memory usage** >> >> Use memory_usage_in_bytes() for providing os::available_memory() by subtracting the usage from the total available memory allocated to the container. >> >> D. Adding container configuration to error crash logs. >> >> As as troubleshooting aid, we will dump any available container statistics to the hotspot error log. >> >> E. Adding a startup flag to enable/disable this support. >> >> Add a -XX:+UseContainerSupport VM option that will be used to enable this support. The default will be off until this feature is proven. >> >> Alternatives >> ------------ >> >> There are a few existing RFE's filed that could be used to enhance the current experimental implementation rather than taking the JEP route. >> >> Testing >> ------- >> >> Docker/container specific tests should be added in order to validate the functionality being provided with this JEP. >> >> Risks and Assumptions >> --------------------- >> >> Docker is currently based on cgroups v1. Cgroups v2 is also available but is incomplete and not yet supported by Docker. It's possible that v2 could replace v1 in an incompatible way rendering this work unusable until it is upgraded. >> >> Dependencies >> ----------- >> >> None at this time. >> From claes.redestad at oracle.com Fri Jul 14 17:03:47 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 19:03:47 +0200 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> Message-ID: Hi Roger, On 2017-07-14 18:25, Roger Riggs wrote: > Hi Claes, > > Using == with references always looks a bit suspicious in the source > code, especially strings. > Since the first thing in equals() is the identity check, I'd suggest > using .equals for the comparisons. Sure, there's no significant performance difference, even in interpreted mode: http://cr.openjdk.java.net/~redestad/8184665/jdk.01/ /Claes From Roger.Riggs at Oracle.com Fri Jul 14 17:12:09 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 14 Jul 2017 13:12:09 -0400 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> Message-ID: <9aa1b6dd-bca6-2d44-6d83-7f254cba3957@Oracle.com> +1, Thanks, Roger On 7/14/2017 1:03 PM, Claes Redestad wrote: > Hi Roger, > > On 2017-07-14 18:25, Roger Riggs wrote: >> Hi Claes, >> >> Using == with references always looks a bit suspicious in the source >> code, especially strings. >> Since the first thing in equals() is the identity check, I'd suggest >> using .equals for the comparisons. > > Sure, there's no significant performance difference, even in > interpreted mode: > > http://cr.openjdk.java.net/~redestad/8184665/jdk.01/ > > /Claes From naoto.sato at oracle.com Fri Jul 14 17:30:06 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 14 Jul 2017 10:30:06 -0700 Subject: [10] RFR (XS) 8184314: Javadoc for Offsettime has "." where it should be ":" prior to seconds Message-ID: <1525484a-e2b7-300d-57aa-a48a1ab9dccb@oracle.com> Hello, Please review this trivial doc fix to java.time classes. The issue is: https://bugs.openjdk.java.net/browse/JDK-8184314 And the proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8184314/webrev.00/ Naoto From Roger.Riggs at Oracle.com Fri Jul 14 17:33:21 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 14 Jul 2017 13:33:21 -0400 Subject: [10] RFR (XS) 8184314: Javadoc for Offsettime has "." where it should be ":" prior to seconds In-Reply-To: <1525484a-e2b7-300d-57aa-a48a1ab9dccb@oracle.com> References: <1525484a-e2b7-300d-57aa-a48a1ab9dccb@oracle.com> Message-ID: Looks fine, Thanks, Roger On 7/14/2017 1:30 PM, Naoto Sato wrote: > Hello, > > Please review this trivial doc fix to java.time classes. The issue is: > > https://bugs.openjdk.java.net/browse/JDK-8184314 > > And the proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8184314/webrev.00/ > > Naoto From xueming.shen at oracle.com Fri Jul 14 17:42:21 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 14 Jul 2017 10:42:21 -0700 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> Message-ID: <5969027D.8040400@oracle.com> Hi Claes, The change looks fine. The only concern is that, in theory, it appears we no longer have any "check" to guarantee that all "alias" names defined for these 3 charsets indeed follow the spec? The consequence of this is that someone can obtain the alias name from the specific "charset", and then that name will fail for Charset.forName(). I doubt we currently have a regression test to catch this. The possibility that we are going to add a new alias for these 3 is low, but either a regress test (if we don't have one already) or a comment at jdk/make/data/charsetmapping/charsets (for each of the def, to remind a possible change) might help to prevent this from happening? -Sherman PS: The next step is to remove these 3 from the sun.nio.cs.StandardCharsets? :-) On 07/14/2017 10:03 AM, Claes Redestad wrote: > Hi Roger, > > On 2017-07-14 18:25, Roger Riggs wrote: >> Hi Claes, >> >> Using == with references always looks a bit suspicious in the source code, especially strings. >> Since the first thing in equals() is the identity check, I'd suggest using .equals for the comparisons. > > Sure, there's no significant performance difference, even in interpreted mode: > > http://cr.openjdk.java.net/~redestad/8184665/jdk.01/ > > /Claes From forax at univ-mlv.fr Fri Jul 14 18:01:24 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 14 Jul 2017 20:01:24 +0200 (CEST) Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: <9aa1b6dd-bca6-2d44-6d83-7f254cba3957@Oracle.com> References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> <9aa1b6dd-bca6-2d44-6d83-7f254cba3957@Oracle.com> Message-ID: <1360525601.1358152.1500055284293.JavaMail.zimbra@u-pem.fr> I do not like the equals in the constructor of Charset given that in StandardCharsets, == is used. I think the constructor of Charset should use == and a comment should be added explaining why it's valid to use == like in StandardCharsets. cheers, R?mi ----- Mail original ----- > De: "Roger Riggs" > ?: "core-libs-dev" > Envoy?: Vendredi 14 Juillet 2017 19:12:09 > Objet: Re: [10] RFR: 8184665: Skip name and alias checks for standard Charsets > +1, > > Thanks, Roger > > On 7/14/2017 1:03 PM, Claes Redestad wrote: >> Hi Roger, >> >> On 2017-07-14 18:25, Roger Riggs wrote: >>> Hi Claes, >>> >>> Using == with references always looks a bit suspicious in the source >>> code, especially strings. >>> Since the first thing in equals() is the identity check, I'd suggest >>> using .equals for the comparisons. >> >> Sure, there's no significant performance difference, even in >> interpreted mode: >> >> http://cr.openjdk.java.net/~redestad/8184665/jdk.01/ >> > > /Claes From Roger.Riggs at Oracle.com Fri Jul 14 18:08:34 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 14 Jul 2017 14:08:34 -0400 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: <1360525601.1358152.1500055284293.JavaMail.zimbra@u-pem.fr> References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> <9aa1b6dd-bca6-2d44-6d83-7f254cba3957@Oracle.com> <1360525601.1358152.1500055284293.JavaMail.zimbra@u-pem.fr> Message-ID: <03371f14-178c-7917-4eef-95e875576ea3@Oracle.com> Hi Remi, Point taken about consistency. I'm concerned about code that is unnecessarily fragile due to unnecessary and unexpected optimizations. $.02, Roger On 7/14/2017 2:01 PM, Remi Forax wrote: > I do not like the equals in the constructor of Charset given that in StandardCharsets, == is used. > > I think the constructor of Charset should use == and a comment should be added explaining why it's valid to use == like in StandardCharsets. > > cheers, > R?mi > > ----- Mail original ----- >> De: "Roger Riggs" >> ?: "core-libs-dev" >> Envoy?: Vendredi 14 Juillet 2017 19:12:09 >> Objet: Re: [10] RFR: 8184665: Skip name and alias checks for standard Charsets >> +1, >> >> Thanks, Roger >> >> On 7/14/2017 1:03 PM, Claes Redestad wrote: >>> Hi Roger, >>> >>> On 2017-07-14 18:25, Roger Riggs wrote: >>>> Hi Claes, >>>> >>>> Using == with references always looks a bit suspicious in the source >>>> code, especially strings. >>>> Since the first thing in equals() is the identity check, I'd suggest >>>> using .equals for the comparisons. >>> Sure, there's no significant performance difference, even in >>> interpreted mode: >>> >>> http://cr.openjdk.java.net/~redestad/8184665/jdk.01/ >>> >>> /Claes From claes.redestad at oracle.com Fri Jul 14 18:40:25 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 14 Jul 2017 20:40:25 +0200 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: <03371f14-178c-7917-4eef-95e875576ea3@Oracle.com> References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> <9aa1b6dd-bca6-2d44-6d83-7f254cba3957@Oracle.com> <1360525601.1358152.1500055284293.JavaMail.zimbra@u-pem.fr> <03371f14-178c-7917-4eef-95e875576ea3@Oracle.com> Message-ID: <21d327e0-2540-8fb6-6966-4598ff22840c@oracle.com> Hi, in this case the code isn't really fragile, since two equal but not identical Strings will end up with the same Charset, so there's no *real* surprises to be had (only a tiny performance loss that isn't really consequential except for startup). So: I did use == mostly to be consistent with StandardCharsets, although it is also a gain by a few bytecodes less executed on startup. We could change to equals in both places as well if consistency is all that matters, but since this is established behavior I'd rather use == in the new place, and add a comment about why it's valid. Reasonable? I'll add a regression test to test these standard Charsets are kept well-behaved, as per Sherman's comment. Thanks! /Claes On 2017-07-14 20:08, Roger Riggs wrote: > Hi Remi, > > Point taken about consistency. > I'm concerned about code that is unnecessarily fragile due to > unnecessary and unexpected optimizations. > > $.02, Roger > > > On 7/14/2017 2:01 PM, Remi Forax wrote: >> I do not like the equals in the constructor of Charset given that in >> StandardCharsets, == is used. >> >> I think the constructor of Charset should use == and a comment should >> be added explaining why it's valid to use == like in StandardCharsets. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Roger Riggs" >>> ?: "core-libs-dev" >>> Envoy?: Vendredi 14 Juillet 2017 19:12:09 >>> Objet: Re: [10] RFR: 8184665: Skip name and alias checks for >>> standard Charsets >>> +1, >>> >>> Thanks, Roger >>> >>> On 7/14/2017 1:03 PM, Claes Redestad wrote: >>>> Hi Roger, >>>> >>>> On 2017-07-14 18:25, Roger Riggs wrote: >>>>> Hi Claes, >>>>> >>>>> Using == with references always looks a bit suspicious in the source >>>>> code, especially strings. >>>>> Since the first thing in equals() is the identity check, I'd suggest >>>>> using .equals for the comparisons. >>>> Sure, there's no significant performance difference, even in >>>> interpreted mode: >>>> >>>> http://cr.openjdk.java.net/~redestad/8184665/jdk.01/ >>>> >>>> /Claes > From forax at univ-mlv.fr Fri Jul 14 19:30:04 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 14 Jul 2017 21:30:04 +0200 (CEST) Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: <21d327e0-2540-8fb6-6966-4598ff22840c@oracle.com> References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> <9aa1b6dd-bca6-2d44-6d83-7f254cba3957@Oracle.com> <1360525601.1358152.1500055284293.JavaMail.zimbra@u-pem.fr> <03371f14-178c-7917-4eef-95e875576ea3@Oracle.com> <21d327e0-2540-8fb6-6966-4598ff22840c@oracle.com> Message-ID: <16210179.1364813.1500060604341.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Claes Redestad" > ?: "Roger Riggs" , "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Vendredi 14 Juillet 2017 20:40:25 > Objet: Re: [10] RFR: 8184665: Skip name and alias checks for standard Charsets > Hi, > > in this case the code isn't really fragile, since two equal but not > identical Strings will end up with the same Charset, so there's no > *real* surprises to be had (only a tiny performance loss that isn't > really consequential except for startup). > > So: I did use == mostly to be consistent with StandardCharsets, although > it is also a gain by a few bytecodes less executed on startup. We could > change to equals in both places as well if consistency is all that > matters, but since this is established behavior I'd rather use == > in the new place, and add a comment about why it's valid. Reasonable? yes, i agree with Roger that this 'optimization' usually bites you in the back when you start to update some parts of the code and not others. The fact that the Charset code uses == is a kind of historical glitch and it's not that awful if tested, nevertheless if in the future someone what to change == by equals in these two codes, my gut feeling is that there are other Charset related codes that uses ==, so an audit should be done to change all the codes at once. > > I'll add a regression test to test these standard Charsets are kept > well-behaved, as per Sherman's comment. > > Thanks! > > /Claes cheers, R?mi > > On 2017-07-14 20:08, Roger Riggs wrote: >> Hi Remi, >> >> Point taken about consistency. >> I'm concerned about code that is unnecessarily fragile due to >> unnecessary and unexpected optimizations. >> >> $.02, Roger >> >> >> On 7/14/2017 2:01 PM, Remi Forax wrote: >>> I do not like the equals in the constructor of Charset given that in >>> StandardCharsets, == is used. >>> >>> I think the constructor of Charset should use == and a comment should >>> be added explaining why it's valid to use == like in StandardCharsets. >>> >>> cheers, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Roger Riggs" >>>> ?: "core-libs-dev" >>>> Envoy?: Vendredi 14 Juillet 2017 19:12:09 >>>> Objet: Re: [10] RFR: 8184665: Skip name and alias checks for >>>> standard Charsets >>>> +1, >>>> >>>> Thanks, Roger >>>> >>>> On 7/14/2017 1:03 PM, Claes Redestad wrote: >>>>> Hi Roger, >>>>> >>>>> On 2017-07-14 18:25, Roger Riggs wrote: >>>>>> Hi Claes, >>>>>> >>>>>> Using == with references always looks a bit suspicious in the source >>>>>> code, especially strings. >>>>>> Since the first thing in equals() is the identity check, I'd suggest >>>>>> using .equals for the comparisons. >>>>> Sure, there's no significant performance difference, even in >>>>> interpreted mode: >>>>> >>>>> http://cr.openjdk.java.net/~redestad/8184665/jdk.01/ >>>>> >>>>> /Claes From ivan.gerasimov at oracle.com Sat Jul 15 08:41:36 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 15 Jul 2017 01:41:36 -0700 Subject: [10] RFR 8184706: Matcher doesn't indicate hitEnd after matching \u0D with \R at EOL Message-ID: <9671fd18-d744-f8aa-f31a-6473eacf8290@oracle.com> Hello! It was spotted that in certain situations the Matcher.hitEnd() returns false, though the regexp engine in fact has hit the end of the input. This is because the \R pattern can match both 0x0d and 0x0d0x0a sequences. Thus, the engine "hits the end", if the input ends with 0x0d, since the engine wants to greedily consume 0x0a. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8184706 WEBREV: http://cr.openjdk.java.net/~igerasim/8184706/00/webrev/ -- With kind regards, Ivan Gerasimov From peter.levart at gmail.com Sat Jul 15 12:08:43 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 15 Jul 2017 14:08:43 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> Message-ID: <7b7cbf1c-3873-492c-a025-4b9c24511727@gmail.com> Hi, On 07/14/2017 04:22 PM, Aleksey Shipilev wrote: > On 07/14/2017 04:12 PM, Claes Redestad wrote: >>> Thing is, "volatile" is not as strong as "final" for racy initializations: >>> >>> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals >>> >>> >>> If that is not a concern -- e.g. if private constructor is never used to make >>> shared OSFs -- then "volatile" is superfluous. If it is a concern, then >>> "volatile" is not enough, and you have to keep "final". >> Gosh! >> >> Seeing how it's possible to lookup ObjectStreamClass and get at >> ObjectStreamField's that might have been created from the internal >> constructors, I think it *is* a concern. >> >> Thus the only viable option that allows us to be correct *and* lazy might be to >> add a new field that is lazily initialized only when using the public constructors: >> >> http://cr.openjdk.java.net/~redestad/8184603/jdk.02/ > I think this is fine from concurrency standpoint. Not sure how safe it is to > increase OSF footprint, that's your call! I also think the largest improvement > would be from avoiding the intern() call in constructor -- I frequently observed > it on the OSF hot paths. I would trade excess field for avoiding String.intern() > any day. It seems that interning signature(s) is important for correctness (for example, in ObjectOutputStream.writeTypeString(str) the 'str' is used to lookup a handle so that handles are put into stream instead of the type signature(s) for multiple references to the same type). Looking up objects in handles table is based on identity comparison. But there might be a way to obtain a singleton signature String per type and still profit. By adding a field to java.lang.Class and caching the JVM signature there. This would also be a useful public method, don't you think? Out of 191 ObjectStreamField constructions I found in JDK sources, there are only 39 distinct field types involved, so the number if intern() calls is reduced by a factor of ~5. There's no need to cache signature in ObjectStreamField(s) this way any more, but there must still be a single final field for ObjectStreamField(s) constructed with explicit signature(s). Here's how this looks like in code: http://cr.openjdk.java.net/~plevart/misc/Class.getJvmTypeSignature/webrev.01/ What do you think? Regards, Peter > As Doug Lea mentions offlist, another alternative would be to do fullFence at > the end of OSF private constructor. But, this is low-level, and relies on > hardware that handles data-dependent loads fine on reader side (which is true > for all arches OpenJDK targets, I think). If there is no pressing need to keep > OSF footprint minimal, I'd avoid doing explicit fences. > > Thanks, > -Aleksey > From xueming.shen at oracle.com Sat Jul 15 17:09:03 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 15 Jul 2017 10:09:03 -0700 Subject: [10] RFR 8184706: Matcher doesn't indicate hitEnd after matching \u0D with \R at EOL In-Reply-To: <9671fd18-d744-f8aa-f31a-6473eacf8290@oracle.com> References: <9671fd18-d744-f8aa-f31a-6473eacf8290@oracle.com> Message-ID: <596A4C2F.6090909@oracle.com> +1 On 7/15/17, 1:41 AM, Ivan Gerasimov wrote: > Hello! > > It was spotted that in certain situations the Matcher.hitEnd() returns > false, though the regexp engine in fact has hit the end of the input. > This is because the \R pattern can match both 0x0d and 0x0d0x0a > sequences. Thus, the engine "hits the end", if the input ends with > 0x0d, since the engine wants to greedily consume 0x0a. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8184706 > WEBREV: http://cr.openjdk.java.net/~igerasim/8184706/00/webrev/ > From szegedia at gmail.com Sat Jul 15 20:11:51 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Sat, 15 Jul 2017 23:11:51 +0300 Subject: java.util.Pair In-Reply-To: <8f3e2a95-d50e-482e-ceed-d6d0acc3249e@mebigfatguy.com> References: <85D69AC8-A71B-4719-B6DB-49C40B700EA0@amazon.com> <75c7aafd-7b5f-f88c-4aac-e174dd3a1c1c@oracle.com> <231186441.1177524.1499978388049.JavaMail.zimbra@u-pem.fr> <53EB809A-39E7-4E2A-B22E-7626EDFD9B72@oracle.com> <1122534738.1193949.1499982076283.JavaMail.zimbra@u-pem.fr> <8f3e2a95-d50e-482e-ceed-d6d0acc3249e@mebigfatguy.com> Message-ID: In application code I agree that semantics-free tuples are a code smell, but if you're developing a library of generally usable algorithms a need for a type that is a product of two types can naturally arise, without further semantics provided (or required) by the context. In a sense the existence of BiFunction is already a validation of the need to pass pairs as function arguments; we just don't have a way to keep them rectified (or use them as a return value). Attila. > On Jul 14, 2017, at 02:24, Dave Brosius wrote: > > I would avoid Pair and Entry like the plague. They are devoid of meaning and are just there to save your fingers. If that is your main impetus, i'd just turn to using lombok and have true bean classes, that are finger-cost free. > > > On 07/13/2017 05:41 PM, forax at univ-mlv.fr wrote: >>> De: "John Rose" >>> ?: "R?mi Forax" >>> Cc: "joe darcy" , "core-libs-dev" >>> >>> Envoy?: Jeudi 13 Juillet 2017 23:05:14 >>> Objet: Re: java.util.Pair >>> On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | >>> forax at univ-mlv.fr ] > wrote: >>>> Tuples are like an array of value types parameterized by a constant integer >>> The homogeneous case is pretty simple; most of what you need is >>> to allow a generic type to be parameterized by an integer. C++ templates >>> have had that for a long time. >>> What's harder is to have a two-step process for type instantiation: >>> First, tell me the arity N, and second, for each position under that arity, >>> tell me the type T[i], i>> the most Java-like way to handle it might be type-functions that overload >>> alongside generic types. But there are many, many ways to slice it. >> or use a recursive definition like in Ceylon >> https://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/module-doc/Tuple.type.html >> and the fact that value types are flatten to specify the rest, i.e a Tuple contains a T first and a Tuple rest. >> >>> C++ templates can express heterogeneous tuples: >>> [ http://en.cppreference.com/w/cpp/utility/tuple | >>> http://en.cppreference.com/w/cpp/utility/tuple ] >>> Typically there is a small limit to C++ tuple size, because the underlying >>> template implementation has its size set to the arity limit. >>> ? John >> R?mi >> > From ivan.gerasimov at oracle.com Sun Jul 16 04:27:30 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 15 Jul 2017 21:27:30 -0700 Subject: [10] RFR 8184706: Matcher doesn't indicate hitEnd after matching \u0D with \R at EOL In-Reply-To: <596A4C2F.6090909@oracle.com> References: <9671fd18-d744-f8aa-f31a-6473eacf8290@oracle.com> <596A4C2F.6090909@oracle.com> Message-ID: <8bc709a2-6961-9d08-66f1-9384818ec4f7@oracle.com> Thanks for review! On 7/15/17 10:09 AM, Xueming Shen wrote: > +1 > > On 7/15/17, 1:41 AM, Ivan Gerasimov wrote: >> Hello! >> >> It was spotted that in certain situations the Matcher.hitEnd() >> returns false, though the regexp engine in fact has hit the end of >> the input. >> This is because the \R pattern can match both 0x0d and 0x0d0x0a >> sequences. Thus, the engine "hits the end", if the input ends with >> 0x0d, since the engine wants to greedily consume 0x0a. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8184706 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8184706/00/webrev/ >> > > -- With kind regards, Ivan Gerasimov From amy.lu at oracle.com Mon Jul 17 07:49:29 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 17 Jul 2017 15:49:29 +0800 Subject: JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java In-Reply-To: References: <846D7A40-148A-4BCB-99FE-0744DE198A6D@oracle.com> Message-ID: <933abb50-7bae-5fb0-45fb-c12d494a4842@oracle.com> On 7/14/17 4:41 PM, Mandy Chung wrote: > I think compiling the other classes to a destination explicitly to replace: > 29 * @build Alice Bob SupAlice SupBob > 30 * @run driver SetupLoader > > will make the test clearer. It?d be good to make that change. Webrev updated: http://cr.openjdk.java.net/~amlu/8183377/webrev.01/ Please review. Thanks, Amy From claes.redestad at oracle.com Mon Jul 17 12:16:11 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 17 Jul 2017 14:16:11 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: <7b7cbf1c-3873-492c-a025-4b9c24511727@gmail.com> References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> <7b7cbf1c-3873-492c-a025-4b9c24511727@gmail.com> Message-ID: Hi Peter! On 2017-07-15 14:08, Peter Levart wrote: > > It seems that interning signature(s) is important for correctness (for > example, in ObjectOutputStream.writeTypeString(str) the 'str' is used > to lookup a handle so that handles are put into stream instead of the > type signature(s) for multiple references to the same type). Looking > up objects in handles table is based on identity comparison. Yes, interned signatures is important for correctness (and performance?) of the current serialization implementation. > > But there might be a way to obtain a singleton signature String per > type and still profit. By adding a field to java.lang.Class and > caching the JVM signature there. This would also be a useful public > method, don't you think? I have a nagging feeling that we should be careful about leaking implementation details about the underlying VM through public APIs, since making changes to various specifications is hard enough as it is. > > Out of 191 ObjectStreamField constructions I found in JDK sources, > there are only 39 distinct field types involved, so the number if > intern() calls is reduced by a factor of ~5. There's no need to cache > signature in ObjectStreamField(s) this way any more, but there must > still be a single final field for ObjectStreamField(s) constructed > with explicit signature(s). > > Here's how this looks like in code: > > http://cr.openjdk.java.net/~plevart/misc/Class.getJvmTypeSignature/webrev.01/ Could this be done as a ClassValue instead of another field on Class? My guess is only a small number of classes in any given app will be directly involved in serialization, so growing Class seems to be a pessimization. > > What do you think? I wonder what workloads actually see a bottleneck in these String.intern calls, and *which* String.intern calls we are bottlenecking on in these workloads. There's still a couple of constructors here that won't see a speedup. I think we need more data to ensure this is actually worthwhile to pursue, or whether there are other optimizations on a higher level that could be done. Thanks! /Claes From Alan.Bateman at oracle.com Mon Jul 17 14:14:47 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Jul 2017 15:14:47 +0100 Subject: [9] JDK-8184306: zlib 1.2.11 upgrade triggers j.u.zip.Deflater regression In-Reply-To: References: <5966AB5A.80208@oracle.com> Message-ID: <01c7c437-60d5-9df4-719c-d83f0a63b229@oracle.com> On 13/07/2017 18:08, Martin Buchholz wrote: > : > > - configure on linux reports: > --with-zlib use zlib from build system or OpenJDK source > (system, bundled) [bundled] > Does this need updating to "system" ? Yes, except when on Windows, but that can be updated in jdk10/jdk10, not needed for the current issue. -Alan From volker.simonis at gmail.com Mon Jul 17 15:55:53 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Jul 2017 17:55:53 +0200 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: References: Message-ID: On Fri, Jul 14, 2017 at 6:54 PM, Bob Vandette wrote: > >> On Jul 14, 2017, at 12:15 PM, Volker Simonis wrote: >> >> Hi Bob, >> >> thanks for starting this JEP. I think it is long overdue and will be >> very helpful for many people. >> > Thanks for taking a look at the JEP. > >> That said, I don't see any mentioning of the targeted Java release. As >> JEPs usually go into the development version first, I suppose the work >> for this JEP will be done in JDK10. However, taking into account the >> current release cycles, the usefulness of this JEP for the Java >> community will significantly depend on the its availability in Java 9 >> (at least) and Java 8 (hopefully?). Any thoughts on this? > > I am certainly going to do my best to try to get this feature into JDK10 and > I understand your concern about supporting Java 8 and 9. The decision to > backport this feature will have to be done based on the usual criteria (complexity, > usefulness, resource availability and compatibility). It may be possible to > add some subset of this functionality in a backport but we?ll have to wait until > the design is further along. > >> >> You also mention that this JEP is only about Docker support on >> Linux/x86_64. I'd argue that we should at least address at least all >> Docker supported Linux platforms. I'm pretty sure our colleagues from >> IBM would like to support this on Linux/ppc64 and Linux/s390 as well. > > Right now I don?t expect to have to write CPU specific logic. > Therefore supporting ppc64, s390 or even aarch64 should boil down to testing. > >> >> Moreover, the suggested API and the new JVM_xxxxxx functions should be >> at least designed in such a way that other virtualisation environment >> such as VMWare/VirtualBox/Xen/KVM can take advantage of it. I'm also >> not sure if a completely new API solely for Docker containers is >> making sense and is worth the effort? I understand that containers and >> virtualisation are two different things, but they both impose similar >> restrictions to the VM (i.e. virtualisation may present a huge number >> of CPUs to the OS/VM which in reality are mapped to a single, physical >> CPU) so maybe we should design the new API in such a way that it can >> be used to tackle both problems. > > I will try to keep that in mind. I will have to look into the feasibility of accessing > host configuration from within a container or virtual machine. For containers, > it seems to me that would break the intent of isolation. Did you wanted to say "for virtualisation, it seems to me that would break the intent of isolation." here? So you're right, that you can not easily query the host/guest information in a virtualised environment (like for examples VmWare) because that would break isolation. But as far as I know, every virtualisation solution has it's own library/API which can be used to query the host (if there is any) and get information about the host system and the resources allocated for the guest. We've done some basic virtualisation detection for common systems like VmWare or Xen (cc'ed Matthias who may know more details. > I know that host information > does leak into containers through the proc file system but I suspect this was done > for simplicity and compatibility reasons. > >> >> Finally, you mention in section D. that all the information should be >> logged the to error crash logs. That's good but maybe you could add >> that all the detection and all the findings should also be made >> available through the new Unified JVM Logging facility (JEP 158)? > > That?s a good idea. I will add that to the JEP. > > Thanks, > Bob. > >> >> Regards, >> Volker >> >> >> On Fri, Jul 14, 2017 at 4:22 PM, Bob Vandette wrote: >>> I?d like to propose the following JEP that will enhance the Java runtime to be more container aware. >>> This will allow the Java runtime to performance better ergonomics and provide better >>> execution time statistics when running in a container. >>> >>> >>> JEP Issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8182070 >>> >>> Here?s a Text dump of the JEP contents for your convenience: >>> >>> >>> Summary >>> ------- >>> >>> Container aware Java runtime >>> >>> Goals >>> ----- >>> >>> Enhance the JVM and Core libraries to detect running in a container and adapt to the system resources available to it. This JEP will only support Docker on Linux-x64 although the design should be flexible enough to allow support for other platforms and container technologies. The initial focus will be on Linux low level container technology such as cgroups so that we will be able to easily support other container technologies running on Linux in addition to Docker. >>> >>> Non-Goals >>> --------- >>> >>> It is not a goal of this JEP to support any platform other than Docker container technology running on Linux x64. >>> >>> Success Metrics >>> --------------- >>> >>> Success will be measured by the improved efficiency of running multiple Java containers on a host system with out of the box options. >>> >>> Motivation >>> ---------- >>> >>> Container technology is becoming more and more prevalent in Cloud based applications. This technology provides process isolation and allows the platform vendor to specify limits and alter the behavior of a process running inside a container that the Java runtime is not aware of. This causes the Java runtime to potentially attempt to use more system resources than are available to it causing performance degradation or even termination. >>> >>> >>> Description >>> ----------- >>> >>> This enhancement will be made up of the following work items: >>> >>> A. Detecting if Java is running in a container. >>> >>> The Java runtime, as well as any tests that we might write for this feature, will need to be able to detect that the current Java process is running in a container. I propose that we add a new JVM_ native function that returns a boolean true value if we are running inside a container. >>> >>> JVM_InContainer will return true if the currently running process is running in a container, otherwise false will be returned. >>> >>> B. Exposing container resource limits and configuration. >>> >>> There are several configuration options and limits that can be imposed upon a running container. Not all of these >>> are important to a running Java process. We clearly want to be able to detect how many CPUs have been allocated to our process along with the maximum amount of memory that we be allocated but there are other options that we might want to base runtime decisions on. >>> >>> In addition, since Container typically impose limits on system resources, they also provide the ability to easily access the amount of consumption of these resources. I intent on providing this information in addition to the configuration data. >>> >>> I propose adding a new jdk.internal.Platform class that will allow access to this information. Since some of this information is needed during the startup of the VM, I propose that much of the implementation of the methods in the Platform class be done in the VM and exposed as JVM_xxxxxx functions. In hotspot, the JVM_xxxxxx function will be implemented via the os.hpp interface. >>> >>> Here are the categories of configuration and consumption statistics that will be made available (The exact API is TBD): >>> >>> isContainerized >>> Memory Limit >>> Total Memory Limit >>> Soft Memory Limit >>> Max Memory Usage >>> Current Memory Usage >>> Maximum Kernel Memory >>> CPU Shares >>> CPU Period >>> CPU Quote >>> Number of CPUs >>> CPU Sets >>> CPU Set Memory Nodes >>> CPU Usage >>> CPU Usage Per CPU >>> Block I/O Weight >>> Block I/O Device Weight >>> Device I/O Read Rate >>> Device I/O Write Rate >>> OOM Kill Enabled >>> OOM Score Adjustment >>> Memory Swappiness >>> Shared Memory Size >>> >>> TODO: >>> 1. Need to specify the exact arguments and return format for these accessor functions. >>> >>> C. Adjusting Java runtime configuration based on limits. >>> >>> Java startup normally queries the operating system in order to setup runtime defaults for things such as the number of GC threads and default memory limits. When running in a container, the operating system functions used provide information about the host and does not include the containers configuration and limits. The VM and core libraries will be modified as part of this JEP to first determine if the current running process is running in a container. It will then cause the runtime to use the container values rather than the general operating system functions for configuring and managing the Java process. There have been a few attempts to correct some of these issue in the VM but they are not complete. The CPU detection in the VM currently only handles a container that limits cpu usage via CPU sets. If the Docker --cpu or --cpu-period along with --cpu-quota options are specified, it currently has no effect on the VMs configuration. >>> >>> The experimental memory detection that has been implemented only impacts the Heap selection and does not apply to the os::physical_memory or os::available_memory low level functions. This leaves other parts of the VM and >>> core libraries to believe there is more memory available than there actually is. >>> >>> The Numa support available in the VM is also not correct when running in a container. The number of available memory nodes and enabled nodes as reported by the libnuma library does not take into account the impact of the Docker --cpuset-mems option which restricts which memory nodes the container can use. Inside the container, the file /proc/{pid}/self does report the correct Cpus_allowed and Mems_Allowed but libnuma doesn't respect this. This has been verified via the numactl utility. >>> >>> To correct these shortcomings and make this support more robust, here's a list of the current cgroup subsystems that we be examined in order to update the internal VM and core library configuration. >>> >>> **Number of CPUs** >>> >>> Use a combination of number_of_cpus() and cpu_sets() in order to determine how many processors are available to the process and adjust the JVMs os::active_processor_count appropriately. The number_of_cpus() will be calculated based on the cpu_quota() and cpu_period() using this formula: number_of_cpus() = cpu_quota() / cpu_period(). Since it's not currently possible to understand the relative weight of the running container against all other containers, altering the cpu_shares of a running container will have no affect on altering Java's configuration. >>> >>> **Total available memory** >>> >>> Use the memory_limit() value from the cgroup file system to initialize the os::physical_memory() value in the VM. This value will propagate to all other parts of the Java runtime. >>> >>> We might also consider examining the soft_memory_limit and total_memory_limit in addition to the memory_limit during the ergonomics startup processing in order to fine tuning some of the other VM settings. >>> >>> **CPU Memory Nodes** >>> >>> Use cpu_set_memory_nodes() to configure the os::numa support. >>> >>> **Memory usage** >>> >>> Use memory_usage_in_bytes() for providing os::available_memory() by subtracting the usage from the total available memory allocated to the container. >>> >>> D. Adding container configuration to error crash logs. >>> >>> As as troubleshooting aid, we will dump any available container statistics to the hotspot error log. >>> >>> E. Adding a startup flag to enable/disable this support. >>> >>> Add a -XX:+UseContainerSupport VM option that will be used to enable this support. The default will be off until this feature is proven. >>> >>> Alternatives >>> ------------ >>> >>> There are a few existing RFE's filed that could be used to enhance the current experimental implementation rather than taking the JEP route. >>> >>> Testing >>> ------- >>> >>> Docker/container specific tests should be added in order to validate the functionality being provided with this JEP. >>> >>> Risks and Assumptions >>> --------------------- >>> >>> Docker is currently based on cgroups v1. Cgroups v2 is also available but is incomplete and not yet supported by Docker. It's possible that v2 could replace v1 in an incompatible way rendering this work unusable until it is upgraded. >>> >>> Dependencies >>> ----------- >>> >>> None at this time. >>> > From huizhe.wang at oracle.com Mon Jul 17 20:40:17 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 17 Jul 2017 13:40:17 -0700 Subject: RFR(jdk10/jaxp) 8183519: XMLInputFactory.newFactory() is marked as deprecated Message-ID: <35b75e16-d6c3-9707-39be-2cf1cdd83b1e@oracle.com> Please review the change to remove the incorrectly added @Deprecated annotation. The webrevs are the same as the specification of the CSR (https://bugs.openjdk.java.net/browse/JDK-8183894). JBS: https://bugs.openjdk.java.net/browse/JDK-8183519 webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8183519/webrev/ Thanks, Joe From lance.andersen at oracle.com Mon Jul 17 20:46:19 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 17 Jul 2017 16:46:19 -0400 Subject: RFR(jdk10/jaxp) 8183519: XMLInputFactory.newFactory() is marked as deprecated In-Reply-To: <35b75e16-d6c3-9707-39be-2cf1cdd83b1e@oracle.com> References: <35b75e16-d6c3-9707-39be-2cf1cdd83b1e@oracle.com> Message-ID: <4867FCB9-9ACF-4E42-BB28-88A4A924392B@oracle.com> looks fine joe > On Jul 17, 2017, at 4:40 PM, huizhe wang wrote: > > Please review the change to remove the incorrectly added @Deprecated annotation. The webrevs are the same as the specification of the CSR (https://bugs.openjdk.java.net/browse/JDK-8183894). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8183519 > webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8183519/webrev/ > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Mon Jul 17 21:43:11 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 17 Jul 2017 14:43:11 -0700 Subject: RFR(jdk10/jaxp) 8183519: XMLInputFactory.newFactory() is marked as deprecated In-Reply-To: <4867FCB9-9ACF-4E42-BB28-88A4A924392B@oracle.com> References: <35b75e16-d6c3-9707-39be-2cf1cdd83b1e@oracle.com> <4867FCB9-9ACF-4E42-BB28-88A4A924392B@oracle.com> Message-ID: <7431316e-28bb-ba58-a63c-3a66fa32819d@oracle.com> Thanks Lance! On 7/17/2017 1:46 PM, Lance Andersen wrote: > looks fine joe > >> On Jul 17, 2017, at 4:40 PM, huizhe wang > > wrote: >> >> Please review the change to remove the incorrectly added @Deprecated >> annotation. The webrevs are the same as the specification of the CSR >> (https://bugs.openjdk.java.net/browse/JDK-8183894). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8183519 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8183519/webrev/ >> >> >> Thanks, >> Joe >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From ecki at zusammenkunft.net Mon Jul 17 21:57:39 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 17 Jul 2017 21:57:39 +0000 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: References: , Message-ID: For a virtualized solution you can use the normal methods for getting the number of virtual CPUs or the RAM size (and I am quite sure nobody expects auto tuning based on host resources). JVM already does that. This fails for soft partitioning, especially cgroups, CPU sets (and NUMA Zones). I am not sure how important auto tuning is, but it does make sense to observe soft partitioning limits. None of them are Docker specific, however. Besides the maximum heap it also affects parallelity for GC and the default fork/join pool. Anything else in scope for this JEP? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: core-libs-dev on behalf of Volker Simonis Sent: Monday, July 17, 2017 5:55:53 PM To: Bob Vandette Cc: hotspot-dev Source Developers; core-libs-dev; Baesken, Matthias Subject: Re: JEP [DRAFT]: Container aware Java On Fri, Jul 14, 2017 at 6:54 PM, Bob Vandette wrote: > >> On Jul 14, 2017, at 12:15 PM, Volker Simonis wrote: >> >> Hi Bob, >> >> thanks for starting this JEP. I think it is long overdue and will be >> very helpful for many people. >> > Thanks for taking a look at the JEP. > >> That said, I don't see any mentioning of the targeted Java release. As >> JEPs usually go into the development version first, I suppose the work >> for this JEP will be done in JDK10. However, taking into account the >> current release cycles, the usefulness of this JEP for the Java >> community will significantly depend on the its availability in Java 9 >> (at least) and Java 8 (hopefully?). Any thoughts on this? > > I am certainly going to do my best to try to get this feature into JDK10 and > I understand your concern about supporting Java 8 and 9. The decision to > backport this feature will have to be done based on the usual criteria (complexity, > usefulness, resource availability and compatibility). It may be possible to > add some subset of this functionality in a backport but we?ll have to wait until > the design is further along. > >> >> You also mention that this JEP is only about Docker support on >> Linux/x86_64. I'd argue that we should at least address at least all >> Docker supported Linux platforms. I'm pretty sure our colleagues from >> IBM would like to support this on Linux/ppc64 and Linux/s390 as well. > > Right now I don?t expect to have to write CPU specific logic. > Therefore supporting ppc64, s390 or even aarch64 should boil down to testing. > >> >> Moreover, the suggested API and the new JVM_xxxxxx functions should be >> at least designed in such a way that other virtualisation environment >> such as VMWare/VirtualBox/Xen/KVM can take advantage of it. I'm also >> not sure if a completely new API solely for Docker containers is >> making sense and is worth the effort? I understand that containers and >> virtualisation are two different things, but they both impose similar >> restrictions to the VM (i.e. virtualisation may present a huge number >> of CPUs to the OS/VM which in reality are mapped to a single, physical >> CPU) so maybe we should design the new API in such a way that it can >> be used to tackle both problems. > > I will try to keep that in mind. I will have to look into the feasibility of accessing > host configuration from within a container or virtual machine. For containers, > it seems to me that would break the intent of isolation. Did you wanted to say "for virtualisation, it seems to me that would break the intent of isolation." here? So you're right, that you can not easily query the host/guest information in a virtualised environment (like for examples VmWare) because that would break isolation. But as far as I know, every virtualisation solution has it's own library/API which can be used to query the host (if there is any) and get information about the host system and the resources allocated for the guest. We've done some basic virtualisation detection for common systems like VmWare or Xen (cc'ed Matthias who may know more details. > I know that host information > does leak into containers through the proc file system but I suspect this was done > for simplicity and compatibility reasons. > >> >> Finally, you mention in section D. that all the information should be >> logged the to error crash logs. That's good but maybe you could add >> that all the detection and all the findings should also be made >> available through the new Unified JVM Logging facility (JEP 158)? > > That?s a good idea. I will add that to the JEP. > > Thanks, > Bob. > >> >> Regards, >> Volker >> >> >> On Fri, Jul 14, 2017 at 4:22 PM, Bob Vandette wrote: >>> I?d like to propose the following JEP that will enhance the Java runtime to be more container aware. >>> This will allow the Java runtime to performance better ergonomics and provide better >>> execution time statistics when running in a container. >>> >>> >>> JEP Issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8182070 >>> >>> Here?s a Text dump of the JEP contents for your convenience: >>> >>> >>> Summary >>> ------- >>> >>> Container aware Java runtime >>> >>> Goals >>> ----- >>> >>> Enhance the JVM and Core libraries to detect running in a container and adapt to the system resources available to it. This JEP will only support Docker on Linux-x64 although the design should be flexible enough to allow support for other platforms and container technologies. The initial focus will be on Linux low level container technology such as cgroups so that we will be able to easily support other container technologies running on Linux in addition to Docker. >>> >>> Non-Goals >>> --------- >>> >>> It is not a goal of this JEP to support any platform other than Docker container technology running on Linux x64. >>> >>> Success Metrics >>> --------------- >>> >>> Success will be measured by the improved efficiency of running multiple Java containers on a host system with out of the box options. >>> >>> Motivation >>> ---------- >>> >>> Container technology is becoming more and more prevalent in Cloud based applications. This technology provides process isolation and allows the platform vendor to specify limits and alter the behavior of a process running inside a container that the Java runtime is not aware of. This causes the Java runtime to potentially attempt to use more system resources than are available to it causing performance degradation or even termination. >>> >>> >>> Description >>> ----------- >>> >>> This enhancement will be made up of the following work items: >>> >>> A. Detecting if Java is running in a container. >>> >>> The Java runtime, as well as any tests that we might write for this feature, will need to be able to detect that the current Java process is running in a container. I propose that we add a new JVM_ native function that returns a boolean true value if we are running inside a container. >>> >>> JVM_InContainer will return true if the currently running process is running in a container, otherwise false will be returned. >>> >>> B. Exposing container resource limits and configuration. >>> >>> There are several configuration options and limits that can be imposed upon a running container. Not all of these >>> are important to a running Java process. We clearly want to be able to detect how many CPUs have been allocated to our process along with the maximum amount of memory that we be allocated but there are other options that we might want to base runtime decisions on. >>> >>> In addition, since Container typically impose limits on system resources, they also provide the ability to easily access the amount of consumption of these resources. I intent on providing this information in addition to the configuration data. >>> >>> I propose adding a new jdk.internal.Platform class that will allow access to this information. Since some of this information is needed during the startup of the VM, I propose that much of the implementation of the methods in the Platform class be done in the VM and exposed as JVM_xxxxxx functions. In hotspot, the JVM_xxxxxx function will be implemented via the os.hpp interface. >>> >>> Here are the categories of configuration and consumption statistics that will be made available (The exact API is TBD): >>> >>> isContainerized >>> Memory Limit >>> Total Memory Limit >>> Soft Memory Limit >>> Max Memory Usage >>> Current Memory Usage >>> Maximum Kernel Memory >>> CPU Shares >>> CPU Period >>> CPU Quote >>> Number of CPUs >>> CPU Sets >>> CPU Set Memory Nodes >>> CPU Usage >>> CPU Usage Per CPU >>> Block I/O Weight >>> Block I/O Device Weight >>> Device I/O Read Rate >>> Device I/O Write Rate >>> OOM Kill Enabled >>> OOM Score Adjustment >>> Memory Swappiness >>> Shared Memory Size >>> >>> TODO: >>> 1. Need to specify the exact arguments and return format for these accessor functions. >>> >>> C. Adjusting Java runtime configuration based on limits. >>> >>> Java startup normally queries the operating system in order to setup runtime defaults for things such as the number of GC threads and default memory limits. When running in a container, the operating system functions used provide information about the host and does not include the containers configuration and limits. The VM and core libraries will be modified as part of this JEP to first determine if the current running process is running in a container. It will then cause the runtime to use the container values rather than the general operating system functions for configuring and managing the Java process. There have been a few attempts to correct some of these issue in the VM but they are not complete. The CPU detection in the VM currently only handles a container that limits cpu usage via CPU sets. If the Docker --cpu or --cpu-period along with --cpu-quota options are specified, it currently has no effect on the VMs configuration. >>> >>> The experimental memory detection that has been implemented only impacts the Heap selection and does not apply to the os::physical_memory or os::available_memory low level functions. This leaves other parts of the VM and >>> core libraries to believe there is more memory available than there actually is. >>> >>> The Numa support available in the VM is also not correct when running in a container. The number of available memory nodes and enabled nodes as reported by the libnuma library does not take into account the impact of the Docker --cpuset-mems option which restricts which memory nodes the container can use. Inside the container, the file /proc/{pid}/self does report the correct Cpus_allowed and Mems_Allowed but libnuma doesn't respect this. This has been verified via the numactl utility. >>> >>> To correct these shortcomings and make this support more robust, here's a list of the current cgroup subsystems that we be examined in order to update the internal VM and core library configuration. >>> >>> **Number of CPUs** >>> >>> Use a combination of number_of_cpus() and cpu_sets() in order to determine how many processors are available to the process and adjust the JVMs os::active_processor_count appropriately. The number_of_cpus() will be calculated based on the cpu_quota() and cpu_period() using this formula: number_of_cpus() = cpu_quota() / cpu_period(). Since it's not currently possible to understand the relative weight of the running container against all other containers, altering the cpu_shares of a running container will have no affect on altering Java's configuration. >>> >>> **Total available memory** >>> >>> Use the memory_limit() value from the cgroup file system to initialize the os::physical_memory() value in the VM. This value will propagate to all other parts of the Java runtime. >>> >>> We might also consider examining the soft_memory_limit and total_memory_limit in addition to the memory_limit during the ergonomics startup processing in order to fine tuning some of the other VM settings. >>> >>> **CPU Memory Nodes** >>> >>> Use cpu_set_memory_nodes() to configure the os::numa support. >>> >>> **Memory usage** >>> >>> Use memory_usage_in_bytes() for providing os::available_memory() by subtracting the usage from the total available memory allocated to the container. >>> >>> D. Adding container configuration to error crash logs. >>> >>> As as troubleshooting aid, we will dump any available container statistics to the hotspot error log. >>> >>> E. Adding a startup flag to enable/disable this support. >>> >>> Add a -XX:+UseContainerSupport VM option that will be used to enable this support. The default will be off until this feature is proven. >>> >>> Alternatives >>> ------------ >>> >>> There are a few existing RFE's filed that could be used to enhance the current experimental implementation rather than taking the JEP route. >>> >>> Testing >>> ------- >>> >>> Docker/container specific tests should be added in order to validate the functionality being provided with this JEP. >>> >>> Risks and Assumptions >>> --------------------- >>> >>> Docker is currently based on cgroups v1. Cgroups v2 is also available but is incomplete and not yet supported by Docker. It's possible that v2 could replace v1 in an incompatible way rendering this work unusable until it is upgraded. >>> >>> Dependencies >>> ----------- >>> >>> None at this time. >>> > From andrey.x.nazarov at oracle.com Mon Jul 17 23:51:37 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Mon, 17 Jul 2017 16:51:37 -0700 Subject: RFR 8177357: tools/jar/multiRelease/ApiValidatorTest.java failed due to "Exception java.nio.file.DirectoryNotEmptyException" Message-ID: Hi, Could you review simple test fix? http://cr.openjdk.java.net/~anazarov/JDK-8177357/webrev.00/webrev JBS: https://bugs.openjdk.java.net/browse/JDK-8177357 ?Thanks, Andrei From bob.vandette at oracle.com Tue Jul 18 13:43:24 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 18 Jul 2017 09:43:24 -0400 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: References: Message-ID: > On Jul 17, 2017, at 11:55 AM, Volker Simonis wrote: > > On Fri, Jul 14, 2017 at 6:54 PM, Bob Vandette wrote: >> >>> On Jul 14, 2017, at 12:15 PM, Volker Simonis wrote: >>> >>> Hi Bob, >>> >>> thanks for starting this JEP. I think it is long overdue and will be >>> very helpful for many people. >>> >> Thanks for taking a look at the JEP. >> >>> That said, I don't see any mentioning of the targeted Java release. As >>> JEPs usually go into the development version first, I suppose the work >>> for this JEP will be done in JDK10. However, taking into account the >>> current release cycles, the usefulness of this JEP for the Java >>> community will significantly depend on the its availability in Java 9 >>> (at least) and Java 8 (hopefully?). Any thoughts on this? >> >> I am certainly going to do my best to try to get this feature into JDK10 and >> I understand your concern about supporting Java 8 and 9. The decision to >> backport this feature will have to be done based on the usual criteria (complexity, >> usefulness, resource availability and compatibility). It may be possible to >> add some subset of this functionality in a backport but we?ll have to wait until >> the design is further along. >> >>> >>> You also mention that this JEP is only about Docker support on >>> Linux/x86_64. I'd argue that we should at least address at least all >>> Docker supported Linux platforms. I'm pretty sure our colleagues from >>> IBM would like to support this on Linux/ppc64 and Linux/s390 as well. >> >> Right now I don?t expect to have to write CPU specific logic. >> Therefore supporting ppc64, s390 or even aarch64 should boil down to testing. >> >>> >>> Moreover, the suggested API and the new JVM_xxxxxx functions should be >>> at least designed in such a way that other virtualisation environment >>> such as VMWare/VirtualBox/Xen/KVM can take advantage of it. I'm also >>> not sure if a completely new API solely for Docker containers is >>> making sense and is worth the effort? I understand that containers and >>> virtualisation are two different things, but they both impose similar >>> restrictions to the VM (i.e. virtualisation may present a huge number >>> of CPUs to the OS/VM which in reality are mapped to a single, physical >>> CPU) so maybe we should design the new API in such a way that it can >>> be used to tackle both problems. >> >> I will try to keep that in mind. I will have to look into the feasibility of accessing >> host configuration from within a container or virtual machine. For containers, >> it seems to me that would break the intent of isolation. > > Did you wanted to say "for virtualisation, it seems to me that would > break the intent of isolation." here? Well the comment applies to both technologies but cgroups/containers were specifically designed to isolate or limit processes from accessing host resources. > > So you're right, that you can not easily query the host/guest > information in a virtualised environment (like for examples VmWare) > because that would break isolation. But as far as I know, every > virtualisation solution has it's own library/API which can be used to > query the host (if there is any) and get information about the host > system and the resources allocated for the guest. We've done some > basic virtualisation detection for common systems like VmWare or Xen > (cc'ed Matthias who may know more details. If you can point me at some API docs, I?d appreciate it. Bob. > >> I know that host information >> does leak into containers through the proc file system but I suspect this was done >> for simplicity and compatibility reasons. >> >>> >>> Finally, you mention in section D. that all the information should be >>> logged the to error crash logs. That's good but maybe you could add >>> that all the detection and all the findings should also be made >>> available through the new Unified JVM Logging facility (JEP 158)? >> >> That?s a good idea. I will add that to the JEP. >> >> Thanks, >> Bob. >> >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Jul 14, 2017 at 4:22 PM, Bob Vandette wrote: >>>> I?d like to propose the following JEP that will enhance the Java runtime to be more container aware. >>>> This will allow the Java runtime to performance better ergonomics and provide better >>>> execution time statistics when running in a container. >>>> >>>> >>>> JEP Issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8182070 >>>> >>>> Here?s a Text dump of the JEP contents for your convenience: >>>> >>>> >>>> Summary >>>> ------- >>>> >>>> Container aware Java runtime >>>> >>>> Goals >>>> ----- >>>> >>>> Enhance the JVM and Core libraries to detect running in a container and adapt to the system resources available to it. This JEP will only support Docker on Linux-x64 although the design should be flexible enough to allow support for other platforms and container technologies. The initial focus will be on Linux low level container technology such as cgroups so that we will be able to easily support other container technologies running on Linux in addition to Docker. >>>> >>>> Non-Goals >>>> --------- >>>> >>>> It is not a goal of this JEP to support any platform other than Docker container technology running on Linux x64. >>>> >>>> Success Metrics >>>> --------------- >>>> >>>> Success will be measured by the improved efficiency of running multiple Java containers on a host system with out of the box options. >>>> >>>> Motivation >>>> ---------- >>>> >>>> Container technology is becoming more and more prevalent in Cloud based applications. This technology provides process isolation and allows the platform vendor to specify limits and alter the behavior of a process running inside a container that the Java runtime is not aware of. This causes the Java runtime to potentially attempt to use more system resources than are available to it causing performance degradation or even termination. >>>> >>>> >>>> Description >>>> ----------- >>>> >>>> This enhancement will be made up of the following work items: >>>> >>>> A. Detecting if Java is running in a container. >>>> >>>> The Java runtime, as well as any tests that we might write for this feature, will need to be able to detect that the current Java process is running in a container. I propose that we add a new JVM_ native function that returns a boolean true value if we are running inside a container. >>>> >>>> JVM_InContainer will return true if the currently running process is running in a container, otherwise false will be returned. >>>> >>>> B. Exposing container resource limits and configuration. >>>> >>>> There are several configuration options and limits that can be imposed upon a running container. Not all of these >>>> are important to a running Java process. We clearly want to be able to detect how many CPUs have been allocated to our process along with the maximum amount of memory that we be allocated but there are other options that we might want to base runtime decisions on. >>>> >>>> In addition, since Container typically impose limits on system resources, they also provide the ability to easily access the amount of consumption of these resources. I intent on providing this information in addition to the configuration data. >>>> >>>> I propose adding a new jdk.internal.Platform class that will allow access to this information. Since some of this information is needed during the startup of the VM, I propose that much of the implementation of the methods in the Platform class be done in the VM and exposed as JVM_xxxxxx functions. In hotspot, the JVM_xxxxxx function will be implemented via the os.hpp interface. >>>> >>>> Here are the categories of configuration and consumption statistics that will be made available (The exact API is TBD): >>>> >>>> isContainerized >>>> Memory Limit >>>> Total Memory Limit >>>> Soft Memory Limit >>>> Max Memory Usage >>>> Current Memory Usage >>>> Maximum Kernel Memory >>>> CPU Shares >>>> CPU Period >>>> CPU Quote >>>> Number of CPUs >>>> CPU Sets >>>> CPU Set Memory Nodes >>>> CPU Usage >>>> CPU Usage Per CPU >>>> Block I/O Weight >>>> Block I/O Device Weight >>>> Device I/O Read Rate >>>> Device I/O Write Rate >>>> OOM Kill Enabled >>>> OOM Score Adjustment >>>> Memory Swappiness >>>> Shared Memory Size >>>> >>>> TODO: >>>> 1. Need to specify the exact arguments and return format for these accessor functions. >>>> >>>> C. Adjusting Java runtime configuration based on limits. >>>> >>>> Java startup normally queries the operating system in order to setup runtime defaults for things such as the number of GC threads and default memory limits. When running in a container, the operating system functions used provide information about the host and does not include the containers configuration and limits. The VM and core libraries will be modified as part of this JEP to first determine if the current running process is running in a container. It will then cause the runtime to use the container values rather than the general operating system functions for configuring and managing the Java process. There have been a few attempts to correct some of these issue in the VM but they are not complete. The CPU detection in the VM currently only handles a container that limits cpu usage via CPU sets. If the Docker --cpu or --cpu-period along with --cpu-quota options are specified, it currently has no effect on the VMs configuration. >>>> >>>> The experimental memory detection that has been implemented only impacts the Heap selection and does not apply to the os::physical_memory or os::available_memory low level functions. This leaves other parts of the VM and >>>> core libraries to believe there is more memory available than there actually is. >>>> >>>> The Numa support available in the VM is also not correct when running in a container. The number of available memory nodes and enabled nodes as reported by the libnuma library does not take into account the impact of the Docker --cpuset-mems option which restricts which memory nodes the container can use. Inside the container, the file /proc/{pid}/self does report the correct Cpus_allowed and Mems_Allowed but libnuma doesn't respect this. This has been verified via the numactl utility. >>>> >>>> To correct these shortcomings and make this support more robust, here's a list of the current cgroup subsystems that we be examined in order to update the internal VM and core library configuration. >>>> >>>> **Number of CPUs** >>>> >>>> Use a combination of number_of_cpus() and cpu_sets() in order to determine how many processors are available to the process and adjust the JVMs os::active_processor_count appropriately. The number_of_cpus() will be calculated based on the cpu_quota() and cpu_period() using this formula: number_of_cpus() = cpu_quota() / cpu_period(). Since it's not currently possible to understand the relative weight of the running container against all other containers, altering the cpu_shares of a running container will have no affect on altering Java's configuration. >>>> >>>> **Total available memory** >>>> >>>> Use the memory_limit() value from the cgroup file system to initialize the os::physical_memory() value in the VM. This value will propagate to all other parts of the Java runtime. >>>> >>>> We might also consider examining the soft_memory_limit and total_memory_limit in addition to the memory_limit during the ergonomics startup processing in order to fine tuning some of the other VM settings. >>>> >>>> **CPU Memory Nodes** >>>> >>>> Use cpu_set_memory_nodes() to configure the os::numa support. >>>> >>>> **Memory usage** >>>> >>>> Use memory_usage_in_bytes() for providing os::available_memory() by subtracting the usage from the total available memory allocated to the container. >>>> >>>> D. Adding container configuration to error crash logs. >>>> >>>> As as troubleshooting aid, we will dump any available container statistics to the hotspot error log. >>>> >>>> E. Adding a startup flag to enable/disable this support. >>>> >>>> Add a -XX:+UseContainerSupport VM option that will be used to enable this support. The default will be off until this feature is proven. >>>> >>>> Alternatives >>>> ------------ >>>> >>>> There are a few existing RFE's filed that could be used to enhance the current experimental implementation rather than taking the JEP route. >>>> >>>> Testing >>>> ------- >>>> >>>> Docker/container specific tests should be added in order to validate the functionality being provided with this JEP. >>>> >>>> Risks and Assumptions >>>> --------------------- >>>> >>>> Docker is currently based on cgroups v1. Cgroups v2 is also available but is incomplete and not yet supported by Docker. It's possible that v2 could replace v1 in an incompatible way rendering this work unusable until it is upgraded. >>>> >>>> Dependencies >>>> ----------- >>>> >>>> None at this time. >>>> >> From matthias.baesken at sap.com Tue Jul 18 14:11:27 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Jul 2017 14:11:27 +0000 Subject: JEP [DRAFT]: Container aware Java In-Reply-To: References: Message-ID: Hi Bob, VMWare has the option to install additional tools, in case they are installed you get a number of metrics from the guests. Some info can be found here : https://www.vmware.com/support/developer/guest-sdk/ Running in the guests you would load libvmGuestLib.so / vmGuestLib.dll and then you have access to a number of functions for querying metrics. Of course it is all optional , when you run in a guest without the additional tools/ guestlib installed , you get nothing (or not much at least ). For AIX / IBM PowerVM Virtualization there is something similar available via the perfstat API. https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.prftools/idprftools_perfstat.htm ( libperfstat.a is the related library ) Best regards, Matthias -----Original Message----- From: Bob Vandette [mailto:bob.vandette at oracle.com] Sent: Dienstag, 18. Juli 2017 15:43 To: Volker Simonis Cc: hotspot-dev Source Developers ; core-libs-dev ; Baesken, Matthias Subject: Re: JEP [DRAFT]: Container aware Java > On Jul 17, 2017, at 11:55 AM, Volker Simonis wrote: > > On Fri, Jul 14, 2017 at 6:54 PM, Bob Vandette wrote: >> >>> On Jul 14, 2017, at 12:15 PM, Volker Simonis wrote: >>> >>> Hi Bob, >>> >>> thanks for starting this JEP. I think it is long overdue and will be >>> very helpful for many people. >>> >> Thanks for taking a look at the JEP. >> >>> That said, I don't see any mentioning of the targeted Java release. As >>> JEPs usually go into the development version first, I suppose the work >>> for this JEP will be done in JDK10. However, taking into account the >>> current release cycles, the usefulness of this JEP for the Java >>> community will significantly depend on the its availability in Java 9 >>> (at least) and Java 8 (hopefully?). Any thoughts on this? >> >> I am certainly going to do my best to try to get this feature into JDK10 and >> I understand your concern about supporting Java 8 and 9. The decision to >> backport this feature will have to be done based on the usual criteria (complexity, >> usefulness, resource availability and compatibility). It may be possible to >> add some subset of this functionality in a backport but we?ll have to wait until >> the design is further along. >> >>> >>> You also mention that this JEP is only about Docker support on >>> Linux/x86_64. I'd argue that we should at least address at least all >>> Docker supported Linux platforms. I'm pretty sure our colleagues from >>> IBM would like to support this on Linux/ppc64 and Linux/s390 as well. >> >> Right now I don?t expect to have to write CPU specific logic. >> Therefore supporting ppc64, s390 or even aarch64 should boil down to testing. >> >>> >>> Moreover, the suggested API and the new JVM_xxxxxx functions should be >>> at least designed in such a way that other virtualisation environment >>> such as VMWare/VirtualBox/Xen/KVM can take advantage of it. I'm also >>> not sure if a completely new API solely for Docker containers is >>> making sense and is worth the effort? I understand that containers and >>> virtualisation are two different things, but they both impose similar >>> restrictions to the VM (i.e. virtualisation may present a huge number >>> of CPUs to the OS/VM which in reality are mapped to a single, physical >>> CPU) so maybe we should design the new API in such a way that it can >>> be used to tackle both problems. >> >> I will try to keep that in mind. I will have to look into the feasibility of accessing >> host configuration from within a container or virtual machine. For containers, >> it seems to me that would break the intent of isolation. > > Did you wanted to say "for virtualisation, it seems to me that would > break the intent of isolation." here? Well the comment applies to both technologies but cgroups/containers were specifically designed to isolate or limit processes from accessing host resources. > > So you're right, that you can not easily query the host/guest > information in a virtualised environment (like for examples VmWare) > because that would break isolation. But as far as I know, every > virtualisation solution has it's own library/API which can be used to > query the host (if there is any) and get information about the host > system and the resources allocated for the guest. We've done some > basic virtualisation detection for common systems like VmWare or Xen > (cc'ed Matthias who may know more details. If you can point me at some API docs, I?d appreciate it. Bob. > >> I know that host information >> does leak into containers through the proc file system but I suspect this was done >> for simplicity and compatibility reasons. >> >>> >>> Finally, you mention in section D. that all the information should be >>> logged the to error crash logs. That's good but maybe you could add >>> that all the detection and all the findings should also be made >>> available through the new Unified JVM Logging facility (JEP 158)? >> >> That?s a good idea. I will add that to the JEP. >> >> Thanks, >> Bob. >> >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Jul 14, 2017 at 4:22 PM, Bob Vandette wrote: >>>> I?d like to propose the following JEP that will enhance the Java runtime to be more container aware. >>>> This will allow the Java runtime to performance better ergonomics and provide better >>>> execution time statistics when running in a container. >>>> >>>> >>>> JEP Issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8182070 >>>> >>>> Here?s a Text dump of the JEP contents for your convenience: >>>> >>>> >>>> Summary >>>> ------- >>>> >>>> Container aware Java runtime >>>> >>>> Goals >>>> ----- >>>> >>>> Enhance the JVM and Core libraries to detect running in a container and adapt to the system resources available to it. This JEP will only support Docker on Linux-x64 although the design should be flexible enough to allow support for other platforms and container technologies. The initial focus will be on Linux low level container technology such as cgroups so that we will be able to easily support other container technologies running on Linux in addition to Docker. >>>> >>>> Non-Goals >>>> --------- >>>> >>>> It is not a goal of this JEP to support any platform other than Docker container technology running on Linux x64. >>>> >>>> Success Metrics >>>> --------------- >>>> >>>> Success will be measured by the improved efficiency of running multiple Java containers on a host system with out of the box options. >>>> >>>> Motivation >>>> ---------- >>>> >>>> Container technology is becoming more and more prevalent in Cloud based applications. This technology provides process isolation and allows the platform vendor to specify limits and alter the behavior of a process running inside a container that the Java runtime is not aware of. This causes the Java runtime to potentially attempt to use more system resources than are available to it causing performance degradation or even termination. >>>> >>>> >>>> Description >>>> ----------- >>>> >>>> This enhancement will be made up of the following work items: >>>> >>>> A. Detecting if Java is running in a container. >>>> >>>> The Java runtime, as well as any tests that we might write for this feature, will need to be able to detect that the current Java process is running in a container. I propose that we add a new JVM_ native function that returns a boolean true value if we are running inside a container. >>>> >>>> JVM_InContainer will return true if the currently running process is running in a container, otherwise false will be returned. >>>> >>>> B. Exposing container resource limits and configuration. >>>> >>>> There are several configuration options and limits that can be imposed upon a running container. Not all of these >>>> are important to a running Java process. We clearly want to be able to detect how many CPUs have been allocated to our process along with the maximum amount of memory that we be allocated but there are other options that we might want to base runtime decisions on. >>>> >>>> In addition, since Container typically impose limits on system resources, they also provide the ability to easily access the amount of consumption of these resources. I intent on providing this information in addition to the configuration data. >>>> >>>> I propose adding a new jdk.internal.Platform class that will allow access to this information. Since some of this information is needed during the startup of the VM, I propose that much of the implementation of the methods in the Platform class be done in the VM and exposed as JVM_xxxxxx functions. In hotspot, the JVM_xxxxxx function will be implemented via the os.hpp interface. >>>> >>>> Here are the categories of configuration and consumption statistics that will be made available (The exact API is TBD): >>>> >>>> isContainerized >>>> Memory Limit >>>> Total Memory Limit >>>> Soft Memory Limit >>>> Max Memory Usage >>>> Current Memory Usage >>>> Maximum Kernel Memory >>>> CPU Shares >>>> CPU Period >>>> CPU Quote >>>> Number of CPUs >>>> CPU Sets >>>> CPU Set Memory Nodes >>>> CPU Usage >>>> CPU Usage Per CPU >>>> Block I/O Weight >>>> Block I/O Device Weight >>>> Device I/O Read Rate >>>> Device I/O Write Rate >>>> OOM Kill Enabled >>>> OOM Score Adjustment >>>> Memory Swappiness >>>> Shared Memory Size >>>> >>>> TODO: >>>> 1. Need to specify the exact arguments and return format for these accessor functions. >>>> >>>> C. Adjusting Java runtime configuration based on limits. >>>> >>>> Java startup normally queries the operating system in order to setup runtime defaults for things such as the number of GC threads and default memory limits. When running in a container, the operating system functions used provide information about the host and does not include the containers configuration and limits. The VM and core libraries will be modified as part of this JEP to first determine if the current running process is running in a container. It will then cause the runtime to use the container values rather than the general operating system functions for configuring and managing the Java process. There have been a few attempts to correct some of these issue in the VM but they are not complete. The CPU detection in the VM currently only handles a container that limits cpu usage via CPU sets. If the Docker --cpu or --cpu-period along with --cpu-quota options are specified, it currently has no effect on the VMs configuration. >>>> >>>> The experimental memory detection that has been implemented only impacts the Heap selection and does not apply to the os::physical_memory or os::available_memory low level functions. This leaves other parts of the VM and >>>> core libraries to believe there is more memory available than there actually is. >>>> >>>> The Numa support available in the VM is also not correct when running in a container. The number of available memory nodes and enabled nodes as reported by the libnuma library does not take into account the impact of the Docker --cpuset-mems option which restricts which memory nodes the container can use. Inside the container, the file /proc/{pid}/self does report the correct Cpus_allowed and Mems_Allowed but libnuma doesn't respect this. This has been verified via the numactl utility. >>>> >>>> To correct these shortcomings and make this support more robust, here's a list of the current cgroup subsystems that we be examined in order to update the internal VM and core library configuration. >>>> >>>> **Number of CPUs** >>>> >>>> Use a combination of number_of_cpus() and cpu_sets() in order to determine how many processors are available to the process and adjust the JVMs os::active_processor_count appropriately. The number_of_cpus() will be calculated based on the cpu_quota() and cpu_period() using this formula: number_of_cpus() = cpu_quota() / cpu_period(). Since it's not currently possible to understand the relative weight of the running container against all other containers, altering the cpu_shares of a running container will have no affect on altering Java's configuration. >>>> >>>> **Total available memory** >>>> >>>> Use the memory_limit() value from the cgroup file system to initialize the os::physical_memory() value in the VM. This value will propagate to all other parts of the Java runtime. >>>> >>>> We might also consider examining the soft_memory_limit and total_memory_limit in addition to the memory_limit during the ergonomics startup processing in order to fine tuning some of the other VM settings. >>>> >>>> **CPU Memory Nodes** >>>> >>>> Use cpu_set_memory_nodes() to configure the os::numa support. >>>> >>>> **Memory usage** >>>> >>>> Use memory_usage_in_bytes() for providing os::available_memory() by subtracting the usage from the total available memory allocated to the container. >>>> >>>> D. Adding container configuration to error crash logs. >>>> >>>> As as troubleshooting aid, we will dump any available container statistics to the hotspot error log. >>>> >>>> E. Adding a startup flag to enable/disable this support. >>>> >>>> Add a -XX:+UseContainerSupport VM option that will be used to enable this support. The default will be off until this feature is proven. >>>> >>>> Alternatives >>>> ------------ >>>> >>>> There are a few existing RFE's filed that could be used to enhance the current experimental implementation rather than taking the JEP route. >>>> >>>> Testing >>>> ------- >>>> >>>> Docker/container specific tests should be added in order to validate the functionality being provided with this JEP. >>>> >>>> Risks and Assumptions >>>> --------------------- >>>> >>>> Docker is currently based on cgroups v1. Cgroups v2 is also available but is incomplete and not yet supported by Docker. It's possible that v2 could replace v1 in an incompatible way rendering this work unusable until it is upgraded. >>>> >>>> Dependencies >>>> ----------- >>>> >>>> None at this time. >>>> >> From claes.redestad at oracle.com Tue Jul 18 14:16:48 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 18 Jul 2017 16:16:48 +0200 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: <5969027D.8040400@oracle.com> References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> <5969027D.8040400@oracle.com> Message-ID: Hi Sherman, On 07/14/2017 07:42 PM, Xueming Shen wrote: > Hi Claes, > > The change looks fine. > > The only concern is that, in theory, it appears we no longer have any > "check" > to guarantee that all "alias" names defined for these 3 charsets > indeed follow > the spec? The consequence of this is that someone can obtain the alias > name > from the specific "charset", and then that name will fail for > Charset.forName(). > > I doubt we currently have a regression test to catch this. > > The possibility that we are going to add a new alias for these 3 is > low, but either > a regress test (if we don't have one already) or a comment at > > jdk/make/data/charsetmapping/charsets > > (for each of the def, to remind a possible change) might help to > prevent this > from happening? added regression sanity test, and reverted to use identity checks as discussed elsewhere (if we are to clean this up to use equals everywhere, better do it consistently throughout the code and ensure this works as expected with no performance loss): http://cr.openjdk.java.net/~redestad/8184665/jdk.02/ > -Sherman > > PS: The next step is to remove these 3 from the > sun.nio.cs.StandardCharsets? :-) The static initializer for sun.nio.cs.StandardCharsets is loading a bunch of Strings into the string table but only executes around 1.5k bytecode, so splitting these always-loaded Charsets out might be a small footprint gain, but a very tiny startup win at best. /Claes From xueming.shen at oracle.com Tue Jul 18 14:59:34 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 18 Jul 2017 07:59:34 -0700 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> <5969027D.8040400@oracle.com> Message-ID: <596E2256.5010707@oracle.com> +1 * the test needs a bugid before pushing. On 7/18/17, 7:16 AM, Claes Redestad wrote: > Hi Sherman, > > On 07/14/2017 07:42 PM, Xueming Shen wrote: >> Hi Claes, >> >> The change looks fine. >> >> The only concern is that, in theory, it appears we no longer have any >> "check" >> to guarantee that all "alias" names defined for these 3 charsets >> indeed follow >> the spec? The consequence of this is that someone can obtain the >> alias name >> from the specific "charset", and then that name will fail for >> Charset.forName(). >> >> I doubt we currently have a regression test to catch this. >> >> The possibility that we are going to add a new alias for these 3 is >> low, but either >> a regress test (if we don't have one already) or a comment at >> >> jdk/make/data/charsetmapping/charsets >> >> (for each of the def, to remind a possible change) might help to >> prevent this >> from happening? > > added regression sanity test, and reverted to use identity checks as > discussed > elsewhere (if we are to clean this up to use equals everywhere, > better do it consistently throughout the code and ensure this works as > expected with no performance loss): > > http://cr.openjdk.java.net/~redestad/8184665/jdk.02/ > >> -Sherman >> >> PS: The next step is to remove these 3 from the >> sun.nio.cs.StandardCharsets? :-) > > The static initializer for sun.nio.cs.StandardCharsets is loading a > bunch of Strings > into the string table but only executes around 1.5k bytecode, so > splitting these > always-loaded Charsets out might be a small footprint gain, but a very > tiny startup > win at best. > > /Claes From claes.redestad at oracle.com Tue Jul 18 15:04:25 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 18 Jul 2017 17:04:25 +0200 Subject: [10] RFR: 8184665: Skip name and alias checks for standard Charsets In-Reply-To: <596E2256.5010707@oracle.com> References: <5ee3e214-5a88-d212-7fc8-39bd596f75cc@oracle.com> <5969027D.8040400@oracle.com> <596E2256.5010707@oracle.com> Message-ID: On 07/18/2017 04:59 PM, Xueming Shen wrote: > +1 Thanks! > > * the test needs a bugid before pushing. Will do. /Claes From martinrb at google.com Tue Jul 18 16:35:37 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 18 Jul 2017 09:35:37 -0700 Subject: RFR: jsr166 jdk10 integration wave 1 In-Reply-To: References: Message-ID: After a long delay, we are finally ready to try again to get in jsr166 jdk10 integration wave 1. The set of changes has grown a lot over the past few months (too much?), and contains the usual hard-to-review tck test improvements. Our infrastructure for generating these commits has changed a lot as well, but reviewers should see little difference. We now run errorprone over the jsr166 sources occasionally ("ant errorprone"). This set of commits contains the first annotations to suppress errorprone warnings, e.g. + @SuppressWarnings("FutureReturnValueIgnored") http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ On Mon, Apr 10, 2017 at 2:19 PM, Martin Buchholz wrote: > Non-thread-pool changes committed while we wait for thread-pool CCC. > > From paul.sandoz at oracle.com Tue Jul 18 18:38:17 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 18 Jul 2017 11:38:17 -0700 Subject: RFR 8177357: tools/jar/multiRelease/ApiValidatorTest.java failed due to "Exception java.nio.file.DirectoryNotEmptyException" In-Reply-To: References: Message-ID: <9FC3684E-3506-4AED-B506-C8AF2ABABB41@oracle.com> > On 17 Jul 2017, at 16:51, Andrey Nazarov wrote: > > Hi, > > Could you review simple test fix? > > http://cr.openjdk.java.net/~anazarov/JDK-8177357/webrev.00/webrev > > JBS: https://bugs.openjdk.java.net/browse/JDK-8177357 > Looks ok. (It bothers me that deletion of a directory is so fragile.) Paul. From Roger.Riggs at Oracle.com Tue Jul 18 18:46:38 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 18 Jul 2017 14:46:38 -0400 Subject: RFR 10: 8184808 (process) isAlive should use pid for validity, not /proc/pid Message-ID: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> Please review a fix for an intermittent failure in the ProcessHandle OnExitTest that fails frequently on Solaris. ProcessHandle.isAlive is using /proc/pid/psinfo to determine if a process is alive and it's start time. However, it appears that the between the process exiting and the reaping of its status, the psinfo file indicates the process is alive but kill(pid, 0) reports that is is not alive. Depending on a race, the ProcessHandler.onExit may determine the process has exited but later isAlive may report it is alive. To have a consistent view of the process being alive, ProcessHandle.isAlive in its native implementation should use kill(pid, 0) to determine if the process is definitively determine if the process alive. The original issue[1] will be kept open until it is known that it is resolved. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-alive-solaris-8184808/ Issue: https://bugs.openjdk.java.net/browse/JDK-8184808 Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8177932 From thomas.stuefe at gmail.com Tue Jul 18 18:53:22 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 18 Jul 2017 20:53:22 +0200 Subject: RFR 10: 8184808 (process) isAlive should use pid for validity, not /proc/pid In-Reply-To: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> References: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> Message-ID: Hi Roger, I think this may fail if you have no permission to send a signal to that process. In that case, kill(2) may yield EPERM and isAlive may return false even though the process is alive. But then, I am not sure if that could happen in that particular scenario, plus it may also mean that you do not have access to /proc/pid either. So, I do not know how much of an issue this could be. Otherwise, the fix seems straightforward. Kind Regards, Thomas On Tue, Jul 18, 2017 at 8:46 PM, Roger Riggs wrote: > Please review a fix for an intermittent failure in the ProcessHandle > OnExitTest > that fails frequently on Solaris. > > ProcessHandle.isAlive is using /proc/pid/psinfo to determine if a process > is alive and it's start time. > However, it appears that the between the process exiting and the reaping > of its status, the > psinfo file indicates the process is alive but kill(pid, 0) reports that > is is not alive. > Depending on a race, the ProcessHandler.onExit may determine the process > has exited > but later isAlive may report it is alive. > > To have a consistent view of the process being alive, > ProcessHandle.isAlive in its native implementation > should use kill(pid, 0) to determine if the process is definitively > determine if the process alive. > > The original issue[1] will be kept open until it is known that it is > resolved. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-alive-solaris-8184808/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8184808 > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8177932 > > > From Roger.Riggs at Oracle.com Tue Jul 18 19:01:13 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 18 Jul 2017 15:01:13 -0400 Subject: RFR 10: 8184808 (process) isAlive should use pid for validity, not /proc/pid In-Reply-To: References: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> Message-ID: <64a1cabc-589a-2ba8-263d-e391f8fb1bce@Oracle.com> Hi Thomas, Yes, if there is no access to the pid, then it can't report alive or not, and assume not. If there access restrictions it will apply to the waitid/waitpid in the waitForProcessExit0 logic also and the answer will be at least consistent (and avoid a possible race between //proc/pid/psinfo and kill state). Thanks, Roger On 7/18/2017 2:53 PM, Thomas St?fe wrote: > Hi Roger, > > I think this may fail if you have no permission to send a signal to > that process. In that case, kill(2) may yield EPERM and isAlive may > return false even though the process is alive. > > But then, I am not sure if that could happen in that particular > scenario, plus it may also mean that you do not have access to > /proc/pid either. So, I do not know how much of an issue this could be. > > Otherwise, the fix seems straightforward. > > Kind Regards, Thomas > > On Tue, Jul 18, 2017 at 8:46 PM, Roger Riggs > wrote: > > Please review a fix for an intermittent failure in the > ProcessHandle OnExitTest > that fails frequently on Solaris. > > ProcessHandle.isAlive is using /proc/pid/psinfo to determine if a > process is alive and it's start time. > However, it appears that the between the process exiting and the > reaping of its status, the > psinfo file indicates the process is alive but kill(pid, 0) > reports that is is not alive. > Depending on a race, the ProcessHandler.onExit may determine the > process has exited > but later isAlive may report it is alive. > > To have a consistent view of the process being alive, > ProcessHandle.isAlive in its native implementation > should use kill(pid, 0) to determine if the process is > definitively determine if the process alive. > > The original issue[1] will be kept open until it is known that it > is resolved. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-alive-solaris-8184808/ > > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8184808 > > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8177932 > > > > From naoto.sato at oracle.com Tue Jul 18 22:23:01 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 18 Jul 2017 15:23:01 -0700 Subject: [10] RFR (XS) 8183902: Remove unnecessary definitions in locale_str.h for macOS Message-ID: <0d81fa82-7d5c-3e56-ff02-084223a45da3@oracle.com> Hello, Please review this small fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8183902 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8183902/webrev.00/ This is a leftover fix to 8160199. With the fix to 8160199, there is no need to supplement the language aliases for macOS, as they are all accompanied with designated country code. Naoto From felix.yang at oracle.com Wed Jul 19 04:27:25 2017 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 19 Jul 2017 12:27:25 +0800 Subject: RFR 10: 8184808 (process) isAlive should use pid for validity, not /proc/pid In-Reply-To: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> References: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> Message-ID: <49d73417-fc02-ec83-01e8-b3c7c8b5f06b@oracle.com> Hi Roger, is it necessary to add the bug id to OnExitTest? -Felix On 2017/7/19 2:46, Roger Riggs wrote: > Please review a fix for an intermittent failure in the ProcessHandle > OnExitTest > that fails frequently on Solaris. > > ProcessHandle.isAlive is using /proc/pid/psinfo to determine if a > process is alive and it's start time. > However, it appears that the between the process exiting and the > reaping of its status, the > psinfo file indicates the process is alive but kill(pid, 0) reports > that is is not alive. > Depending on a race, the ProcessHandler.onExit may determine the > process has exited > but later isAlive may report it is alive. > > To have a consistent view of the process being alive, > ProcessHandle.isAlive in its native implementation > should use kill(pid, 0) to determine if the process is definitively > determine if the process alive. > > The original issue[1] will be kept open until it is known that it is > resolved. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-alive-solaris-8184808/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8184808 > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8177932 > > From thomas.stuefe at gmail.com Wed Jul 19 08:20:54 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 19 Jul 2017 10:20:54 +0200 Subject: RFR 10: 8184808 (process) isAlive should use pid for validity, not /proc/pid In-Reply-To: <64a1cabc-589a-2ba8-263d-e391f8fb1bce@Oracle.com> References: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> <64a1cabc-589a-2ba8-263d-e391f8fb1bce@Oracle.com> Message-ID: Hi Roger, On Tue, Jul 18, 2017 at 9:01 PM, Roger Riggs wrote: > Hi Thomas, > > Yes, if there is no access to the pid, then it can't report alive or not, > and assume not. > If there access restrictions it will apply to the waitid/waitpid in the > waitForProcessExit0 > logic also and the answer will be at least consistent (and avoid a > possible race > between //proc/pid/psinfo and kill state). > > Thanks, Roger > > Okay, sounds reasonable. Interestingly, while reading up on the semantics of kill(), I found: http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html "Existing implementations vary on the result of a kill() with pid indicating an inactive process (a terminated process that has not been waited for by its parent). Some indicate success on such a call (subject to permission checking), while others give an error of [ESRCH]. Since the definition of process lifetime in this volume of IEEE Std 1003.1-2001 covers inactive processes, the [ESRCH] error as described is inappropriate in this case. In particular, this means that an application cannot have a parent process check for termination of a particular child with kill(). (Usually this is done with the null signal; this can be done reliably with waitpid().)" So, kill() may return success for terminated but not yet reaped processes. I did not know that. But this does not invalidate your change, does it, if all you want to do is to force one consistent view. At least I did not find any code relying on isAlive returning false for not-yet-reaped processes. Thanks, Thomas > > On 7/18/2017 2:53 PM, Thomas St?fe wrote: > > Hi Roger, > > I think this may fail if you have no permission to send a signal to that > process. In that case, kill(2) may yield EPERM and isAlive may return false > even though the process is alive. > > But then, I am not sure if that could happen in that particular scenario, > plus it may also mean that you do not have access to /proc/pid either. So, > I do not know how much of an issue this could be. > > Otherwise, the fix seems straightforward. > > Kind Regards, Thomas > > On Tue, Jul 18, 2017 at 8:46 PM, Roger Riggs > wrote: > >> Please review a fix for an intermittent failure in the ProcessHandle >> OnExitTest >> that fails frequently on Solaris. >> >> ProcessHandle.isAlive is using /proc/pid/psinfo to determine if a process >> is alive and it's start time. >> However, it appears that the between the process exiting and the reaping >> of its status, the >> psinfo file indicates the process is alive but kill(pid, 0) reports that >> is is not alive. >> Depending on a race, the ProcessHandler.onExit may determine the process >> has exited >> but later isAlive may report it is alive. >> >> To have a consistent view of the process being alive, >> ProcessHandle.isAlive in its native implementation >> should use kill(pid, 0) to determine if the process is definitively >> determine if the process alive. >> >> The original issue[1] will be kept open until it is known that it is >> resolved. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-alive-solaris-8184808/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8184808 >> >> Thanks, Roger >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8177932 >> >> >> > > From ivan.gerasimov at oracle.com Wed Jul 19 08:41:46 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 19 Jul 2017 01:41:46 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator Message-ID: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Hello! It is a proposal to provide a String comparator, which will pay attention to the numbers embedded into the strings (should they present). This proposal was initially discussed back in 2014 and seemed to bring some interest from the community: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html In the latest webrev two methods are added to the public API: j.u.Comparator.comparingNumerically() and j.u.Comparator.comparingNumericallyLeadingZerosAhead(). The regression test is extended to exercise this new comparator. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ Comments, suggestions are very welcome! -- With kind regards, Ivan Gerasimov From felix.yang at oracle.com Wed Jul 19 09:43:23 2017 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 19 Jul 2017 17:43:23 +0800 Subject: RFR 8184904/10, jdk/internal/jrtfs/WithSecurityManager fails with exploded builds Message-ID: Hi all, please review a patch to skip parts of testing with exploded builds. Bug: https://bugs.openjdk.java.net/browse/JDK-8184904 Webrev: http://cr.openjdk.java.net/~xiaofeya/8184904/webrev.00/ Thanks, Felix From Alan.Bateman at oracle.com Wed Jul 19 09:50:04 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Jul 2017 10:50:04 +0100 Subject: RFR 8184904/10, jdk/internal/jrtfs/WithSecurityManager fails with exploded builds In-Reply-To: References: Message-ID: On 19/07/2017 10:43, Felix Yang wrote: > Hi all, > > please review a patch to skip parts of testing with exploded builds. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8184904 > > Webrev: > > http://cr.openjdk.java.net/~xiaofeya/8184904/webrev.00/ The check for the image type should be independent of the allow/deny parameter. Alternatively, and as jrtfs does support exploded builds, is to use a different policy file when on an exploded build. Also checking for an image doesn't only need to check for ${java.home}/lib/modules. -Alan From peter.levart at gmail.com Wed Jul 19 09:49:18 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Jul 2017 11:49:18 +0200 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> <7b7cbf1c-3873-492c-a025-4b9c24511727@gmail.com> Message-ID: <40d38dda-61ef-c986-686d-bad823e19dcb@gmail.com> Hi Claes, On 07/17/2017 02:16 PM, Claes Redestad wrote: > Hi Peter! > > On 2017-07-15 14:08, Peter Levart wrote: >> >> It seems that interning signature(s) is important for correctness >> (for example, in ObjectOutputStream.writeTypeString(str) the 'str' is >> used to lookup a handle so that handles are put into stream instead >> of the type signature(s) for multiple references to the same type). >> Looking up objects in handles table is based on identity comparison. > > Yes, interned signatures is important for correctness (and performance?) > of the current serialization implementation. > >> >> But there might be a way to obtain a singleton signature String per >> type and still profit. By adding a field to java.lang.Class and >> caching the JVM signature there. This would also be a useful public >> method, don't you think? > > I have a nagging feeling that we should be careful about leaking > implementation details about the underlying VM through public APIs, > since making changes to various specifications is hard enough as it is. You're right. There's already more than enough "implementation details" that pertain to JVM exposed through reflection API which was supposed to represent Java - the language - view of the world. JVM type signatures just happen to be used in serialization too, which is another implementation detail which might change in the future (with value types etc), so it's better to keep it private. > >> >> Out of 191 ObjectStreamField constructions I found in JDK sources, >> there are only 39 distinct field types involved, so the number if >> intern() calls is reduced by a factor of ~5. There's no need to cache >> signature in ObjectStreamField(s) this way any more, but there must >> still be a single final field for ObjectStreamField(s) constructed >> with explicit signature(s). >> >> Here's how this looks like in code: >> >> http://cr.openjdk.java.net/~plevart/misc/Class.getJvmTypeSignature/webrev.01/ >> > > Could this be done as a ClassValue instead of another field on Class? My > guess is only a small number of classes in any given app will be directly > involved in serialization, so growing Class seems to be a pessimization. It could be, yes. We are trying to solve two issues here. One is the original 8184603 which is concerned with start-up overhead and your proposal is the right solution for it as it only delays the work to when/if it is needed. The other issue is overheads of repeatable signature interning. These are not frequent enough for cases that just create a bunch of ObjectStreamField instances assigned to static final fields, but I suspect are more frequent when signatures are being de-serialized from stream. At that time, we don't yet have a Class object to go with the signature and to use as a caching anchor, but we still want to keep the invariant of OSF signature(s) being interned Strings. If they really need to be interned right away in that case is a question which needs more studying of deserialization code. > >> >> What do you think? > > I wonder what workloads actually see a bottleneck in these String.intern > calls, and *which* String.intern calls we are bottlenecking on in these > workloads. There's still a couple of constructors here that won't see a > speedup. Right. I suspect the intern() call bottleneck is most problematic when deserializing. All other cases could be optimized by caching the signature on the appropriate Class object(s) via ClassValue for example. > > I think we need more data to ensure this is actually worthwhile to > pursue, > or whether there are other optimizations on a higher level that could > be done. Ok, we agree that no new public API for JVM signatures is desired and the problem of intern() calls bottleneck when deserializing should be researched more deeply. I agree that your solution is currently the best for the original issue. > > Thanks! > > /Claes Regards, Peter From Alan.Bateman at oracle.com Wed Jul 19 13:47:18 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Jul 2017 14:47:18 +0100 Subject: 8184917: System.initPhase1 does not need to pre-load libzip Message-ID: System.initPhase1 (formerly initializeSystemClasses) currently pre-loads the zip library. I'd like to drop this in jdk10/jdk10 so that it is loaded lazily and so reduce the code executed in this phase of startup. One motivation is that the zip code no longer uses native methods in libzip to access zip files, it is only now needed when inflating/deflating or for checksums. Another motivation is that jlink can be used to create runtime images that contain the main application and all modules that is needed (there is no class path or module path with JAR files in these cases and libzip is only needed if the image is created with compression). The changes are trivial but something for early in a release to shake out any issues (attempts to touch this code in this past ended in tears due to bootstrapping issues, all issues that are in the past now). http://cr.openjdk.java.net/~alanb/8184917/webrev/index.html -Alan From Roger.Riggs at Oracle.com Wed Jul 19 13:53:23 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 19 Jul 2017 09:53:23 -0400 Subject: [10] RFR: 8184603: Create ObjectStreamField signature lazily when possible In-Reply-To: <40d38dda-61ef-c986-686d-bad823e19dcb@gmail.com> References: <3e85cb55-19f2-db98-d94b-acf56963ff04@redhat.com> <34f014c2-c724-363c-fd7c-30d2ddbb597a@redhat.com> <441b7114-ee50-bd7f-c3a7-83f51781c57e@oracle.com> <5690759d-b826-d2d4-2e8a-0f13faae7b1e@redhat.com> <7b7cbf1c-3873-492c-a025-4b9c24511727@gmail.com> <40d38dda-61ef-c986-686d-bad823e19dcb@gmail.com> Message-ID: <40c99046-4d11-d5ef-1036-bf904a39201d@Oracle.com> Hi, On 7/19/2017 5:49 AM, Peter Levart wrote: > Hi Claes, > > > On 07/17/2017 02:16 PM, Claes Redestad wrote: >> Hi Peter! >> >> On 2017-07-15 14:08, Peter Levart wrote: >>> >>> It seems that interning signature(s) is important for correctness >>> (for example, in ObjectOutputStream.writeTypeString(str) the 'str' >>> is used to lookup a handle so that handles are put into stream >>> instead of the type signature(s) for multiple references to the same >>> type). Looking up objects in handles table is based on identity >>> comparison. >> >> Yes, interned signatures is important for correctness (and performance?) >> of the current serialization implementation. >> >>> >>> But there might be a way to obtain a singleton signature String per >>> type and still profit. By adding a field to java.lang.Class and >>> caching the JVM signature there. This would also be a useful public >>> method, don't you think? >> >> I have a nagging feeling that we should be careful about leaking >> implementation details about the underlying VM through public APIs, >> since making changes to various specifications is hard enough as it is. > > You're right. There's already more than enough "implementation > details" that pertain to JVM exposed through reflection API which was > supposed to represent Java - the language - view of the world. JVM > type signatures just happen to be used in serialization too, which is > another implementation detail which might change in the future (with > value types etc), so it's better to keep it private. right > >> >>> >>> Out of 191 ObjectStreamField constructions I found in JDK sources, >>> there are only 39 distinct field types involved, so the number if >>> intern() calls is reduced by a factor of ~5. There's no need to >>> cache signature in ObjectStreamField(s) this way any more, but there >>> must still be a single final field for ObjectStreamField(s) >>> constructed with explicit signature(s). >>> >>> Here's how this looks like in code: >>> >>> http://cr.openjdk.java.net/~plevart/misc/Class.getJvmTypeSignature/webrev.01/ >>> >> >> Could this be done as a ClassValue instead of another field on Class? My >> guess is only a small number of classes in any given app will be >> directly >> involved in serialization, so growing Class seems to be a pessimization. > > It could be, yes. We are trying to solve two issues here. One is the > original 8184603 which is concerned with start-up overhead and your > proposal is the right solution for it as it only delays the work to > when/if it is needed. The other issue is overheads of repeatable > signature interning. These are not frequent enough for cases that just > create a bunch of ObjectStreamField instances assigned to static final > fields, but I suspect are more frequent when signatures are being > de-serialized from stream. At that time, we don't yet have a Class > object to go with the signature and to use as a caching anchor, but we > still want to keep the invariant of OSF signature(s) being interned > Strings. If they really need to be interned right away in that case is > a question which needs more studying of deserialization code. The pacakge-private ObjectStreamField constructor(name, signature, unshare) is used only to create temporary OSF objects during deserialization. Those OSF instances are compared with the OSF instances created from the local class to determine common fields. The signature.intern() in that constructor is not significant. The signature.intern() in the public constructor is not important for correctness, comparisons between signatures use equals. It may have a slight performance or size impact on the object streams because otherwise equivalent signatures will be serialized as separate strings. > >> >>> >>> What do you think? >> >> I wonder what workloads actually see a bottleneck in these String.intern >> calls, and *which* String.intern calls we are bottlenecking on in these >> workloads. There's still a couple of constructors here that won't see a >> speedup. > > Right. I suspect the intern() call bottleneck is most problematic when > deserializing. All other cases could be optimized by caching the > signature on the appropriate Class object(s) via ClassValue for example. I'd remove the intern in the package-private constructor. > >> >> I think we need more data to ensure this is actually worthwhile to >> pursue, >> or whether there are other optimizations on a higher level that could >> be done. > > Ok, we agree that no new public API for JVM signatures is desired and > the problem of intern() calls bottleneck when deserializing should be > researched more deeply. I agree that your solution is currently the > best for the original issue. Ditto. Roger From claes.redestad at oracle.com Wed Jul 19 14:19:01 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 19 Jul 2017 16:19:01 +0200 Subject: 8184917: System.initPhase1 does not need to pre-load libzip In-Reply-To: References: Message-ID: Hi Alan, this looks good to me! /Claes On 2017-07-19 15:47, Alan Bateman wrote: > > System.initPhase1 (formerly initializeSystemClasses) currently > pre-loads the zip library. I'd like to drop this in jdk10/jdk10 so > that it is loaded lazily and so reduce the code executed in this phase > of startup. One motivation is that the zip code no longer uses native > methods in libzip to access zip files, it is only now needed when > inflating/deflating or for checksums. Another motivation is that jlink > can be used to create runtime images that contain the main application > and all modules that is needed (there is no class path or module path > with JAR files in these cases and libzip is only needed if the image > is created with compression). > > The changes are trivial but something for early in a release to shake > out any issues (attempts to touch this code in this past ended in > tears due to bootstrapping issues, all issues that are in the past now). > http://cr.openjdk.java.net/~alanb/8184917/webrev/index.html > > -Alan From cushon at google.com Wed Jul 19 18:29:39 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 19 Jul 2017 11:29:39 -0700 Subject: JDK 9 rejects zip files where the modified day or month is 0 (JDK-8184940) Message-ID: Hello, While testing JDK 9 we noticed that zip archives containing zeroed-out dates are no longer accepted. These archives are arguably invalid, but some zip implementations produce them and there's a significant number of them in the wild. I filed a bug with more details: https://bugs.openjdk.java.net/browse/JDK-8184940 Would you consider relaxing the JDK 9 behaviour to continue to handle zeroed-out dates, to avoid a breaking change and ensure it can read the same legacy zip and jar files as earlier releases? Thanks, Liam From martinrb at google.com Wed Jul 19 18:44:34 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 19 Jul 2017 11:44:34 -0700 Subject: JDK 9 rejects zip files where the modified day or month is 0 (JDK-8184940) In-Reply-To: References: Message-ID: I support this change and commented on the bug. Too late for jdk9, but should go into a jdk9 update. On Wed, Jul 19, 2017 at 11:29 AM, Liam Miller-Cushon wrote: > Hello, > > While testing JDK 9 we noticed that zip archives containing zeroed-out > dates are no longer accepted. These archives are arguably invalid, but some > zip implementations produce them and there's a significant number of them > in the wild. I filed a bug with more details: > https://bugs.openjdk.java.net/browse/JDK-8184940 > > Would you consider relaxing the JDK 9 behaviour to continue to handle > zeroed-out dates, to avoid a breaking change and ensure it can read the > same legacy zip and jar files as earlier releases? > > Thanks, > Liam > From brent.christian at oracle.com Wed Jul 19 19:06:34 2017 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 19 Jul 2017 12:06:34 -0700 Subject: [10] RFR (XS) 8183902: Remove unnecessary definitions in locale_str.h for macOS In-Reply-To: <0d81fa82-7d5c-3e56-ff02-084223a45da3@oracle.com> References: <0d81fa82-7d5c-3e56-ff02-084223a45da3@oracle.com> Message-ID: <817bcb83-e99d-530b-3e18-f1b7d6d5a15f@oracle.com> The fix looks good, Naoto. Thanks, -Brent On 7/18/17 3:23 PM, Naoto Sato wrote: > Hello, > > Please review this small fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8183902 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8183902/webrev.00/ > > This is a leftover fix to 8160199. With the fix to 8160199, there is no > need to supplement the language aliases for macOS, as they are all > accompanied with designated country code. > > Naoto From Roger.Riggs at Oracle.com Wed Jul 19 19:47:38 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 19 Jul 2017 15:47:38 -0400 Subject: RFR 10: 8184808 (process) isAlive should use pid for validity, not /proc/pid In-Reply-To: <49d73417-fc02-ec83-01e8-b3c7c8b5f06b@oracle.com> References: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> <49d73417-fc02-ec83-01e8-b3c7c8b5f06b@oracle.com> Message-ID: <53bd6000-adca-e24b-2b2b-db067924fe41@Oracle.com> Hi Felix, OnExitTest is unchanged and was the test the discovered the bug; so I don't think it needs a @bug. Thanks, Roger On 7/19/2017 12:27 AM, Felix Yang wrote: > Hi Roger, > > is it necessary to add the bug id to OnExitTest? > > -Felix > On 2017/7/19 2:46, Roger Riggs wrote: >> Please review a fix for an intermittent failure in the ProcessHandle >> OnExitTest >> that fails frequently on Solaris. >> >> ProcessHandle.isAlive is using /proc/pid/psinfo to determine if a >> process is alive and it's start time. >> However, it appears that the between the process exiting and the >> reaping of its status, the >> psinfo file indicates the process is alive but kill(pid, 0) reports >> that is is not alive. >> Depending on a race, the ProcessHandler.onExit may determine the >> process has exited >> but later isAlive may report it is alive. >> >> To have a consistent view of the process being alive, >> ProcessHandle.isAlive in its native implementation >> should use kill(pid, 0) to determine if the process is definitively >> determine if the process alive. >> >> The original issue[1] will be kept open until it is known that it is >> resolved. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-alive-solaris-8184808/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8184808 >> >> Thanks, Roger >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8177932 >> >> > From Roger.Riggs at Oracle.com Wed Jul 19 20:39:44 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 19 Jul 2017 16:39:44 -0400 Subject: [10] RFR (XS) 8183902: Remove unnecessary definitions in locale_str.h for macOS In-Reply-To: <0d81fa82-7d5c-3e56-ff02-084223a45da3@oracle.com> References: <0d81fa82-7d5c-3e56-ff02-084223a45da3@oracle.com> Message-ID: Hi Naoto, The update looks fine. Roger On 7/18/2017 6:23 PM, Naoto Sato wrote: > Hello, > > Please review this small fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8183902 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8183902/webrev.00/ > > This is a leftover fix to 8160199. With the fix to 8160199, there is > no need to supplement the language aliases for macOS, as they are all > accompanied with designated country code. > > Naoto From andrey.x.nazarov at oracle.com Thu Jul 20 01:03:23 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 19 Jul 2017 18:03:23 -0700 Subject: RFR 8177357: tools/jar/multiRelease/ApiValidatorTest.java failed due to "Exception java.nio.file.DirectoryNotEmptyException" In-Reply-To: <9FC3684E-3506-4AED-B506-C8AF2ABABB41@oracle.com> References: <9FC3684E-3506-4AED-B506-C8AF2ABABB41@oracle.com> Message-ID: <7BA2F169-17DC-4C12-AC96-3F196EE3A548@oracle.com> > On 18 Jul 2017, at 11:38, Paul Sandoz wrote: > > >> On 17 Jul 2017, at 16:51, Andrey Nazarov wrote: >> >> Hi, >> >> Could you review simple test fix? >> >> http://cr.openjdk.java.net/~anazarov/JDK-8177357/webrev.00/webrev >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177357 >> > > Looks ok. (It bothers me that deletion of a directory is so fragile.) I dig into the intermittent issue a bit. Here is my investigation https://bugs.openjdk.java.net/browse/JDK-8184961 > > Paul. From andrey.x.nazarov at oracle.com Thu Jul 20 01:21:01 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 19 Jul 2017 18:21:01 -0700 Subject: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file Message-ID: Hi, Could you review fix in test library which should help to resolve intermittent issues on Windows machines during directories clean up. Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 Review: http://cr.openjdk.java.net/~anazarov/JDK-8184961/webrev.00/webrev/ ?Andrei From felix.yang at oracle.com Thu Jul 20 03:22:45 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 20 Jul 2017 11:22:45 +0800 Subject: RFR 8184904/10, jdk/internal/jrtfs/WithSecurityManager fails with exploded builds In-Reply-To: References: Message-ID: <4ee2a0f0-b825-204d-92e6-30d9bcef562b@oracle.com> Hi Alan, if I understand correctly, you meant that just to check for ${java.home}/lib/modules is enough? Please review the updated patch. I also adjusted checking in Basic.java, which also has duplicate checking and is problematic (jrt-fs.jar is no longer under JDK root directory) Webrev: http://cr.openjdk.java.net/~xiaofeya/8184904/webrev.01/ Thanks, Felix On 2017/7/19 17:50, Alan Bateman wrote: > On 19/07/2017 10:43, Felix Yang wrote: >> Hi all, >> >> please review a patch to skip parts of testing with exploded builds. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8184904 >> >> Webrev: >> >> http://cr.openjdk.java.net/~xiaofeya/8184904/webrev.00/ > The check for the image type should be independent of the allow/deny > parameter. Alternatively, and as jrtfs does support exploded builds, > is to use a different policy file when on an exploded build. > > Also checking for an image doesn't only need to check for > ${java.home}/lib/modules. > > -Alan > > From Alan.Bateman at oracle.com Thu Jul 20 11:23:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Jul 2017 12:23:22 +0100 Subject: RFR 8184904/10, jdk/internal/jrtfs/WithSecurityManager fails with exploded builds In-Reply-To: <4ee2a0f0-b825-204d-92e6-30d9bcef562b@oracle.com> References: <4ee2a0f0-b825-204d-92e6-30d9bcef562b@oracle.com> Message-ID: On 20/07/2017 04:22, Felix Yang wrote: > Hi Alan, > > if I understand correctly, you meant that just to check for > ${java.home}/lib/modules is enough? > > Please review the updated patch. I also adjusted checking in > Basic.java, which also has duplicate checking and is problematic > (jrt-fs.jar is no longer under JDK root directory) > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8184904/webrev.01/ This skips the testing on exploded builds, which I think is okay. A minor point before pushing is that you replace "lib/modules" with "lib", "modules" as the elements will be joined by the method. -Alan From felix.yang at oracle.com Thu Jul 20 14:09:30 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 20 Jul 2017 22:09:30 +0800 Subject: RFR 8184904/10, jdk/internal/jrtfs/WithSecurityManager fails with exploded builds In-Reply-To: References: <4ee2a0f0-b825-204d-92e6-30d9bcef562b@oracle.com> Message-ID: Hi Alan, pushed as suggested. Thanks, Felix > On 20 Jul 2017, at 7:23 PM, Alan Bateman wrote: > > This skips the testing on exploded builds, which I think is okay. A minor point before pushing is that you replace "lib/modules" with "lib", "modules" as the elements will be joined by the method. > > -Alan From Roger.Riggs at Oracle.com Thu Jul 20 14:25:17 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 20 Jul 2017 10:25:17 -0400 Subject: RFR 10: 8184808 (process) isAlive should use pid for validity, not /proc/pid In-Reply-To: References: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> <64a1cabc-589a-2ba8-263d-e391f8fb1bce@Oracle.com> Message-ID: <4ab6f9a7-d06e-3fef-2c76-bcf013e72d37@Oracle.com> Hi Thomas, Thanks for the investigation and links. The variations, across os's, in the status of exited vs reaped (zombie) process have been a problem for quite a while (for portable apps). The description of waitpid is focused heavily on child processes; this a particular case is dealing with non-child processes so I stayed with using kill(pid,0) to determine liveness. Thanks, Roger On 7/19/2017 4:20 AM, Thomas St?fe wrote: > Hi Roger, > > On Tue, Jul 18, 2017 at 9:01 PM, Roger Riggs > wrote: > > Hi Thomas, > > Yes, if there is no access to the pid, then it can't report alive > or not, and assume not. > If there access restrictions it will apply to the waitid/waitpid > in the waitForProcessExit0 > logic also and the answer will be at least consistent (and avoid a > possible race > between //proc/pid/psinfo and kill state). > > Thanks, Roger > > > Okay, sounds reasonable. Interestingly, while reading up on the > semantics of kill(), I found: > > http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html > > "Existing implementations vary on the result of a kill() with pid > indicating an inactive process (a terminated process that has not been > waited for by its parent). Some indicate success on such a call > (subject to permission checking), while others give an error of > [ESRCH]. Since the definition of process lifetime in this volume of > IEEE Std 1003.1-2001 covers inactive processes, the [ESRCH] error as > described is inappropriate in this case. In particular, this means > that an application cannot have a parent process check for termination > of a particular child with kill(). (Usually this is done with the null > signal; this can be done reliably with waitpid().)" > > So, kill() may return success for terminated but not yet reaped > processes. I did not know that. > > But this does not invalidate your change, does it, if all you want to > do is to force one consistent view. At least I did not find any code > relying on isAlive returning false for not-yet-reaped processes. > > Thanks, Thomas > > > On 7/18/2017 2:53 PM, Thomas St?fe wrote: >> Hi Roger, >> >> I think this may fail if you have no permission to send a signal >> to that process. In that case, kill(2) may yield EPERM and >> isAlive may return false even though the process is alive. >> >> But then, I am not sure if that could happen in that particular >> scenario, plus it may also mean that you do not have access to >> /proc/pid either. So, I do not know how much of an issue this >> could be. >> >> Otherwise, the fix seems straightforward. >> >> Kind Regards, Thomas >> >> On Tue, Jul 18, 2017 at 8:46 PM, Roger Riggs >> > wrote: >> >> Please review a fix for an intermittent failure in the >> ProcessHandle OnExitTest >> that fails frequently on Solaris. >> >> ProcessHandle.isAlive is using /proc/pid/psinfo to determine >> if a process is alive and it's start time. >> However, it appears that the between the process exiting and >> the reaping of its status, the >> psinfo file indicates the process is alive but kill(pid, 0) >> reports that is is not alive. >> Depending on a race, the ProcessHandler.onExit may determine >> the process has exited >> but later isAlive may report it is alive. >> >> To have a consistent view of the process being alive, >> ProcessHandle.isAlive in its native implementation >> should use kill(pid, 0) to determine if the process is >> definitively determine if the process alive. >> >> The original issue[1] will be kept open until it is known >> that it is resolved. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-alive-solaris-8184808/ >> >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8184808 >> >> >> Thanks, Roger >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8177932 >> >> >> >> > > From kumar.x.srinivasan at oracle.com Thu Jul 20 18:53:59 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 20 Jul 2017 11:53:59 -0700 Subject: RFR: JDK-8183579: refactor and cleanup launcher help messages Message-ID: <5970FC47.3060509@oracle.com> Hi, Please review refactoring and clean up of the java launcher's help/usage messages. The highlights of the changes are as follows: 1. Helper.java: is renamed from LauncherHelper.java, simpler name, containing mostly methods to help with class loading, module assistance etc. 2. OptionHelper.java: moved those methods in Helper.java, pertaining to option printing, to this class. 3. Options.java: is heavily inspired by javadoc's option management, it is very structured, and makes the resources much simpler to manage. 4. Modified the options descriptions to be _more consistent_, keeping in mind, these options have been in there for eons. Bug: https://bugs.openjdk.java.net/browse/JDK-8183579 Webrev: http://cr.openjdk.java.net/~ksrini/8183579/webrev.00/ java -help output: http://cr.openjdk.java.net/~ksrini/8183579/help.txt java -X output: http://cr.openjdk.java.net/~ksrini/8183579/x-help.txt Thanks Kumar From thomas.stuefe at gmail.com Fri Jul 21 05:07:06 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 21 Jul 2017 07:07:06 +0200 Subject: RFR 10: 8184808 (process) isAlive should use pid for validity, not /proc/pid In-Reply-To: <4ab6f9a7-d06e-3fef-2c76-bcf013e72d37@Oracle.com> References: <67d6a964-a9ee-1668-addf-96f4ccf42b91@Oracle.com> <64a1cabc-589a-2ba8-263d-e391f8fb1bce@Oracle.com> <4ab6f9a7-d06e-3fef-2c76-bcf013e72d37@Oracle.com> Message-ID: Hi Roger, On Thu, Jul 20, 2017 at 4:25 PM, Roger Riggs wrote: > Hi Thomas, > > Thanks for the investigation and links. > The variations, across os's, in the status of exited vs reaped (zombie) > process have been a > problem for quite a while (for portable apps). > > The description of waitpid is focused heavily on child processes; this a > particular case > is dealing with non-child processes so I stayed with using kill(pid,0) to > determine liveness. > > Thanks, Roger > > That makes sense. Thanks for clarifying. ..Thomas > On 7/19/2017 4:20 AM, Thomas St?fe wrote: > > Hi Roger, > > On Tue, Jul 18, 2017 at 9:01 PM, Roger Riggs > wrote: > >> Hi Thomas, >> >> Yes, if there is no access to the pid, then it can't report alive or not, >> and assume not. >> If there access restrictions it will apply to the waitid/waitpid in the >> waitForProcessExit0 >> logic also and the answer will be at least consistent (and avoid a >> possible race >> between //proc/pid/psinfo and kill state). >> >> Thanks, Roger >> >> > Okay, sounds reasonable. Interestingly, while reading up on the semantics > of kill(), I found: > > http://pubs.opengroup.org/onlinepubs/009695399/functions/kill.html > > "Existing implementations vary on the result of a kill() with pid > indicating an inactive process (a terminated process that has not been > waited for by its parent). Some indicate success on such a call (subject to > permission checking), while others give an error of [ESRCH]. Since the > definition of process lifetime in this volume of IEEE Std 1003.1-2001 > covers inactive processes, the [ESRCH] error as described is inappropriate > in this case. In particular, this means that an application cannot have a > parent process check for termination of a particular child with kill(). > (Usually this is done with the null signal; this can be done reliably with > waitpid().)" > > So, kill() may return success for terminated but not yet reaped processes. > I did not know that. > > But this does not invalidate your change, does it, if all you want to do > is to force one consistent view. At least I did not find any code relying > on isAlive returning false for not-yet-reaped processes. > > Thanks, Thomas > > > >> >> On 7/18/2017 2:53 PM, Thomas St?fe wrote: >> >> Hi Roger, >> >> I think this may fail if you have no permission to send a signal to that >> process. In that case, kill(2) may yield EPERM and isAlive may return false >> even though the process is alive. >> >> But then, I am not sure if that could happen in that particular scenario, >> plus it may also mean that you do not have access to /proc/pid either. So, >> I do not know how much of an issue this could be. >> >> Otherwise, the fix seems straightforward. >> >> Kind Regards, Thomas >> >> On Tue, Jul 18, 2017 at 8:46 PM, Roger Riggs >> wrote: >> >>> Please review a fix for an intermittent failure in the ProcessHandle >>> OnExitTest >>> that fails frequently on Solaris. >>> >>> ProcessHandle.isAlive is using /proc/pid/psinfo to determine if a >>> process is alive and it's start time. >>> However, it appears that the between the process exiting and the reaping >>> of its status, the >>> psinfo file indicates the process is alive but kill(pid, 0) reports that >>> is is not alive. >>> Depending on a race, the ProcessHandler.onExit may determine the process >>> has exited >>> but later isAlive may report it is alive. >>> >>> To have a consistent view of the process being alive, >>> ProcessHandle.isAlive in its native implementation >>> should use kill(pid, 0) to determine if the process is definitively >>> determine if the process alive. >>> >>> The original issue[1] will be kept open until it is known that it is >>> resolved. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-alive-solaris-8184808/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8184808 >>> >>> Thanks, Roger >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8177932 >>> >>> >>> >> >> > > From andrey.x.nazarov at oracle.com Sat Jul 22 01:35:28 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Fri, 21 Jul 2017 18:35:28 -0700 Subject: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider Message-ID: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> Hi, Please review changes in launcher tests. I?ve added absent @modules jtreg tags. Review: http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.00/webrev/ JBS: https://bugs.openjdk.java.net/browse/JDK-8179292 ?Andrei From martinrb at google.com Sat Jul 22 18:29:40 2017 From: martinrb at google.com (Martin Buchholz) Date: Sat, 22 Jul 2017 11:29:40 -0700 Subject: RFR: jsr166 jdk10 integration wave 1 In-Reply-To: References: Message-ID: Finally submitted. On Tue, Jul 18, 2017 at 9:35 AM, Martin Buchholz wrote: > After a long delay, we are finally ready to try again to get in jsr166 > jdk10 integration wave 1. > > The set of changes has grown a lot over the past few months (too much?), > and contains the usual hard-to-review tck test improvements. Our > infrastructure for generating these commits has changed a lot as well, but > reviewers should see little difference. > > We now run errorprone over the jsr166 sources occasionally ("ant > errorprone"). This set of commits contains the first annotations to > suppress errorprone warnings, e.g. > > + @SuppressWarnings("FutureReturnValueIgnored") > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ > > On Mon, Apr 10, 2017 at 2:19 PM, Martin Buchholz > wrote: > >> Non-thread-pool changes committed while we wait for thread-pool CCC. >> >> > From ivan.gerasimov at oracle.com Sun Jul 23 04:36:04 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 22 Jul 2017 21:36:04 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: <90df7646-be24-22f3-bd3f-f325daad875f@oracle.com> Hello! This is a gentle reminder. The proposed comparator implementation would be particularly useful when one will need to compare version strings. Some popular file managers also use similar comparing algorithm, as the results often look more natural to the human eyes (e.g. File Explorer on Windows, Files on Ubuntu). Now, as Java 10 is been worked on, to sort the list of Java names correctly, this kind of comparator is needed: Look: a list { ... "Java 8", "Java 9", "Java 10" } definitely looks nicer than { "Java 1", "Java 10", "Java 2", ... } :-) Would you please help review the proposal? With kind regards, Ivan On 7/19/17 1:41 AM, Ivan Gerasimov wrote: > Hello! > > It is a proposal to provide a String comparator, which will pay > attention to the numbers embedded into the strings (should they present). > > This proposal was initially discussed back in 2014 and seemed to bring > some interest from the community: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html > > > In the latest webrev two methods are added to the public API: > j.u.Comparator.comparingNumerically() and > j.u.Comparator.comparingNumericallyLeadingZerosAhead(). > > The regression test is extended to exercise this new comparator. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 > WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ > > Comments, suggestions are very welcome! > -- With kind regards, Ivan Gerasimov From jbluettduncan at gmail.com Sun Jul 23 10:56:29 2017 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Sun, 23 Jul 2017 11:56:29 +0100 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> <90df7646-be24-22f3-bd3f-f325daad875f@oracle.com> Message-ID: Meant to reply to core-libs-dev as well; doing so now. Jonathan On 23 July 2017 at 11:50, Jonathan Bluett-Duncan wrote: > Hi Ivan, > > I'm not a reviewer per se, but I thought I'd chime in. > > There's a few things with Comparator.java which I think could be improved: > > 1. `comparingNumericallyLeadingZerosAhead()` is a confusing name for > me, as the "ahead" has no meaning in my mind; IMO the name ` > comparingNumericallyLeadingZerosFirst()` better implies that "0001" < > "001" < "01". > 2. It wasn't clear to me from the javadoc that the comparators compare > strings like "abc9" and "abc10" as "abc9" < "abc10", so I think they should > include more examples. > 3. There's a typo in the javadocs for both methods: "represets" --> > "represents". > 4. Where the javadocs say "follows the procedure", I think it'd make > more grammatical sense if they said "does the following". > 5. The lines which say "at the boundary of a subsequence, consisting > of decimal digits, the" would flow better if they said "at the boundary of > a subsequence *consisting solely of decimal digits*, then the". Note > the removal of the comma between "subsequence" and "consisting". > > Hope this helps! > > Jonathan > > On 23 July 2017 at 05:36, Ivan Gerasimov > wrote: > >> Hello! >> >> This is a gentle reminder. >> >> The proposed comparator implementation would be particularly useful when >> one will need to compare version strings. >> Some popular file managers also use similar comparing algorithm, as the >> results often look more natural to the human eyes (e.g. File Explorer on >> Windows, Files on Ubuntu). >> >> Now, as Java 10 is been worked on, to sort the list of Java names >> correctly, this kind of comparator is needed: >> >> Look: a list { ... "Java 8", "Java 9", "Java 10" } definitely looks nicer >> than { "Java 1", "Java 10", "Java 2", ... } :-) >> >> Would you please help review the proposal? >> >> With kind regards, >> Ivan >> >> >> >> On 7/19/17 1:41 AM, Ivan Gerasimov wrote: >> >>> Hello! >>> >>> It is a proposal to provide a String comparator, which will pay >>> attention to the numbers embedded into the strings (should they present). >>> >>> This proposal was initially discussed back in 2014 and seemed to bring >>> some interest from the community: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-De >>> cember/030343.html >>> >>> In the latest webrev two methods are added to the public API: >>> j.u.Comparator.comparingNumerically() and >>> j.u.Comparator.comparingNumericallyLeadingZerosAhead(). >>> >>> The regression test is extended to exercise this new comparator. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ >>> >>> Comments, suggestions are very welcome! >>> >>> >> -- >> With kind regards, >> Ivan Gerasimov >> >> > From claes.redestad at oracle.com Sun Jul 23 13:37:44 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 23 Jul 2017 15:37:44 +0200 Subject: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly Message-ID: Hi, java.lang.CharacterDataLatin1 and others are generated at build time by the GenerateCharacter tool, which has a -string mode to generate lookup tables as Strings literals rather than arrays directly. This serves multiple purposes: 1. it reduces the size of the generated bytecode, which is necessary to keep code below method bytecode limits if the arrays generated are very large 2. it may under certain circumstances (large enough arrays, JITed code) be a performance optimization While having other performance benefits, the compact strings feature that went into 9 made String::toCharArray less friendly to startup, and since the same feature means we're now always loading CharacterDataLatin1 on bootstrap in all locales it seemed reasonable to re-examine whether this class in particular really gains from generating its lookup tables via String literals. Turns out it doesn't. By generating CharacterDataLatin1 tables as arrays explicitly: - executed bytecode drop from 21,782 to 2,077 when initializing this class (approximately 2% of executed bytecode; 1.5% of total instructions) - slight reduction (~1Kb) in the minimum retained heap usage - the size of CharacterDataLatin1.class only grows from 6458 to 7385 bytes Proposed patch is to drop passing -string to GenerateCharacter for the latin1 case: Webrev: http://cr.openjdk.java.net/~redestad/8185104/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8185104 Thanks! /Claes From ivan.gerasimov at oracle.com Mon Jul 24 05:21:04 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 23 Jul 2017 22:21:04 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> <90df7646-be24-22f3-bd3f-f325daad875f@oracle.com> Message-ID: <926028c0-5052-0b6a-bcbf-58bd410b3a0e@oracle.com> Thank you Jonathan for looking into that! I agree with all your suggestions. Here's the updated webrev with suggested modifications: WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/02/webrev/ With kind regards, Ivan On 7/23/17 3:56 AM, Jonathan Bluett-Duncan wrote: > Meant to reply to core-libs-dev as well; doing so now. > > Jonathan > > On 23 July 2017 at 11:50, Jonathan Bluett-Duncan > > wrote: > > Hi Ivan, > > I'm not a reviewer per se, but I thought I'd chime in. > > There's a few things with Comparator.java which I think could be > improved: > > 1. `comparingNumericallyLeadingZerosAhead()` is a confusing name > for me, as the "ahead" has no meaning in my mind; IMO the name > `comparingNumericallyLeadingZerosFirst()` better implies that > "0001" < "001" < "01". > 2. It wasn't clear to me from the javadoc that the comparators > compare strings like "abc9" and "abc10" as "abc9" < "abc10", > so I think they should include more examples. > 3. There's a typo in the javadocs for both methods: "represets" > --> "represents". > 4. Where the javadocs say "follows the procedure", I think it'd > make more grammatical sense if they said "does the following". > 5. The lines which say "at the boundary of a subsequence, > consisting of decimal digits, the" would flow better if they > said "at the boundary of a subsequence *consisting solely of > decimal digits*, then the". Note the removal of the comma > between "subsequence" and "consisting". > > Hope this helps! > > Jonathan > > On 23 July 2017 at 05:36, Ivan Gerasimov > > wrote: > > Hello! > > This is a gentle reminder. > > The proposed comparator implementation would be particularly > useful when one will need to compare version strings. > Some popular file managers also use similar comparing > algorithm, as the results often look more natural to the human > eyes (e.g. File Explorer on Windows, Files on Ubuntu). > > Now, as Java 10 is been worked on, to sort the list of Java > names correctly, this kind of comparator is needed: > > Look: a list { ... "Java 8", "Java 9", "Java 10" } definitely > looks nicer than { "Java 1", "Java 10", "Java 2", ... } :-) > > Would you please help review the proposal? > > With kind regards, > Ivan > > > > On 7/19/17 1:41 AM, Ivan Gerasimov wrote: > > Hello! > > It is a proposal to provide a String comparator, which > will pay attention to the numbers embedded into the > strings (should they present). > > This proposal was initially discussed back in 2014 and > seemed to bring some interest from the community: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html > > > > In the latest webrev two methods are added to the public API: > j.u.Comparator.comparingNumerically() and > j.u.Comparator.comparingNumericallyLeadingZerosAhead(). > > The regression test is extended to exercise this new > comparator. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 > > WEBREV: > http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ > > > Comments, suggestions are very welcome! > > > -- > With kind regards, > Ivan Gerasimov > > > -- With kind regards, Ivan Gerasimov From Alan.Bateman at oracle.com Mon Jul 24 08:29:00 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Jul 2017 09:29:00 +0100 Subject: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly In-Reply-To: References: Message-ID: On 23/07/2017 14:37, Claes Redestad wrote: > Hi, > > java.lang.CharacterDataLatin1 and others are generated at build time > by the GenerateCharacter tool, which has a -string mode to generate > lookup tables as Strings literals rather than arrays directly. This > serves multiple purposes: > > 1. it reduces the size of the generated bytecode, which is necessary > to keep code below method bytecode limits if the arrays generated are > very large > 2. it may under certain circumstances (large enough arrays, JITed > code) be a performance optimization > > While having other performance benefits, the compact strings feature > that went into 9 made String::toCharArray less friendly to startup, > and since the same feature means we're now always loading > CharacterDataLatin1 on bootstrap in all locales it seemed reasonable > to re-examine whether this class in particular really gains from > generating its lookup tables via String literals. > > Turns out it doesn't. By generating CharacterDataLatin1 tables as > arrays explicitly: > > - executed bytecode drop from 21,782 to 2,077 when initializing this > class (approximately 2% of executed bytecode; 1.5% of total instructions) > - slight reduction (~1Kb) in the minimum retained heap usage > - the size of CharacterDataLatin1.class only grows from 6458 to 7385 > bytes > > Proposed patch is to drop passing -string to GenerateCharacter for the > latin1 case: > > Webrev: http://cr.openjdk.java.net/~redestad/8185104/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8185104 This is a good sleuthing. I can't see of any reason why the tables in CharacterDataLatin1 need to be generated as Strings now I think this change is good. -Alan From claes.redestad at oracle.com Mon Jul 24 08:32:55 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 24 Jul 2017 10:32:55 +0200 Subject: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly In-Reply-To: References: Message-ID: On 07/24/2017 10:29 AM, Alan Bateman wrote: > > On 23/07/2017 14:37, Claes Redestad wrote: >> Proposed patch is to drop passing -string to GenerateCharacter for >> the latin1 case: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8185104/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8185104 > This is a good sleuthing. I can't see of any reason why the tables in > CharacterDataLatin1 need to be generated as Strings now I think this > change is good. Thanks for reviewing, Alan! /Claes From jbluettduncan at gmail.com Mon Jul 24 10:42:03 2017 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Mon, 24 Jul 2017 11:42:03 +0100 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: <926028c0-5052-0b6a-bcbf-58bd410b3a0e@oracle.com> References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> <90df7646-be24-22f3-bd3f-f325daad875f@oracle.com> <926028c0-5052-0b6a-bcbf-58bd410b3a0e@oracle.com> Message-ID: You're welcome Ivan! I'm just proofreading the new webrev, and a few more things have occurred to me: 1. What happens if the comparators are given the elements {"1abc", "2abc", "10abc"} to compare? Would they sort the elements as {"1abc", "2abc", "10abc"} or as {"1abc", "10abc", "2abc"}? What about the array {"x1yz", "x2yz", "x10yz"}? I wonder if these two cases should be added to the test too and given as additional examples in the javadocs. 2. The example arrays which you kindly added to the comparators' javadoc have no whitespace at the start but one space between the last element and the }, so I think there either should be no space at the end or an extra space at the start. 3. Very sorry, error on my part: on the javadoc lines which now say "then the corresponding numerical values are compared; otherwise", I suggested to add a "then" at the start; re-reading it though, I personally think it reads better without, but I would understand and not press it further if you disagree and think that the "then" is a useful addition. Best regards, Jonathan On 24 Jul 2017 06:21, "Ivan Gerasimov" wrote: Thank you Jonathan for looking into that! I agree with all your suggestions. Here's the updated webrev with suggested modifications: WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/02/webrev/ With kind regards, Ivan On 7/23/17 3:56 AM, Jonathan Bluett-Duncan wrote: Meant to reply to core-libs-dev as well; doing so now. Jonathan On 23 July 2017 at 11:50, Jonathan Bluett-Duncan wrote: > Hi Ivan, > > I'm not a reviewer per se, but I thought I'd chime in. > > There's a few things with Comparator.java which I think could be improved: > > 1. `comparingNumericallyLeadingZerosAhead()` is a confusing name for > me, as the "ahead" has no meaning in my mind; IMO the name > `comparingNumericallyLeadingZerosFirst()` better implies that "0001" < > "001" < "01". > 2. It wasn't clear to me from the javadoc that the comparators compare > strings like "abc9" and "abc10" as "abc9" < "abc10", so I think they should > include more examples. > 3. There's a typo in the javadocs for both methods: "represets" --> > "represents". > 4. Where the javadocs say "follows the procedure", I think it'd make > more grammatical sense if they said "does the following". > 5. The lines which say "at the boundary of a subsequence, consisting > of decimal digits, the" would flow better if they said "at the boundary of > a subsequence *consisting solely of decimal digits*, then the". Note > the removal of the comma between "subsequence" and "consisting". > > Hope this helps! > > Jonathan > > On 23 July 2017 at 05:36, Ivan Gerasimov > wrote: > >> Hello! >> >> This is a gentle reminder. >> >> The proposed comparator implementation would be particularly useful when >> one will need to compare version strings. >> Some popular file managers also use similar comparing algorithm, as the >> results often look more natural to the human eyes (e.g. File Explorer on >> Windows, Files on Ubuntu). >> >> Now, as Java 10 is been worked on, to sort the list of Java names >> correctly, this kind of comparator is needed: >> >> Look: a list { ... "Java 8", "Java 9", "Java 10" } definitely looks nicer >> than { "Java 1", "Java 10", "Java 2", ... } :-) >> >> Would you please help review the proposal? >> >> With kind regards, >> Ivan >> >> >> >> On 7/19/17 1:41 AM, Ivan Gerasimov wrote: >> >>> Hello! >>> >>> It is a proposal to provide a String comparator, which will pay >>> attention to the numbers embedded into the strings (should they present). >>> >>> This proposal was initially discussed back in 2014 and seemed to bring >>> some interest from the community: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-De >>> cember/030343.html >>> >>> In the latest webrev two methods are added to the public API: >>> j.u.Comparator.comparingNumerically() and >>> j.u.Comparator.comparingNumericallyLeadingZerosAhead(). >>> >>> The regression test is extended to exercise this new comparator. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ >>> >>> Comments, suggestions are very welcome! >>> >>> >> -- >> With kind regards, >> Ivan Gerasimov >> >> > -- With kind regards, Ivan Gerasimov From Roger.Riggs at Oracle.com Mon Jul 24 14:42:56 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 24 Jul 2017 10:42:56 -0400 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: Hi Ivan, Thanks for bringing this up again. Some initial comments, not a full review. Though the enhancement says that no consideration is given to sign characters they may produce puzzling results for strings like "-2000" and "-2001" where the strings appear to be signed numbers but the comparison will be for the "-" prefix and the rest unsigned. Including the word 'unsigned' in the description might help reinforce the semantics. Also, I don't see test cases for strings like: "abc200123" and "abc20000123" which share a prefix part of which is numeric but differ in the number of "leading" zeros after the prefix. What about strings that include more than 1 numeric segment: abc2003def0001 and abc02003def001 in the leading zero case? Though the test adds the @key randomness, it would be useful to use the test library mechanisms to report the seed and be able to run the test with a seed, if case they fail. (As might be provided by the test library jdk.test.lib.RandomFactory). Comparator.java: 576: "the common prefix is skipped" is problematic when considering leading zeros. The common prefix may contain non-zero digits. 585: it is not clear whether the "different number of leading zeros" is applied regardless of the common prefix or only starting after the common prefix. 550, 586: for many readers, it is easier to read 'for example' than "e.g." or "i.e.". 562, 598: editorial: "is to compare" -> "compares" Comparators.java: 192: @param for param o is missing; (the param name "o" usually refers to an object, not a string). 200: Can skipLeadingZeros be coded to correctly work if cnt == 0; it would be more robust SkipLeading zeros works correctly only if pos is given the first numeric digit in the subsequence so the numStart1 and numStart2 must be first digit in each string. compare(): Line 223: if strings typically have non-numeric prefixes, it might perform slightly better to detect the end of the common prefix and then scan back to find the beginning of the numeric part. (Avoiding checking every char for isDigit). Line 224: If assigned for every digit, it will hold the last equal digit in the common prefix, not the first digit. 239, 240: chars at o1(index) and o2(index) are already known to be digits, can it be avoided checking them twice by starting at index+1? $.02, Roger On 7/19/2017 4:41 AM, Ivan Gerasimov wrote: > Hello! > > It is a proposal to provide a String comparator, which will pay > attention to the numbers embedded into the strings (should they present). > > This proposal was initially discussed back in 2014 and seemed to bring > some interest from the community: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html > > > In the latest webrev two methods are added to the public API: > j.u.Comparator.comparingNumerically() and > j.u.Comparator.comparingNumericallyLeadingZerosAhead(). > > The regression test is extended to exercise this new comparator. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 > WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ > > Comments, suggestions are very welcome! > From mandy.chung at oracle.com Mon Jul 24 17:15:23 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 24 Jul 2017 10:15:23 -0700 Subject: JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java In-Reply-To: <933abb50-7bae-5fb0-45fb-c12d494a4842@oracle.com> References: <846D7A40-148A-4BCB-99FE-0744DE198A6D@oracle.com> <933abb50-7bae-5fb0-45fb-c12d494a4842@oracle.com> Message-ID: <7D8763A3-8A35-46B1-8ED1-977A165C89BD@oracle.com> > On Jul 17, 2017, at 12:49 AM, Amy Lu wrote: > > On 7/14/17 4:41 PM, Mandy Chung wrote: >> I think compiling the other classes to a destination explicitly to replace: >> 29 * @build Alice Bob SupAlice SupBob >> 30 * @run driver SetupLoader >> >> will make the test clearer. It?d be good to make that change. > > Webrev updated: http://cr.openjdk.java.net/~amlu/8183377/webrev.01/ Looks good. One minor suggestion is to place the source files under a directory showing its package hierachy e.g. src/comSA/Alice.java, src/comSB/Bob.java No need for a new webrev. thanks Mandy From jonathan.gibbons at oracle.com Mon Jul 24 20:07:49 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 24 Jul 2017 13:07:49 -0700 Subject: RFR: 8185150: javax/activation/CommandInfo.html has empty

Message-ID: <59765395.2060703@oracle.com> Please review a trivial fix to remove a superfluous

in a javadoc comment. No webrev; here is the patch: $ hg diff -R jaxws diff -r 97e67df03f88 src/java.activation/share/classes/javax/activation/CommandInfo.java --- a/src/java.activation/share/classes/javax/activation/CommandInfo.java Thu Jul 20 18:17:14 2017 +0000 +++ b/src/java.activation/share/classes/javax/activation/CommandInfo.java Mon Jul 24 13:03:03 2017 -0700 @@ -112,7 +112,7 @@ * this method will check if it implements the * java.io.Externalizable interface. If it does, the bean's * readExternal method will be called if an InputStream - * can be acquired from the DataHandler.

+ * can be acquired from the DataHandler. * * @param dh The DataHandler that describes the data to be * passed to the command. JBS: https://bugs.openjdk.java.net/browse/JDK-8185150 -- Jon From lance.andersen at oracle.com Mon Jul 24 20:16:52 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 24 Jul 2017 16:16:52 -0400 Subject: RFR: 8185150: javax/activation/CommandInfo.html has empty

In-Reply-To: <59765395.2060703@oracle.com> References: <59765395.2060703@oracle.com> Message-ID: +1 > On Jul 24, 2017, at 4:07 PM, Jonathan Gibbons wrote: > > Please review a trivial fix to remove a superfluous

in a javadoc comment. > > No webrev; here is the patch: > > $ hg diff -R jaxws > diff -r 97e67df03f88 src/java.activation/share/classes/javax/activation/CommandInfo.java > --- a/src/java.activation/share/classes/javax/activation/CommandInfo.java Thu Jul 20 18:17:14 2017 +0000 > +++ b/src/java.activation/share/classes/javax/activation/CommandInfo.java Mon Jul 24 13:03:03 2017 -0700 > @@ -112,7 +112,7 @@ > * this method will check if it implements the > * java.io.Externalizable interface. If it does, the bean's > * readExternal method will be called if an InputStream > - * can be acquired from the DataHandler.

> + * can be acquired from the DataHandler. > * > * @param dh The DataHandler that describes the data to be > * passed to the command. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185150 > > -- Jon Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jonathan.gibbons at oracle.com Mon Jul 24 20:20:37 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 24 Jul 2017 13:20:37 -0700 Subject: RFR: 8185150: javax/activation/CommandInfo.html has empty

In-Reply-To: References: <59765395.2060703@oracle.com> Message-ID: <59765695.3090901@oracle.com> Thanks, Lance. -- Jon On 07/24/2017 01:16 PM, Lance Andersen wrote: > +1 >> On Jul 24, 2017, at 4:07 PM, Jonathan Gibbons >> > wrote: >> >> Please review a trivial fix to remove a superfluous

in a javadoc >> comment. >> >> No webrev; here is the patch: >> >> $ hg diff -R jaxws >> diff -r 97e67df03f88 >> src/java.activation/share/classes/javax/activation/CommandInfo.java >> --- >> a/src/java.activation/share/classes/javax/activation/CommandInfo.java >> Thu Jul 20 18:17:14 2017 +0000 >> +++ >> b/src/java.activation/share/classes/javax/activation/CommandInfo.java >> Mon Jul 24 13:03:03 2017 -0700 >> @@ -112,7 +112,7 @@ >> * this method will check if it implements the >> * java.io.Externalizable interface. If it does, the bean's >> * readExternal method will be called if an InputStream >> - * can be acquired from the DataHandler.

>> + * can be acquired from the DataHandler. >> * >> * @param dh The DataHandler that describes the data to be >> * passed to the command. >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8185150 >> >> -- Jon > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From jonathan.gibbons at oracle.com Mon Jul 24 20:44:01 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 24 Jul 2017 13:44:01 -0700 Subject: RFR: JDK-8184217: Redundant

tag before list Message-ID: <59765C11.2050005@oracle.com> Please review a small fix to the documentation for the java.rmi module. No webrev; here is the patch to remove an unnecessary line: $ hg diff -R jdk diff -r 13119f57b8da src/java.rmi/share/classes/module-info.java --- a/src/java.rmi/share/classes/module-info.java Mon Jul 24 10:18:33 2017 -0400 +++ b/src/java.rmi/share/classes/module-info.java Mon Jul 24 13:37:15 2017 -0700 @@ -31,7 +31,6 @@ * object registry, and the {@index rmid rmid tool} tool to start * the activation system daemon. * - *

*

*
Tool Guides:
*
{@extLink rmiregistry_tool_reference rmiregistry}, JBS: https://bugs.openjdk.java.net/browse/JDK-8184217 -- Jon From lance.andersen at oracle.com Mon Jul 24 20:53:14 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 24 Jul 2017 16:53:14 -0400 Subject: RFR: JDK-8184217: Redundant

tag before list In-Reply-To: <59765C11.2050005@oracle.com> References: <59765C11.2050005@oracle.com> Message-ID: +1 > On Jul 24, 2017, at 4:44 PM, Jonathan Gibbons wrote: > > Please review a small fix to the documentation for the java.rmi module. > > No webrev; here is the patch to remove an unnecessary line: > > $ hg diff -R jdk > diff -r 13119f57b8da src/java.rmi/share/classes/module-info.java > --- a/src/java.rmi/share/classes/module-info.java Mon Jul 24 10:18:33 2017 -0400 > +++ b/src/java.rmi/share/classes/module-info.java Mon Jul 24 13:37:15 2017 -0700 > @@ -31,7 +31,6 @@ > * object registry, and the {@index rmid rmid tool} tool to start > * the activation system daemon. > * > - *

> *

> *
Tool Guides:
> *
{@extLink rmiregistry_tool_reference rmiregistry}, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184217 > > -- Jon Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Mon Jul 24 23:37:26 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 24 Jul 2017 16:37:26 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> Message-ID: Vladimir, I believe you don?t want to add the dependency from JVMCI to java.management. Otherwise, JVMCI can?t run with only java.base. Is the MBean in jdk.internal.vm.compiler or in Lab?s Graal compiler? src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/src/jdk/vm/ci/services/internal/JVMCIMXBeans.java - I suspect this file meant to be in src/jdk.internal.vm.ci/share/classes/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/internal/JVMCIMXBeans.java Mandy > On Jul 12, 2017, at 2:20 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8182701 > webrev: > http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ > http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ > > Contributed by Jaroslav Tulach. > > JDK itself contains quite a lot of platform MBeans which get registered "on demand". Graal compiler (jdk.internal.vm.compiler) provides its own MBean(s) - however currently there is no way to register it "on demand". JDK9 already contains support for collecting platform MBeans from various modules. We just need to expose Graal MBean through JVMCI. > > Thanks, > Vladimir From doug.simon at oracle.com Tue Jul 25 08:33:16 2017 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 25 Jul 2017 10:33:16 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> Message-ID: <70D79D86-E20A-4D7B-9EF3-04DD0C3FA2A4@oracle.com> > On 25 Jul 2017, at 01:37, Mandy Chung wrote: > > Vladimir, > > I believe you don?t want to add the dependency from JVMCI to java.management. Otherwise, JVMCI can?t run with only java.base. The dependency is unfortunate. Can you suggest how JVMCI platform beans could participate in platform bean registration without the dependency? > Is the MBean in jdk.internal.vm.compiler or in Lab?s Graal compiler? Anything in Lab?s Graal compiler is destined for JDK Graal so the distinction is only temporary at best. > > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/src/jdk/vm/ci/services/internal/JVMCIMXBeans.java > - I suspect this file meant to be in src/jdk.internal.vm.ci/share/classes/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/internal/JVMCIMXBeans.java Not sure I follow - there is currently no such directory src/jdk.internal.vm.ci/share/classes/src -Doug >> On Jul 12, 2017, at 2:20 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8182701 >> webrev: >> http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ >> http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ >> >> Contributed by Jaroslav Tulach. >> >> JDK itself contains quite a lot of platform MBeans which get registered "on demand". Graal compiler (jdk.internal.vm.compiler) provides its own MBean(s) - however currently there is no way to register it "on demand". JDK9 already contains support for collecting platform MBeans from various modules. We just need to expose Graal MBean through JVMCI. >> >> Thanks, >> Vladimir > From Ulf.Zibis at CoSoCo.de Tue Jul 25 11:14:18 2017 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 25 Jul 2017 13:14:18 +0200 Subject: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly In-Reply-To: References: Message-ID: <996062e3-fead-39f8-9564-43868650a817@CoSoCo.de> Hi, Am 23.07.2017 um 15:37 schrieb Claes Redestad: > 1. it reduces the size of the generated bytecode, which is necessary > to keep code below method bytecode limits if the arrays generated are > very large I always was wondering why filling large lookup tables is done by static java code in the class. Wouldn't it be more clever, to load the lookup table content from a binary resource file? Then we must not bother to initialize tables by static fake strings to save bytecode footprint. The same thoughts would apply to the charset mappings in sun.nio.charset classes. -Ulf From claes.redestad at oracle.com Tue Jul 25 11:28:30 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 25 Jul 2017 13:28:30 +0200 Subject: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly In-Reply-To: <996062e3-fead-39f8-9564-43868650a817@CoSoCo.de> References: <996062e3-fead-39f8-9564-43868650a817@CoSoCo.de> Message-ID: <8b5059ba-b8c0-6acf-f6c6-2ebb52230e68@oracle.com> Hi, On 07/25/2017 01:14 PM, Ulf Zibis wrote: > Hi, > > > Am 23.07.2017 um 15:37 schrieb Claes Redestad: >> 1. it reduces the size of the generated bytecode, which is necessary >> to keep code below method bytecode limits if the arrays generated are >> very large > > I always was wondering why filling large lookup tables is done by > static java code in the class. Wouldn't it be more clever, to load the > lookup table content from a binary resource file? Then we must not > bother to initialize tables by static fake strings to save bytecode > footprint. > The same thoughts would apply to the charset mappings in > sun.nio.charset classes. while I think it's something to be avoided for CharacterDataLatin1 (since it's small enough anyway, as shown here), it seems like a fine thing to do to experiment with loading arrays from binary resource files instead of via "fake Strings". As a follow-up, of course. Doing so may have both some good and some bad[1] startup implications, but only an actual experiment will tell if the good outweighs the bad. /Claes [1] Loading some more classes, need to drop into the runtime image from java code etc.. From mandy.chung at oracle.com Tue Jul 25 18:39:04 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 25 Jul 2017 11:39:04 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <70D79D86-E20A-4D7B-9EF3-04DD0C3FA2A4@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <70D79D86-E20A-4D7B-9EF3-04DD0C3FA2A4@oracle.com> Message-ID: > On Jul 25, 2017, at 1:33 AM, Doug Simon wrote: > > >> On 25 Jul 2017, at 01:37, Mandy Chung wrote: >> >> Vladimir, >> >> I believe you don?t want to add the dependency from JVMCI to java.management. Otherwise, JVMCI can?t run with only java.base. > > The dependency is unfortunate. Can you suggest how JVMCI platform beans could participate in platform bean registration without the dependency? > If it exposes a MBean, the dependency would be needed. One consideration might be to separate the JVMCI MBean provider in its own module so that it?s registered only when such module is resolved in the module graph. This way JVMCI can work even if java.management is not present. >> Is the MBean in jdk.internal.vm.compiler or in Lab?s Graal compiler? > > Anything in Lab?s Graal compiler is destined for JDK Graal so the distinction is only temporary at best. > Good to know. >> >> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/src/jdk/vm/ci/services/internal/JVMCIMXBeans.java >> - I suspect this file meant to be in src/jdk.internal.vm.ci/share/classes/src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/internal/JVMCIMXBeans.java > > Not sure I follow - there is currently no such directory src/jdk.internal.vm.ci/share/classes/src Typo - it?s an existing directory: src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/internal Mandy > > -Doug > >>> On Jul 12, 2017, at 2:20 PM, Vladimir Kozlov wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8182701 >>> webrev: >>> http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ >>> http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ >>> >>> Contributed by Jaroslav Tulach. >>> >>> JDK itself contains quite a lot of platform MBeans which get registered "on demand". Graal compiler (jdk.internal.vm.compiler) provides its own MBean(s) - however currently there is no way to register it "on demand". JDK9 already contains support for collecting platform MBeans from various modules. We just need to expose Graal MBean through JVMCI. >>> >>> Thanks, >>> Vladimir >> > From xueming.shen at oracle.com Tue Jul 25 21:09:40 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 25 Jul 2017 14:09:40 -0700 Subject: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly In-Reply-To: References: Message-ID: <5977B394.8020306@oracle.com> +1 On 7/23/17, 6:37 AM, Claes Redestad wrote: > Hi, > > java.lang.CharacterDataLatin1 and others are generated at build time > by the GenerateCharacter tool, which has a -string mode to generate > lookup tables as Strings literals rather than arrays directly. This > serves multiple purposes: > > 1. it reduces the size of the generated bytecode, which is necessary > to keep code below method bytecode limits if the arrays generated are > very large > 2. it may under certain circumstances (large enough arrays, JITed > code) be a performance optimization > > While having other performance benefits, the compact strings feature > that went into 9 made String::toCharArray less friendly to startup, > and since the same feature means we're now always loading > CharacterDataLatin1 on bootstrap in all locales it seemed reasonable > to re-examine whether this class in particular really gains from > generating its lookup tables via String literals. > > Turns out it doesn't. By generating CharacterDataLatin1 tables as > arrays explicitly: > > - executed bytecode drop from 21,782 to 2,077 when initializing this > class (approximately 2% of executed bytecode; 1.5% of total instructions) > - slight reduction (~1Kb) in the minimum retained heap usage > - the size of CharacterDataLatin1.class only grows from 6458 to 7385 > bytes > > Proposed patch is to drop passing -string to GenerateCharacter for the > latin1 case: > > Webrev: http://cr.openjdk.java.net/~redestad/8185104/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8185104 > > Thanks! > > /Claes From andrey.x.nazarov at oracle.com Tue Jul 25 22:59:25 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 25 Jul 2017 15:59:25 -0700 Subject: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file In-Reply-To: References: Message-ID: Can anyone look? ?Thanks, Andrei > On 19 Jul 2017, at 18:21, Andrey Nazarov wrote: > > Hi, > > Could you review fix in test library which should help to resolve intermittent issues on Windows machines during directories clean up. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 > Review: http://cr.openjdk.java.net/~anazarov/JDK-8184961/webrev.00/webrev/ > > > ?Andrei From andrey.x.nazarov at oracle.com Tue Jul 25 22:59:54 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 25 Jul 2017 15:59:54 -0700 Subject: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider In-Reply-To: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> References: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> Message-ID: <49D81AE4-2A43-40D7-BC90-D8CB8BEB8047@oracle.com> Can anyone look? ?Thanks, Andrei > On 21 Jul 2017, at 18:35, Andrey Nazarov wrote: > > Hi, > > Please review changes in launcher tests. I?ve added absent @modules jtreg tags. > > Review: http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.00/webrev/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8179292 > > ?Andrei From mandy.chung at oracle.com Tue Jul 25 23:12:35 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 25 Jul 2017 16:12:35 -0700 Subject: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider In-Reply-To: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> References: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> Message-ID: <9C185A83-6F5D-4A9E-831F-DB46356EF63B@oracle.com> > On Jul 21, 2017, at 6:35 PM, Andrey Nazarov wrote: > > Hi, > > Please review changes in launcher tests. I?ve added absent @modules jtreg tags. > > Review: http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.00/webrev/ A few tests only require java.compiler but not jdk.compiler. Maybe TestHelper should be updated to use java.util.spi.ToolProvider to find ?javac? to avoid the dependency to java.compiler if no compiler is needed. test/tools/launcher/modules/upgrademodulepath/UpgradeModulePathTest.java - can you keep @modules list in alphabetical order. Mandy From brian.burkhalter at oracle.com Tue Jul 25 23:41:07 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 25 Jul 2017 16:41:07 -0700 Subject: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file In-Reply-To: References: Message-ID: <9EDF7199-8FA3-4C2E-8792-E36E456B8778@oracle.com> Hi Andrei, I think this looks good. Thanks, Brian On Jul 25, 2017, at 3:59 PM, Andrey Nazarov wrote: > Can anyone look? > > ?Thanks, > Andrei >> On 19 Jul 2017, at 18:21, Andrey Nazarov wrote: >> >> Hi, >> >> Could you review fix in test library which should help to resolve intermittent issues on Windows machines during directories clean up. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 >> Review: http://cr.openjdk.java.net/~anazarov/JDK-8184961/webrev.00/webrev/ >> >> >> ?Andrei From andrey.x.nazarov at oracle.com Wed Jul 26 00:08:32 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 25 Jul 2017 17:08:32 -0700 Subject: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file In-Reply-To: <9EDF7199-8FA3-4C2E-8792-E36E456B8778@oracle.com> References: <9EDF7199-8FA3-4C2E-8792-E36E456B8778@oracle.com> Message-ID: <32378F69-FDE6-4DAC-86D0-9F150F446442@oracle.com> Thanks, Brian ?Andrei > On 25 Jul 2017, at 16:41, Brian Burkhalter wrote: > > Hi Andrei, > > I think this looks good. > > Thanks, > > Brian > > On Jul 25, 2017, at 3:59 PM, Andrey Nazarov wrote: > >> Can anyone look? >> >> ?Thanks, >> Andrei >>> On 19 Jul 2017, at 18:21, Andrey Nazarov wrote: >>> >>> Hi, >>> >>> Could you review fix in test library which should help to resolve intermittent issues on Windows machines during directories clean up. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 >>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8184961/webrev.00/webrev/ >>> >>> >>> ?Andrei > From andrey.x.nazarov at oracle.com Wed Jul 26 00:29:02 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 25 Jul 2017 17:29:02 -0700 Subject: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider In-Reply-To: <9C185A83-6F5D-4A9E-831F-DB46356EF63B@oracle.com> References: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> <9C185A83-6F5D-4A9E-831F-DB46356EF63B@oracle.com> Message-ID: <8E736A7E-8782-4232-B0C9-CCACE214109A@oracle.com> Thanks, Mandy I?ve updated patch http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.01/webrev/ ?Andrei > On 25 Jul 2017, at 16:12, Mandy Chung wrote: > > >> On Jul 21, 2017, at 6:35 PM, Andrey Nazarov wrote: >> >> Hi, >> >> Please review changes in launcher tests. I?ve added absent @modules jtreg tags. >> >> Review: http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.00/webrev/ > > A few tests only require java.compiler but not jdk.compiler. Maybe TestHelper should be updated to use java.util.spi.ToolProvider to find ?javac? to avoid the dependency to java.compiler if no compiler is needed. > > test/tools/launcher/modules/upgrademodulepath/UpgradeModulePathTest.java > - can you keep @modules list in alphabetical order. > > Mandy From mandy.chung at oracle.com Wed Jul 26 01:01:45 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 25 Jul 2017 18:01:45 -0700 Subject: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider In-Reply-To: <8E736A7E-8782-4232-B0C9-CCACE214109A@oracle.com> References: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> <9C185A83-6F5D-4A9E-831F-DB46356EF63B@oracle.com> <8E736A7E-8782-4232-B0C9-CCACE214109A@oracle.com> Message-ID: <65D774B9-1EA5-4F9F-8520-0506AA7DB1BB@oracle.com> > On Jul 25, 2017, at 5:29 PM, Andrey Nazarov wrote: > > Thanks, Mandy > I?ve updated patch http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.01/webrev/ > Thanks for the update. One suggestion: you could simply change line 133 to compiler = java.util.spi.ToolProvider.findFirst("javac?).orElse(null); Or, no need for saving the compiler but instead have getCompiler() to return: return java.util.spi.ToolProvider.findFirst("javac?).orElseThrow(() -> throw new RuntimeException(?javac not found?)); Mandy > ?Andrei >> On 25 Jul 2017, at 16:12, Mandy Chung > wrote: >> >> >>> On Jul 21, 2017, at 6:35 PM, Andrey Nazarov > wrote: >>> >>> Hi, >>> >>> Please review changes in launcher tests. I?ve added absent @modules jtreg tags. >>> >>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.00/webrev/ > >> >> A few tests only require java.compiler but not jdk.compiler. Maybe TestHelper should be updated to use java.util.spi.ToolProvider to find ?javac? to avoid the dependency to java.compiler if no compiler is needed. >> >> test/tools/launcher/modules/upgrademodulepath/UpgradeModulePathTest.java >> - can you keep @modules list in alphabetical order. >> >> Mandy > From andrey.x.nazarov at oracle.com Wed Jul 26 01:18:39 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 25 Jul 2017 18:18:39 -0700 Subject: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider In-Reply-To: <65D774B9-1EA5-4F9F-8520-0506AA7DB1BB@oracle.com> References: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> <9C185A83-6F5D-4A9E-831F-DB46356EF63B@oracle.com> <8E736A7E-8782-4232-B0C9-CCACE214109A@oracle.com> <65D774B9-1EA5-4F9F-8520-0506AA7DB1BB@oracle.com> Message-ID: <8A88B380-4BB2-4073-81C7-3127E8D04F52@oracle.com> > On 25 Jul 2017, at 18:01, Mandy Chung wrote: > > >> On Jul 25, 2017, at 5:29 PM, Andrey Nazarov > wrote: >> >> Thanks, Mandy >> I?ve updated patch http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.01/webrev/ >> > > Thanks for the update. > > One suggestion: you could simply change line 133 to > compiler = java.util.spi.ToolProvider.findFirst("javac?).orElse(null); Updated by this line. http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.02/webrev/ > Or, no need for saving the compiler but instead have getCompiler() to return: > > return java.util.spi.ToolProvider.findFirst("javac?).orElseThrow(() -> > throw new RuntimeException(?javac not found?)); > > Mandy > >> ?Andrei >>> On 25 Jul 2017, at 16:12, Mandy Chung > wrote: >>> >>> >>>> On Jul 21, 2017, at 6:35 PM, Andrey Nazarov > wrote: >>>> >>>> Hi, >>>> >>>> Please review changes in launcher tests. I?ve added absent @modules jtreg tags. >>>> >>>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.00/webrev/ > >>> >>> A few tests only require java.compiler but not jdk.compiler. Maybe TestHelper should be updated to use java.util.spi.ToolProvider to find ?javac? to avoid the dependency to java.compiler if no compiler is needed. >>> >>> test/tools/launcher/modules/upgrademodulepath/UpgradeModulePathTest.java >>> - can you keep @modules list in alphabetical order. >>> >>> Mandy >> > From mandy.chung at oracle.com Wed Jul 26 01:20:36 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 25 Jul 2017 18:20:36 -0700 Subject: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider In-Reply-To: <8A88B380-4BB2-4073-81C7-3127E8D04F52@oracle.com> References: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> <9C185A83-6F5D-4A9E-831F-DB46356EF63B@oracle.com> <8E736A7E-8782-4232-B0C9-CCACE214109A@oracle.com> <65D774B9-1EA5-4F9F-8520-0506AA7DB1BB@oracle.com> <8A88B380-4BB2-4073-81C7-3127E8D04F52@oracle.com> Message-ID: <168AB469-874A-48B6-B201-49B25C572892@oracle.com> > On Jul 25, 2017, at 6:18 PM, Andrey Nazarov wrote: > > > Updated by this line. http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.02/webrev/ Looks good. Mandy From amy.lu at oracle.com Wed Jul 26 01:24:54 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 26 Jul 2017 09:24:54 +0800 Subject: JDK 10 RFR of JDK-8183377: Refactor java/lang/ClassLoader/deadlock shell tests to java In-Reply-To: <7D8763A3-8A35-46B1-8ED1-977A165C89BD@oracle.com> References: <846D7A40-148A-4BCB-99FE-0744DE198A6D@oracle.com> <933abb50-7bae-5fb0-45fb-c12d494a4842@oracle.com> <7D8763A3-8A35-46B1-8ED1-977A165C89BD@oracle.com> Message-ID: <29657f65-e853-b6d1-1004-574c79f3d840@oracle.com> On 7/25/17 1:15 AM, Mandy Chung wrote: >> Webrev updated:http://cr.openjdk.java.net/~amlu/8183377/webrev.01/ > Looks good. One minor suggestion is to place the source files under a directory showing its package hierachy e.g. src/comSA/Alice.java, src/comSB/Bob.java > > No need for a new webrev. Thank you Mandy for reviewing. Pushed with change as suggested. Thanks, Amy From andrey.x.nazarov at oracle.com Wed Jul 26 01:30:34 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Tue, 25 Jul 2017 18:30:34 -0700 Subject: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider In-Reply-To: <168AB469-874A-48B6-B201-49B25C572892@oracle.com> References: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> <9C185A83-6F5D-4A9E-831F-DB46356EF63B@oracle.com> <8E736A7E-8782-4232-B0C9-CCACE214109A@oracle.com> <65D774B9-1EA5-4F9F-8520-0506AA7DB1BB@oracle.com> <8A88B380-4BB2-4073-81C7-3127E8D04F52@oracle.com> <168AB469-874A-48B6-B201-49B25C572892@oracle.com> Message-ID: Thank you! > On 25 Jul 2017, at 18:20, Mandy Chung wrote: > > >> On Jul 25, 2017, at 6:18 PM, Andrey Nazarov > wrote: >> >> >> Updated by this line. http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.02/webrev/ > > > Looks good. > > Mandy > From kumar.x.srinivasan at oracle.com Wed Jul 26 15:14:54 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 26 Jul 2017 08:14:54 -0700 Subject: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider In-Reply-To: References: <2B0D45C0-4319-4DA1-9DDE-01206533C26B@oracle.com> <9C185A83-6F5D-4A9E-831F-DB46356EF63B@oracle.com> <8E736A7E-8782-4232-B0C9-CCACE214109A@oracle.com> <65D774B9-1EA5-4F9F-8520-0506AA7DB1BB@oracle.com> <8A88B380-4BB2-4073-81C7-3127E8D04F52@oracle.com> <168AB469-874A-48B6-B201-49B25C572892@oracle.com> Message-ID: <5978B1EE.6020604@oracle.com> +1 Kumar On 7/25/2017 6:30 PM, Andrey Nazarov wrote: > Thank you! >> On 25 Jul 2017, at 18:20, Mandy Chung wrote: >> >> >>> On Jul 25, 2017, at 6:18 PM, Andrey Nazarov > wrote: >>> >>> >>> Updated by this line. http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.02/webrev/ >> >> Looks good. >> >> Mandy >> From mandy.chung at oracle.com Wed Jul 26 15:59:43 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 26 Jul 2017 08:59:43 -0700 Subject: RFR: JDK-8183579: refactor and cleanup launcher help messages In-Reply-To: <5970FC47.3060509@oracle.com> References: <5970FC47.3060509@oracle.com> Message-ID: <617202EB-4621-43A0-A850-2BAFBE7FF8F8@oracle.com> > On Jul 20, 2017, at 11:53 AM, Kumar Srinivasan wrote: > > Hi, > > Please review refactoring and clean up of the java launcher's help/usage > messages. > > The highlights of the changes are as follows: > > 1. Helper.java: is renamed from LauncherHelper.java, simpler name, > containing mostly methods to help with class loading, module assistance etc. > There are tests depending on `sun.launcher.LauncherHelper` class name. I actually like LauncherHelper better than Helper to make it clear what it is just by its simple name. > > Webrev: > http://cr.openjdk.java.net/~ksrini/8183579/webrev.00/ launcher.properties 40 # Translators please note do not translate the options themselves Option names are no longer in the resource bundle. It would be helpful to add the comment describing the key name java.launcher.opt.$OPTION_NAME.param java.launcher.opt.$OPTION_NAME.desc A newline between each option may help readability. Since the whitespace in description is irrelevant, maybe keep the indentation to 4 space? Does the help message show the options in the order listed here? I would hope it uses the order of the Option enums. If so, we could list them in alphabetical order in launcher.properties. 80 java.launcher.opt.x.desc = print help on extra options to the error stream Should $OPTION_NAME match the option name (rather than toLowerCase)? OptionsHelper.java 311 Arrays.asList(Option.values()).stream() Alternative: Stream(Option.values()) This class includes the entry point for -XshowSettings but not other options such as ?-list-modules. It may cause confusion to which class a new launcher option is added. It may be okay. Maybe just move the code for printing the help messages in Option class and consider the refactoring for -XshowSetting and other options in the future. Mandy From hohensee at amazon.com Wed Jul 26 17:03:54 2017 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 26 Jul 2017 17:03:54 +0000 Subject: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file In-Reply-To: <32378F69-FDE6-4DAC-86D0-9F150F446442@oracle.com> References: <9EDF7199-8FA3-4C2E-8792-E36E456B8778@oracle.com> <32378F69-FDE6-4DAC-86D0-9F150F446442@oracle.com> Message-ID: <7BE6B120-8100-4A6B-9560-DF5008E74D39@amazon.com> A double negative (!Files.notExists) somewhat unusual coding and will perplex people reading it. They might even switch it back to Files.exists as a style cleanup, so I recommend adding a comment explaining why you?re using it. Thanks, Paul On 7/25/17, 5:08 PM, "core-libs-dev on behalf of Andrey Nazarov" wrote: Thanks, Brian ?Andrei > On 25 Jul 2017, at 16:41, Brian Burkhalter wrote: > > Hi Andrei, > > I think this looks good. > > Thanks, > > Brian > > On Jul 25, 2017, at 3:59 PM, Andrey Nazarov wrote: > >> Can anyone look? >> >> ?Thanks, >> Andrei >>> On 19 Jul 2017, at 18:21, Andrey Nazarov wrote: >>> >>> Hi, >>> >>> Could you review fix in test library which should help to resolve intermittent issues on Windows machines during directories clean up. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 >>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8184961/webrev.00/webrev/ >>> >>> >>> ?Andrei > From jonathan.gibbons at oracle.com Wed Jul 26 18:57:04 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 26 Jul 2017 11:57:04 -0700 Subject: RFR: JDK-8185359: Unnecessary

in module doc comment Message-ID: <5978E600.9090301@oracle.com> Continuing the ongoing docs cleanup, please review this fix to remove a superfluous

in the docs for the java.scripting module. No webrev; just one line deleted, as shown here: $ hg diff -R jdk diff -r d93f2fd542b7 src/java.scripting/share/classes/module-info.java --- a/src/java.scripting/share/classes/module-info.java Tue Jul 25 18:36:19 2017 -0700 +++ b/src/java.scripting/share/classes/module-info.java Wed Jul 26 11:49:07 2017 -0700 @@ -31,7 +31,6 @@ * that supports executing JavaScript and other languages if its corresponding * script engine is installed. * - *

*

*
Tool Guides: *
{@extLink jrunscript_tool_reference jrunscript}
JBS: https://bugs.openjdk.java.net/browse/JDK-8185359 -- Jon From lance.andersen at oracle.com Wed Jul 26 19:09:50 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 26 Jul 2017 15:09:50 -0400 Subject: RFR: JDK-8185359: Unnecessary

in module doc comment In-Reply-To: <5978E600.9090301@oracle.com> References: <5978E600.9090301@oracle.com> Message-ID: <89993D12-361E-49B5-828F-09451269AE4E@oracle.com> +1 > On Jul 26, 2017, at 2:57 PM, Jonathan Gibbons wrote: > > Continuing the ongoing docs cleanup, please review this fix to remove a superfluous

> in the docs for the java.scripting module. > > No webrev; just one line deleted, as shown here: > > $ hg diff -R jdk > diff -r d93f2fd542b7 src/java.scripting/share/classes/module-info.java > --- a/src/java.scripting/share/classes/module-info.java Tue Jul 25 18:36:19 2017 -0700 > +++ b/src/java.scripting/share/classes/module-info.java Wed Jul 26 11:49:07 2017 -0700 > @@ -31,7 +31,6 @@ > * that supports executing JavaScript and other languages if its corresponding > * script engine is installed. > * > - *

> *

> *
Tool Guides: > *
{@extLink jrunscript_tool_reference jrunscript}
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8185359 > > -- Jon Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From chris.hegarty at oracle.com Wed Jul 26 19:31:37 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 26 Jul 2017 20:31:37 +0100 Subject: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file In-Reply-To: <7BE6B120-8100-4A6B-9560-DF5008E74D39@amazon.com> References: <9EDF7199-8FA3-4C2E-8792-E36E456B8778@oracle.com> <32378F69-FDE6-4DAC-86D0-9F150F446442@oracle.com> <7BE6B120-8100-4A6B-9560-DF5008E74D39@amazon.com> Message-ID: > On 26 Jul 2017, at 18:03, Hohensee, Paul wrote: > > A double negative (!Files.notExists) somewhat unusual coding and will perplex people reading it. They might even switch it back to Files.exists as a style cleanup, so I recommend adding a comment explaining why you?re using it. As the original author of this code, +1000 -Chris. > Thanks, > > Paul > > On 7/25/17, 5:08 PM, "core-libs-dev on behalf of Andrey Nazarov" wrote: > > Thanks, Brian > > ?Andrei >> On 25 Jul 2017, at 16:41, Brian Burkhalter wrote: >> >> Hi Andrei, >> >> I think this looks good. >> >> Thanks, >> >> Brian >> >>> On Jul 25, 2017, at 3:59 PM, Andrey Nazarov wrote: >>> >>> Can anyone look? >>> >>> ?Thanks, >>> Andrei >>>> On 19 Jul 2017, at 18:21, Andrey Nazarov wrote: >>>> >>>> Hi, >>>> >>>> Could you review fix in test library which should help to resolve intermittent issues on Windows machines during directories clean up. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 >>>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8184961/webrev.00/webrev/ >>>> >>>> >>>> ?Andrei >> > > > From andrey.x.nazarov at oracle.com Wed Jul 26 19:45:23 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 26 Jul 2017 12:45:23 -0700 Subject: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file In-Reply-To: References: <9EDF7199-8FA3-4C2E-8792-E36E456B8778@oracle.com> <32378F69-FDE6-4DAC-86D0-9F150F446442@oracle.com> <7BE6B120-8100-4A6B-9560-DF5008E74D39@amazon.com> Message-ID: <58779F1E-AC18-437D-95D4-9427722B3FB0@oracle.com> > On 26 Jul 2017, at 12:31, Chris Hegarty wrote: > > >> On 26 Jul 2017, at 18:03, Hohensee, Paul wrote: >> >> A double negative (!Files.notExists) somewhat unusual coding and will perplex people reading it. They might even switch it back to Files.exists as a style cleanup, so I recommend adding a comment explaining why you?re using it. > > As the original author of this code, +1000 Code has been pushed. I?ll create new issue for that :) ?Andrei > > -Chris. > > >> Thanks, >> >> Paul >> >> On 7/25/17, 5:08 PM, "core-libs-dev on behalf of Andrey Nazarov" wrote: >> >> Thanks, Brian >> >> ?Andrei >>> On 25 Jul 2017, at 16:41, Brian Burkhalter wrote: >>> >>> Hi Andrei, >>> >>> I think this looks good. >>> >>> Thanks, >>> >>> Brian >>> >>>> On Jul 25, 2017, at 3:59 PM, Andrey Nazarov wrote: >>>> >>>> Can anyone look? >>>> >>>> ?Thanks, >>>> Andrei >>>>> On 19 Jul 2017, at 18:21, Andrey Nazarov wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could you review fix in test library which should help to resolve intermittent issues on Windows machines during directories clean up. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 >>>>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8184961/webrev.00/webrev/ >>>>> >>>>> >>>>> ?Andrei >>> >> >> >> > From mandy.chung at oracle.com Wed Jul 26 19:57:18 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 26 Jul 2017 12:57:18 -0700 Subject: RFR: JDK-8185359: Unnecessary

in module doc comment In-Reply-To: <5978E600.9090301@oracle.com> References: <5978E600.9090301@oracle.com> Message-ID: <55889A69-DC90-4E4C-8D4B-2748CB81DA53@oracle.com> +1 Mandy > On Jul 26, 2017, at 11:57 AM, Jonathan Gibbons wrote: > > Continuing the ongoing docs cleanup, please review this fix to remove a superfluous

> in the docs for the java.scripting module. > > No webrev; just one line deleted, as shown here: > > $ hg diff -R jdk > diff -r d93f2fd542b7 src/java.scripting/share/classes/module-info.java > --- a/src/java.scripting/share/classes/module-info.java Tue Jul 25 18:36:19 2017 -0700 > +++ b/src/java.scripting/share/classes/module-info.java Wed Jul 26 11:49:07 2017 -0700 > @@ -31,7 +31,6 @@ > * that supports executing JavaScript and other languages if its corresponding > * script engine is installed. > * > - *

> *

> *
Tool Guides: > *
{@extLink jrunscript_tool_reference jrunscript}
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8185359 > > -- Jon From andrey.x.nazarov at oracle.com Wed Jul 26 20:22:10 2017 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Wed, 26 Jul 2017 13:22:10 -0700 Subject: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file In-Reply-To: <58779F1E-AC18-437D-95D4-9427722B3FB0@oracle.com> References: <9EDF7199-8FA3-4C2E-8792-E36E456B8778@oracle.com> <32378F69-FDE6-4DAC-86D0-9F150F446442@oracle.com> <7BE6B120-8100-4A6B-9560-DF5008E74D39@amazon.com> <58779F1E-AC18-437D-95D4-9427722B3FB0@oracle.com> Message-ID: Hi, Please review this simple documentation patch diff -r a133a7d1007b test/lib/jdk/test/lib/util/FileUtils.java --- a/test/lib/jdk/test/lib/util/FileUtils.java Tue Jul 25 17:04:46 2017 -0700 +++ b/test/lib/jdk/test/lib/util/FileUtils.java Wed Jul 26 13:20:44 2017 -0700 @@ -98,6 +98,7 @@ while (true) { try { Files.delete(path); + // Checks for absence of the file. Semantics of Files.exists() is not the same. while (!Files.notExists(path)) { times++; if (times > MAX_RETRY_DELETE_TIMES) { ?Andrei > On 26 Jul 2017, at 12:45, Andrey Nazarov wrote: > > >> On 26 Jul 2017, at 12:31, Chris Hegarty wrote: >> >> >>> On 26 Jul 2017, at 18:03, Hohensee, Paul wrote: >>> >>> A double negative (!Files.notExists) somewhat unusual coding and will perplex people reading it. They might even switch it back to Files.exists as a style cleanup, so I recommend adding a comment explaining why you?re using it. >> >> As the original author of this code, +1000 > Code has been pushed. I?ll create new issue for that :) > > ?Andrei >> >> -Chris. >> >> >>> Thanks, >>> >>> Paul >>> >>> On 7/25/17, 5:08 PM, "core-libs-dev on behalf of Andrey Nazarov" wrote: >>> >>> Thanks, Brian >>> >>> ?Andrei >>>> On 25 Jul 2017, at 16:41, Brian Burkhalter wrote: >>>> >>>> Hi Andrei, >>>> >>>> I think this looks good. >>>> >>>> Thanks, >>>> >>>> Brian >>>> >>>>> On Jul 25, 2017, at 3:59 PM, Andrey Nazarov wrote: >>>>> >>>>> Can anyone look? >>>>> >>>>> ?Thanks, >>>>> Andrei >>>>>> On 19 Jul 2017, at 18:21, Andrey Nazarov wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Could you review fix in test library which should help to resolve intermittent issues on Windows machines during directories clean up. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184961 >>>>>> Review: http://cr.openjdk.java.net/~anazarov/JDK-8184961/webrev.00/webrev/ >>>>>> >>>>>> >>>>>> ?Andrei >>>> >>> >>> >>> >> > From mark.reinhold at oracle.com Wed Jul 26 21:09:45 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 26 Jul 2017 14:09:45 -0700 (PDT) Subject: JEP 306: Restore Always-Strict Floating-Point Semantics Message-ID: <20170726210945.AE001983AE@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/306 - Mark From martinrb at google.com Wed Jul 26 21:20:32 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 26 Jul 2017 14:20:32 -0700 Subject: RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570 Message-ID: 1. JDK-8185365 Tidy up leftover dead code after JDK-8136570 http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/ From cushon at google.com Wed Jul 26 22:32:55 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 26 Jul 2017 18:32:55 -0400 Subject: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0 Message-ID: Hello, This change fixes a regression in JDK 9 by allowing the java.util and zipfs zip implementations to read archives where the modified day or month is 0. bug: https://bugs.openjdk.java.net/browse/JDK-8184940 webrev: http://cr.openjdk.java.net/~cushon/8184940/webrev.00/ Thanks, Liam From martinrb at google.com Wed Jul 26 23:12:42 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 26 Jul 2017 16:12:42 -0700 Subject: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0 In-Reply-To: References: Message-ID: Looks good. This should go into jdk10 and later into a jdk9 update. (Will an Oracle engineer volunteer?) I wonder where the "8" in the "Friday the 30th" date comes from. Could your California time zone be leaking into the test? The DOS timestamp is interpreted as local time while Instant.parse uses UTC? Will the test still pass if you run jtreg under TZ=EST? On Wed, Jul 26, 2017 at 3:32 PM, Liam Miller-Cushon wrote: > Hello, > > This change fixes a regression in JDK 9 by allowing the java.util and > zipfs zip implementations to read archives where the modified day or month > is 0. > > bug: https://bugs.openjdk.java.net/browse/JDK-8184940 > webrev: http://cr.openjdk.java.net/~cushon/8184940/webrev.00/ > > Thanks, > Liam > From jaroslav.tulach at oracle.com Thu Jul 27 09:07:20 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 27 Jul 2017 11:07:20 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <70D79D86-E20A-4D7B-9EF3-04DD0C3FA2A4@oracle.com> Message-ID: <4506356.BY5Vv2ZSov@logoutik> Thanks for your review Mandy. >> Mandy Chung : 25.07.17 @ 11:39 << > > On Jul 25, 2017, at 1:33 AM, Doug Simon wrote: > >> On 25 Jul 2017, at 01:37, Mandy Chung wrote: > >> > >> Vladimir, > >> > >> I believe you don?t want to add the dependency from JVMCI to > >> java.management. Otherwise, JVMCI can?t run with only java.base.> > > The dependency is unfortunate. Can you suggest how JVMCI platform beans > > could participate in platform bean registration without the dependency? Yes, it seems like a desirable goal to let Graal compiler work with just java.base. Is there a description how to build JDK9/10 with just java.base that I could follow and test against? > If it exposes a MBean, the dependency would be needed. Isn't there a way to require an optional dependency? That would be sufficient - as the classes in question are only loaded once java.management searches for them. E.g. only when java.management is installed. > One consideration might be to separate the JVMCI MBean provider in its own > module so that it?s registered only when such module is resolved in the > module graph. This way JVMCI can work even if java.management is not > present. Yes, I can create something like jdk.internal.vm.ci.management and move the JVMCIMXBeans.java (to be renamed to JVMCIMBeans.java per Vladimir's suggestion, if I remember correctly) there. This module would have dependency on jdk.internal.vm.ci and java.management and bridge them together. How do I make sure this module is enabled when possible? Or is that automatic? > >> Is the MBean in jdk.internal.vm.compiler or in Lab?s Graal compiler? > > > > Anything in Lab?s Graal compiler is destined for JDK Graal so the > > distinction is only temporary at best. > Good to know. The bean is in there and implements DynamicMBean interface. E.g. this part of Graal compiler module has to have dependency on java.management - that means to make that dependency optional or split the module in two, I assume. > > >> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/src/jdk/vm/ci/ser > >> vices/internal/JVMCIMXBeans.java - I suspect this file meant to be in > >> src/jdk.internal.vm.ci/share/classes/src/jdk.internal.vm.ci/share/classe > >> s/jdk/vm/ci/services/internal/JVMCIMXBeans.java> > > Not sure I follow - there is currently no such directory > > src/jdk.internal.vm.ci/share/classes/src > Typo - it?s an existing directory: > > src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/servic > es/internal The location is probably not correct. I am even surprised the code builds fine. Thanks for catching this. -jt > >>> On Jul 12, 2017, at 2:20 PM, Vladimir Kozlov > >>> wrote: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8182701 > >>> webrev: > >>> http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/ > >>> http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/ > >>> > >>> Contributed by Jaroslav Tulach. > >>> > >>> JDK itself contains quite a lot of platform MBeans which get registered > >>> "on demand". Graal compiler (jdk.internal.vm.compiler) provides its own > >>> MBean(s) - however currently there is no way to register it "on > >>> demand". JDK9 already contains support for collecting platform MBeans > >>> from various modules. We just need to expose Graal MBean through JVMCI. > >>> > >>> Thanks, > >>> Vladimir From chris.hegarty at oracle.com Thu Jul 27 10:11:57 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 27 Jul 2017 11:11:57 +0100 Subject: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file In-Reply-To: References: <9EDF7199-8FA3-4C2E-8792-E36E456B8778@oracle.com> <32378F69-FDE6-4DAC-86D0-9F150F446442@oracle.com> <7BE6B120-8100-4A6B-9560-DF5008E74D39@amazon.com> <58779F1E-AC18-437D-95D4-9427722B3FB0@oracle.com> Message-ID: > On 26 Jul 2017, at 21:22, Andrey Nazarov wrote: > > Hi, > > Please review this simple documentation patch > > diff -r a133a7d1007b test/lib/jdk/test/lib/util/FileUtils.java > --- a/test/lib/jdk/test/lib/util/FileUtils.java Tue Jul 25 17:04:46 2017 -0700 > +++ b/test/lib/jdk/test/lib/util/FileUtils.java Wed Jul 26 13:20:44 2017 -0700 > @@ -98,6 +98,7 @@ > while (true) { > try { > Files.delete(path); > + // Checks for absence of the file. Semantics of Files.exists() is not the same. > while (!Files.notExists(path)) { > times++; > if (times > MAX_RETRY_DELETE_TIMES) { Thank you. Reviewed. -Chris. From Roger.Riggs at Oracle.com Thu Jul 27 13:27:56 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 27 Jul 2017 09:27:56 -0400 Subject: RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570 In-Reply-To: References: Message-ID: <2ef65f3a-5bbf-074e-95df-cb88d409d860@Oracle.com> Look fine Martin. Roger On 7/26/2017 5:20 PM, Martin Buchholz wrote: > 1. JDK-8185365 > > Tidy up leftover dead code after JDK-8136570 > http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/ From Alan.Bateman at oracle.com Thu Jul 27 13:29:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Jul 2017 14:29:52 +0100 Subject: RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570 In-Reply-To: References: Message-ID: <2b13c4e7-98e7-8fda-3611-1eb5275c4cce@oracle.com> On 26/07/2017 22:20, Martin Buchholz wrote: > 1. JDK-8185365 > > Tidy up leftover dead code after JDK-8136570 > http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/ This looks okay to me. -Alan From Alan.Bateman at oracle.com Thu Jul 27 14:01:17 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Jul 2017 15:01:17 +0100 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <4506356.BY5Vv2ZSov@logoutik> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <70D79D86-E20A-4D7B-9EF3-04DD0C3FA2A4@oracle.com> <4506356.BY5Vv2ZSov@logoutik> Message-ID: <7d0b9ec7-5bbb-5f5f-b1e3-f1a771c449ec@oracle.com> On 27/07/2017 10:07, Jaroslav Tulach wrote: > : > Yes, it seems like a desirable goal to let Graal compiler work with just > java.base. Is there a description how to build JDK9/10 with just java.base > that I could follow and test against? You can use jlink to create a run-time image that only contains java.base (jlink --module-path $JAVA_HOME/jmods --add-modules java.base --output smalljre). > >> If it exposes a MBean, the dependency would be needed. > Isn't there a way to require an optional dependency? That would be sufficient - > as the classes in question are only loaded once java.management searches for > them. E.g. only when java.management is installed. There is `requires static` but it would be a lot cleaner if the management support could be refactored into its own service provider module, meaning JVMCIMXBeans would be in its own module. -Alan From philip.race at oracle.com Thu Jul 27 14:13:47 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 27 Jul 2017 07:13:47 -0700 Subject: RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570 In-Reply-To: <2b13c4e7-98e7-8fda-3611-1eb5275c4cce@oracle.com> References: <2b13c4e7-98e7-8fda-3611-1eb5275c4cce@oracle.com> Message-ID: <5979F51B.7030908@oracle.com> Ok by me too ... it would not have crossed my mind to look at ProcessBuilder but I suppose it was trying to support the now deleted behaviours. -phil. On 7/27/17, 6:29 AM, Alan Bateman wrote: > > > On 26/07/2017 22:20, Martin Buchholz wrote: >> 1. JDK-8185365 >> >> Tidy up leftover dead code after JDK-8136570 >> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/ > This looks okay to me. > > -Alan From cushon at google.com Thu Jul 27 18:54:21 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 27 Jul 2017 11:54:21 -0700 Subject: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0 In-Reply-To: References: Message-ID: On Wed, Jul 26, 2017 at 4:12 PM, Martin Buchholz wrote: > I wonder where the "8" in the "Friday the 30th" date comes from. Could > your California time zone be leaking into the test? The DOS timestamp is > interpreted as local time while Instant.parse uses UTC? Will the test > still pass if you run jtreg under TZ=EST? > Thanks, fixed: http://cr.openjdk.java.net/~cushon/8184940/webrev.01/ From jonathan.gibbons at oracle.com Thu Jul 27 20:35:27 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 27 Jul 2017 13:35:27 -0700 Subject: RFR: JDK-8185464: Link issues in java.xml module Message-ID: <597A4E8F.80107@oracle.com> Continuing the documentation cleanup: Please review the following simple changes to the API documentation for the java.xml module, to address issues with links in these files. Some missing ids have been declared as appropriate. The issue with a mailto: link in the public API to an obsolete address has been side-stepped by converting a number of explicit Author and See constructs to the equivalent @author and @see tags. Since we don't publish authors in the generated documentation, that addresses the appearance of the bad mailto: link. I'll leave it to someone else to take on the general task of cleaning up the many references to obsolete @sun.com email addresses in the source code. JBS: https://bugs.openjdk.java.net/browse/JDK-8185464 Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/ API: http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html -- Jon From lance.andersen at oracle.com Thu Jul 27 20:49:22 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 27 Jul 2017 16:49:22 -0400 Subject: RFR: JDK-8185464: Link issues in java.xml module In-Reply-To: <597A4E8F.80107@oracle.com> References: <597A4E8F.80107@oracle.com> Message-ID: Hi Jon, Overall it looks good. Maybe it is my browser, but I do not see the Author tag in the DataType package summary though it is there in JDK 8 and looks like it should still display unless I am missing something? Best Lance > On Jul 27, 2017, at 4:35 PM, Jonathan Gibbons wrote: > > Continuing the documentation cleanup: > > Please review the following simple changes to the API documentation for the java.xml module, > to address issues with links in these files. > > Some missing ids have been declared as appropriate. > > The issue with a mailto: link in the public API to an obsolete address has been side-stepped > by converting a number of explicit Author and See constructs to the equivalent @author and @see > tags. Since we don't publish authors in the generated documentation, that addresses the > appearance of the bad mailto: link. I'll leave it to someone else to take on the general task of > cleaning up the many references to obsolete @sun.com email addresses in the source code. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185464 > Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/ > API: http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html > > -- Jon > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jonathan.gibbons at oracle.com Thu Jul 27 21:10:18 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 27 Jul 2017 14:10:18 -0700 Subject: RFR: JDK-8185464: Link issues in java.xml module In-Reply-To: References: <597A4E8F.80107@oracle.com> Message-ID: <597A56BA.7080505@oracle.com> Lance, It is intentional that the Author designation has disappeared from the javax.xml.datatype package summary. The following lines 154 *
    155 *
  • Author Jeff Suttor
    • were normalized to 152 * @author Jeff Suttor and since we do not use the -author option when generating the main API doc bundle, the author information is not produced in the output. This is the same for all other uses of @author in our source code doc comments. Here is the relevant extract from the command-line help: Provided by the Standard doclet: -author Include @author paragraphs You can see the differences in the generated output for JDK 9: http://download.java.net/java/jdk9/docs/api/javax/xml/datatype/package-summary.html ------------------------------------------------------------------------ * Author Jeff Suttor * See W3C XML Schema 1.0 Part 2, Section 3.2.7-14 * See XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration * See XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration * Since 1.5 ------------------------------------------------------------------------ Since: 1.5 (note the non-standard Author and See entries, and the double "Since" info) and proposed, after the patch, http://cr.openjdk.java.net/~jjg/8185464/api.00/javax/xml/datatype/package-summary.html Since: 1.5 See Also: W3C XML Schema 1.0 Part 2, Section 3.2.7-14 , XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration , XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration -- Jon On 07/27/2017 01:49 PM, Lance Andersen wrote: > Hi Jon, > > Overall it looks good. Maybe it is my browser, but I do not see the > Author tag in the DataType package summary though it is there in JDK 8 > and looks like it should still display unless I am missing something? > > Best > Lance >> On Jul 27, 2017, at 4:35 PM, Jonathan Gibbons >> > wrote: >> >> Continuing the documentation cleanup: >> >> Please review the following simple changes to the API documentation >> for the java.xml module, >> to address issues with links in these files. >> >> Some missing ids have been declared as appropriate. >> >> The issue with a mailto: link in the public API to an obsolete >> address has been side-stepped >> by converting a number of explicit Author and See constructs to the >> equivalent @author and @see >> tags. Since we don't publish authors in the generated documentation, >> that addresses the >> appearance of the bad mailto: link. I'll leave it to someone else to >> take on the general task of >> cleaning up the many references to obsolete @sun.com >> email addresses in the source code. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8185464 >> Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/ >> >> API: >> http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html >> >> >> -- Jon >> >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Thu Jul 27 21:12:12 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 27 Jul 2017 17:12:12 -0400 Subject: RFR: JDK-8185464: Link issues in java.xml module In-Reply-To: <597A56BA.7080505@oracle.com> References: <597A4E8F.80107@oracle.com> <597A56BA.7080505@oracle.com> Message-ID: <409897F4-F050-42D1-A5B7-4DEC0187FF1E@oracle.com> > On Jul 27, 2017, at 5:10 PM, Jonathan Gibbons wrote: > > Lance, > > It is intentional that the Author designation has disappeared from the javax.xml.datatype package summary. I was just about to send another email, as I realized that we were not using -author after I hit send. Thanks for the follow up :-) Best Lance > The following lines > > 154 *
      > 155 *
    • Author >Jeff Suttor
      • > were normalized to > 152 * @author >Jeff Suttor > and since we do not use the -author option when generating the main API doc bundle, the author information is not produced in the output. This is the same for all other uses of @author in our source code doc comments. Here is the relevant extract from the command-line help: > > Provided by the Standard doclet: > -author Include @author paragraphs > > > You can see the differences in the generated output for JDK 9: > http://download.java.net/java/jdk9/docs/api/javax/xml/datatype/package-summary.html > > > Author Jeff Suttor > See W3C XML Schema 1.0 Part 2, Section 3.2.7-14 > See XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration > See XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration > Since 1.5 > Since: > 1.5 > > (note the non-standard Author and See entries, and the double "Since" info) > > and proposed, after the patch, > http://cr.openjdk.java.net/~jjg/8185464/api.00/javax/xml/datatype/package-summary.html > > Since: > 1.5 > See Also: > W3C XML Schema 1.0 Part 2, Section 3.2.7-14 , XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration , XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration > -- Jon > > > > On 07/27/2017 01:49 PM, Lance Andersen wrote: >> Hi Jon, >> >> Overall it looks good. Maybe it is my browser, but I do not see the Author tag in the DataType package summary though it is there in JDK 8 and looks like it should still display unless I am missing something? >> >> Best >> Lance >>> On Jul 27, 2017, at 4:35 PM, Jonathan Gibbons > wrote: >>> >>> Continuing the documentation cleanup: >>> >>> Please review the following simple changes to the API documentation for the java.xml module, >>> to address issues with links in these files. >>> >>> Some missing ids have been declared as appropriate. >>> >>> The issue with a mailto: link in the public API to an obsolete address has been side-stepped >>> by converting a number of explicit Author and See constructs to the equivalent @author and @see >>> tags. Since we don't publish authors in the generated documentation, that addresses the >>> appearance of the bad mailto: link. I'll leave it to someone else to take on the general task of >>> cleaning up the many references to obsolete @sun.com email addresses in the source code. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8185464 >>> Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/ >>> API: http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html >>> >>> -- Jon >>> >>> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Thu Jul 27 23:12:17 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 27 Jul 2017 16:12:17 -0700 Subject: RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570 In-Reply-To: <5979F51B.7030908@oracle.com> References: <2b13c4e7-98e7-8fda-3611-1eb5275c4cce@oracle.com> <5979F51B.7030908@oracle.com> Message-ID: Some ancient history: I wrote those ProcessBuilder tests back in 2005 and tripped over the changes to NLSPATH and XFILESEARCHPATH. I filed a bug back then, but it did not get fixed. I rediscovered those changes a decade later when putenv/getenv was found to be the root cause of SIGSEGV in real world usage. I had forgotten about my workarounds in the ProcessBuilder test; rediscovered by recursive grep, which is still my workhorse code understanding tool. On Thu, Jul 27, 2017 at 7:13 AM, Philip Race wrote: > Ok by me too ... it would not have crossed my mind to look at > ProcessBuilder > but I suppose it was trying to support the now deleted behaviours. > > -phil. > > > On 7/27/17, 6:29 AM, Alan Bateman wrote: > >> >> >> On 26/07/2017 22:20, Martin Buchholz wrote: >> >>> 1. JDK-8185365 >>> >>> Tidy up leftover dead code after JDK-8136570 >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/ >>> >> This looks okay to me. >> >> -Alan >> > From stuart.marks at oracle.com Thu Jul 27 23:50:19 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 27 Jul 2017 16:50:19 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: Hi Ivan, I think this is an interesting avenue to explore adding to the platform. The idea of sorting this way is pretty subtle and it seems to come up frequently, so it seems valuable. There are some issues that warrant further discussion, though. Briefly: 1. Should this be in the JDK? 2. What do other platforms do? 3. Does it have the right semantics? Discussion follows. -- 1. Should this be in the JDK? I think a case for it can be made. It does appear in other platforms (see below) and there are also several third party implementations available in a variety of environments. So people do have a need for this feature. It's also complicated enough to have generated lots of discussions and articles on the topic. The questions are whether this can be specified sufficiently clearly, and whether it provides value for the use cases for which it's intended. It's not obvious whether this is true, but I believe a case can and should be made. 2. What do other platforms do? It was a bit difficult to find information about this, since it doesn't seem to have a well established name. Words like "natural", "logical", "alphanum", and "mixed" tend to be used. I eventually found these: Windows XP StrCmpLogicalW [1]: Compares two Unicode strings. Digits in the strings are considered as numerical content rather than text. This test is not case-sensitive. Windows 7 CompareStringEx SORT_DIGITSASNUMBERS [2] Treat digits as numbers during sorting, for example, sort "2" before "10". (Note: this API takes a locale parameter.) Macintosh Mac NSString localizedStandardCompare [3] This method should be used whenever file names or other strings are presented in lists and tables where Finder-like sorting is appropriate. The exact sorting behavior of this method is different under different locales and may be changed in future releases. This method uses the current locale. (Note: I observe that the Mac Finder sorting is case insensitive.) Swift String.localizedStandardCompare [4] Compares strings as sorted by the Finder. There are also third party, open source implementations available for a variety of platforms. These aren't too hard to find; this Coding Horror article [5] has a discussion of the issues and links to several implementations. Of particular note is the short Python implementation embedded in the article. There is also the Node package javascript-natural-sort [6] which is one of several (of course) similar packages on NPM. This one seems popular, with more than 200,000 downloads in the past month. Finally, there is mention of "numericOrdering" in this Unicode TR [7] but it seems fairly non-specific, and I don't know how it applies. The point here is that the Unicode community is aware of this kind of ordering, and various libraries that implement Unicode collation, such as ICU [8], might have implementations that can provide guidance. 3. Does it have the right semantics? I think you can see from the above survey that there is no standard, and different implementations are all over the map, and most if not all are completely ill-specified. But what is useful about the survey is that it shows what people are actually using, and that there are things that many of them have in common. Two items jump out at me: - case-insensitive comparison (sometimes optional) - locale-specific collation The obvious (but simplistic) thing to do is to provide variations of this API that can use String.CASE_INSENSITIVE_ORDER. Note however that its doc specifically states that it provides "unsatisfactory ordering for certain locales" and directs the reader to the Collator class, which does take locale into account. Now, I'm sensitive about making this more complicated than necessary. But the point of "logical" comparator is to provide something that makes sense to humans looking at the result, which implies that locale-specific collation needs to be applied, as well as case insensitivity (which itself is locale-specific). So I think consideration of those is indeed necessary. I don't know what the API should look like. The java.text.Collator class implements Comparator. This suggests the possibility of an API that allows a "downstream" comparator to be specified, to which ordering of certain subsequences can be delegated. s'marks [1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb759947(v=vs.85).aspx [2] https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761(v=vs.85).aspx [3] https://developer.apple.com/documentation/foundation/nsstring/1409742-localizedstandardcompare?language=objc [4] https://developer.apple.com/documentation/swift/string/1408384-localizedstandardcompare [5] https://blog.codinghorror.com/sorting-for-humans-natural-sort-order/ [6] https://www.npmjs.com/package/javascript-natural-sort [7] http://unicode.org/reports/tr35/tr35-collation.html#Setting_Options [8] http://userguide.icu-project.org/collation On 7/19/17 1:41 AM, Ivan Gerasimov wrote: > Hello! > > It is a proposal to provide a String comparator, which will pay attention to the > numbers embedded into the strings (should they present). > > This proposal was initially discussed back in 2014 and seemed to bring some > interest from the community: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html > > In the latest webrev two methods are added to the public API: > j.u.Comparator.comparingNumerically() and > j.u.Comparator.comparingNumericallyLeadingZerosAhead(). > > The regression test is extended to exercise this new comparator. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 > WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ > > Comments, suggestions are very welcome! > From huizhe.wang at oracle.com Thu Jul 27 23:58:02 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 27 Jul 2017 16:58:02 -0700 Subject: RFR: JDK-8185464: Link issues in java.xml module In-Reply-To: <409897F4-F050-42D1-A5B7-4DEC0187FF1E@oracle.com> References: <597A4E8F.80107@oracle.com> <597A56BA.7080505@oracle.com> <409897F4-F050-42D1-A5B7-4DEC0187FF1E@oracle.com> Message-ID: <7be62c9d-ec86-b0da-dcfb-f99d7030a7cc@oracle.com> Looks good to me too. A side issue, the 'fixedNav' block is preventing the browser from showing the exact content of an inner anchor, the Nav section covers that much of content as its height. If I click on the link to CatalogFeatures.html#PREFER for example, I'd get to see DEFER. Best, Joe On 7/27/2017 2:12 PM, Lance Andersen wrote: >> On Jul 27, 2017, at 5:10 PM, Jonathan Gibbons wrote: >> >> Lance, >> >> It is intentional that the Author designation has disappeared from the javax.xml.datatype package summary. > I was just about to send another email, as I realized that we were not using -author after I hit send. > > Thanks for the follow up :-) > > Best > Lance >> The following lines >> >> 154 *
        >> 155 *
      • Author >Jeff Suttor
        • >> were normalized to >> 152 * @author >Jeff Suttor >> and since we do not use the -author option when generating the main API doc bundle, the author information is not produced in the output. This is the same for all other uses of @author in our source code doc comments. Here is the relevant extract from the command-line help: >> >> Provided by the Standard doclet: >> -author Include @author paragraphs >> >> >> You can see the differences in the generated output for JDK 9: >> http://download.java.net/java/jdk9/docs/api/javax/xml/datatype/package-summary.html >> >> >> Author Jeff Suttor >> See W3C XML Schema 1.0 Part 2, Section 3.2.7-14 >> See XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration >> See XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration >> Since 1.5 >> Since: >> 1.5 >> >> (note the non-standard Author and See entries, and the double "Since" info) >> >> and proposed, after the patch, >> http://cr.openjdk.java.net/~jjg/8185464/api.00/javax/xml/datatype/package-summary.html >> >> Since: >> 1.5 >> See Also: >> W3C XML Schema 1.0 Part 2, Section 3.2.7-14 , XQuery 1.0 and XPath 2.0 Data Model, xdt:dayTimeDuration , XQuery 1.0 and XPath 2.0 Data Model, xdt:yearMonthDuration >> -- Jon >> >> >> >> On 07/27/2017 01:49 PM, Lance Andersen wrote: >>> Hi Jon, >>> >>> Overall it looks good. Maybe it is my browser, but I do not see the Author tag in the DataType package summary though it is there in JDK 8 and looks like it should still display unless I am missing something? >>> >>> Best >>> Lance >>>> On Jul 27, 2017, at 4:35 PM, Jonathan Gibbons > wrote: >>>> >>>> Continuing the documentation cleanup: >>>> >>>> Please review the following simple changes to the API documentation for the java.xml module, >>>> to address issues with links in these files. >>>> >>>> Some missing ids have been declared as appropriate. >>>> >>>> The issue with a mailto: link in the public API to an obsolete address has been side-stepped >>>> by converting a number of explicit Author and See constructs to the equivalent @author and @see >>>> tags. Since we don't publish authors in the generated documentation, that addresses the >>>> appearance of the bad mailto: link. I'll leave it to someone else to take on the general task of >>>> cleaning up the many references to obsolete @sun.com email addresses in the source code. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8185464 >>>> Webrev: http://cr.openjdk.java.net/~jjg/8185464/webrev.00/ >>>> API: http://cr.openjdk.java.net/~jjg/8185464/api.00/overview-summary.html >>>> >>>> -- Jon >>>> >>>> >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From jonathan.gibbons at oracle.com Fri Jul 28 00:47:11 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 27 Jul 2017 17:47:11 -0700 Subject: RFR: JDK-8185464: Link issues in java.xml module In-Reply-To: <7be62c9d-ec86-b0da-dcfb-f99d7030a7cc@oracle.com> References: <597A4E8F.80107@oracle.com> <597A56BA.7080505@oracle.com> <409897F4-F050-42D1-A5B7-4DEC0187FF1E@oracle.com> <7be62c9d-ec86-b0da-dcfb-f99d7030a7cc@oracle.com> Message-ID: <597A898F.1090903@oracle.com> On 07/27/2017 04:58 PM, huizhe wang wrote: > Looks good to me too. > > A side issue, the 'fixedNav' block is preventing the browser from > showing the exact content of an inner anchor, the Nav section covers > that much of content as its height. If I click on the link to > CatalogFeatures.html#PREFER for example, I'd get to see DEFER. > > Best, > Joe I noticed the fixedNav issue when checking this out yesterday, and I already filed 8185368: Navbar causes confusing behavior when navigating to a link https://bugs.openjdk.java.net/browse/JDK-8185368 -- Jon From mandy.chung at oracle.com Fri Jul 28 05:00:39 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Jul 2017 22:00:39 -0700 Subject: Review Request: JDK-8161121: VM::isSystemDomainLoader should consider platform class loader Message-ID: <85DB5141-E751-4BCB-9ED6-E278956BD77F@oracle.com> With deprivileging, several modules of the runtime are mow defined to the platform class loader. VM::isSystemDomainLoader is extended to detect if the given class loader is boot loader or platform loader. Webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8161121/webrev.00/index.html thanks Mandy From ivan.gerasimov at oracle.com Fri Jul 28 09:29:00 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 28 Jul 2017 02:29:00 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> <90df7646-be24-22f3-bd3f-f325daad875f@oracle.com> <926028c0-5052-0b6a-bcbf-58bd410b3a0e@oracle.com> Message-ID: Hi Jonathan! On 7/24/17 3:42 AM, Jonathan Bluett-Duncan wrote: > You're welcome Ivan! > > I'm just proofreading the new webrev, and a few more things have > occurred to me: > > 1. What happens if the comparators are given the elements {"1abc", > "2abc", "10abc"} to compare? Would they sort the elements as {"1abc", > "2abc", "10abc"} or as {"1abc", "10abc", "2abc"}? > What about the array {"x1yz", "x2yz", "x10yz"}? > I wonder if these two cases should be added to the test too and given > as additional examples in the javadocs. > These arrays would be sorted in the way you expect: i.e. {"1abc", "2abc", "10abc"} and {"x1yz", "x2yz", "x10yz"}, respectively. I agree it is worthwhile to choose a good descriptive example for the javadoc, so it would make it clear for a reader what to expect from the routine. Probably, something similar to what they have in MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/bb759947(v=vs.85).aspx > 2. The example arrays which you kindly added to the comparators' > javadoc have no whitespace at the start but one space between the last > element and the }, so I think there either should be no space at the > end or an extra space at the start. > Okay, I'll make it consistent. > 3. Very sorry, error on my part: on the javadoc lines which now say > "then the corresponding numerical values are compared; otherwise", I > suggested to add a "then" at the start; re-reading it though, I > personally think it reads better without, but I would understand and > not press it further if you disagree and think that the "then" is a > useful addition. > Fixed, thanks! I'll post the updated webrev later, once incorporate other suggestions. With kind regards, Ivan > Best regards, > Jonathan > > > On 24 Jul 2017 06:21, "Ivan Gerasimov" > wrote: > > Thank you Jonathan for looking into that! > > I agree with all your suggestions. > > Here's the updated webrev with suggested modifications: > WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/02/webrev/ > > > With kind regards, > Ivan > > > On 7/23/17 3:56 AM, Jonathan Bluett-Duncan wrote: >> Meant to reply to core-libs-dev as well; doing so now. >> >> Jonathan >> >> On 23 July 2017 at 11:50, Jonathan Bluett-Duncan >> > wrote: >> >> Hi Ivan, >> >> I'm not a reviewer per se, but I thought I'd chime in. >> >> There's a few things with Comparator.java which I think could >> be improved: >> >> 1. `comparingNumericallyLeadingZerosAhead()` is a confusing >> name for me, as the "ahead" has no meaning in my mind; >> IMO the name `comparingNumericallyLeadingZerosFirst()` >> better implies that "0001" < "001" < "01". >> 2. It wasn't clear to me from the javadoc that the >> comparators compare strings like "abc9" and "abc10" as >> "abc9" < "abc10", so I think they should include more >> examples. >> 3. There's a typo in the javadocs for both methods: >> "represets" --> "represents". >> 4. Where the javadocs say "follows the procedure", I think >> it'd make more grammatical sense if they said "does the >> following". >> 5. The lines which say "at the boundary of a subsequence, >> consisting of decimal digits, the" would flow better if >> they said "at the boundary of a subsequence *consisting >> solely of decimal digits*, then the". Note the removal of >> the comma between "subsequence" and "consisting". >> >> Hope this helps! >> >> Jonathan >> >> On 23 July 2017 at 05:36, Ivan Gerasimov >> > > wrote: >> >> Hello! >> >> This is a gentle reminder. >> >> The proposed comparator implementation would be >> particularly useful when one will need to compare version >> strings. >> Some popular file managers also use similar comparing >> algorithm, as the results often look more natural to the >> human eyes (e.g. File Explorer on Windows, Files on Ubuntu). >> >> Now, as Java 10 is been worked on, to sort the list of >> Java names correctly, this kind of comparator is needed: >> >> Look: a list { ... "Java 8", "Java 9", "Java 10" } >> definitely looks nicer than { "Java 1", "Java 10", "Java >> 2", ... } :-) >> >> Would you please help review the proposal? >> >> With kind regards, >> Ivan >> >> >> >> On 7/19/17 1:41 AM, Ivan Gerasimov wrote: >> >> Hello! >> >> It is a proposal to provide a String comparator, >> which will pay attention to the numbers embedded into >> the strings (should they present). >> >> This proposal was initially discussed back in 2014 >> and seemed to bring some interest from the community: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html >> >> >> >> In the latest webrev two methods are added to the >> public API: >> j.u.Comparator.comparingNumerically() and >> j.u.Comparator.comparingNumericallyLeadingZerosAhead(). >> >> The regression test is extended to exercise this new >> comparator. >> >> BUGURL: >> https://bugs.openjdk.java.net/browse/JDK-8134512 >> >> WEBREV: >> http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ >> >> >> Comments, suggestions are very welcome! >> >> >> -- >> With kind regards, >> Ivan Gerasimov >> >> >> > > -- > With kind regards, > Ivan Gerasimov > > > -- With kind regards, Ivan Gerasimov From Alan.Bateman at oracle.com Fri Jul 28 13:16:00 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Jul 2017 14:16:00 +0100 Subject: Review Request: JDK-8161121: VM::isSystemDomainLoader should consider platform class loader In-Reply-To: <85DB5141-E751-4BCB-9ED6-E278956BD77F@oracle.com> References: <85DB5141-E751-4BCB-9ED6-E278956BD77F@oracle.com> Message-ID: On 28/07/2017 06:00, Mandy Chung wrote: > With deprivileging, several modules of the runtime are mow defined to > the platform class loader. VM::isSystemDomainLoader is extended to > detect if the given class loader is boot loader or platform loader. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8161121/webrev.00/index.html > Looks okay to me. -Alan From peter.levart at gmail.com Fri Jul 28 14:12:27 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 28 Jul 2017 16:12:27 +0200 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: Hi Ivan, Would I be wrong if I described the logic of these two comparators as the following: The comparator compares two character sequences as though each of them would be 1st transformed into a tuple of the form: (A0, N0, A1, N1, ..., An-1, Nn-1, An) where: A0 and An are (possibly empty) sub-sequences consisting of non-decimal-digit characters A1 ... An-1 are non-empty sub-sequences consisting of non-decimal-digit characters N0 ... Nn-1 are non-empty sub-sequences consisting of decimal-digit characters ...such that all sub-sequences concatenated together in order as they appear in the tuple yield the original character sequence. Any characher sequence can be uniquely transformed into such tuple. For example: "" -> (A0); where A0 == "" "ab10" -> (A0, N0, A1); where A0 == "ab", N0 == "10", A1 = "" "1" -> (A0, N0, A1); where A0 == "", N0 == "1", A1 = "" ... After transformation, the tuples are compared by their elements (from left to right) so that corresponding Ax elements are compared lexicographically and Nx elements are compared as decimal integers (with two variations considering leading zeroes). If I am right than perhaps such description would be easier to understand. What do you think? Regards, Peter On 07/19/2017 10:41 AM, Ivan Gerasimov wrote: > Hello! > > It is a proposal to provide a String comparator, which will pay > attention to the numbers embedded into the strings (should they present). > > This proposal was initially discussed back in 2014 and seemed to bring > some interest from the community: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html > > > In the latest webrev two methods are added to the public API: > j.u.Comparator.comparingNumerically() and > j.u.Comparator.comparingNumericallyLeadingZerosAhead(). > > The regression test is extended to exercise this new comparator. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 > WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ > > Comments, suggestions are very welcome! > From peter.levart at gmail.com Fri Jul 28 14:32:25 2017 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 28 Jul 2017 16:32:25 +0200 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: Hi Ivan, In the light of what Stuart Marks wrote, then what do you think about a parameterized comparator (would be sub-optimal, I know) where one would supply 2 Comparator(s) which would be used to compare Ax and Nx sub-sequences respectively as described below... For Nx sub-sequences, one would need a comparator comparing the reversed sequence lexicographically, but for Ax sub-sequences, one could choose from a plethora of case-(in)sensitive comparator(s) and collators already available on the platform. Regards, peter On 07/28/2017 04:12 PM, Peter Levart wrote: > Hi Ivan, > > Would I be wrong if I described the logic of these two comparators as > the following: > > The comparator compares two character sequences as though each of them > would be 1st transformed into a tuple of the form: > > (A0, N0, A1, N1, ..., An-1, Nn-1, An) > > where: > > A0 and An are (possibly empty) sub-sequences consisting of > non-decimal-digit characters > A1 ... An-1 are non-empty sub-sequences consisting of > non-decimal-digit characters > N0 ... Nn-1 are non-empty sub-sequences consisting of decimal-digit > characters > > ...such that all sub-sequences concatenated together in order as they > appear in the tuple yield the original character sequence. > > Any characher sequence can be uniquely transformed into such tuple. > For example: > > "" -> (A0); where A0 == "" > "ab10" -> (A0, N0, A1); where A0 == "ab", N0 == "10", A1 = "" > "1" -> (A0, N0, A1); where A0 == "", N0 == "1", A1 = "" > ... > > After transformation, the tuples are compared by their elements (from > left to right) so that corresponding Ax elements are compared > lexicographically and Nx elements are compared as decimal integers > (with two variations considering leading zeroes). > > If I am right than perhaps such description would be easier to > understand. > > What do you think? > > > Regards, Peter > > On 07/19/2017 10:41 AM, Ivan Gerasimov wrote: >> Hello! >> >> It is a proposal to provide a String comparator, which will pay >> attention to the numbers embedded into the strings (should they >> present). >> >> This proposal was initially discussed back in 2014 and seemed to >> bring some interest from the community: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html >> >> >> In the latest webrev two methods are added to the public API: >> j.u.Comparator.comparingNumerically() and >> j.u.Comparator.comparingNumericallyLeadingZerosAhead(). >> >> The regression test is extended to exercise this new comparator. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ >> >> Comments, suggestions are very welcome! >> > From kumar.x.srinivasan at oracle.com Fri Jul 28 14:33:57 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 28 Jul 2017 07:33:57 -0700 Subject: RFR: JDK-8183579: refactor and cleanup launcher help messages In-Reply-To: <617202EB-4621-43A0-A850-2BAFBE7FF8F8@oracle.com> References: <5970FC47.3060509@oracle.com> <617202EB-4621-43A0-A850-2BAFBE7FF8F8@oracle.com> Message-ID: <597B4B55.8030605@oracle.com> Mandy, Thanks for the review....please see in-lined comments, >> On Jul 20, 2017, at 11:53 AM, Kumar Srinivasan wrote: >> >> Hi, >> >> Please review refactoring and clean up of the java launcher's help/usage >> messages. >> >> The highlights of the changes are as follows: >> >> 1. Helper.java: is renamed from LauncherHelper.java, simpler name, >> containing mostly methods to help with class loading, module assistance etc. >> > There are tests depending on `sun.launcher.LauncherHelper` class name. > I actually like LauncherHelper better than Helper to make it clear > what it is just by its simple name. The rationale was to simplify the fullname from sun.launcher.LauncherHelper -> sun.launcher.Helper wrt. the test Ugh, Ok renamed Helper.java back to LauncherHelper.java >> Webrev: >> http://cr.openjdk.java.net/~ksrini/8183579/webrev.00/ > launcher.properties > 40 # Translators please note do not translate the options themselves > > Option names are no longer in the resource bundle. > It would be helpful to add the comment describing the key name > java.launcher.opt.$OPTION_NAME.param > java.launcher.opt.$OPTION_NAME.desc Added the notes/comments describing what needs to be done wrt. adding any new keys. > A newline between each option may help readability. > Since the whitespace in description is irrelevant, maybe keep the indentation > to 4 space? Done > Does the help message show the options in the order listed here? In the declaration order. > I would hope it uses the order of the Option enums. If so, we could > list them in alphabetical order in launcher.properties. The keys are alpha sorted now. > 80 java.launcher.opt.x.desc = print help on extra options to the error stream > > Should $OPTION_NAME match the option name (rather than toLowerCase)? Ok used the Enum name directly with no translations. > OptionsHelper.java > 311 Arrays.asList(Option.values()).stream() > > Alternative: Stream(Option.values()) Done. > This class includes the entry point for -XshowSettings but not other options such as ?-list-modules. It may cause confusion to which class a new launcher option is added. It may be okay. Maybe just move the code for printing the help messages in Option class and consider the refactoring for -XshowSetting and other options in the future. As you suggested, moved only the two usage helper methods to the new UsageHelper. This simplifies the changes. New webrev at: http://cr.openjdk.java.net/~ksrini/8183579/webrev.01/ Thanks Kumar > Mandy From ivan.gerasimov at oracle.com Fri Jul 28 16:03:56 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 28 Jul 2017 09:03:56 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: <02668744-bef8-cbd2-c45e-e49e7890b37e@oracle.com> Hi Roger! On 7/24/17 7:42 AM, Roger Riggs wrote: > Hi Ivan, > > Thanks for bringing this up again. > > Some initial comments, not a full review. > > Though the enhancement says that no consideration is given to sign > characters they > may produce puzzling results for strings like "-2000" and "-2001" > where the strings appear > to be signed numbers but the comparison will be for the "-" prefix and > the rest unsigned. > Including the word 'unsigned' in the description might help reinforce > the semantics. > Yes, it's a good point. I'll add some words to make it certain we only recognize unsigned numbers. Otherwise, it would become confusing when comparing something like "2017-07-28" and "2017-07-29". > Also, I don't see test cases for strings like: "abc200123" and > "abc20000123" which share > a prefix part of which is numeric but differ in the number of > "leading" zeros after the prefix. > Sure. Good addition to the test. > What about strings that include more than 1 numeric segment: > abc2003def0001 and abc02003def001 > in the leading zero case? > With the first comparator (which treats the numbers with more leading zeroes as greater ones), these strings would be sorted as "abc2003def0001" < "abc02003def001". The logic here is as following: 1) skip common prefix "abc", 2) find the numerical parts: "2003" and "02003", 3) after skipping leading zeroes, they are compared to be equal, 4) then, the string with more leading zeroes is said to be greater. > Though the test adds the @key randomness, it would be useful to use > the test library > mechanisms to report the seed and be able to run the test with a seed, > if case they fail. > (As might be provided by the test library jdk.test.lib.RandomFactory). > Okay, I'll add this Random to the shuffling to make it reproducible. > > Comparator.java: > 576: "the common prefix is skipped" is problematic when considering > leading zeros. > The common prefix may contain non-zero digits. Yes, of course. While scanning the string for the common prefix, we still keep track of the numeric part. Probably "skip" is a wrong word here. > 585: it is not clear whether the "different number of leading zeros" > is applied regardless > of the common prefix or only starting after the common prefix. > When talking about leading zeroes, then the entire numerical substring is meant. Part of this substring can belong to the common prefix. > 550, 586: for many readers, it is easier to read 'for example' than > "e.g." or "i.e.". > Thanks! I'll change it accordingly. > 562, 598: editorial: "is to compare" -> "compares" > Thanks! > Comparators.java: > > 192: @param for param o is missing; (the param name "o" usually > refers to an object, not a string). > 200: Can skipLeadingZeros be coded to correctly work if cnt == 0; it > would be more robust > SkipLeading zeros works correctly only if pos is given the first > numeric digit in the subsequence > so the numStart1 and numStart2 must be first digit in each string. I don't think that skipLeadingZeros() is very specific that it always called for longer string, trying to reduce its size via skipping leading zeroes. It wouldn't make sense to call it with cnt == 0, and so we can avoid one initial comparing and save a couple of nanoseconds :) I added this prerequisite to the javadoc of the method, so hopefully it shouldn't cause much confusion. > compare(): > > Line 223: if strings typically have non-numeric prefixes, it might > perform slightly better > to detect the end of the common prefix and then scan back to find the > beginning of the numeric part. > (Avoiding checking every char for isDigit). > On the other hand, we're saving on not calling String.charAt() for the second time :) > Line 224: If assigned for every digit, it will hold the last equal > digit in the common prefix, not the first digit. It will only be assigned when a non-digit is met. And since the index was just incremented @ Line 222, numStart1 will be set to the index of the first digit inside the common prefix. For example, if the common prefix is abc123, then the numStart1 will be updated to 3 when looking at the char 'c'. Last three cycles of the loop it won't be updated, since all the trailing chars are digits. > > 239, 240: chars at o1(index) and o2(index) are already known to be > digits, can it be avoided checking them twice > by starting at index+1? > Not quite necessarily. We can be here due to numLen1 > 0, and *only one* or *none* of the string remainders start with digits. In the later case we'll end up @ line 279. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8134512/03/webrev/ Given the further discussion this iteration is probably not the final, but it's better to have a checkpoint :) With kind regards, Ivan > $.02, Roger > > > On 7/19/2017 4:41 AM, Ivan Gerasimov wrote: >> Hello! >> >> It is a proposal to provide a String comparator, which will pay >> attention to the numbers embedded into the strings (should they >> present). >> >> This proposal was initially discussed back in 2014 and seemed to >> bring some interest from the community: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html >> >> >> In the latest webrev two methods are added to the public API: >> j.u.Comparator.comparingNumerically() and >> j.u.Comparator.comparingNumericallyLeadingZerosAhead(). >> >> The regression test is extended to exercise this new comparator. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ >> >> Comments, suggestions are very welcome! >> > > -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Fri Jul 28 16:25:52 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 28 Jul 2017 09:25:52 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: Hi Peter! Thank a lot for looking into this! On 7/28/17 7:32 AM, Peter Levart wrote: > Hi Ivan, > > In the light of what Stuart Marks wrote, then what do you think about > a parameterized comparator (would be sub-optimal, I know) where one > would supply > 2 Comparator(s) which would be used to compare Ax and Nx sub-sequences > respectively as described below... > Yes. Inspired by what Stuart suggested I made a draft of such a comparator (see below). It works, but as you've said it's not that efficient (mostly due to expensive substrings) and a bit harder to use in a simple case. Now I need to think about how to combine two approaches. > For Nx sub-sequences, one would need a comparator comparing the > reversed sequence lexicographically, I'm not sure I understand why they need to be reversed. > but for Ax sub-sequences, one could choose from a plethora of > case-(in)sensitive comparator(s) and collators already available on > the platform. > Yes. In the example below I used compareToIgnoreCase to compare alpha subsequences. ------- class MyComparator implements Comparator {Comparator alphaCmp;Comparator numCmp;MyComparator(Comparator alphaCmp,Comparator numCmp) {this.alphaCmp = alphaCmp;this.numCmp = numCmp;}boolean skipLeadingZeroes(String s, int len) {for (int i = 0; i < len ; ++i) {if (Character.digit(s.charAt(i), 10) != 0)return false;}return true;}@Override public int compare(String o1, String o2) {Supplier s1 = new NumberSlicer(o1);Supplier s2 = new NumberSlicer(o2);while (true) {// alpha part String ss1 = s1.get();String ss2 = s2.get();int cmp = alphaCmp.compare(ss1, ss2);if (cmp != 0) return cmp;if (ss1.length() == 0) return 0;// numeric part ss1 = s1.get();ss2 = s2.get();int len1 = ss1.length();int len2 = ss2.length();int dlen = len1 - len2;if (dlen > 0) {if (!skipLeadingZeroes(ss1, dlen))return 1;ss1 = ss1.substring(dlen, len1);} else if (dlen < 0) {if (!skipLeadingZeroes(ss2, -dlen))return -1;ss2 = ss2.substring(-dlen, len2);}cmp = numCmp.compare(ss1, ss2);if (cmp != 0) return cmp;if (dlen != 0) return dlen;}}static class NumberSlicer implements Supplier {private String sequence;private boolean expectNumber = false;private int index = 0;NumberSlicer(String s) {sequence = s;}@Override public String get() {int start = index, end = start, len = sequence.length() - start;for (; len > 0; ++end, --len) {if (Character.isDigit(sequence.charAt(end)) ^ expectNumber)break;}expectNumber = !expectNumber;return sequence.substring(start, index = end);}}}------------Here how it is invoked with case-insensitive comparator:Arrays.sort(str,new MyComparator(Comparator.comparing(String::toString,String::compareToIgnoreCase),Comparator.comparing(String::toString,String::compareTo)));------------ simple test results for case insensitive sorting:java 1java 1 javajava 1 JAVAJava 2JAVA 5jaVA 6.1java 10java 10 v 13Java 10 v 013Java 10 v 000013java 10 v 113Java 2017Java 2017Java 20017Java 200017Java 2000017Java 20000017Java 20000017Java 200000017With kind regards, Ivan From joe.darcy at oracle.com Fri Jul 28 16:48:09 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 28 Jul 2017 09:48:09 -0700 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: <02668744-bef8-cbd2-c45e-e49e7890b37e@oracle.com> References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> <02668744-bef8-cbd2-c45e-e49e7890b37e@oracle.com> Message-ID: <52ec255c-1adc-df9e-5cdd-0df66ff58906@oracle.com> Hi Ivan, A few comments. I don't have a specific suggestion for a different name, but I don't think "comparingNumerically" does an adequate job capturing the described behavior of the method. Likewise, the summary of the methods' behavior in the javadoc should have a more suggestive description of the behavior. Please add comments describing what the "// Fullwidth characters" values are in the test. Interesting test cases would also include substrings for Integer.MAX_VALUE, Integer.MAX_VALUE+1, Long.MAX_VALUE, Long.MAX_VALUE + 1, etc. Test cases of purely numerical and purely alphabetical inputs would be warranted too. While randomizing the array and sorting is a valid test, a more through test would do pair-wise comparisons of each array element. While such comparisons are quadratic with array length, the arrays here are small. Cheers, -Joe On 7/28/2017 9:03 AM, Ivan Gerasimov wrote: > Hi Roger! > > > On 7/24/17 7:42 AM, Roger Riggs wrote: >> Hi Ivan, >> >> Thanks for bringing this up again. >> >> Some initial comments, not a full review. >> >> Though the enhancement says that no consideration is given to sign >> characters they >> may produce puzzling results for strings like "-2000" and "-2001" >> where the strings appear >> to be signed numbers but the comparison will be for the "-" prefix >> and the rest unsigned. >> Including the word 'unsigned' in the description might help reinforce >> the semantics. >> > Yes, it's a good point. I'll add some words to make it certain we > only recognize unsigned numbers. > Otherwise, it would become confusing when comparing something like > "2017-07-28" and "2017-07-29". > >> Also, I don't see test cases for strings like: "abc200123" and >> "abc20000123" which share >> a prefix part of which is numeric but differ in the number of >> "leading" zeros after the prefix. >> > Sure. Good addition to the test. > >> What about strings that include more than 1 numeric segment: >> abc2003def0001 and abc02003def001 >> in the leading zero case? >> > With the first comparator (which treats the numbers with more leading > zeroes as greater ones), these strings would be sorted as > "abc2003def0001" < "abc02003def001". > The logic here is as following: > 1) skip common prefix "abc", > 2) find the numerical parts: "2003" and "02003", > 3) after skipping leading zeroes, they are compared to be equal, > 4) then, the string with more leading zeroes is said to be greater. > >> Though the test adds the @key randomness, it would be useful to use >> the test library >> mechanisms to report the seed and be able to run the test with a >> seed, if case they fail. >> (As might be provided by the test library jdk.test.lib.RandomFactory). >> > Okay, I'll add this Random to the shuffling to make it reproducible. >> >> Comparator.java: >> 576: "the common prefix is skipped" is problematic when considering >> leading zeros. >> The common prefix may contain non-zero digits. > Yes, of course. > While scanning the string for the common prefix, we still keep track > of the numeric part. > Probably "skip" is a wrong word here. > >> 585: it is not clear whether the "different number of leading zeros" >> is applied regardless >> of the common prefix or only starting after the common prefix. >> > When talking about leading zeroes, then the entire numerical substring > is meant. > Part of this substring can belong to the common prefix. > >> 550, 586: for many readers, it is easier to read 'for example' than >> "e.g." or "i.e.". >> > Thanks! I'll change it accordingly. > >> 562, 598: editorial: "is to compare" -> "compares" >> > Thanks! >> Comparators.java: >> >> 192: @param for param o is missing; (the param name "o" usually >> refers to an object, not a string). >> 200: Can skipLeadingZeros be coded to correctly work if cnt == 0; >> it would be more robust >> SkipLeading zeros works correctly only if pos is given the first >> numeric digit in the subsequence >> so the numStart1 and numStart2 must be first digit in each string. > I don't think that skipLeadingZeros() is very specific that it always > called for longer string, trying to reduce its size via skipping > leading zeroes. > It wouldn't make sense to call it with cnt == 0, and so we can avoid > one initial comparing and save a couple of nanoseconds :) > I added this prerequisite to the javadoc of the method, so hopefully > it shouldn't cause much confusion. > >> compare(): >> >> Line 223: if strings typically have non-numeric prefixes, it might >> perform slightly better >> to detect the end of the common prefix and then scan back to find the >> beginning of the numeric part. >> (Avoiding checking every char for isDigit). >> > On the other hand, we're saving on not calling String.charAt() for the > second time :) > >> Line 224: If assigned for every digit, it will hold the last equal >> digit in the common prefix, not the first digit. > It will only be assigned when a non-digit is met. > And since the index was just incremented @ Line 222, numStart1 will be > set to the index of the first digit inside the common prefix. > > For example, if the common prefix is abc123, then the numStart1 will > be updated to 3 when looking at the char 'c'. Last three cycles of > the loop it won't be updated, since all the trailing chars are digits. > >> >> 239, 240: chars at o1(index) and o2(index) are already known to be >> digits, can it be avoided checking them twice >> by starting at index+1? >> > Not quite necessarily. We can be here due to numLen1 > 0, and *only > one* or *none* of the string remainders start with digits. > In the later case we'll end up @ line 279. > > Here's the updated webrev: > http://cr.openjdk.java.net/~igerasim/8134512/03/webrev/ > > Given the further discussion this iteration is probably not the final, > but it's better to have a checkpoint :) > > With kind regards, > Ivan > >> $.02, Roger >> >> >> On 7/19/2017 4:41 AM, Ivan Gerasimov wrote: >>> Hello! >>> >>> It is a proposal to provide a String comparator, which will pay >>> attention to the numbers embedded into the strings (should they >>> present). >>> >>> This proposal was initially discussed back in 2014 and seemed to >>> bring some interest from the community: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030343.html >>> >>> >>> In the latest webrev two methods are added to the public API: >>> j.u.Comparator.comparingNumerically() and >>> j.u.Comparator.comparingNumericallyLeadingZerosAhead(). >>> >>> The regression test is extended to exercise this new comparator. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134512 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8134512/01/webrev/ >>> >>> Comments, suggestions are very welcome! >>> >> >> > From jbluettduncan at gmail.com Fri Jul 28 19:16:37 2017 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Fri, 28 Jul 2017 20:16:37 +0100 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: Hi Ivan, It looks like the MyComparator code example which you gave in your last email lost its formatting along the way, so I'm finding it difficult to read. Would you mind resubmitting it? Cheers, Jonathan On 28 July 2017 at 17:25, Ivan Gerasimov wrote: > Hi Peter! > > Thank a lot for looking into this! > > On 7/28/17 7:32 AM, Peter Levart wrote: > >> Hi Ivan, >> >> In the light of what Stuart Marks wrote, then what do you think about a >> parameterized comparator (would be sub-optimal, I know) where one would >> supply >> 2 Comparator(s) which would be used to compare Ax and Nx sub-sequences >> respectively as described below... >> >> Yes. Inspired by what Stuart suggested I made a draft of such a > comparator (see below). > It works, but as you've said it's not that efficient (mostly due to > expensive substrings) and a bit harder to use in a simple case. > Now I need to think about how to combine two approaches. > > For Nx sub-sequences, one would need a comparator comparing the reversed >> sequence lexicographically, >> > I'm not sure I understand why they need to be reversed. > >> but for Ax sub-sequences, one could choose from a plethora of >> case-(in)sensitive comparator(s) and collators already available on the >> platform. >> >> Yes. In the example below I used compareToIgnoreCase to compare alpha > subsequences. > > ------- > > class MyComparator implements Comparator {Comparator > alphaCmp;Comparator numCmp;MyComparator(Comparator > alphaCmp,Comparator numCmp) {this.alphaCmp = alphaCmp;this.numCmp = > numCmp;}boolean skipLeadingZeroes(String s, int len) {for (int i = 0; i < > len ; ++i) {if (Character.digit(s.charAt(i), 10) != 0)return false;}return > true;}@Override public int compare(String o1, String o2) > {Supplier s1 = new NumberSlicer(o1);Supplier s2 = new > NumberSlicer(o2);while (true) {// alpha part String ss1 = s1.get();String > ss2 = s2.get();int cmp = alphaCmp.compare(ss1, ss2);if (cmp != 0) return > cmp;if (ss1.length() == 0) return 0;// numeric part ss1 = s1.get();ss2 = > s2.get();int len1 = ss1.length();int len2 = ss2.length();int dlen = len1 - > len2;if (dlen > 0) {if (!skipLeadingZeroes(ss1, dlen))return 1;ss1 = > ss1.substring(dlen, len1);} else if (dlen < 0) {if (!skipLeadingZeroes(ss2, > -dlen))return -1;ss2 = ss2.substring(-dlen, len2);}cmp = > numCmp.compare(ss1, ss2);if (cmp != 0) return cmp;if (dlen != 0) return > dlen;}}static class NumberSlicer implements Supplier {private > String sequence;private boolean expectNumber = false;private int index = > 0;NumberSlicer(String s) {sequence = s;}@Override public String get() > {int start = index, end = start, len = sequence.length() - start;for (; len > > 0; ++end, --len) {if (Character.isDigit(sequence.charAt(end)) ^ > expectNumber)break;}expectNumber = !expectNumber;return > sequence.substring(start, index = end);}}}------------Here how it is > invoked with case-insensitive comparator:Arrays.sort(str,new > MyComparator(Comparator.comparing(String::toString,String:: > compareToIgnoreCase),Comparator.comparing(String::toString, > String::compareTo)));------------ > > simple test results for case insensitive sorting:java 1java 1 javajava 1 > JAVAJava 2JAVA 5jaVA 6.1java 10java 10 v 13Java 10 v 013Java 10 v > 000013java 10 v 113Java 2017Java 2017Java 20017Java 200017Java 2000017Java > 20000017Java 20000017Java 200000017With kind regards, Ivan > From leonid.mesnik at oracle.com Fri Jul 28 21:05:00 2017 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 28 Jul 2017 14:05:00 -0700 Subject: =?utf-8?Q?RFR=28XS=29_8184775=3A_tools/launcher/modules/illegalac?= =?utf-8?Q?cess/IllegalAccessTest=2Ejava_times_out_on_some_platforms?= =?utf-8?Q?=E2=80=A6_?= Message-ID: Hi Please review following small fix which excludes test tools/launcher/modules/illegalaccess/IllegalAccessTest.java from execution in Xcomp mode. Test launches about 100 VMs and fails when -Xcomp is used. Tested locally with and without adding -Xcomp option. Webrev: http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8184775 Diff: --- old/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java 2017-07-27 17:15:37.000000000 -0700 +++ new/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java 2017-07-27 17:15:37.000000000 -0700 @@ -23,6 +23,7 @@ /** * @test + * @requires vm.compMode != "Xcomp" * @modules java.base/jdk.internal.misc * java.base/sun.security.x509 * java.activation Leonid From martinrb at google.com Fri Jul 28 21:17:47 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 28 Jul 2017 14:17:47 -0700 Subject: =?UTF-8?Q?Re=3A_RFR=28XS=29_8184775=3A_tools=2Flauncher=2Fmodules=2Fillegala?= =?UTF-8?Q?ccess=2FIllegalAccessTest=2Ejava_times_out_on_some_platforms=E2=80=A6?= In-Reply-To: References: Message-ID: Won't this test fail with any "slow" VM, e.g. fastdebug, -Xint, etc ? On Fri, Jul 28, 2017 at 2:05 PM, Leonid Mesnik wrote: > Hi > > Please review following small fix which excludes test > tools/launcher/modules/illegalaccess/IllegalAccessTest.java from > execution in Xcomp mode. Test launches about 100 VMs and fails when -Xcomp > is used. > > Tested locally with and without adding -Xcomp option. > > Webrev: http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/ < > http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/> > Bug: https://bugs.openjdk.java.net/browse/JDK-8184775 < > https://bugs.openjdk.java.net/browse/JDK-8184775> > Diff: > --- old/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java > 2017-07-27 17:15:37.000000000 -0700 > +++ new/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java > 2017-07-27 17:15:37.000000000 -0700 > @@ -23,6 +23,7 @@ > > /** > * @test > + * @requires vm.compMode != "Xcomp" > * @modules java.base/jdk.internal.misc > * java.base/sun.security.x509 > * java.activation > > Leonid From Alan.Bateman at oracle.com Fri Jul 28 21:29:40 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Jul 2017 22:29:40 +0100 Subject: =?UTF-8?Q?Re:_RFR=28XS=29_8184775:_tools/launcher/modules/illegalac?= =?UTF-8?Q?cess/IllegalAccessTest.java_times_out_on_some_platforms=e2=80=a6?= In-Reply-To: References: Message-ID: <3b67c8ce-66e2-ec7a-86a7-9fb27984579a@oracle.com> On 28/07/2017 22:17, Martin Buchholz wrote: > Won't this test fail with any "slow" VM, e.g. fastdebug, -Xint, etc ? When testing with debug builds or -Xint or -Xcomp then default timeout is often insufficient so the recommendation has always been to specify -timeoutFactor to jtreg. This test is dominated by startup and can take a long time with a debug + -Xcomp run. I think Leonid found a particularly slow machine too. So I think skipping it for -Xcomp runs should be okay as this test is unlikely to helping finding compiler/VM bugs. -Alan From leonid.mesnik at oracle.com Fri Jul 28 21:30:31 2017 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 28 Jul 2017 14:30:31 -0700 Subject: =?utf-8?Q?Re=3A_RFR=28XS=29_8184775=3A_tools/launcher/modules/ill?= =?utf-8?Q?egalaccess/IllegalAccessTest=2Ejava_times_out_on_some_platforms?= =?utf-8?Q?=E2=80=A6?= In-Reply-To: References: Message-ID: <5D116E87-B1A1-46FC-BF97-ADF16B4CAFE3@oracle.com> Hi Currently there were no timeouts wit fastdebug were observed. I don?t know exactly how Xint affects this test but don?t expect significant performance degradation comparing with other tests. Usually timeoutfactor is used to increase timeouts of all tests if VM or host are slow. However this test launches a lot of VMs with small applications and significantly depends on JVM startup performance. I don?t think that other ?slow? modes affect startup performance so significantly as Xcomp. Leonid > On Jul 28, 2017, at 2:17 PM, Martin Buchholz wrote: > > Won't this test fail with any "slow" VM, e.g. fastdebug, -Xint, etc ? > > > On Fri, Jul 28, 2017 at 2:05 PM, Leonid Mesnik > wrote: > Hi > > Please review following small fix which excludes test tools/launcher/modules/illegalaccess/IllegalAccessTest.java from execution in Xcomp mode. Test launches about 100 VMs and fails when -Xcomp is used. > > Tested locally with and without adding -Xcomp option. > > Webrev: http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184775 > > Diff: > --- old/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java 2017-07-27 17:15:37.000000000 -0700 > +++ new/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java 2017-07-27 17:15:37.000000000 -0700 > @@ -23,6 +23,7 @@ > > /** > * @test > + * @requires vm.compMode != "Xcomp" > * @modules java.base/jdk.internal.misc > * java.base/sun.security.x509 > * java.activation > > Leonid > From martinrb at google.com Fri Jul 28 21:34:17 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 28 Jul 2017 14:34:17 -0700 Subject: =?UTF-8?Q?Re=3A_RFR=28XS=29_8184775=3A_tools=2Flauncher=2Fmodules=2Fillegala?= =?UTF-8?Q?ccess=2FIllegalAccessTest=2Ejava_times_out_on_some_platforms=E2=80=A6?= In-Reply-To: <5D116E87-B1A1-46FC-BF97-ADF16B4CAFE3@oracle.com> References: <5D116E87-B1A1-46FC-BF97-ADF16B4CAFE3@oracle.com> Message-ID: OK, that makes sense - short-lived programs with -Xcomp are dominated by cost of compiling everything. On Fri, Jul 28, 2017 at 2:30 PM, Leonid Mesnik wrote: > Hi > > Currently there were no timeouts wit fastdebug were observed. I don?t know > exactly how Xint affects this test but don?t expect significant > performance degradation comparing with other tests. Usually timeoutfactor > is used to increase timeouts of all tests if VM or host are slow. However > this test launches a lot of VMs with small applications and significantly > depends on JVM startup performance. I don?t think that other ?slow? modes > affect startup performance so significantly as Xcomp. > > Leonid > > On Jul 28, 2017, at 2:17 PM, Martin Buchholz wrote: > > Won't this test fail with any "slow" VM, e.g. fastdebug, -Xint, etc ? > > > On Fri, Jul 28, 2017 at 2:05 PM, Leonid Mesnik > wrote: > >> Hi >> >> Please review following small fix which excludes test >> tools/launcher/modules/illegalaccess/IllegalAccessTest.java from >> execution in Xcomp mode. Test launches about 100 VMs and fails when -Xcomp >> is used. >> >> Tested locally with and without adding -Xcomp option. >> >> Webrev: http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/ < >> http://cr.openjdk.java.net/~lmesnik/8184775/webrev.00/> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8184775 < >> https://bugs.openjdk.java.net/browse/JDK-8184775> >> Diff: >> --- old/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java >> 2017-07-27 17:15:37.000000000 -0700 >> +++ new/test/tools/launcher/modules/illegalaccess/IllegalAccessTest.java >> 2017-07-27 17:15:37.000000000 -0700 >> @@ -23,6 +23,7 @@ >> >> /** >> * @test >> + * @requires vm.compMode != "Xcomp" >> * @modules java.base/jdk.internal.misc >> * java.base/sun.security.x509 >> * java.activation >> >> Leonid > > > > From martinrb at google.com Fri Jul 28 22:30:43 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 28 Jul 2017 15:30:43 -0700 Subject: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0 In-Reply-To: References: Message-ID: I took another look. 90 if ((dtime >> 25) == 0) { It looks like this will test only the year, not all the date fields. Shouldn't that be s/25/16/ ? Does this code handle the "true" epoch of 1980-01-01 ? On Thu, Jul 27, 2017 at 11:54 AM, Liam Miller-Cushon wrote: > On Wed, Jul 26, 2017 at 4:12 PM, Martin Buchholz > wrote: > >> I wonder where the "8" in the "Friday the 30th" date comes from. Could >> your California time zone be leaking into the test? The DOS timestamp is >> interpreted as local time while Instant.parse uses UTC? Will the test >> still pass if you run jtreg under TZ=EST? >> > > Thanks, fixed: > http://cr.openjdk.java.net/~cushon/8184940/webrev.01/ > From peter.levart at gmail.com Sat Jul 29 17:22:33 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 29 Jul 2017 19:22:33 +0200 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: Hi Ivan, On 07/28/2017 06:25 PM, Ivan Gerasimov wrote: > > Hi Peter! > > Thank a lot for looking into this! > > On 7/28/17 7:32 AM, Peter Levart wrote: >> Hi Ivan, >> >> In the light of what Stuart Marks wrote, then what do you think about >> a parameterized comparator (would be sub-optimal, I know) where one >> would supply >> 2 Comparator(s) which would be used to compare Ax and Nx >> sub-sequences respectively as described below... >> > Yes. Inspired by what Stuart suggested I made a draft of such a > comparator (see below). > It works, but as you've said it's not that efficient (mostly due to > expensive substrings) and a bit harder to use in a simple case. > Now I need to think about how to combine two approaches. There is a bug in MyComparator. Comparing "1" with "2" gives 0 (equal). You must not return "equal" when both alpha prefixes are empty. > >> For Nx sub-sequences, one would need a comparator comparing the >> reversed sequence lexicographically, > I'm not sure I understand why they need to be reversed. Scrap that. I got confused. :-o >> but for Ax sub-sequences, one could choose from a plethora of >> case-(in)sensitive comparator(s) and collators already available on >> the platform. >> > Yes. In the example below I used compareToIgnoreCase to compare alpha > subsequences. ... > Arrays.sort(str,new > MyComparator(Comparator.comparing(String::toString,String::compareToIgnoreCase),Comparator.comparing(String::toString,String::compareTo))); Substrings are by copy. There is another approach. Originally you created the NumericComparator to compare CharSequence(s) - not String(s) as you did with MyComparator. So why not keeping that? While talking about types, you don't need to have a generic parameter: NumericComparator implements CharSequence simple: NumericComparator implements Comparator is suitable for comparing any subtype of CharSequence as use-sites should accept Comparator or Comparator. For example: Stream sorted(Comparator comparator); You can use Comparator to sort Stream as well as Stream or Stream... I tried an approach where sub-sequences are CharSequence objects by delegation and use sub-comparators that don't convert CharSequence(s) to String(s). Here's what this looks like: http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/AlphadecimalComparator.java with supporting sub-comparator classes: http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/CharSequenceComparator.java http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/DecimalComparator.java I created a JMH benchmark comparing your 02/webrev (ivan.NumericComparator): http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/ivan/NumericComparator.java with a modified variant of your MyComparator that works correctly (ivan.MyComparator): http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/ivan/MyComparator.java and my (peter.AlphadecimalComparator). The later two are tested with case-sensitive (CS) and case-insensitive (CIS) variants for comparing alpha sub-sequences. Here are the results: http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/bench_results_speed.txt With -prof gc, it can be seen that JIT is able to optimize-away allocation of sub-sequence CharSequence(s). When the hot code is JIT-ed, at least with provided helper sub-comparators, no allocation is taking place (not so with MyComparator which creates substrings): http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/bench_results_gc.txt The performance of AlphadecimalComparator is about 50% slower than your specialized NumericComparator, but it allows custom parametrization. Perhaps the decimal part of variations could be hidden behind a boolean or an enum parameter (there is a leading-zeroes-greater, leading-zeroes-less, but also a leading-zeroes-equal variant that makes sense). I tried to do that by making DecimalComparator an enum and restricting the decimalComparato parameter to that type, but maybe specializing code around a boolean flag might yield better performance and DecimalComparator as Comparator doesn't make much sense outside the AlphadecimalComparator. So what do you think? Also, what do you think about the name? Regards, Peter From peter.levart at gmail.com Sun Jul 30 07:36:01 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 30 Jul 2017 09:36:01 +0200 Subject: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator In-Reply-To: References: <92ca3601-f228-026a-8378-16c331ab9cb5@oracle.com> Message-ID: <075afe49-4f41-88cd-a7ff-7b5cecaca7d7@gmail.com> Hi Ivan, On 07/29/2017 07:22 PM, Peter Levart wrote: > I tried an approach where sub-sequences are CharSequence objects by > delegation and use sub-comparators that don't convert CharSequence(s) > to String(s). Here's what this looks like: > > http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/src/main/java/peter/AlphadecimalComparator.java > > Here are the results: > > http://cr.openjdk.java.net/~plevart/misc/AlphadecimalComparator/alphadecimal-comparator/bench_results_speed.txt A simple optimization of above code (manually unrolling the alpha/decimal alteration - i.e. getting rid of 'alpha' boolean flag): before: boolean alpha = true; while (true) { if (ss1.next(alpha)) { if (ss2.next(alpha)) { Comparator comparator = alpha ? alphaComparator : decimalComparator; int cmp = comparator.compare(ss1, ss2); if (cmp != 0) { return cmp; } } else { return 1; } } else { if (ss2.next(alpha)) { return -1; } else { return 0; } } alpha = !alpha; } after: while (true) { // alpha part if (ss1.next(true)) { if (ss2.next(true)) { int cmp = alphaComparator.compare(ss1, ss2); if (cmp != 0) { return cmp; } } else { return 1; } } else { if (ss2.next(true)) { return -1; } else { return 0; } } // decimal part if (ss1.next(false)) { if (ss2.next(false)) { int cmp = decimalComparator.compare(ss1, ss2); if (cmp != 0) { return cmp; } } else { return 1; } } else { if (ss2.next(false)) { return -1; } else { return 0; } } } ...yields a noticeable spead-up: // reference: Benchmark (_strings) (comparator) Mode Cnt Score Error Units ComparatorBench.test strings1 ivan.NumericComparator avgt 10 1455.789 ? 37.158 ns/op ComparatorBench.test strings2 ivan.NumericComparator avgt 10 13680.131 ? 338.763 ns/op // before explicit alpha/decimal alteration unrolling: Benchmark (_strings) (comparator) Mode Cnt Score Error Units ComparatorBench.test strings1 peter.AlphadecimalComparator.CS avgt 10 2065.324 ? 50.532 ns/op ComparatorBench.test strings2 peter.AlphadecimalComparator.CS avgt 10 21118.430 ? 350.769 ns/op // after explicit alpha/decimal alteration unrolling: Benchmark (_strings) (comparator) Mode Cnt Score Error Units ComparatorBench.test strings1 peter.AlphadecimalComparator.CS avgt 10 1692.145 ? 2.160 ns/op ComparatorBench.test strings2 peter.AlphadecimalComparator.CS avgt 10 18624.677 ? 1900.779 ns/op With this mod, AlphadecimalComparator is only about 16 - 35% slower than NumericComparator. Regards, Peter From cushon at google.com Mon Jul 31 18:41:09 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Mon, 31 Jul 2017 11:41:09 -0700 Subject: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0 In-Reply-To: References: Message-ID: On Fri, Jul 28, 2017 at 3:30 PM, Martin Buchholz wrote: > It looks like this will test only the year, not all the date fields. > Shouldn't that be s/25/16/ ? > Does this code handle the "true" epoch of 1980-01-01 ? > It does now, thanks: http://cr.openjdk.java.net/~cushon/8184940/webrev.02/ This raises the question of what it should do if a day or month is zero but year/month/day are not all zero. Is 1980-0-0 special, or should 1980-0-1 and 1980-1-0 also be tolerated for compatibility with JDK 8?