RFR: 8026369: javac potentially ambiguous overload warning needs an improved scheme [v3]

[Archie L. Cobbs]

On Fri, 24 Feb 2023 19:00:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I think the code should be split a bit using helper methods

OK - will do.

> I'm a bit worried that overuse of streams in this code could imply some performance hit

I asked basically the same question ([in a separate thread](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022259.html)) two days ago and nobody replied with a definitive answer (not surprising).

However, note also that in that same thread Christoph reported no timing difference between `Stream` vs. `for()` loop ([here](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022261.html)), although there were more allocations. FWIW.

Sorry to go off on a tangent here, but I'm sure this issue will come up again and it would be nice to have some kind of (informal) policy to go on...

I generally try to follow the "measure first, optimize second" rule to avoid preemptive "optimizations" that come at the expense of code clarity for unproven meaningful benefit.

So I can de-`Stream` the code but are we sure it's worth it? Are we going to have a no `Stream` policy in the compiler code? Why did we develop `Stream`'s if they can't be used in a mainstream tool like `javac`? Where does the madness end? :)

There is also the larger philosophical question as well, which is that if a `Stream` is appreciably slower than the semantically-equivalent `for()` loop, then isn't that a Hotspot problem, not a developer problem?

-------------

PR: https://git.openjdk.org/jdk/pull/12645