November 2017 - core-libs-dev

RFR: 8067661 transferTo() for Appendable
by Patrick Reinhart 05 Nov '17

05 Nov '17

After discussing [0] for about the API for the new transferTo() method on Appendable, I have created an initial Version of the actual implementation for review: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.00/index.html Any comments/suggestions are welcome, also I will need a sponsor for it at the end… -Patrick [0|] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/049797.h…

2 2

[PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
by Christoph Dreis 03 Nov '17

03 Nov '17

Hey, while discussing JDK-8029019 & JDK-8189266 Claes came up with the idea to introduce non-copying access to the underlying parameter types of an Executable [1]. While there is a (for a good reason?) package-private Method.getSharedParameterTypes() already I thought of an alternative that doesn't open up the parameterTypes array to the outside world and actually solves the use-case where we wanted an allocation-free alternative for Method.getParameterTypes()[index]. Here is a draft of what I'm thinking of: Executable: /** * Returns the {@code Class} object that represents the formal * parameter type, at the given index, of the executable * represented by this object. The given index starts at 0 and * represents the declaration order of the parameters. * * * @param index index to look for the parameter type * @return the parameter type at the given index for the executable this object * represents * @throws IndexOutOfBoundsException if the parameter type * at the given index of the underlying executable could not be found */ public abstract Class<?> getParameterType(int index); Method & Constructor: /** * {@inheritDoc} * @throws IndexOutOfBoundsException {@inheritDoc} * @since 18.3 */ public Class<?> getParameterType(int index) { if (index < 0 || index > getParameterCount()) { throw new IndexOutOfBoundsException("No parameter found on index " + index); } return parameterTypes[index]; } As I don't know what the official @since should look like in the future, do not pay too much attention on that. I'm not happy with the documentation wording though. What do you think about that? Is someone willing to sponsor this given it's considered worthwhile. Cheers, Christoph [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049520.htm l

5 16

JDK 10 RFR of JDK-8190573: Problem list InheritedChannelNotServerSocket.java
by joe darcy 02 Nov '17

02 Nov '17

Hello, The test java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java fails intermittently fairly often (JDK-8170562). Until the instability is addressed, I'd like to put the test on the problem list. Patch below. Thanks, -Joe diff -r 30186b6741b8 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Thu Oct 26 18:04:29 2017 -0700 +++ b/test/jdk/ProblemList.txt Thu Nov 02 13:12:00 2017 -0700 @@ -200,6 +200,8 @@ java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java 8169569 windows-all +java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java 8170562 generic-all + java/rmi/registry/readTest/CodebaseTest.java 8173324 windows-all ############################################################################

2 1

[PATCH] 8178117: Add public state constructors for Int/Long/DoubleSummaryStatistics
by Chris Dennis 02 Nov '17

02 Nov '17

Hi Paul (et al) Like all things API there are wrinkles here when it comes to implementing. This patch isn’t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that’s the only testing that can really occur here). The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn’t defend against: * I chose to ignore all parameters if 'count == 0’ and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things’ (beyond how broken they would already be) if count == 0 only due to overflow. * I chose to fail if count is negative. * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I’m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result). I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented. There are arguments for this and also arguments for the other extreme (no validation at all). Personally I’m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it’s at odds with approach of the existing implementation. Would appreciate thoughts/feedback. Thanks. Chris P.S. I presume tests would be required for the parameter checking (once it is finalized)?

8 23

Confusion (or bugs) regarding the 'UNORDERED' Collector Characteristic
by Chris Dennis 02 Nov '17

02 Nov '17

Hi All, I’m very confused about what was intended with the ‘UNORDERED’ Collector characteristic. My logical inference was that unordered as a Collector characteristic meant that the result of this collector applied to any stream was independent of the order of element delivery. This means that the stream backend could safely elide any ordered characteristic of the stream driving the collector and open up more possible execution pathways (parallelism for example). The javadoc for unordered is two sentences: /** * Indicates that the collection operation does not commit to preserving * the encounter order of input elements. (This might be true if the * result container has no intrinsic order, such as a {@link Set}.) */ The first sentence makes sense, although it is phrased in a way that also explains the behavior seen if you flag an order sensitive collector as unordered. The second sentence is weird, it implies a relation between collectors, encounter order, and an inherent ordering or iteration order of a collection object that might be the target of a collection. To me the important property of a Collection object with regards to ordering of a Collector that fills it is whether reordering the insertions to the collection can change the resultant state, for a Set this is clearly true since only the first presented element that is equal will be stored. There is also a paragraph in the Collector javadoc: * <p>For collectors that do not have the {@code UNORDERED} characteristic, * two accumulated results {@code a1} and {@code a2} are equivalent if * {@code finisher.apply(a1).equals(finisher.apply(a2))}. For unordered * collectors, equivalence is relaxed to allow for non-equality related to * differences in order. (For example, an unordered collector that accumulated * elements to a {@code List} would consider two lists equivalent if they * contained the same elements, ignoring order.) This seems weird, why would we try to define correctness of a parallel reduction against a collector that was sensitive to ordering. Finally, when investigating the properties of the collectors returned from the Collectors static factory I was surprised to discover that none of the collectors that are truly unordered were marked as such (counting, min, max, averaging, summing, summarizing), and the only collector that was marked as unordered was Collectors.toSet(), which although it is explicitly marked as unordered seems like it really shouldn’t be. Whats going on here? Which parts of all this are intended and which (if any) are bugs? Thanks in advance for any enlightenment, Chris Dennis P.S. Coincidentally the unordered toSet() collector works perfectly at the moment due to the happy interaction of the Spliterator.trySplit() contract and the folding/combining behavior of the stream implementations parallel reduction algorithm.

2 2

[Bug][JDK10] Fix duplicated "a" occurrences in docs
by Christoph Dreis 02 Nov '17

02 Nov '17

Hey, similar to JDK-8190323 the attached patch removes duplicated "a" occurrences in java.base docs. Would be happy if this is sponsored. I wasn't sure about the capitalization change on EventObject. What's the rule of thumb in cases where the class does not follow the guidelines for docs[1]? Sticking to the overall class scheme or aligning everything? Cheers, Christoph [1] http://www.oracle.com/technetwork/articles/java/index-137868.html

7 10

RFR 8190505, typo in test/jdk/ProblemList.txt
by Felix Yang 02 Nov '17

02 Nov '17

Please review a minor patch to correct typo in test/jdk/ProblemList.txt. Change "Hashmap" to "HashMap". diff -r 4a35a00eb001 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Wed Nov 01 16:45:28 2017 +0100 +++ b/test/jdk/ProblemList.txt Wed Nov 01 23:34:44 2017 -0400 @@ -320,7 +320,7 @@ org/omg/CORBA/OrbPropertiesTest.java 8175177 generic-all -javax/rmi/PortableRemoteObject/ConcurrentHashmapTest.java 8080643 generic-all +javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java 8080643 generic-all javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all Issue: https://bugs.openjdk.java.net/browse/JDK-8190505 Thanks, Felix

2 1