On Fri, May 18, 2018 at 10:07 AM, Gintautas Grigelionis <g.grigelio...@gmail.com> wrote: > I accepted the original criticism that going Enumeration -> List -> Stream > has an overhead and I tried to address that by using a decorator. > 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. > > 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. > > Gintas
As a lurker on this list, but also Java developer in $dayjob [1], I'd like to add my 2 cents, FWIW. I see two things going on that are causing a lot of irritation / frustration: 1) Large codebase-wide changes for adapting old (well working) code to new API's, syntax, idioms, ... usually mostly cosmetic. From my personal perspective (I know, I carry little weight here, I'm just an innocent bystander) this is not a good idea. Except in specific cases for example for security reasons, or where there is a clear benefit also for users (for example it improves performance significantly in certain scenarios -- Note that I say "significantly", because shaving off 1 byte off an operation that's only run once by normal users is not worth the code churn / review effort / risk (yes that means you need to measure and show the significant improvement if you want to use this as an argument)). I remember years ago we had a similar discussion at $dayjob, when someone proposed to standardize our rules for grouping import statements. "Should we now bulk-change our entire codebase?" After discussion the consensus was "no" (needless code churn, review burden, possible future backport conflicts, ...), except when you're going to edit the class anyway. So the simple rule was: "use the new style in new code, and in code that you're going to change for 'external reasons' anyway". Which brings me to the more important problem: 2) There is clearly no consensus here on the merits / desirability of these bulk changes. Gintas, I understand your desire to move things along, and you clearly have an opinion about it, but IMHO you really need to stop doing any more bulk changes as long as there is no consensus. Several people have voiced objections on this lists ([2], [3], [4], ...), so why are you continuing to do this? When people start raising flags you really should pause for a moment, and start discussing before making more commits. By making further disputable commits you are making the discussion more difficult (it's much more difficult to freely speak your mind if the code has already been changed ... the work has already been done and it's even more work to revert it, ...). [1] Full disclosure: I work at the same company as Maarten Coene. I'm also an ASF member and PMC member of the Subversion project, but that doesn't really matter here. [2] https://mail-archives.apache.org/mod_mbox/ant-dev/201804.mbox/%3C5682399f-c52e-49bd-a48b-740feaf60653%40apache.org%3E and its entire thread [3] https://mail-archives.apache.org/mod_mbox/ant-dev/201804.mbox/%3C001301d3e070%246555ff10%243001fd30%24%40de%3E and previous answers by other committers in that same thread. [4] https://mail-archives.apache.org/mod_mbox/ant-dev/201805.mbox/%3C87efitnm5f.fsf_-_%40v45346.1blu.de%3E -- Johan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
