On 2018-05-20, Gintautas Grigelionis wrote:
> 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.
I'm afraid you misunderstood my question. I didn't ask why streams may
be preferable over Enumerations when you write new code or change
existing code. I was asking how does this benefit the existing code
right now when there is no other change at all.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
