May 2015 - core-libs-dev

RFR: 8074657: Missing space on a boundary of concatenated strings
by Ivan Gerasimov 12 May '15

12 May '15

Hi all! grep found a few places, where a space is missing. Would you please help review this cleanup fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8074657 WEBREV: http://cr.openjdk.java.net/~igerasim/8074657/00/webrev/ Sincerely yours, Ivan

3 7

[Annotation Processor] Accessing type annotations on VariableElement at compile time
by DuyHai Doan 12 May '15

12 May '15

Hello I've tried to play with the new JSR 308 feature (type annotations) and I'm facing a rather annoying limitation: Suppose a class: public static class SimpleEntityCodecFactoryTest { private Map<@JSON Integer,Map<@Frozen Integer,@Enumerated(value = Enumerated.Encoding.NAME, test = "123") String>> map; } What I need is to access all annotations set on type parameters as well as their attribute values. Right now the only way I find so far is to cast the VariableElement to "Symbol.VarSymbol" and then access the internal api getMetadata(). It works but it is far from being developer-friendly. More details here: https://gist.github.com/doanduyhai/b11f9cd843f9be557382 I've tried with declareType.getTypeArguments().get(0).getAnnotationMirrors() but the returned list is empty. Note: I'm using JDK 1.8.0_45. I also tried 1.8.0_u60 but same result ... Am I missing something or is it really a bug in the javax.lang.model package ? Thanks

1 0

Re: JDK 9 RFR of JDK-8053918: make the spec for @Documented comprehensible
by Joseph D. Darcy 11 May '15

11 May '15

How about as a first sentence "The Documented meta-annotation indicates whether or not annotations of the annotation types it annotates are considered part of the public contract of the elements they in turn annotate." (Admittedly still a bit convoluted.) -Joe On 5/11/2015 4:07 PM, Jonathan Gibbons wrote: > Although the original "first sentence" is somewhat hard to parse, at > least there is a single "first sentence" The rewrite doesn't seem to > have such a succint first sentence. > > If I were to change just one word in the original first sentence, I > would change "with" to "on": > > - * Indicates that annotations with a type are to be documented by > javadoc > - * and similar tools by default. > + * Indicates that annotations on a type are to be documented by javadoc > +* and similar tools by default. > > -- Jon > > On 05/11/2015 03:58 PM, joe darcy wrote: >> Hello, >> >> Some are of the opinion that the specification for the Documented >> meta-annotation type could be clarified. >> >> JDK-8053918: make the spec for @Documented comprehensible >> http://cr.openjdk.java.net/~darcy/8053918.0/ >> >> Please review the patch below which aims to accomplish this. >> >> Thanks, >> >> -Joe >> >> --- >> old/src/java.base/share/classes/java/lang/annotation/Documented.java >> 2015-05-11 15:54:37.273033243 -0700 >> +++ >> new/src/java.base/share/classes/java/lang/annotation/Documented.java >> 2015-05-11 15:54:37.153033240 -0700 >> @@ -26,12 +26,20 @@ >> package java.lang.annotation; >> >> /** >> - * Indicates that annotations with a type are to be documented by >> javadoc >> - * and similar tools by default. This type should be used to >> annotate the >> - * declarations of types whose annotations affect the use of annotated >> - * elements by their clients. If a type declaration is annotated with >> - * Documented, its annotations become part of the public API >> - * of the annotated elements. >> + * When an annotation type A is annotated with {@code >> + * Documented}, the presence and value of annotations of type A >> + * are a part of the public contract of the elements A >> + * annotates. >> + * >> + * Conversely, if an annotation type B is not >> + * annotated with {@code Documented}, the presence and value of >> + * Bannotations are not part of the public contract of >> + * the elements B annotates. >> + * >> + * Concretely, if an annotation type is annotated with {@code >> + * Documented}, by default a tool like javadoc will display >> + * annotations of that type in its output while annotations of >> + * annotation types without {@code Documented} will not be displayed. >> * >> * @author Joshua Bloch >> * @since 1.5 >> >

3 2

JDK 9 RFR of JDK-8053918: make the spec for @Documented comprehensible
by joe darcy 11 May '15

11 May '15

Hello, Some are of the opinion that the specification for the Documented meta-annotation type could be clarified. JDK-8053918: make the spec for @Documented comprehensible http://cr.openjdk.java.net/~darcy/8053918.0/ Please review the patch below which aims to accomplish this. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/annotation/Documented.java 2015-05-11 15:54:37.273033243 -0700 +++ new/src/java.base/share/classes/java/lang/annotation/Documented.java 2015-05-11 15:54:37.153033240 -0700 @@ -26,12 +26,20 @@ package java.lang.annotation; /** - * Indicates that annotations with a type are to be documented by javadoc - * and similar tools by default. This type should be used to annotate the - * declarations of types whose annotations affect the use of annotated - * elements by their clients. If a type declaration is annotated with - * Documented, its annotations become part of the public API - * of the annotated elements. + * When an annotation type A is annotated with {@code + * Documented}, the presence and value of annotations of type A + * are a part of the public contract of the elements A + * annotates. + * + * Conversely, if an annotation type B is not + * annotated with {@code Documented}, the presence and value of + * Bannotations are not part of the public contract of + * the elements B annotates. + * + * Concretely, if an annotation type is annotated with {@code + * Documented}, by default a tool like javadoc will display + * annotations of that type in its output while annotations of + * annotation types without {@code Documented} will not be displayed. * * @author Joshua Bloch * @since 1.5

1 0

RFR: 8079773: java/util/logging/LogManager/TestLoggerNames.java
by Daniel Fuchs 11 May '15

11 May '15

Please find below a fix for: 8079773: java/util/logging/LogManager/TestLoggerNames.java The issue arises from a race condition in the test logic. The test calls LogManager.getLoggerNames(), reset, and adds and remove loggers concurrently - mostly for the purpose of validating that no CME will be thrown. It also attempts to partially validate the logger names enumeration returned by LogManager - but the validation logic left a small opportunity for a race condition to appear (and it did). http://cr.openjdk.java.net/~dfuchs/webrev_8079773/webrev.00/ best regards, -- daniel

2 1

RFR JDK-8079778: Mark intermittently failing: java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java
by FELIX YANG 08 May '15

08 May '15

Hi all, java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java has been observed to fail intermittently. This fix is to mark it with keyword 'intermittent'. Bug: https://bugs.openjdk.java.net/browse/JDK-8079778 thanks, -Felix diff -r d18205a1ef80 test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java --- a/test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java Fri May 08 09:05:15 2015 -0400 +++ b/test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java Fri May 08 15:47:53 2015 +0100 @@ -29,6 +29,7 @@ * @library ../../testlibrary * @build TestLibrary RMID ActivationLibrary * @run main/othervm/timeout=240 RmidViaInheritedChannel + * @key intermittent */ import java.io.IOException;

2 1

RFR JDK-8029689: (spec) Reader.read(char[], int, int) throws unspecified IndexOutOfBoundsException
by Pavel Rappo 08 May '15

08 May '15

Hi everyone, Could you please review my change for JDK-8029689 http://cr.openjdk.java.net/~prappo/8029689/webrev.00/ ------------------------------------------------------------------------------- There is a long-standing issue when platform implementations of java.io.Reader throw IndexOutOfBoundsException for bounds checks from inherited java.io.Reader.read(char[], int, int) method though java.io.Reader itself does not specify this situation. Suggested solution is to update the contract of java.io.Reader.read(char[], int, int) and its publicly exported descendants to capture the implied preconditions for reading range and the array size. Given that throwing IOBE in this situation is a de facto standard, this change won't bring any kind of incompatibility, though to stay compliant 3rd party implementations may need to be updated. -Pavel

4 6

RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls
by Aleksey Shipilev 08 May '15

08 May '15

Hi, This seems to be a simple one-liner fix, but the background is more complicated. See the bug: https://bugs.openjdk.java.net/browse/JDK-8076759 The bottom line is that our current resizing policy in ASB is hostile for long appends. There is a heuristics that extends the capacity to match the *exact* length of append if doubling the array would not help. This heuristics has a nasty corner case: if there is an upcoming append after a large one, then we are guaranteed to re-size again. If an upcoming append is large in itself, the resizing is inevitable even under the doubling-the-storage strategy; but if we only do a small append, then we can be smarter. After trying a few options to fix this (see below), I have settled on just adding a simple static "pad", to absorb the trivial appends after a large append: http://cr.openjdk.java.net/~shade/8076759/webrev.00/ The choice of "32" as magic number is deliberate: arraycopy likes large power-of-two strides (and it does not like to make catch up loops for small residuals). "16" is too small to fit the decimal representation of Long.MIN_VALUE, therefore, we pick "32". There are other approaches, briefly mentioned here: http://cr.openjdk.java.net/~shade/8076759/patches.txt There is a direct correlation between the allocation pressure, and test performance: http://cr.openjdk.java.net/~shade/8076759/data-perf.png http://cr.openjdk.java.net/~shade/8076759/data-foot.png Naively, one could expect doubling the storage ("mult2") until we reach $minimalCapacity solves the problem, but it wastes too much memory, and only reaches the "plus32" on power-of-two sizes. That is also the Achilles' Heel of the heuristics, because appending the power-of-two-plus-one-sized string will set us up for the original problem. This effect can be alleviated by doing the padding as well ("mult2-plus32"). Exactly the same trouble manifests on smaller strings that go through the usual double-the-storage route, and this is why a proposed patch makes the pad on common path. I do believe the current heuristics is smart about large appends, and mult2* strategies undo it. Therefore, I would think keeping the minimumCapacity cap is a good thing, and just adding the pad is a good solution. Thus, it is in the webrev. Thanks, -Aleksey.

4 12

RFR: 8062518: AIOBE occurs when accessing to document function in extended function in JAXP
by Aleksej Efimov 07 May '15

07 May '15

Please, review the fix for the failure observed while accessing external document during xsl transformation: https://bugs.openjdk.java.net/browse/JDK-8062518 The jaxp code limits the access to external documents, but there is a possibility to access such documents from the xsl code - new regression test checks this functionality. The fix removes this restriction and AIOBE: http://cr.openjdk.java.net/~aefimov/8062518/9/webrev.00/ Testing: xml related regression tests (with new test) - no failures (from jdk and jaxp repos). JCK xml related tests - no failures. With Best Regards, Aleksej

2 4

RFR [9] RandomFactory should be in the jdk.testlibrary package
by Chris Hegarty 07 May '15

07 May '15

When trying to use the recently added RandomFactory test library utility, I noticed that it is missing a package declaration. The pattern to date has been for these test library utilities to be declared in the jdk.testlibrary package, and imported by tests requiring them. This is a simple patch that does just that. I think this was a minor oversight, as opposed to a deliberate decision to put RandomFactory in the unnamed package. diff --git a/test/lib/testlibrary/jdk/testlibrary/RandomFactory.java b/test/lib/testlibrary/jdk/testlibrary/RandomFactory.java --- a/test/lib/testlibrary/jdk/testlibrary/RandomFactory.java +++ b/test/lib/testlibrary/jdk/testlibrary/RandomFactory.java @@ -21,6 +21,8 @@ * questions. */ +package jdk.testlibrary; + import java.util.Random; import java.util.SplittableRandom; diff --git a/test/java/lang/Double/ParseHexFloatingPoint.java b/test/java/lang/Double/ParseHexFloatingPoint.java --- a/test/java/lang/Double/ParseHexFloatingPoint.java +++ b/test/java/lang/Double/ParseHexFloatingPoint.java @@ -32,6 +32,8 @@ * @key randomness */ +import jdk.testlibrary.RandomFactory; + public class ParseHexFloatingPoint { private ParseHexFloatingPoint(){} diff --git a/test/java/lang/Integer/BitTwiddle.java b/test/java/lang/Integer/BitTwiddle.java --- a/test/java/lang/Integer/BitTwiddle.java +++ b/test/java/lang/Integer/BitTwiddle.java @@ -33,6 +33,7 @@ */ import java.util.Random; +import jdk.testlibrary.RandomFactory; import static java.lang.Integer.*; public class BitTwiddle { diff --git a/test/java/lang/Long/BitTwiddle.java b/test/java/lang/Long/BitTwiddle.java --- a/test/java/lang/Long/BitTwiddle.java +++ b/test/java/lang/Long/BitTwiddle.java @@ -33,6 +33,7 @@ */ import java.util.Random; +import jdk.testlibrary.RandomFactory; import static java.lang.Long.*; public class BitTwiddle { diff --git a/test/java/lang/Math/CubeRootTests.java b/test/java/lang/Math/CubeRootTests.java --- a/test/java/lang/Math/CubeRootTests.java +++ b/test/java/lang/Math/CubeRootTests.java @@ -32,6 +32,8 @@ * @key randomness */ +import jdk.testlibrary.RandomFactory; + public class CubeRootTests { private CubeRootTests(){} diff --git a/test/java/lang/Math/HypotTests.java b/test/java/lang/Math/HypotTests.java --- a/test/java/lang/Math/HypotTests.java +++ b/test/java/lang/Math/HypotTests.java @@ -32,6 +32,8 @@ * @key randomness */ +import jdk.testlibrary.RandomFactory; + public class HypotTests { private HypotTests(){} diff --git a/test/java/lang/Math/IeeeRecommendedTests.java b/test/java/lang/Math/IeeeRecommendedTests.java --- a/test/java/lang/Math/IeeeRecommendedTests.java +++ b/test/java/lang/Math/IeeeRecommendedTests.java @@ -32,6 +32,8 @@ * @key randomness */ +import jdk.testlibrary.RandomFactory; + public class IeeeRecommendedTests { private IeeeRecommendedTests(){} diff --git a/test/java/lang/Math/Log1pTests.java b/test/java/lang/Math/Log1pTests.java --- a/test/java/lang/Math/Log1pTests.java +++ b/test/java/lang/Math/Log1pTests.java @@ -32,6 +32,8 @@ * @key randomness */ +import jdk.testlibrary.RandomFactory; + public class Log1pTests { private Log1pTests(){} diff --git a/test/java/math/BigDecimal/StringConstructor.java b/test/java/math/BigDecimal/StringConstructor.java --- a/test/java/math/BigDecimal/StringConstructor.java +++ b/test/java/math/BigDecimal/StringConstructor.java @@ -33,6 +33,7 @@ import java.math.*; import java.util.Random; +import jdk.testlibrary.RandomFactory; public class StringConstructor { diff --git a/test/java/math/BigInteger/BigIntegerTest.java b/test/java/math/BigInteger/BigIntegerTest.java --- a/test/java/math/BigInteger/BigIntegerTest.java +++ b/test/java/math/BigInteger/BigIntegerTest.java @@ -40,6 +40,7 @@ import java.io.ObjectOutputStream; import java.math.BigInteger; import java.util.Random; +import jdk.testlibrary.RandomFactory; /** * This is a simple test class created to ensure that the results diff --git a/test/java/math/BigInteger/ModPow65537.java b/test/java/math/BigInteger/ModPow65537.java --- a/test/java/math/BigInteger/ModPow65537.java +++ b/test/java/math/BigInteger/ModPow65537.java @@ -37,6 +37,7 @@ import java.security.*; import java.security.spec.*; import java.util.Random; +import jdk.testlibrary.RandomFactory; public class ModPow65537 { diff --git a/test/java/math/BigInteger/PrimeTest.java b/test/java/math/BigInteger/PrimeTest.java --- a/test/java/math/BigInteger/PrimeTest.java +++ b/test/java/math/BigInteger/PrimeTest.java @@ -40,6 +40,7 @@ import java.util.Set; import java.util.SplittableRandom; import java.util.TreeSet; +import jdk.testlibrary.RandomFactory; import static java.util.stream.Collectors.toCollection; import static java.util.stream.Collectors.toList; diff --git a/test/java/math/BigInteger/SymmetricRangeTests.java b/test/java/math/BigInteger/SymmetricRangeTests.java --- a/test/java/math/BigInteger/SymmetricRangeTests.java +++ b/test/java/math/BigInteger/SymmetricRangeTests.java @@ -40,6 +40,7 @@ import java.util.Arrays; import java.math.BigInteger; import java.util.Random; +import jdk.testlibrary.RandomFactory; public class SymmetricRangeTests { diff --git a/test/java/util/regex/RegExTest.java b/test/java/util/regex/RegExTest.java --- a/test/java/util/regex/RegExTest.java +++ b/test/java/util/regex/RegExTest.java @@ -46,6 +46,7 @@ import java.util.*; import java.nio.CharBuffer; import java.util.function.Predicate; +import jdk.testlibrary.RandomFactory; /** * This is a test class created to check the operation of -Chris.

2 1