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