RFR JDK-8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile

Paul Sandoz paul.sandoz at oracle.com
Tue Apr 30 16:35:13 UTC 2013


On Apr 30, 2013, at 5:43 PM, Henry Jen <henry.jen at oracle.com> wrote:
> 
>> So if possible we should report ORDERED and state the association, if any, of encounter order with the order declared in the central directory, which i hope is, and seems to be, the same. (Plus update the docs of entries() too.)
>> 
> 
> I agree with you entries() and streams() should be in sync on ordering. Spec-wise, I have no clear preference.

> But when I looked into a zip file archive, I always would like to see entries in alphabetic order so I can find the files I really care, which will also have directory structure nicely. Order in central directory not necessary helping me.
> 

When you do the following what entry do you think should be returned?

  zipfile.entries().nextElement();

  zipfile.stream().findFirst();

  zipfile.stream().parallel().findFirst();

I would expect all entries to be equal and to be the first entry in the central directory. I would not expect the latter to be non-deterministic [*].

Or what about the following:

  List l = new ArrayList(); Enumeration e = zip file.entries(); 
  for(int i = 0; i < 10 & e.hasMoreElements(); i++) l.add(e.nextElement()); 
  List ss = zipfile.entries().limit(10).collect(toList());
  List sp = zipfile.entries().parallel().limit(10).collect(toList());

Should those lists be equal? Again i would expect so.

There does appear to be a well-defined encounter order. I don't think most developers will consider the collection of zip entries to behave like a Set. It is more list-like.

Paul.

[*] Note that our current implementation is deterministic, but that is because we don't currently check when doing a find first if the stream has no order and then defer to find any, which is a minor optimization we can enable.


More information about the core-libs-dev mailing list