March 2016 - core-libs-dev

Re: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8
by Dmitry Cherepanov 09 Mar '16

09 Mar '16

On Feb 19, 2016, at 1:55 PM, Nikolay Gorshkov <nikolay(a)azulsystems.com<mailto:nikolay@azulsystems.com>> wrote: Hi Sherman, Sean, Could you please help with making progress on this code review request? This fix is waiting for review since October. Webrev for jdk7u: http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.01/ Original mail thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035884.ht… I’m not expert in this area but the changes look reasonable to me. +1 for pushing this into JDK9. Thanks Dmitry Webrev for jdk9 (contributed by Alex Kashchenko): http://cr.openjdk.java.net/~akasko/jdk9/8133206/webrev.00/ Original mail thread: http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-November/003036.html Thanks, Nikolay On 11.12.2015 15:09, Nikolay Gorshkov wrote: Hi Sean, Thank you for your attention to this matter! Actually, the code review request was sent to core-libs-dev alias a month ago: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036463.h… Unfortunately, we haven't got any feedback yet. Thanks, Nikolay On 11.12.2015 14:34, Seán Coffey wrote: Hi Alex, I'm dropping jdk7u-dev mailing list for the moment. core-libs-dev is the mailing list where this review should happen. This fix would be required in JDK 9 first as per process. I think Sherman would be best to review if possible. Once it's soaked in JDK 9 for a few weeks, we could consider jdk8u and 7u backports. Regards, Sean. On 10/11/15 10:57, Alex Kashchenko wrote: Hi, On 10/21/2015 04:39 PM, Nikolay Gorshkov wrote: Hi Sherman, Thank you for your reply! My answers are inlined. > Can you be more specific about the "class loading cases" above? Sounds > more like we have a memory leaking here (the real root cause)? for example > the inflateEnd() never gets called? I agree, the real root cause is probably the following issue that exists since the end of 2002: https://bugs.openjdk.java.net/browse/JDK-4797189 "Finalizers not called promptly enough" And it is "the absence of a general solution to the non-heap resource exhaustion problem". zlib's inflateEnd() function is called by void java.util.zip.Inflater.end(long addr) native method only, and this method, in turn, is called only by void java.util.zip.Inflater.end() and void java.util.zip.Inflater.finalize() methods. According to the experiments, the typical stack trace for instantiating java.util.zip.Inflater is: java.util.zip.Inflater.<init>(Inflater.java:116) java.util.zip.ZipFile.getInflater(ZipFile.java:450) java.util.zip.ZipFile.getInputStream(ZipFile.java:369) java.util.jar.JarFile.getInputStream(JarFile.java:412) org.jboss.virtual.plugins.context.zip.ZipFileWrapper.openStream(ZipFileWrapper.java:222) <more jboss frames> org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:592) java.security.AccessController.doPrivileged(Native Method) org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:591) <more jboss frames> org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:447) java.lang.ClassLoader.loadClass(ClassLoader.java:358) java.lang.Class.forName0(Native Method) java.lang.Class.forName(Class.java:278) org.jboss.deployers.plugins.annotations.WeakClassLoaderHolder.loadClass(WeakClassLoaderHolder.java:72) <more jboss and other frames> It's quite hard to understand who is responsible for not calling Inflater.end() method explicitly; probably, it is the jboss/application's code. Unfortunately, we were in "it worked before and is broken now" customer situation here, so needed to fix it anyway. > From the doc/impl in inflate() it appears the proposed change should be > fine, though it's a little hacky, as you never know if it starts to return > Z_OK from some future release(s). Since the "current" implementation > never returns Z_OK, it might be worth considering to keep the Z_OK logic > asis in Inflater.c, together with the Z_BUF_ERROR, just in case? OK, I added handling of Z_OK code back. > I would be desired to add some words in Inflater.c to remind the > future maintainer why we switched from partial to finish and why to > check z_buf_error. I agree, added a comment. The updated webrev is available here: http://cr.openjdk.java.net/~nikgor/8133206/jdk7u-dev/webrev.01/ The change looks good to me (not a Reviewer/Committer). Patched jdk7u also passes JCK-7 on RHEL 7.1. I forward-ported this patch to jdk9 (consulted with Nikolay Gorshkov first), jtreg reproducer for jdk9 also works with jdk7u - http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-November/003036.html

3 2

RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator
by Chris Hegarty 09 Mar '16

09 Mar '16

sun.misc.ASCIICaseInsensitiveComparator appears to be a specialized comparator for comparing strings that contain only ASCII characters. Its main usage seems to be in sorted maps that support the character set implementation. This is startup/performance sensitive code. It looks like an "optimized" version of Strings public case insensitive comparator, when the strings are known to contain only ASCII characters. The public string case insensitive comparator, in some cases, does a toUpperCase and a toLowerCase. ASCIICaseInsensitiveComparator is trying to avoid this. Looking at String.CASE_INSENSITIVE_ORDER it looks like it can be, somewhat easily, optimized to give similar performance to that of ASCIICaseInsensitiveComparator without much risk. This will allow usages of ASCIICaseInsensitiveComparator to be replaced with String.CASE_INSENSITIVE_ORDER. For one, internal getChar does not pay the cost of bounds checks that charAt does ( which is used by ASCIICaseInsensitiveComparator ). What is in the webrev is specialized versions of compare when the coder of the strings match. Alternatively, this could be pushed down to String[Latin1|UTF16]. Webrev & bug: http://cr.openjdk.java.net/~chegar/8151384/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8151384 Benchmarks and results ( based, somewhat, on Aleksey's [1] ): http://cr.openjdk.java.net/~chegar/8151384/bench/ Two micro benchmarks: 1) Compare performance of comparing available charset names with ASCIICaseInsensitiveComparator and CASE_INSENSITIVE_ORDER. After the changes, CASE_INSENSITIVE_ORDER marginally out performs ASCIICaseInsensitiveComparator. 2) Compare general performance of CASE_INSENSITIVE_ORDER. The results show improved performance for all cases, especially when one, or more, strings contains UTF16. Note: this issue is not intending to optimize String.CASE_INSENSITIVE_ORDER as much as possible, just to make reasonable changes that improve performance to a point where it is a reasonable replacement for ASCIICaseInsensitiveComparator. Further optimization should not be prevented, or twarted, by this work. Note: the usage of ASCIICaseInsensitiveComparator in jar attributes appears to have been done to avoid the allocation cost of toLowerCase. This seems acceptable for hashCode, but could be avoided, if necessary. -Chris. [2] http://cr.openjdk.java.net/~shade/density/

5 22

java.net.http.ExecutorWrapper "memory fence"
by Aleksey Shipilev 09 Mar '16

09 Mar '16

Hi, In recently committed java.net.http.ExecutorWrapper, there is a synchronize() method [1], which is used as "memory fence" [2]: public synchronized void synchronize() {} public void execute(Runnable r, Supplier<AccessControlContext> ctxSupplier) { synchronize(); Runnable r1 = () -> { try { r.run(); } catch (Throwable t) { Log.logError(t); } }; ... executor.execute(r1); } How's that supposed to work? Is that supposed to guard from bad Runnable $r? The problem is, once you get $r via the race, there is no way to recover with local synchronization (IOW: There is no way to sanitize a racy input, once it happened. Races are bad like that) And if $r got to you properly, you don't need to do anything special too (IOW: API may as well assume it is coming from the current thread). Therefore, I think synchronize() method there is superfluous. In fact, assuming that a synchronized method has any *detached* memory semantics is wrong too -- compilers are known to elide associated fences. E.g. if ExecutorWrapper is known to never escape a thread, or a single thread locks on it, and biases a lock towards itself. Thanks, -Aleksey [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/e0da6c2a5c32/src/java.httpcli… [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/e0da6c2a5c32/src/java.httpcli…

3 3

CollectionAndMapModifyStreamTest: minor copy-paste error
by Stefan Zobel 09 Mar '16

09 Mar '16

Hi all, just noticed that org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest has a small copy & paste error in line 116: 115: maps.put(HashMap.class.getName(), () -> new HashMap<>(content)); 116: maps.put(HashMap.class.getName(), () -> new LinkedHashMap<>(content)); The same key is used for HashMap and LinkedHashMap, so the tests for HashMap never get executed. Btw, the "ThowableHelper" from /bootlib/java.base/java/util/stream should be renamed to the correct "ThRowableHelper" someday ;-) Regards, Stefan

2 1

[9] RFR: 8150702: change in javadoc for parseObject for MessageFormat - JDK-8073211
by vaibhav x.choudhary 09 Mar '16

09 Mar '16

Hello, Please review this small fix for jdk9/dev repo :- Bug: https://bugs.openjdk.java.net/browse/JDK-8150702 Webrev: http://cr.openjdk.java.net/~ntv/vaibhav/8150702/webrev.00/ Reason :- MessageFormat don't throw NullPointer exception if source is null. This condition is explicitly handled in the code by :- if (source == null) { Object[] empty = {}; return empty; } -- Thank You, Vaibhav Choudhary http://blogs.oracle.com/vaibhav

2 1

Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)
by Uwe Schindler 08 Mar '16

08 Mar '16

Hi OpenJDK Core Developers, you may know the Apache Lucene team is testing early access releases of Java 9. We reported many bugs already, but most of them only applied to Hotspot and Lucene itsself. But this problem since build 108 is now really severe, because it breaks the build system already! To allow further testing of Open Source Projects, I'd suggest to revert the Multi-Release-JAR runtime support patch and provide a new preview build ASAP, because we found out after a night of debugging a build system from which we don't know all internals what is causing the problems and there is no workaround. I am very sorry that I have to say this, but it unfortunately build 108 breaks *ALL* versions of Apache Ant, the grandfather of all Java build systems :-) I know also OpenJDK is using it, too! So with Multi-Release JAR file patch applied (see http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c) any Ant-based build - including the JDK build itsself - would no longer bootstrap. It is impossible to also build Gradle projects, because Gradle uses Ant internally for many tasks). Maven projects may be affected, too. Now you might have the question: What happened? We tried to build Lucene on our Jenkins server, but the build itsself failed with a stupid error message: BUILD FAILED /home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:21: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:56: not doesn't support the nested "matches" element. The first idea was: Ah, there were changes in XML parsing (JDK-8149915). So we debugged the build. But it was quite clear that XML parsing was not the issue. It got quite clear when we enabled "-debug" on the build. What happened was that Ant was not loading its internal conditions/tasks/type definitions anymore, so the build system does not know almost any type anymore. The debug log showed that Ant was no longer able to load the resource "/org/apache/tools/ant/antlib.xml" from its own JAR file anymore. Instead it printed some strange debugging output (which looked totally broken). I spend the whole night digging through their code and found the issue: The commit of Multi-Release-Jar files (see http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c) broke resource handling in Apache Ant. In short: If you call ClassLoader.getResources() / or getResource() you get back an URL from where you can load the Resource - this is all fine and still works. But, with the Multi-Release JAR files patch this now has an URL fragment appended to the URL: '#release' (see http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f9913ea0f95c) this also applies to non-multi-release JAR files like Apache Ant's "ant.jar". In Java 7, Java 8,... and Java 9pre-b108, ClassLoader.getResource()/getResources() returned stuff like: "jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml" Now in Java 9b108 the following is returned: "jar:file:/C:/Program%20Files/Java/apache-ant-1.9.6/lib/ant.jar!/org/apache/tools/ant/antlib.xml#release" And here Ant breaks (and I assume many other projects like Maven, too). Ant checks for the file extension of the string (because it may load definitions from both XML and properties files). So it does endsWith(".xml") and of course this now returns false. The effect is that Ant tries to load its own task definitions as a java properties file instead of XML. Of course this fails, because the data behind this URL is XML. The effect is that Ant cannot bootstrap as everything to build is missing. One might say: Ant's code is broken (I agree, it is not nice because it relies on the string representation of the resource URL - which is a no-go anyways), but it is impossible to fix, because Ant is bundled on most developer computers and those will suddenly break with Java 9! There is also no version out there that works around this, so we cannot test anything anymore! The problematic line in Ant's code is here: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.ant/ant/1.9.6/or… I'd suggest to please ASAP revert the Multi-Release JAR file patch and provide a new preview build as soon as possible. I think there is more work needed to fix this. If this does not revert to the original state, it will be impossible to build and test Lucene, Elasticsearch,.... (and almost every Java project out there!). So short: We cannot test anymore and it is likely that we cannot support Java 9 anymore because the build system used by most Java projects behind the scenes does not bootstrap itself anymore. My suggestion would be to investigate other versions for this patch that does *not* modify the resource URLs by appending a fragment to them (at least not for the "standard" case without an actual Multi-Release Jar). For new multi-release JAR files I am fine with appending fragments, but please not for default ones. Maybe change code to handle the URLs from the non-versioned part differently (without fragment). Leaving the fragment inide may break many othe rprojects, because many programmers are very sloppy with handling URLs (well-known issue is calling URL#getFile() of a file:-URL that breaks on Windows systems and spaces in path name). Many people just call toString() on URL and do some test on it (startsWith, endsWith). So appending fragments is a no-go for backwards compatibility with JAR resources! I posted this to the mailing list and did not open a bug report on http://bugs.java.com/, because this is a more general issue - feel free to open bug reports around this!!! I would be very happy if we could find a quick solution for this problem. Until there is a solution we have to stop testing Java 9 with Apache Lucene/Solr/..., and this is not a good sign, especially as Jigsaw will be merged soon. Thanks for listening, Uwe P.S.: I also CCed the Apache Ant team. They should fix the broken code anyways, but this won't help for many projects already out there (e.g. Apache Lucene still has a minimum requirement of Ant 1.8.2 because MacOSX computers ship with that version since years). ----- Uwe Schindler uschindler(a)apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/

8 13

RFR: 8151339 Adding fragment to JAR URLs breaks ant
by Steve Drach 08 Mar '16

08 Mar '16

Hi, Please review the following changeset. We’d like to get this into build 109, which means by noon today. This is essentially a temporary fix, but it’s been tested and Lucene has been built against it. We will follow up with a more comprehensive fix by build 110. webrev: http://cr.openjdk.java.net/~sdrach/8151339/webrev/ <http://cr.openjdk.java.net/~sdrach/8151339/webrev/> issue: https://bugs.openjdk.java.net/browse/JDK-8151339 <https://bugs.openjdk.java.net/browse/JDK-8151339> Thanks Steve

5 5

JDK 9 RFR of JDK-8151393: Revert changes for JDK-8087104
by joe darcy 07 Mar '16

07 Mar '16

Hello, The changes for JDK-8087104 introduced some test failures which have not yet been addressed (JDK-8151310). In order to get a clean snapshot for the next integration, if the fix for JDK-8151310 doesn't arrive in time, the changes for JDK-8087104 should be reverted until they can be otherwise corrected. In case the fix doesn't arrive, I patch -R'ed the changset for JDK-8087104. The (anti)diff to DateFormatSymbols.java is below; the newly-introduced failing test file from the previous changeset test/java/text/Format/DateFormat/DFSConstructorCloneTest.java is deleted. Thanks, -Joe --- a/src/java.base/share/classes/java/text/DateFormatSymbols.java Fri Mar 04 10:09:54 2016 -0800 +++ b/src/java.base/share/classes/java/text/DateFormatSymbols.java Mon Mar 07 11:20:50 2016 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2013, 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 @@ -606,7 +606,7 @@ try { DateFormatSymbols other = (DateFormatSymbols)super.clone(); - copyMembers(new SymbolsCacheEntry(locale), other); + copyMembers(this, other); return other; } catch (CloneNotSupportedException e) { throw new InternalError(e); @@ -669,7 +669,7 @@ /** * Cache to hold DateFormatSymbols instances per Locale. */ - private static final ConcurrentMap<Locale, SoftReference<SymbolsCacheEntry>> cachedInstances + private static final ConcurrentMap<Locale, SoftReference<DateFormatSymbols>> cachedInstances = new ConcurrentHashMap<>(3); private transient int lastZoneIndex; @@ -683,10 +683,10 @@ locale = desiredLocale; // Copy values of a cached instance if any. - SoftReference<SymbolsCacheEntry> ref = cachedInstances.get(locale); - SymbolsCacheEntry sce; - if (ref != null && (sce = ref.get()) != null) { - copyMembers(sce, this); + SoftReference<DateFormatSymbols> ref = cachedInstances.get(locale); + DateFormatSymbols dfs; + if (ref != null && (dfs = ref.get()) != null) { + copyMembers(dfs, this); return; } @@ -717,11 +717,11 @@ weekdays = toOneBasedArray(resource.getStringArray("DayNames")); shortWeekdays = toOneBasedArray(resource.getStringArray("DayAbbreviations")); - sce = new SymbolsCacheEntry(locale); - ref = new SoftReference<>(sce); - SoftReference<SymbolsCacheEntry> x = cachedInstances.putIfAbsent(locale, ref); + // Put a clone in the cache + ref = new SoftReference<>((DateFormatSymbols)this.clone()); + SoftReference<DateFormatSymbols> x = cachedInstances.putIfAbsent(locale, ref); if (x != null) { - SymbolsCacheEntry y = x.get(); + DateFormatSymbols y = x.get(); if (y == null) { // Replace the empty SoftReference with ref. cachedInstances.put(locale, ref); @@ -812,7 +812,7 @@ * @param src the source DateFormatSymbols. * @param dst the target DateFormatSymbols. */ - private void copyMembers(SymbolsCacheEntry src, DateFormatSymbols dst) + private void copyMembers(DateFormatSymbols src, DateFormatSymbols dst) { dst.eras = Arrays.copyOf(src.eras, src.eras.length); dst.months = Arrays.copyOf(src.months, src.months.length); @@ -821,7 +821,7 @@ dst.shortWeekdays = Arrays.copyOf(src.shortWeekdays, src.shortWeekdays.length); dst.ampms = Arrays.copyOf(src.ampms, src.ampms.length); if (src.zoneStrings != null) { - dst.zoneStrings = getZoneStringsImpl(true); + dst.zoneStrings = src.getZoneStringsImpl(true); } else { dst.zoneStrings = null; } @@ -842,43 +842,4 @@ } stream.defaultWriteObject(); } - - private static class SymbolsCacheEntry { - - final String eras[]; - final String months[]; - final String shortMonths[]; - final String weekdays[]; - final String shortWeekdays[]; - final String ampms[]; - final String zoneStrings[][]; - final String localPatternChars; - - SymbolsCacheEntry(Locale locale) { - // Initialize the fields from the ResourceBundle for locale. - LocaleProviderAdapter adapter = LocaleProviderAdapter.getAdapter(DateFormatSymbolsProvider.class, locale); - // Avoid any potential recursions - if (!(adapter instanceof ResourceBundleBasedAdapter)) { - adapter = LocaleProviderAdapter.getResourceBundleBased(); - } - ResourceBundle resource = ((ResourceBundleBasedAdapter) adapter).getLocaleData().getDateFormatData(locale); - if (resource.containsKey("Eras")) { - this.eras = resource.getStringArray("Eras"); - } else if (resource.containsKey("long.Eras")) { - this.eras = resource.getStringArray("long.Eras"); - } else if (resource.containsKey("short.Eras")) { - this.eras = resource.getStringArray("short.Eras"); - } else { - this.eras = null; - } - this.months = resource.getStringArray("MonthNames"); - this.shortMonths = resource.getStringArray("MonthAbbreviations"); - this.weekdays = toOneBasedArray(resource.getStringArray("DayNames")); - this.shortWeekdays = toOneBasedArray(resource.getStringArray("DayAbbreviations")); - this.ampms = resource.getStringArray("AmPmMarkers"); - this.zoneStrings = TimeZoneNameUtility.getZoneStrings(locale); - this.localPatternChars = resource.getString("DateTimePatternChars"); - - } - } }

2 1

Stream API: Fuse sorted().limit(n) into single operation
by Tagir F. Valeev 07 Mar '16

07 Mar '16

Hello! One of the popular bulk data operation is to find given number of least or greatest elements. Currently Stream API provides no dedicated operation to do this. Of course, it could be implemented by custom collector and some third-party libraries already provide it. However it would be quite natural to use existing API: stream.sorted().limit(k) - k least elements stream.sorted(Comparator.reverseOrder()).limit(k) - k greatest elements. In fact people already doing this. Some samples could be found on GitHub: https://github.com/search?l=java&q=%22sorted%28%29.limit%28%22&type=Code&ut… Unfortunately current implementation of such sequence of operations is suboptimal: first the whole stream content is dumped into intermediate array, then sorted fully and after that k least elements is selected. On the other hand it's possible to provide a special implementation for this particular case which takes O(k) additional memory and in many cases works significantly faster. I wrote proof-of-concept implementation, which could be found here: http://cr.openjdk.java.net/~tvaleev/patches/sortedLimit/webrev/ The implementation switches to new algorithm if limit is less than 1000 which is quite common for such scenario (supporting bigger values is also possible, but would require more testing). New algorithm allocates an array of 2*limit elements. When its size is reached, it sorts the array (using Arrays.sort) and discards the second half. After that only those elements are accumulated which are less than the worst element found so far. When array is filled again, the second half is sorted and merged with the first half. Here's JMH test with results which covers several input patterns: http://cr.openjdk.java.net/~tvaleev/patches/sortedLimit/jmh/ You may check summary first: http://cr.openjdk.java.net/~tvaleev/patches/sortedLimit/jmh/summary.txt Speedup values bigger than 1 are good. The most significant regression in the sequential mode of the new implementation is the ever decreasing input (especially with the low limit value). Still, it's not that bad (given the fact that old implementation processes such input very fast). On the other hand, for random input new implementation could be in order of magnitude faster. Even for ever ascending input noteable speedup (like 40%) could be achieved. For parallel stream the new implementation is almost always faster, especially if you ignore the cases when parallel stream is unprofitable. What do you think about this improvement? Could it be included into JDK-9? Are there any issues I'm unaware of? I would be really happy to complete this work if this is supported by JDK team. Current implementation has no primitive specialization and does not optimize the sorting out if the input is known to be sorted, but it's not very hard to add these features as well if you find my idea useful. With best regards, Tagir Valeev.

3 5

default random access list spliterator
by Michael Hixson 07 Mar '16

07 Mar '16

The default List.spliterator() is iterator-based. Could this be improved for random access lists, using List.get(int) to fetch elements instead of List.iterator()? I think it could improve most on Spliterator.trySplit(). The current implementation allocates a new array for split-off elements. I see almost twice the throughput from list.parallelStream().forEach(...) with a custom get(int)-based implementation over the default one. For example, instead of this: default Spliterator<E> spliterator() { return Spliterators.spliterator(this, Spliterator.ORDERED); } I'm suggesting something like this: default Spliterator<E> spliterator() { return (this instanceof RandomAccess) ? Spliterators.randomAccessListSpliterator(this) : Spliterators.spliterator(this, Spliterator.ORDERED); } where randomAccessListSpliterator is new code that looks a lot like Spliterators.ArraySpliterator. -Michael

4 9