RFR JDK-8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile
Paul Sandoz
paul.sandoz at oracle.com
Tue Apr 30 08:33:31 UTC 2013
On Apr 29, 2013, at 9:41 PM, Henry Jen <henry.jen at oracle.com> wrote:
> On 04/27/2013 08:01 AM, Alan Bateman wrote:
>> On 27/04/2013 00:08, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review webrev at
>>>
>>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/webrev
>>>
>>> The API doc in specdiff format is at
>>>
>>> http://cr.openjdk.java.net/~henryjen/ccc/8012645.0/specdiff
>>>
>>> Cheers,
>>> Henry
>> In the ZipFile spec it reads "Entries appear in the {@code Stream} in
>> the order they appear in the ZIP file" but I think the order of the
>> entries in the central directory and this may not be the same as the
>> order of the entries in the archive.
>>
>
> It is the order of enumeration of entries(), which I believe is the
> order of the entries in the central directory of a zip file.
>
> After another thought, is the ordering actually meaningful or has any
> sort of benefit/guaranteed characteristics we should preserve?
> Otherwise, it is probably better to left out the ORDERED.
>
ZipFile/JarFile entry enumeration/stream can have an encounter order if repeated traversal of the same zip file entries (for multiple program executions) will always encounter those entries in the same order.
Having an encounter order will ensure deterministic results when evaluating sequentially and in parallel. My expectation would be that entries of a zip file would have an encounter order.
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.)
Paul.
More information about the core-libs-dev
mailing list