June 2014 - core-libs-dev

Streams and Spliterator characteristics confusion
by Kasper Nielsen 30 Jun '14

30 Jun '14

Hi, I'm trying to understand how the Spliterator.characteristics are maintained across stream operations and I'm a bit confused. Maybe someone here can clear it up for me s.sorted().spliterator() -> Spliterator.SORTED = true But if I use specify a comparator the stream is not sorted s.sorted((a,b) -> 1).spliterator() -> Spliterator.SORTED = false s.distinct().spliterator() -> Spliterator.DISTINCT = true but limiting the number of distinct elements makes the stream non distinct s.distinct().limit(10).spliterator() -> Spliterator.DISTINCT = false On the other hand something like Spliterator.SORTED is maintained when I invoke limit s.sorted().limit(10).spliterator() -> Spliterator.SORTED = true A flag such as Spliterator.NONNULL is also cleared in situations where it should not be. In my opinion an operation such as filter(predicate) should not flip the flag. Finally, are there any relationship between Spliterator.SORTED and Spliterator.ORDERED. I would think that a stream cannot be sorted without it also being ordered? but s.sorted().unordered().spliterator returns ORDERED=false and SORTED=true Cheers Kasper

2 3

[9] Request for Review: 8048337: Examine if macosx/bundle/JavaAppLauncher and JavaAppLauncher.java can be removed
by David DeHaven 27 Jun '14

27 Jun '14

As the subject says, so examined and determined that it can indeed be removed. The Java source was being built and included in rt.jar, but it would not run because jdk/src/macosx/native/apple/launcher/JavaAppLauncher.m (implementing the two native methods) was not being built so it would have died with an UnsatisfiedLinkError. The Xcode project is not referenced anywhere in any makefile I looked at. Since it's not used anywhere (and appears to never have been used at all?), it should be purged from the jdk source. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8048337 Webrev: http://cr.openjdk.java.net/~ddehaven/8048337/jdk.0/ -DrD-

2 2

Ready for Review : 8042469 : Launcher changes for native memory tracking scalability enhancement
by Neil Toda 27 Jun '14

27 Jun '14

Launcher support for modified Native Memory Tracking mechanism in JVM in JDK9. Webrev : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/ bug : https://bugs.openjdk.java.net/browse/JDK-8042469 CCC : http://ccc.us.oracle.com/8042469 Thanks. -neil

5 20

RFR: 8048207 : (xs) Collections.checkedQueue offer() calls add() on wrapped queue
by Mike Duigou 27 Jun '14

27 Jun '14

Hello all; This changeset corrects an issue with the Collections.checkedQueue() utility method added in Java 8. The wrapper implementation incorrectly calls add() on the wrapped queue rather than offer(). I improved the existing unit test to include this condition (and converted it to TestNG). I also converted a few uses of Collections.CheckedCollection.typeCheck to use the returned properly typed result where previously the callers had been using it as a standalone check. jbsbug: https://bugs.openjdk.java.net/browse/JDK-8048207 webrev: http://cr.openjdk.java.net/~mduigou/JDK-8048207/0/webrev/ Mike

2 1

Re: JDK9 project: XML/JAXP Approachability / Ease of Use
by Michael Kay 27 Jun '14

27 Jun '14

Here are some quick thoughts about the state of XML support in the JDK: 1. XML Parser. The version of Xerces in the JDK has long been buggy, and no-one has been fixing the bugs. It needs to be replaced with a more recent version of Apache Xerces if that hasn't already been done. 2. DOM. From a usability perspective DOM is awful. There are much better alternatives available, for example JDOM2 or XOM. The only reason anyone uses DOM rather than these alternatives is either (a) because they aren't aware of the alternatives, or (b) because of some kind of perception that DOM is "more standard". If we want to address the usability of XML processing in the JDK then an alternative/replacement for DOM would seem to be a high priority. If someone wants a summary of the badness of DOM then I'll address that in a separate thread. 3. JAXP factory mechanism. While the goal of allowing multiple implementations of core interfaces such as DOM, XPath, and XSLT is laudable, the current mechanism has many failings. It's hideously expensive because of the classpath search; it's fragile because the APIs are so weakly defined that the implemntations aren't 100% interoperable (for example you have no way of knowing whether the XPath factory will give you an XPath 1.0 or 2.0 processor, and no way of finding out which you have got); so in practice we see lots of problems where applications get a processor that doesn't work as the applications expects, just because it happens to be lying around on the classpath. 4. XQJ. The XQJ spec never found its way into the JDK, so there is no out-of-the-box XQuery support. The licensing terms for XQJ are also unsatisfactory (the license doesn't allow modification, which purists say means it's not a true open source license). 5. General lack of integration across the whole XML scene, e.g, separate and potentially incompatible factories for different services; a lack of clarity as to whether the XPath API is supposed to handle object models other than DOM, etc; weak typing of interfaces such as setParameter() in order to accomodate variation, at the cost of interoperability. 6. Failure to keep up to date with the W3C specs; if you want support for recent versions of XSLT or XPath then you need to go to third-party products. Even at the DOM level, namespaces are a bolt-on optional extra rather than an intrinsic capability. 7. Inconsistent policy on concrete classes versus interfaces. Is this project attempting to address the fundamental problems, or only to paper over the cracks? > We're planning on a jaxp project to address usability issues in the JAXP > API. One of the complaints about the JAXP API is the number of lines of > code that are needed to implement a simple task. Tasks that should take > one or two lines often take ten or twelve lines instead. Michael Kay Saxonica mike(a)saxonica.com +44 (0118) 946 5893

3 2

Process trees and termination
by roger riggs 26 Jun '14

26 Jun '14

Hi, The next step for JEP 102, Process API Updates is to provide an API to enumerate the hierarchy of processes and to be able to terminate a process tree. This draft javadoc <http://bussund0416/%7Erriggs/pdoc/>update [1] includes: - ProcessHandle class to provide handles to processes, their children, parent, process id and liveness - Process extends ProcessHandle and inherits the new behaviors - Method destroyProcessTree() terminates a process tree Additional functions related to termination and information about processes will be added in a later update. Comments appreciated, Roger [1] http://cr.openjdk.java.net/~rriggs/ph-apidraft/

5 7

RFR: 8047795: Collections.checkedList checking bypassed by List.replaceAll
by Mike Duigou 25 Jun '14

25 Jun '14

Hello all; This changeset corrects a reported problem with the lists returned by Collections.checkedList(). Since Java 8 the replaceAll() method on checked lists has erroneously allowed the operator providing replacements to provide illegal replacement values which are then stored, unchecked into the wrapped list. This changeset adds a check on the proposed replacement value and throws a ClassCastException if the replacement value is incompatible with the list. Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable. Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained. jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795 webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/ This change will be backported to Java 8. Mike

4 7

JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for private methods
by Joe Darcy 25 Jun '14

25 Jun '14

Hello, Please review the libraries update portion of allowing @SafeVarargs on private instance methods: JDK-8048014: Update java.lang.SafeVararags for private methods The patch is diff -r 6c26f18d9bc0 src/share/classes/java/lang/SafeVarargs.java --- a/src/share/classes/java/lang/SafeVarargs.java Mon Jun 23 12:12:30 2014 -0700 +++ b/src/share/classes/java/lang/SafeVarargs.java Tue Jun 24 10:03:21 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2010, 2014, 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 @@ -45,7 +45,7 @@ * <li> the declaration is a fixed arity method or constructor * * <li> the declaration is a variable arity method that is neither - * {@code static} nor {@code final}. + * {@code static} nor {@code final} nor {@code private}. * * </ul> * The bulk of the change to allow @SafeVarargs on private methods, including the tests, are over in the langtools repo with javac updates. The javac changes have been reviewed and approved on compiler-dev: http://mail.openjdk.java.net/pipermail/compiler-dev/2014-June/008855.html Thanks, -Joe

4 5

RFR: 8047723: @since tag cleanup in jaxp
by Henry Jen 24 Jun '14

24 Jun '14

Hi, Please review a trivial webrev for jdk9/jaxp that do the same @since tag normalization as in jdk9/jdk. http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/ I am not sure if there is another mailing list thatis more appropriate for this, if so, please direct me to the right ml. Thanks. Cheers, Henry

2 6

A question about Depth of container annotations
by deven you 24 Jun '14

24 Jun '14

Hi All, I have a question about repeated annotation depth. If this is not the proper mailing list group, please tell me where I should send it to. My question will be about the depth of container annotations. For instance, assume there are 3 annotations. - RepeatedAnn - ContainerAnn - ContainerContainerAnn So, ContainerContainerAnn can have ContainerAnn and that can also have RepeatbleAnn in it. In this case, get*AnnotationsByType(RepeatableAnn) APIs wont return repeteableAnns in depth 2. Java docs don't talk about the depth. I wonder if the get*AnnotationsByType api should return the annotations of all depth? If we have below annotations: @Retention(RetentionPolicy.RUNTIME) @Repeatable(ContainerAnn.class) @interface RepeatableAnn { String value(); } @Inherited @Retention(RetentionPolicy.RUNTIME) @Repeatable(ContainerContainerAnn.class) @interface ContainerAnn { RepeatableAnn[] value(); } @Inherited @Retention(RetentionPolicy.RUNTIME) @interface ContainerContainerAnn { ContainerAnn[] value(); } And the main class is annotated by : @ContainerAnn({@RepeatableAnn("Parent-3")}) @ContainerAnn({@RepeatableAnn("Parent-4")}) public class Test { ... when we call getAnnotationsByType(RepeatableAnn.class) on this class, we get nothing because RepeatableAnn is contained by ContainerAnn which is also contained by ContainerContainerAnn. In other words, RepeatableAnn is in depth 2 and get*AnnotationsByType APIs only searches depth 1. The test results are: /home/deven/jdk8_20/jdk1.8.0_20/bin$ java repeated.Test CLASS = repeated.Test getDeclaredAnnotationsByType(RepeatableAnn.class) getDeclaredAnnotationsByType(ContainerAnn.class) @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)]) @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)]) getDeclaredAnnotationsByType(ContainerContainerAnn.class) @repeated.ContainerContainerAnn(value=[@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)]), @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])]) getAnnotationsByType(RepeatableAnn.class) getAnnotationsByType(ContainerAnn.class) @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)]) @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)]) getAnnotationsByType(ContainerContainerAnn.class) @repeated.ContainerContainerAnn(value=[@repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-3)]), @repeated.ContainerAnn(value=[@repeated.RepeatableAnn(value=Parent-4)])])

2 1