Exponential compilation time for List.of(Map.entry) expressions

[Dawid Weiss]

Hi Maurizio,

as Vicente mentioned, this is sadly a known issue.


Thank you and Vicente for pointing at the root problem. I actually did do a
few searches trying to find something similar in Jira but didn't come up
with anything that wasn't closed (like JDK-8263452).


> We have some ideas on how to maybe do it, but they
> are all fairly complex, and the risk of affecting correctness is rather
> high.
>

Fair enough and sorry I can't be more helpful here.


> In the meantime, there's maybe a workaround for you to try: let's remove
> the generic-ness of Map.Entry from the picture, by declaring a new method:

Map.Entry<String, String> newStringEntry(String key, String val) { return
> Map.entry(key, val); }


This is actually a nice hint for adding to Uwe's forbiddenapis checker. [1]
:)

Anyway, I have refactored that initialization into a different code shape
already - this isn't the difficult part.
The difficult part was in figuring out what the problem actually was and
trying to detect it somehow for the
future, until you smart folks figure out how to straighten it up.

This code had been compiling for weeks (slowing down builds) and I only
found out about it because
I was working on something unrelated in the build and noticing these
strange, long compilation times on a literal
dozen of input files. My thought process was: gradle build problem,
hardware problem, extensive I/O somewhere...
javac was way, way at the end of the list (if at all). I mean it as a
compliment - it's typically so robust that it's
hardly ever a suspect.

Thanks again for feedback and sorry for raising an alarm on an existing
issue.

Dawid

[1] https://github.com/policeman-tools/forbidden-apis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250117/30516640/attachment-0001.htm>