April 2016 - core-libs-dev

RFR 8154049: DualPivot sorting calculates incorrect runs for nearly sorted arrays
by Paul Sandoz 03 May '16

03 May '16

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154049-dual-pivot-sort-one-of… https://bugs.openjdk.java.net/browse/JDK-8154049 A bug was introduced with the fix for: https://bugs.openjdk.java.net/browse/JDK-8080945 Improve the performance of primitive Arrays.sort for certain patterns of array elements Certain patterns of nearly sorted data failed to sort, and surprisingly (and embarrassingly) this was not detected by existing sorting tests. It was detected by pack200 tests, but the intermittent nature of the failure at a distance meant it took a while to track this down. If the number of elements to sort is > QUICKSORT_THRESHOLD (286), then a loop over the elements is performed to count equals, ascending and descending (transformed into ascending) runs. If the number of runs is < MAX_RUN_COUNT (67) then a merge sort of the runs is performed. When the loop finishes it is necessary to clean up some edge cases to report a final run. Modifications for JDK-8080945 failed to take into account an additional case for reporting a final run (specifically a run of equals elements, in addition to the previous case of a single last element). The fix is correctly report a final run in all cases. I tried to make the code more explicit. (It might be possible to clean up the code more, but i want to get a conservative fix in). I have also modified the nearly sorted test case: - all primitive types are correctly tested based on size thresholds, specifically short/char have a lower bound, COUNTING_SORT_THRESHOLD_FOR_SHORT_OR_CHAR (3200) above which a counting sort is performed. - added a combinatorial test, where 4 (base 3) digits, each taking values of -1, 0 or 1, bound at either side a sequence of zeros of sufficient length to ensure the array size is above the quick sort threshold. This should exercise all run counting code paths In addition we have run the pack200 “test from hell” (thanks Kumar!) and this now passes without failure. Paul.

2 2

JDK 9 RFR of adding a few @jls tags to java.lang.String
by joe darcy 03 May '16

03 May '16

Hello, Please review the small patch below to add some JLS references to the string class to supplement its textual discussion of a few sections of the JLS. Thanks, -Joe --- a/src/java.base/share/classes/java/lang/String.java Fri Apr 29 16:58:00 2016 -0700 +++ b/src/java.base/share/classes/java/lang/String.java Sat Apr 30 12:32:19 2016 -0700 @@ -117,6 +117,7 @@ * @see java.lang.StringBuilder * @see java.nio.charset.Charset * @since 1.0 + * @jls 15.18.1 String Concatenation Operator + */ public final class String @@ -2979,6 +2980,7 @@ * * @return a string that has the same contents as this string, but is * guaranteed to be from a pool of unique strings. + * @jls 3.10.5 String Literals */ public native String intern();

5 4

RFR: 8155600: jaxp.library.TestPolicy should extend the default security policy
by Frank Yuan 03 May '16

03 May '16

Hi Mandy, Joe and all Would you like to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8155514? The webrev is at: http://cr.openjdk.java.net/~fyuan/8155514/webrev.00/. It's verified with the source bundle in http://scaaa637.us.oracle.com/archive/2016/04/2016-04-26-045641.mlchung.jdk… Thanks, Frank

3 7

JEP 118 Parameter Names by default
by Steven Schlansker 03 May '16

03 May '16

Hi core-libs-dev, Apologies in advance if this is the wrong list, I was torn between this one and compiler-dev, but I'm already subscribed here so we'll try this first :) I am trying to understand why the javac '-parameters' option is not enabled by default. Normally it would not be too onerous, but due to some limitations in e.g. Maven it is surprisingly difficult to configure correctly in a world where you must build code that both targets e.g. 1.8 and 1.7 (and soon 1.9): http://mail-archives.apache.org/mod_mbox/maven-dev/201604.mbox/browser While I am happy to work with the Maven project to improve their support for sending compiler arguments more flexibly, I did wonder -- why is this feature not on by default? I did some brief searching and was unable to come up with any downside, but maybe I missed something obvious? Can we turn it on by default for Java 9? Thanks for humoring me, Steven

2 2

RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them
by Steve Drach 03 May '16

03 May '16

I’ve updated the webrev to change all instances of the word “reified” to “real” as in getRealName(). Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 <https://bugs.openjdk.java.net/browse/JDK-8151542> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev.01/ <http://cr.openjdk.java.net/~sdrach/8151542/webrev.01/>

5 19

RFR (M) 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures
by Aleksey Shipilev 02 May '16

02 May '16

Hi, I would like to fix a simple testbug in our weakCompareAndSet VarHandles and Unsafe intrinsics tests. weakCompareAndSet is spec-ed to allow spurious failures, but current tests do not allow that. This blocks development and testing on non-x86 platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8155739 Webrevs: http://cr.openjdk.java.net/~shade/8155739/webrev.hs.00/ http://cr.openjdk.java.net/~shade/8155739/webrev.jdk.00/ The tests are auto-generated, and the substantiative changes are in *.template files. I also removed obsolete generate-unsafe-tests.sh. I would like to push through hs-comp to expose this to Power and AArch64 folks early. Testing: x86_64, jdk:java/lang/invoke/VarHandle, hotspot:compiler/unsafe Thanks, -Aleksey

3 4

RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean
by Daniel Fuchs 02 May '16

02 May '16

Hi, Please find below a patch [2] that eliminates a static dependency of java.lang.management on java.util.logging.LoggingMXBean. When JDK-6876135 was fixed, it introduced the PlatformLoggingMXBean interface, and recommended using PlatformLoggingMXBean over LoggingMXBean. However, it left a static dependency on java.util.logging.LoggingMXBean in java.lang.management: The MBean registered in the MBeanServer was a private class in ManagementFactoryHelper implementing a non standard interface that extended both PlatformLoggingMXBean and LoggingMXBean. (sun.management.ManagementFactoryHelper$LoggingMXBean) (see https://bugs.openjdk.java.net/browse/JDK-6876135) This patch proposes to relax the constraint on the PlatformLoggingMXBean implementation - by no longer forcing it to implement LoggingMXBean. This will allow to get rid of the non standard interface, and make the MBean declare "java.lang.management.PlatformLoggingMXBean" as its MXBean interface. To make it clear that PlatformLoggingMXBean should be used instead of LoggingMXBean we also propose to deprecate the java.util.logging.LoggingMXBean interface as well as the LogManager.getLoggingMXBean() method (since it returns a deprecated type). As of yet, there no intention of removing any of these. Backward Compatibility considerations: -------------------------------------- 1. Local clients which obtain an instance of the logging MXBean by calling ManagementFactory.getPlatformMXBean( "java.util.logging:type=Logging", PlatformLoggingMXBean.class) will no longer be able to cast the result on java.util.logging.LoggingMXBean. [There should be few, given that PlatformLoggingMXBean already has all the methods defined in LoggingMXBean] 2. ManagementFactory.getPlatformMBeanServer().isInstanceOf( ObjectName, "java.util.logging.LoggingMXBean") will now return 'false' instead of 'true'. 3. The Logging MXBean MBeanInfo will now report that its management interface is "java.lang.management.PlatformLoggingMXBean" instead of "sun.management.ManagementFactoryHelper$LoggingMXBean". 4. Calls to ManagementFactory.newPlatformMXBeanProxy( MBeanServerConnection, ObjectName, java.util.logging.LoggingMXBean.class); and JMX.newMXBeanProxy(MBeanServerConnection, ObjectName, java.util.logging.LoggingMXBean.class) will continue to work as before. 5. Remote clients running previous version of the JDK should see no changes, except for the interface name in MBeanInfo, and the change in isInstanceOf reported in 2. [1] JBS issue: https://bugs.openjdk.java.net/browse/JDK-8139982 [2] webrev: http://cr.openjdk.java.net/~dfuchs/8139982_webrev/webrev.06/index.html best regards, -- daniel

2 6

String.equalsIgnoreCase(...) optimization
by Andrey 01 May '16

01 May '16

Hello! I read source code equalsIgnoreCase(...) in String class and saw that it is not optimal. This method check length and call regionMatches(...) with 'constant' values http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classe… ... && (anotherString.value.length == value.length) && regionMatches(true, 0, anotherString, 0, value.length); ... But regionMatches(...) check 'constant' values http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classe… // Note: toffset, ooffset, or len might be near -1>>>1. if ((ooffset < 0) || (toffset < 0) || (toffset > (long)value.length - len) || (ooffset > (long)other.value.length - len)) { return false; } and increment equalent variables to==po in loop http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classe… while (len-- > 0) { char c1 = ta[to++]; char c2 = pa[po++]; ... } and use if(...) in while loop http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classe… if (ignoreCase) { ... } May be can create optimized regionMatches(...) for use in equalsIgnoreCase(...)?

3 7

Re: RFR(m): 8140281 deprecate Optional.get()
by Paul Benedict 01 May '16

01 May '16

Are you asking Brian to set up another survey monkey for the masses? I expect a happy silent majority and a raucous minority.... just based on past results. :-) On Apr 26, 2016 6:38 PM, "Vitaly Davidovich" <vitalyd(a)gmail.com> wrote: I've yet to hear one supporter on this thread besides yourself and Stuart. Is there some usability survey or something that actually indicates a significant sample of people don't like the name? Guava Optional behaves and is named the same way, and I've not heard anyone complain about that (I and many people I know used it for years). I think the conversation would be *maybe* different if picking a name for a new thing, but the deprecation churn here adds no value, IMO, and is going to be viewed as an annoyance by a large swath of people. On Tuesday, April 26, 2016, Brian Goetz <brian.goetz(a)oracle.com> wrote: > As the person who chose the original (terrible) name, let me weigh in... > > I think calling this method "get()" was our biggest API mistake in Java > 8. Now, one could argue that, if this is the biggest mistake we made, then > we did pretty darn good. Which may be true, but ... make no mistake, it > was the wrong name (mea culpa), and experience has borne out that it is > widely misused. Subjectively, about half the uses of .get() I see are > wrong -- and wrong in the obvious, avoidable way -- they don't consider the > optional might be empty. So they've just traded an unexpected NPE for an > unexpected NSEE. > > Its problem is, essentially: it looks harmless, but isn't, but it sure > seems like the method you obviously want when you're browsing the > autocomplete list / javadoc. It's a hazard both to code writers (pick the > wrong method because the name is bad) and to code readers (deceptively > harmless looking.) > > Methods like orElse or ifPresent look harmless, and are; methods like > orElseThrow have potentially harmful side-effects but have names that are > transparent about what harm they could do. But Optional.get() is neither > safe nor transparent -- and yet awfully tempting-looking -- and this leads > to frequent misuse. Naming matters, and this one was wrong, and the harm > is observable. I wish I'd caught it before 8 shipped. > > Stepping back a bit ... one of the most frequent complaints we get is > "mistakes never get fixed". So, we've decided to be more serious about > deprecation -- Dr. Deprecator is suiting up! But that means, for any given > item, some people are going to disagree about whether deprecation is > suitable, and some will be inconvenienced by the deprecation -- this is > unavoidable. > > Why prioritize this one? In part, because it's a *new* mistake, and has > had less time to become entrenched -- and this is the very first > opportunity we have to fix it. If we can't fix an API mistake at the very > first opportunity, the logical consequence is we can't ever fix anything. > And that doesn't seem to be the world we want to retreat to. > > Similarly, is this the worst mistake in all of Java? Surely not. But its > also not reasonable to say "you can't fix X until you've fixed everything > worse than X" -- again, that's a recipe for never fixing anything. So, in > the context of a deprecation effort, this seems an entirely reasonable > candidate. > > I'd like to see it fixed, and the sooner the better. > > > On 4/26/2016 6:43 AM, Stephen Colebourne wrote: > >> In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this >> would be painful and add no value. >> >> While I understand the pain from some developers not understanding the >> feature, this is hardly unique in the world of Java. Developers learn >> the right way of doing something soon enough. >> >> And while >> >> if (opt.isPresent()) { >> opt.get() >> } >> >> is sometimes not ideal, in other cases it is the only practical choice >> (eg. where the method needs to have a return statement inside the if >> statement). >> >> Changing this to >> >> if (opt.isPresent()) { >> opt.getWhenPresent() >> } >> >> is just noise - I can see the "present" part twice. >> >> I just don't think I can support the rename (although many of the >> webrev tidy-ups are probably good). >> >> Stephen >> >> >> >> On 26 April 2016 at 00:05, Stuart Marks <stuart.marks(a)oracle.com> wrote: >> >>> Hi all, >>> >>> Please review these webrevs that deprecate Optional.get() and to replace >>> it >>> with Optional.getWhenPresent(). The corresponding changes are also >>> applied >>> to OptionalDouble.getAsDouble(), OptionalInt.getAsInt(), and >>> OptionalLong.getAsLong(). >>> >>> Unlike most deprecations, this isn't about the function or the utility of >>> some API, it's about the name. The solution is basically to rename the >>> API. >>> The problem is that "get" shows up as the "obvious" choice in things like >>> IDE code completion, leading to code that mishandles empty Optionals. >>> Typical Stack Overflow discourse runs something like this: >>> >>> Q: what do I do with this Optional thing >>> >>> A: just call get() >>> >>> Q: thanks, it works! >>> >>> Of course, it works until it doesn't. >>> >>> Examining the JDK's use of Optional.get(), I didn't see very many cases >>> that >>> called get() without first checking for the presence of a value. But I >>> did >>> see quite a number of cases like this: >>> >>> if (opt.isPresent()) { >>> doSomething(opt.get()); >>> } else { >>> doSomethingElse(); >>> } >>> >>> In many of these cases, the code could be refactored to use other >>> Optional >>> methods such as filter(), map(), or ifPresent(). >>> >>> In any case this reinforces the contention that use of get() leads to >>> poor >>> code. >>> >>> For this changeset, in just about all cases I've simply replaced the >>> call to >>> get() with a call to getWhenPresent(). In a couple cases I replaced the >>> stream calls >>> >>> .filter(Optional::isPresent).map(Optional::get) >>> >>> with >>> >>> .flatMap(Optional::stream) >>> >>> which I hope will become the new idiom for unwrapping a stream of >>> Optionals. >>> >>> While many cases could be cleaned up further, I didn't change them. The >>> reasons are that I didn't want to spend too much time putting code >>> cleanup >>> into the critical path of this changeset (I'd be happy to help later); >>> doing >>> so would create potential conflicts with code coming in from the Jigsaw >>> forest; and there are non-obvious places where converting from a >>> conditional >>> to one of the lambda-based methods could cause performance problems at >>> startup. >>> >>> There are also a few cases where simplification is prevented because it >>> would end up causing the resulting lambda expressions to throw checked >>> exceptions. :-( >>> >>> Webrevs here: >>> >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.langtools/ >>> >>> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.jdk/ >>> >>> Thanks, >>> >>> s'marks >>> >> > -- Sent from my phone

4 4

(S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's
by David Holmes 30 Apr '16

30 Apr '16

bug: https://bugs.openjdk.java.net/browse/JDK-8154710 webrev: http://cr.openjdk.java.net/~dholmes/8154710/webrev/ This change is small in nature but somewhat broad in scope. It "affects" the implementation of System.currentTimeMillis() in the Java space, and os::javaTimeMillis() in the VM. But on Solaris only. I say "affects" but the change will be unobservable other than in terms of performance. As of Solaris 11.3.6 a new in-memory timestamp has been made available (not unlike what has always existed on Windows). There are actually 3 different timestamps exported but the one we are interested in is get_nsecs_fromepoch - which is of course elapsed nanoseconds since the epoch - which is exactly what javaTimeMillis() is, but expressed in milliseconds. The in-memory timestamps have an update accuracy of 1ms, so are not suitable for any other API's that want the time-of-day, but at a greater accuracy. Microbenchmark shows the in-memory access is approx 45% faster (19ns on my test system) compared to the gettimeofday call (35ns). Thanks, David

6 10