Could we update the Iterator, so it supports manipulation on the Collection
itself, and not throw UnsupportedOperationException during the time of
iteration?
On Sep 12, 2016 9:29 AM, <core-libs-dev-requ...@openjdk.java.net> wrote:
Send core-libs-dev mailing list submissions to
core-libs-dev@openjdk.java.net
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
or, via email, send a message with subject or body 'help' to
core-libs-dev-requ...@openjdk.java.net
You can reach the person managing the list at
core-libs-dev-ow...@openjdk.java.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of core-libs-dev digest..."
Today's Topics:
1. Re: Make iterators cloneable? (Peter Levart)
2. Re: [PATCH] JDK-8134373: explore potential uses of
convenience factories within the JDK (David Holmes)
3. Re: Make iterators cloneable? (Tagir Valeev)
4. Re: Make iterators cloneable? (Tagir Valeev)
5. JDK 9 RFR of JDK-8165818: Remove
tools/pack200/Pack200Props.java from ProblemList (Amy Lu)
6. Re: JDK 9 RFR of JDK-8165818: Remove
tools/pack200/Pack200Props.java from ProblemList (Amy Lu)
----------------------------------------------------------------------
Message: 1
Date: Sun, 11 Sep 2016 23:42:29 +0200
From: Peter Levart <peter.lev...@gmail.com>
To: Dave Brosius <dbros...@mebigfatguy.com>, "Tagir F. Valeev"
<amae...@gmail.com>, core-libs-dev@openjdk.java.net
Subject: Re: Make iterators cloneable?
Message-ID: <06efbb04-e97b-18b7-a1fe-5fa010811...@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
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 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 iterators with stable iteration
>> order, so you could do the following:
>>
>>
>> Set<Integer> set = Set.of(1, 2, 3, 4);
>>
>> Iterator<Integer> it1 = set.iterator();
>> for (int n1 = 0; it1.hasNext(); n1++) {
>> Integer e1 = it1.next();
>> Iterator<Integer> it2 = set.iterator();
>> for (int n2 = 0; n2 < n1; n2++) {
>> Integer e2 = it2.next();
>> System.out.println(e1 + " <-> " + e2);
>> }
>> }
>>
>>
>> Regards, Peter
>>
>> On 09/11/2016 02:02 PM, Tagir F. Valeev wrote:
>>> 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()
>>> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2))
>>> .forEach(System.out::println);
>>>
>>> With best regards,
>>> Tagir Valeev.
>>>
>>>
>>> DB> It would be nice to be able to associate each element in a
>>> collection
>>> DB> with another element in the collection, which is something very
>>> easily
>>> DB> done with index based collections, but with sets, etc this isn't so
>>> DB> easy... unless i'm having a brainfart.
>>>
>>> DB> So i'd like to do this, but Iterator doesn't implement
>>> Cloneable... Any
>>> DB> reason not to? or is there another way that's missing me?
>>>
>>> DB> public class ItClone {
>>>
>>> DB> public static void main(String[] args) {
>>> DB> Set<String> s = Collections.newSetFromMap(new
>>> DB> ConcurrentHashMap<String, Boolean>());
>>>
>>> DB> s.add("Fee");
>>> DB> s.add("Fi");
>>> DB> s.add("Fo");
>>> DB> s.add("Fum");
>>>
>>> DB> Iterator<String> it1 = s.iterator();
>>> DB> while (it1.hasNext()) {
>>> DB> String v1 = it1.next();
>>>
>>> DB> Iterator<String> it2 = (Iterator<String>)
>>> it1.*clone*();
>>> DB> while (it2.hasNext()) {
>>> DB> String v2 = it2.next();
>>>
>>> DB> System.out.println(v1 + " <-->" + v2);
>>> DB> }
>>> DB> }
>>> DB> }
>>> DB> }
>>>
>>
>
------------------------------
Message: 2
Date: Mon, 12 Sep 2016 10:50:49 +1000
From: David Holmes <david.hol...@oracle.com>
To: Jonathan Bluett-Duncan <jbluettdun...@gmail.com>,
core-libs-dev@openjdk.java.net
Subject: Re: [PATCH] JDK-8134373: explore potential uses of
convenience factories within the JDK
Message-ID: <100bf463-ca7d-f0fd-dc6e-4433b5e48...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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.
Cheers,
David
On 11/09/2016 9:42 AM, Jonathan Bluett-Duncan wrote:
> Hi all,
>
> Would you kindly review this patch to replace existing uses of
> Collections.unmodifiable*(*Arrays.asList(*)) and plain Arrays.asList(*)
> with (List|Set|Map).of(*). You may find the patch files in the
attachments.
>
> My rationale for replacing uses of Collections.unmodifiable*... with
> (List|Set|Map).of is to make use of the memory savings allowed by the
newer
> APIs.
>
> The general rationale for replacing the Arrays.asList calls I've touched
is
> to again make use of memory savings, but this may be naive or misguided
> reasoning on my part, as Arrays.asList may or may not be more
> memory-efficient than List.of. However, where I've replaced Arrays.asList
> for List.of in FileTreeIterator, my reasoning for doing so instead was to
> help prevent TOCTOU attacks, but again this may be misguided on my part.
>
> It doesn't seem practical to me to include new unit tests, as these are
> mainly performance improvements, but if it's believed that new unit tests
> are needed, then I'd be happy to go back and try to include some.
>
> Kind regards,
> Jonathan
>
------------------------------
Message: 3
Date: Mon, 12 Sep 2016 07:51:59 +0700
From: Tagir Valeev <amae...@gmail.com>
To: Peter Levart <peter.lev...@gmail.com>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>
Subject: Re: Make iterators cloneable?
Message-ID:
<cae+3fjzzqie5xo_a342ndevsirdraknm06rgyvhjrxx0pay...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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 algorithm can
output garbage (pair with equal e1, e2 or two pairs like e1 <-> e2, e2 <->
e1 or can even die with NoSuchElementException). Not sure what is better in
author's case.
Tagir.
On Sun, Sep 11, 2016 at 7:20 PM, Peter Levart <peter.lev...@gmail.com>
wrote:
> 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<Integer> set = Set.of(1, 2, 3, 4);
>
> Iterator<Integer> it1 = set.iterator();
> for (int n1 = 0; it1.hasNext(); n1++) {
> Integer e1 = it1.next();
> Iterator<Integer> it2 = set.iterator();
> for (int n2 = 0; n2 < n1; n2++) {
> Integer e2 = it2.next();
> System.out.println(e1 + " <-> " + e2);
> }
> }
>
>
> Regards, Peter
>
>
> On 09/11/2016 02:02 PM, Tagir F. Valeev wrote:
>
> 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()
> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2))
> .forEach(System.out::println);
>
> With best regards,
> Tagir Valeev.
>
>
> DB> It would be nice to be able to associate each element in a collection
> DB> with another element in the collection, which is something very easily
> DB> done with index based collections, but with sets, etc this isn't so
> DB> easy... unless i'm having a brainfart.
>
> DB> So i'd like to do this, but Iterator doesn't implement Cloneable...
Any
> DB> reason not to? or is there another way that's missing me?
>
> DB> public class ItClone {
>
> DB> public static void main(String[] args) {
> DB> Set<String> s = Collections.newSetFromMap(new
> DB> ConcurrentHashMap<String, Boolean>());
>
> DB> s.add("Fee");
> DB> s.add("Fi");
> DB> s.add("Fo");
> DB> s.add("Fum");
>
> DB> Iterator<String> it1 = s.iterator();
> DB> while (it1.hasNext()) {
> DB> String v1 = it1.next();
>
> DB> Iterator<String> it2 = (Iterator<String>) it1.*clone*();
> DB> while (it2.hasNext()) {
> DB> String v2 = it2.next();
>
> DB> System.out.println(v1 + " <-->" + v2);
> DB> }
> DB> }
> DB> }
> DB> }
>
>
>
>
------------------------------
Message: 4
Date: Mon, 12 Sep 2016 07:58:27 +0700
From: Tagir Valeev <amae...@gmail.com>
To: Peter Levart <peter.lev...@gmail.com>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>
Subject: Re: Make iterators cloneable?
Message-ID:
<CAE+3fjazR0=Wtwgj98nnTGaq03S+8pPF=psoc3qu7metdfr...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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);
}
}
Again, such algorithm is fragile to concurrent changes.
With best regards,
Tagir Valeev.
On Mon, Sep 12, 2016 at 7:51 AM, Tagir Valeev <amae...@gmail.com> wrote:
> 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 algorithm can
> output garbage (pair with equal e1, e2 or two pairs like e1 <-> e2, e2 <->
> e1 or can even die with NoSuchElementException). Not sure what is better
in
> author's case.
>
> Tagir.
>
> On Sun, Sep 11, 2016 at 7:20 PM, Peter Levart <peter.lev...@gmail.com>
> wrote:
>
>> 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<Integer> set = Set.of(1, 2, 3, 4);
>>
>> Iterator<Integer> it1 = set.iterator();
>> for (int n1 = 0; it1.hasNext(); n1++) {
>> Integer e1 = it1.next();
>> Iterator<Integer> it2 = set.iterator();
>> for (int n2 = 0; n2 < n1; n2++) {
>> Integer e2 = it2.next();
>> System.out.println(e1 + " <-> " + e2);
>> }
>> }
>>
>>
>> Regards, Peter
>>
>>
>> On 09/11/2016 02:02 PM, Tagir F. Valeev wrote:
>>
>> 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()
>> .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2))
>> .forEach(System.out::println);
>>
>> With best regards,
>> Tagir Valeev.
>>
>>
>> DB> It would be nice to be able to associate each element in a collection
>> DB> with another element in the collection, which is something very
easily
>> DB> done with index based collections, but with sets, etc this isn't so
>> DB> easy... unless i'm having a brainfart.
>>
>> DB> So i'd like to do this, but Iterator doesn't implement Cloneable...
Any
>> DB> reason not to? or is there another way that's missing me?
>>
>> DB> public class ItClone {
>>
>> DB> public static void main(String[] args) {
>> DB> Set<String> s = Collections.newSetFromMap(new
>> DB> ConcurrentHashMap<String, Boolean>());
>>
>> DB> s.add("Fee");
>> DB> s.add("Fi");
>> DB> s.add("Fo");
>> DB> s.add("Fum");
>>
>> DB> Iterator<String> it1 = s.iterator();
>> DB> while (it1.hasNext()) {
>> DB> String v1 = it1.next();
>>
>> DB> Iterator<String> it2 = (Iterator<String>) it1.*clone*();
>> DB> while (it2.hasNext()) {
>> DB> String v2 = it2.next();
>>
>> DB> System.out.println(v1 + " <-->" + v2);
>> DB> }
>> DB> }
>> DB> }
>> DB> }
>>
>>
>>
>>
>
------------------------------
Message: 5
Date: Mon, 12 Sep 2016 11:38:32 +0800
From: Amy Lu <amy...@oracle.com>
To: Core-Libs-Dev <core-libs-dev@openjdk.java.net>, Kumar Srinivasan
<kumar.x.sriniva...@oracle.com>
Subject: JDK 9 RFR of JDK-8165818: Remove
tools/pack200/Pack200Props.java from ProblemList
Message-ID: <7498b951-367f-29e6-319f-f91ab2c23...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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 other fixes.
Tested with the very latest build on all platforms, test pass.
Standalone run test in loop for 500 times, test all pass.
As issue does not exist anymore, test could be removed from ProblemList.txt
bug: https://bugs.openjdk.java.net/browse/JDK-8165818
Thanks,
Amy
--- old/test/ProblemList.txt 2016-09-12 11:28:05.000000000 +0800
+++ new/test/ProblemList.txt 2016-09-12 11:28:05.000000000 +0800
@@ -1,4 +1,4 @@
-###########################################################################
+e##########################################################################
#
# Copyright (c) 2009, 2016, Oracle and/or its affiliates. All rights
reserved.
# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
@@ -312,8 +312,6 @@
tools/launcher/FXLauncherTest.java 8068049
linux-all,macosx-all
-tools/pack200/Pack200Props.java 8155857
generic-all
-
tools/launcher/VersionCheck.java 8165772
generic-all
############################################################
################
------------------------------
Message: 6
Date: Mon, 12 Sep 2016 11:58:33 +0800
From: Amy Lu <amy...@oracle.com>
To: Core-Libs-Dev <core-libs-dev@openjdk.java.net>, Kumar Srinivasan
<kumar.x.sriniva...@oracle.com>
Subject: Re: JDK 9 RFR of JDK-8165818: Remove
tools/pack200/Pack200Props.java from ProblemList
Message-ID: <bc42fde1-24d6-7758-014e-1dbb7ab04...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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. Issue
> must has been resolved with other fixes.
>
> Tested with the very latest build on all platforms, test pass.
> Standalone run test in loop for 500 times, test all pass.
>
> As issue does not exist anymore, test could be removed from
> ProblemList.txt
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8165818
>
> Thanks,
> Amy
>
Sorry, the patch: http://cr.openjdk.java.net/~amlu/8165818/webrev.00/
--- old/test/ProblemList.txt 2016-09-12 11:55:51.000000000 +0800
+++ new/test/ProblemList.txt 2016-09-12 11:55:51.000000000 +0800
@@ -312,8 +312,6 @@
tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all
-tools/pack200/Pack200Props.java 8155857 generic-all
-
tools/launcher/VersionCheck.java 8165772 generic-all
############################################################
################
End of core-libs-dev Digest, Vol 113, Issue 35
**********************************************
