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

[Xueming Shen]

On 04/30/2013 01:32 PM, Henry Jen wrote:

That's what it was, but as Alan pointed out, it is potential misleading to 
people who knows detail about zip file.

I think the ordering is an implementation detail, and based on zip file spec, I 
would assume it's the order as in central directory.

I didn't dig down to the native code to confirm what ordering have been 
implemented, so my confidence level is at most be par with Paul. :)

The order from the implementation is the entry's order in cen, the central 
directory.

-Sherman

Cheers,
Henry


On Apr 30, 2013, at 12:56 PM, Martin Buchholz<marti...@google.com>  wrote:

In practice, the order of entries in the central directory is always the
same as the order of actual entries, although in theory they might be
different.  I think it would be useful to say that the entries are returned
in the order that they are stored in the zip file, and leave the central
directory order subtlety out of it.


On Tue, Apr 30, 2013 at 12:40 PM, Paul Sandoz<paul.san...@oracle.com>wrote:

On Apr 30, 2013, at 9:02 PM, Henry Jen<henry....@oracle.com>  wrote:

Point taken.

It seems to me we should at least keep the ORDERED characterristic for

the returned stream, but not necessarily need to specify what order it is,
which would be inline with entries().

Does that make sense?

I'll add back the ORDERED flag but keep the javadoc not mention ordering.

Is there any reason why we cannot mention the order is the same as the
order declared in the central directory?

Or is that considered an implementation detail? If so it seems like a
feature to me we should call out. However, I don't really know much about
the zip implementation to say much with confidence on this matter.

Paul.

Cheers,
Henry

On Apr 30, 2013, at 9:35 AM, Paul Sandoz<paul.san...@oracle.com>  wrote:

On Apr 30, 2013, at 5:43 PM, Henry Jen<henry....@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.