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

[Amy Lu]

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.txt2016-09-12 11:55:51.0 +0800
+++ new/test/ProblemList.txt2016-09-12 11:55:51.0 +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

 

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

[Amy Lu]

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.txt2016-09-12 11:28:05.0 +0800
+++ new/test/ProblemList.txt2016-09-12 11:28:05.0 +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.java8165772 
generic-all
 
 

Re: Make iterators cloneable?

[Tagir Valeev]

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  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 
> 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 set = Set.of(1, 2, 3, 4);
>>
>> Iterator it1 = set.iterator();
>> for (int n1 = 0; it1.hasNext(); n1++) {
>> Integer e1 = it1.next();
>> Iterator 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 s = Collections.newSetFromMap(new
>> DB> ConcurrentHashMap());
>>
>> DB>  s.add("Fee");
>> DB>  s.add("Fi");
>> DB>  s.add("Fo");
>> DB>  s.add("Fum");
>>
>> DB>  Iterator it1 = s.iterator();
>> DB>  while (it1.hasNext()) {
>> DB>  String v1 = it1.next();
>>
>> DB>  Iterator it2 = (Iterator) it1.*clone*();
>> DB>  while (it2.hasNext()) {
>> DB>  String v2 = it2.next();
>>
>> DB>  System.out.println(v1 + " <-->" + v2);
>> DB>  }
>> DB>  }
>> DB>  }
>> DB> }
>>
>>
>>
>>
>

Re: Make iterators cloneable?

[Tagir Valeev]

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 
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 set = Set.of(1, 2, 3, 4);
>
> Iterator it1 = set.iterator();
> for (int n1 = 0; it1.hasNext(); n1++) {
> Integer e1 = it1.next();
> Iterator 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 s = Collections.newSetFromMap(new
> DB> ConcurrentHashMap());
>
> DB>  s.add("Fee");
> DB>  s.add("Fi");
> DB>  s.add("Fo");
> DB>  s.add("Fum");
>
> DB>  Iterator it1 = s.iterator();
> DB>  while (it1.hasNext()) {
> DB>  String v1 = it1.next();
>
> DB>  Iterator it2 = (Iterator) it1.*clone*();
> DB>  while (it2.hasNext()) {
> DB>  String v2 = it2.next();
>
> DB>  System.out.println(v1 + " <-->" + v2);
> DB>  }
> DB>  }
> DB>  }
> DB> }
>
>
>
>

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

[David Holmes]

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

Re: Make iterators cloneable?

[Peter Levart]

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 set = Set.of(1, 2, 3, 4);

Iterator it1 = set.iterator();
for (int n1 = 0; it1.hasNext(); n1++) {
Integer e1 = it1.next();
Iterator 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 s = Collections.newSetFromMap(new
DB> ConcurrentHashMap());

DB>  s.add("Fee");
DB>  s.add("Fi");
DB>  s.add("Fo");
DB>  s.add("Fum");

DB>  Iterator it1 = s.iterator();
DB>  while (it1.hasNext()) {
DB>  String v1 = it1.next();

DB>  Iterator it2 = (Iterator) 
it1.*clone*();

DB>  while (it2.hasNext()) {
DB>  String v2 = it2.next();

DB>  System.out.println(v1 + " <-->" + v2);
DB>  }
DB>  }
DB>  }
DB> }

Re: RFR: 8163798: Create a JarFile versionedStream method

[Claes Redestad]

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

- distinct() could be used instead of explicitly collecting to a
  LinkedHashSet, but this does make me wonder if we could do even
  better by creating a map from base name to the appropriate versioned
  JarEntry and return a stream over that map to avoid looking things up
  via jf::getJarEntry. Could be quite a bit more efficient, and as we
  have to create a set or do distinct the overheads should be roughly
  the same either way

- declaring META_INF_VERSIONS_LEN seems like a premature optimization

- nit: static final is preferred over final static

- nit: rename *ptr to *Index

Test and JarFile changes seem fine to me.

Thanks!

/Claes

On 2016-09-11 22:12, Steve Drach wrote:

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 VersionedStream class to the 
jdk.internal.util.jar package.  Some may recall that I submitted a similar RFR 
a few weeks ago; this is a redesign from that one.  We decided not to make a 
public JarFile::versionedStream method at this time.  Once we get sufficient 
experience with this and find a few more use cases, we will revisit the idea of 
making this a public method in JarFile.

issue: https://bugs.openjdk.java.net/browse/JDK-8163798 

webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.01/index.html 


Thanks,
Steve

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

[Lance Andersen]

+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 the patch below to accomplish this.
> 
> Thanks,
> 
> Joe
> 
> diff -r f2e94fd11c41 test/ProblemList.txt
> --- a/test/ProblemList.txtSat Sep 10 06:46:45 2016 +0530
> +++ b/test/ProblemList.txtSun Sep 11 13:12:37 2016 -0700
> @@ -314,6 +314,8 @@
> 
> tools/pack200/Pack200Props.java 8155857 generic-all
> 
> +tools/launcher/VersionCheck.java 8165772 generic-all
> +
> 
> 
> # jdk_jdi
> 

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

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

[Claes Redestad]

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.

Thanks,

Joe

diff -r f2e94fd11c41 test/ProblemList.txt
--- a/test/ProblemList.txtSat Sep 10 06:46:45 2016 +0530
+++ b/test/ProblemList.txtSun Sep 11 13:12:37 2016 -0700
@@ -314,6 +314,8 @@

  tools/pack200/Pack200Props.java 8155857 generic-all

+tools/launcher/VersionCheck.java 8165772 generic-all
+
  

  # jdk_jdi

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

[joe darcy]

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
--- a/test/ProblemList.txtSat Sep 10 06:46:45 2016 +0530
+++ b/test/ProblemList.txtSun Sep 11 13:12:37 2016 -0700
@@ -314,6 +314,8 @@

 tools/pack200/Pack200Props.java 8155857 generic-all

+tools/launcher/VersionCheck.java 8165772 generic-all
+
 

 # jdk_jdi

Re: RFR: 8163798: Create a JarFile versionedStream method

[Steve Drach]

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 VersionedStream class to the 
> jdk.internal.util.jar package.  Some may recall that I submitted a similar 
> RFR a few weeks ago; this is a redesign from that one.  We decided not to 
> make a public JarFile::versionedStream method at this time.  Once we get 
> sufficient experience with this and find a few more use cases, we will 
> revisit the idea of making this a public method in JarFile.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8163798 
> 
> webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.01/index.html 
> 
> 
> Thanks,
> Steve

Fwd: Make iterators cloneable?

[Jonathan Bluett-Duncan]

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 outer loop iterates, the inner
loop's number of iterations increases by 1, eventually reaching N
iterations when the outer loop itself hits iteration N.

So although Peter's algorithm is O(N^2) in theory, in practice it shouldn't
or isn't as bad as most O(N^2) algos, since the number of steps it takes is
less than some ratio of N^2 for sufficiently large N.

On 11 September 2016 at 17:55, 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 set = Set.of(1, 2, 3, 4);
>>
>> Iterator it1 = set.iterator();
>> for (int n1 = 0; it1.hasNext(); n1++) {
>> Integer e1 = it1.next();
>> Iterator 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 s = Collections.newSetFromMap(new
>>> DB> ConcurrentHashMap());
>>>
>>> DB>  s.add("Fee");
>>> DB>  s.add("Fi");
>>> DB>  s.add("Fo");
>>> DB>  s.add("Fum");
>>>
>>> DB>  Iterator it1 = s.iterator();
>>> DB>  while (it1.hasNext()) {
>>> DB>  String v1 = it1.next();
>>>
>>> DB>  Iterator it2 = (Iterator) it1.*clone*();
>>> DB>  while (it2.hasNext()) {
>>> DB>  String v2 = it2.next();
>>>
>>> DB>  System.out.println(v1 + " <-->" + v2);
>>> DB>  }
>>> DB>  }
>>> DB>  }
>>> DB> }
>>>
>>>
>>
>

Re: Make iterators cloneable?

[Dave Brosius]

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 set = Set.of(1, 2, 3, 4);

Iterator it1 = set.iterator();
for (int n1 = 0; it1.hasNext(); n1++) {
Integer e1 = it1.next();
Iterator 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 s = Collections.newSetFromMap(new
DB> ConcurrentHashMap());

DB>  s.add("Fee");
DB>  s.add("Fi");
DB>  s.add("Fo");
DB>  s.add("Fum");

DB>  Iterator it1 = s.iterator();
DB>  while (it1.hasNext()) {
DB>  String v1 = it1.next();

DB>  Iterator it2 = (Iterator) it1.*clone*();
DB>  while (it2.hasNext()) {
DB>  String v2 = it2.next();

DB>  System.out.println(v1 + " <-->" + v2);
DB>  }
DB>  }
DB>  }
DB> }

Re: Make iterators cloneable?

[Peter Levart]

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; it1.hasNext(); n1++) {
Integer e1 = it1.next();
Iterator 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 s = Collections.newSetFromMap(new
DB> ConcurrentHashMap());

DB>  s.add("Fee");
DB>  s.add("Fi");
DB>  s.add("Fo");
DB>  s.add("Fum");

DB>  Iterator it1 = s.iterator();
DB>  while (it1.hasNext()) {
DB>  String v1 = it1.next();

DB>  Iterator it2 = (Iterator) it1.*clone*();
DB>  while (it2.hasNext()) {
DB>  String v2 = it2.next();

DB>  System.out.println(v1 + " <-->" + v2);
DB>  }
DB>  }
DB>  }
DB> }

Re: Make iterators cloneable?

[Tagir F. Valeev]

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 s = Collections.newSetFromMap(new 
DB> ConcurrentHashMap());

DB>  s.add("Fee");
DB>  s.add("Fi");
DB>  s.add("Fo");
DB>  s.add("Fum");

DB>  Iterator it1 = s.iterator();
DB>  while (it1.hasNext()) {
DB>  String v1 = it1.next();

DB>  Iterator it2 = (Iterator) it1.*clone*();
DB>  while (it2.hasNext()) {
DB>  String v2 = it2.next();

DB>  System.out.println(v1 + " <-->" + v2);
DB>  }
DB>  }
DB>  }
DB> }

Re: Make iterators cloneable?

[Dave Brosius]

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 the genre of subList implementation which 
is different than this use, but ok. The problem is that there are no 
reasonable concurrent indexable collections, and the thought of copying 
large collections into a List everytime you want to do this is crazy.



Unfortunately you can't even have one-off fixes for specific collections 
by having an iterator with a 'copy constructor' for instance, as in the 
case of collection iterators you _really_ have no business knowing what 
the real class is.



On 09/11/2016 05:40 AM, Remi Forax wrote:


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 with several indexes
- it's too C++ish, C++ defines clone and equals, Java tries to define a simpler 
iteration protocol
   (from now, given that this question is raised only once in a while, it's 
doesn't seem to be a bad idea)
- iterators are interfaces, so having several iterators means several virtual 
dispatch calls
   (this one is not true anymore because any JITs routinely devirtualize this 
kind of call).

cheers,
Rémi

- Mail original -

De: "Dave Brosius" 
À: "Louis Wasserman" , "Jonathan Bluett-Duncan" 

Cc: core-libs-dev@openjdk.java.net
Envoyé: Dimanche 11 Septembre 2016 02:23:41
Objet: Re: Make iterators cloneable?

Iterators reading from a BufferedReader

yes that's true. altho given the contract of Cloneable, adding the clone
method on Iterator would be safe, as it would only be available if the
real implementing class 'extends Cloneable'... it's actually kind of
funny that Object methods aren't available on interface references, anyway.


But i get the "age of Iterator" answer.. Shame there isn't an answer, tho.

thanks, dave

On 09/10/2016 07:44 PM, Louis Wasserman wrote:

Some iterators might be.  Many may not be. Certainly Iterator as an
interface has been out there for long enough there are Iterator
implementations out there that aren't cloneable -- say, Iterators
reading from a BufferedReader, where there really won't be any way to
do what you're hoping for; BufferedReaders certainly aren't cloneable.

On Sat, Sep 10, 2016 at 4:33 PM Dave Brosius > wrote:

 Yes Louis is correct.

 I want the pair wise associations or all elements of a set.

 Fee-Fi

 Fee-Fo

 Fee-Fum

 Fi-Fo

 Fi-Fum

 Fo-Fum


 the independent iterators produce Fee-Fee (etc) as well as the
 duplicate Fee-Fi and Fi-Fee (etc), both of which i don't want.


 This is obviously simplistic with index based collections, but not
 with sets/maps

 I don't see why an Iterator isn't by nature easily cloneable.



 On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote:

 Ah okay Louis, if that's the case then that certainly makes
 sense, and I'd agree that there's no good way of doing so, as one
 would need to copy the set into a list.

 Dave, did Louis hit the mark? If not, would you kindly go into
 further detail as to exactly what it is you're trying to do?

 Best,
 Jonathan

 On 10 September 2016 at 23:36, Jonathan Bluett-Duncan
 > wrote:

 Hi Dave,

 Rather than using Iterator.clone(), how about you just call
 collection.iterator() 2 times to return 2 unique, non-same
 iterators; something like the following:

 import java.util.Collections;
 import java.util.Iterator;
 import java.util.Set;
 import java.util.concurrent.ConcurrentHashMap;

 public class Example {public static void main(String[] args) { 
Set s =
 Collections.newSetFromMap(new ConcurrentHashMap()); s.add("Fee"); s.add("Fi"); s.add("Fo");
 s.add("Fum"); Iterator it1 = s.iterator();  for (String v1 
=null;
 it1.hasNext(); v1 =it1.next()) {
Iterator it2 = s.iterator();// a completely separate 
iterator to it1 for
(String v2 =null; it2.hasNext(); v2 = it2.next()) 
{System.out.println(v1 + "
<-->" + v2); } } } }

 Or, even better, if you're using Java 5+, you can skip using
 Iterators altogether and use for-loops directly:

 import java.util.Collections;
 import java.util.Set;
 import java.util.concurrent.ConcurrentHashMap;

 public class Example 

Re: Make iterators cloneable?

[Remi Forax]

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 with several indexes
- it's too C++ish, C++ defines clone and equals, Java tries to define a simpler 
iteration protocol
  (from now, given that this question is raised only once in a while, it's 
doesn't seem to be a bad idea)
- iterators are interfaces, so having several iterators means several virtual 
dispatch calls
  (this one is not true anymore because any JITs routinely devirtualize this 
kind of call).

cheers,
Rémi

- Mail original -
> De: "Dave Brosius" 
> À: "Louis Wasserman" , "Jonathan Bluett-Duncan" 
> 
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Dimanche 11 Septembre 2016 02:23:41
> Objet: Re: Make iterators cloneable?

>>> Iterators reading from a BufferedReader
> 
> yes that's true. altho given the contract of Cloneable, adding the clone
> method on Iterator would be safe, as it would only be available if the
> real implementing class 'extends Cloneable'... it's actually kind of
> funny that Object methods aren't available on interface references, anyway.
> 
> 
> But i get the "age of Iterator" answer.. Shame there isn't an answer, tho.
> 
> thanks, dave
> 
> On 09/10/2016 07:44 PM, Louis Wasserman wrote:
>> Some iterators might be.  Many may not be. Certainly Iterator as an
>> interface has been out there for long enough there are Iterator
>> implementations out there that aren't cloneable -- say, Iterators
>> reading from a BufferedReader, where there really won't be any way to
>> do what you're hoping for; BufferedReaders certainly aren't cloneable.
>>
>> On Sat, Sep 10, 2016 at 4:33 PM Dave Brosius > > wrote:
>>
>> Yes Louis is correct.
>>
>> I want the pair wise associations or all elements of a set.
>>
>> Fee-Fi
>>
>> Fee-Fo
>>
>> Fee-Fum
>>
>> Fi-Fo
>>
>> Fi-Fum
>>
>> Fo-Fum
>>
>>
>> the independent iterators produce Fee-Fee (etc) as well as the
>> duplicate Fee-Fi and Fi-Fee (etc), both of which i don't want.
>>
>>
>> This is obviously simplistic with index based collections, but not
>> with sets/maps
>>
>> I don't see why an Iterator isn't by nature easily cloneable.
>>
>>
>>
>> On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote:
>>> Ah okay Louis, if that's the case then that certainly makes
>>> sense, and I'd agree that there's no good way of doing so, as one
>>> would need to copy the set into a list.
>>>
>>> Dave, did Louis hit the mark? If not, would you kindly go into
>>> further detail as to exactly what it is you're trying to do?
>>>
>>> Best,
>>> Jonathan
>>>
>>> On 10 September 2016 at 23:36, Jonathan Bluett-Duncan
>>> > wrote:
>>>
>>> Hi Dave,
>>>
>>> Rather than using Iterator.clone(), how about you just call
>>> collection.iterator() 2 times to return 2 unique, non-same
>>> iterators; something like the following:
>>>
>>> import java.util.Collections;
>>> import java.util.Iterator;
>>> import java.util.Set;
>>> import java.util.concurrent.ConcurrentHashMap;
>>>
>>> public class Example {public static void main(String[] args) { 
>>> Set s =
>>> Collections.newSetFromMap(new ConcurrentHashMap>> Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo");
>>> s.add("Fum"); Iterator it1 = s.iterator();  for (String 
>>> v1 =null;
>>> it1.hasNext(); v1 =it1.next()) {
>>>Iterator it2 = s.iterator();// a completely separate 
>>> iterator to it1 for
>>>(String v2 =null; it2.hasNext(); v2 = it2.next()) 
>>> {System.out.println(v1 + "
>>><-->" + v2); } } } }
>>>
>>> Or, even better, if you're using Java 5+, you can skip using
>>> Iterators altogether and use for-loops directly:
>>>
>>> import java.util.Collections;
>>> import java.util.Set;
>>> import java.util.concurrent.ConcurrentHashMap;
>>>
>>> public class Example {public static void main(String[] args) { 
>>> Set s =
>>> Collections.newSetFromMap(new ConcurrentHashMap>> Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo");
>>> s.add("Fum");  for (String v1 : s) {
>>>for (String v2 : s) {System.out.println(v1 + "<-->" + v2); } 
>>> } } }
>>>
>>> Kind regards,
>>> Jonathan
>>> On 10 September 2016 at 23:13, Dave Brosius
>>> >
>>> wrote:
>>>
>>> It would be nice to be able to