2018-05-18 16:51 GMT+02:00 Stefan Bodewig <bode...@apache.org>:
> On 2018-05-18, Gintautas Grigelionis wrote:
>
> > I believe that Streams API can at least implement the logic run by an
> > original Enumeration in a more concise way, or provide more powerful
> idioms.
> > That IMO makes it worth the while to investigate the Streams
> alternatives.
>
> I agree to do that as soon as we want to change the code to do something
> that wants to use said idioms. I don't really see a reason to change the
> code before that point in time.
>
> > In the process I also found out that other iterators could be used in a
> > more efficient way, or that there is a redundant object construction
> going
> > on.
> > If you wish, I may spend some time to describe the changes I introduced,
> > and maybe then we could discuss the their merits.
>
> Let's use the concrete example that raised Maarten's email. In
> ZipScanner we've gone from
>
> Enumeration<ZipEntry> e = zf.getEntries();
> while (e.hasMoreElements()) {
> ZipEntry entry = e.nextElement();
>
> to
>
> StreamUtils.enumerationAsStream(zf.getEntries()).forEach(entry
> -> {
>
> the Enumeration instance is created in both cases. What is the benfit
> for the ZipScanner class right now?
>
FWIW, the original java.util.ZipFile has a stream() that is based on an
iterator since Java 8 [1].
What is the reason for adding that method if Enumeration is so much better?
;-)
I dare say, the benefit is that streams are parallelizable.
Gintas
[1]
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/util/zip/ZipFile.java#ZipFile.stream%28%29
