Re: JDK 9 RFR of JDK-8165818: Remove tools/pack200/Pack200Props.java from ProblemList

On 9/12/16 11:38 AM, Amy Lu wrote: tools/pack200/Pack200Props.java This test was put into ProblemList.txt in 9/117 due to test timed out issue: JDK-8155857. Test failure (timed out) is reproducible with 9/117 and 9/118, but issue gone in 9/119 and *not* reproducible anymore since 9/119.

JDK 9 RFR of JDK-8165818: Remove tools/pack200/Pack200Props.java from ProblemList

tools/pack200/Pack200Props.java This test was put into ProblemList.txt in 9/117 due to test timed out issue: JDK-8155857. Test failure (timed out) is reproducible with 9/117 and 9/118, but issue gone in 9/119 and *not* reproducible anymore since 9/119. Issue must has been resolved with

Re: Make iterators cloneable?

Actually given the fact that we're iterating the Set (so the elements are unique) and using the assumption that iteration of the same set is stable, you can avoid numbering like this: for(String e1 : set) { for(String e2 : set) { if(e1 == e2) break; System.out.println(e1+" <-> "+e2);

Re: Make iterators cloneable?

Hello, Peter! I thought about numbering, but original Dave's code involved concurrent set, so I presume that it's expected to be modified from other threads. In this case my algorithm would output some legal pairs (probably reflecting changes or not or reflecting only partially) while your

Re: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Jonathon, Attachments get stripped from most of the mailing lists so you will need to find someone to host these for you on cr.openjdk.java.net. That aside you may be hard pressed to find anyone who can look at this future work now, given where things are with the JDK 9 release schedule.

Re: Make iterators cloneable?

I would say the algorithm is O(n), when you take n to be the number of emitted pairs, wouldn't you ;-) You wanted an algorithm that emits n*(n-1) / 2 distinct pairs of elements from a set of n elements, didn't you? Regards, Peter On 09/11/2016 06:55 PM, Dave Brosius wrote: Sure, but both

Re: RFR: 8163798: Create a JarFile versionedStream method

Hi, jdk/internal/util/jar/VersionedStream.java: - use Integer.parseInt(name, vptr, ptr, 10) to avoid creating vstr on every entry - folding allowedVersions into getBaseSuffix seems easier than to keep global state (sptr) and splitting the logic over a filter and a map operation -

Re: JDK 9 RFR of JDK-8165810: Problem list VersionCheck.java until JDK-8165772 is fixed

+1 Best Lance > On Sep 11, 2016, at 4:12 PM, joe darcy wrote: > > Hello, > > Until the issues discussed in JDK-8165772 are fixed, the test > >tools/launcher/VersionCheck.java > > should added to the problem listed so clean test runs are possible. > > Please review

Re: JDK 9 RFR of JDK-8165810: Problem list VersionCheck.java until JDK-8165772 is fixed

Looks OK to me /Claes On 2016-09-11 22:12, joe darcy wrote: Hello, Until the issues discussed in JDK-8165772 are fixed, the test tools/launcher/VersionCheck.java should added to the problem listed so clean test runs are possible. Please review the patch below to accomplish this.

JDK 9 RFR of JDK-8165810: Problem list VersionCheck.java until JDK-8165772 is fixed

Hello, Until the issues discussed in JDK-8165772 are fixed, the test tools/launcher/VersionCheck.java should added to the problem listed so clean test runs are possible. Please review the patch below to accomplish this. Thanks, Joe diff -r f2e94fd11c41 test/ProblemList.txt ---

Re: RFR: 8163798: Create a JarFile versionedStream method

I made a simple change, the new webrev is http://cr.openjdk.java.net/~sdrach/8163798/webrev.02/ > On Sep 9, 2016, at 4:02 PM, Steve Drach wrote: > > Hi, > > Please review this changeset that adds a

Fwd: Make iterators cloneable?

I think O(N^2)-like performance is unavoidable here Dave. However, although Peter's algorithm is indeed O(N^2), it should be faster than Tagir's and reasonable(-ish) in practice. This is because the inner loop starts off not executing at all in the outer loop's first iteration; and each time the

Re: Make iterators cloneable?

Sure, but both of those algorithms are n^2, which is a bit painful, especially given all the pointer chasing that occurs with iterators. On 09/11/2016 08:20 AM, Peter Levart wrote: Hi, Even if the elements are not comparable, you could rely on the fact that Collection(s) usually create

Re: Make iterators cloneable?

Hi, Even if the elements are not comparable, you could rely on the fact that Collection(s) usually create iterators with stable iteration order, so you could do the following: Set set = Set.of(1, 2, 3, 4); Iterator it1 = set.iterator(); for (int n1 = 0;

Re: Make iterators cloneable?

Hello! As your keys are comparable, you can create normal iterators and filter the results like this: for(String v1 : s) { for(String v2 : s) { if(v1.compareTo(v2) < 0) { System.out.println(v1 + " <-->" + v2); } } } Or using Stream API: s.stream().flatMap(v1 -> s.stream()

Re: Make iterators cloneable?

Hi, The failfast argument is is irrelevant. It only matters if you use it.remove() which is no different than any other failfast situation. Obviously the 3rd argument is bogus too, as you say. The second argument, ok, is not arguable, as it's just a persons opinion. The bug report is in

Re: Make iterators cloneable?

Hi, digging a little bit in the bug database, there is a bug from 1999 https://bugs.openjdk.java.net/browse/JDK-4244952 answers seems to be - having different iterators on the same collection is error prone because iterators are failfast, the proposed workaround to use an array or a List