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

[Henry Jen]

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. :)

Cheers,
Henry


On Apr 30, 2013, at 12:56 PM, Martin Buchholz <martinrb at 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.sandoz at oracle.com>wrote:
> 
>> On Apr 30, 2013, at 9:02 PM, Henry Jen <henry.jen at 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.sandoz at oracle.com> wrote:
>>> 
>>>> 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.
>>> 
>> 
>>