RFR JDK-8012645: Stream methods on BitSet, Random, ThreadLocalRandom, ZipFile
henry.jen at oracle.com
Tue Apr 30 19:02:11 UTC 2013
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.
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?
> 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.
> [*] 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.
More information about the core-libs-dev