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

[Martin Buchholz]

The order of entries in a zip file can be and is used by applications.
Notably, many people spend a lot of time optimizing the order of entries in
a zip file for performance reasons.  But it's also likely some people
depend on the order for correctness.  Whether or not your streams are
ORDERED, many people will need the ability to access the entries in a
sequential fashion.  Both ordered and non-ordered access may be useful.


On Tue, Apr 30, 2013 at 8:43 AM, Henry Jen <henry.jen at oracle.com> wrote:

>
> On Apr 30, 2013, at 1:33 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
> >
> > 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.
> >
>
> Yes, any sequence has an encounter order, but is it significant and should
> be preserved is the question.
>
> The repeatability of order is from the container,  if we have an implicit
> policy that such repeatability implies order, then we can add the ORDERED
> characteristic back.
>
> In latest version, I removed the ORDERED because the order in the central
> directory is tool-dependent AFAIK, which I don't think worth preserving.
>
> > 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.
>
> Cheers,
> Henry
>
>