Get rid of a lambda in Arc runtime code

[geoand]

These are causing NoSuchMethodError on application startup
(this can be verified easily either via the debugger, or from JFR events - see
https://bugs.openjdk.java.net/browse/JDK-8161588 for more details
about why the error occurs) which can have a small impact on startup performance

N.B. I only replaced the code for the instances
that were causing the issue at the startup of a
Quarkus application

[franz1981]

LGTM

[mkouba]

TBH I'm not a big fan of similar changes. How big is the impact? I mean what do we get? Is it at least a millisecond?

[mkouba]

Hm, this is not equivalent in the sense that previously an optimized immutable list (List.of()) was used whereas here we use an unmodifiable wrapper...

[geoand]

It's equivalent for all intents and purposes, no?

[mkouba]

It's not equivalent in terms of memory consumption because in theory there will be a lot resolved lists of beans that are stored in the cache and Collections.unmodifiableList(new ArrayList<>()) is definitely worse compared to List.of().

[geoand]

But that List.of is produced by a Stream which itself takes up memory to be processed.

[mkouba]

But that List.of is produced by a Stream which itself takes up memory to be processed.

Which is freed afterwards but the list is there to stay as a cached value.

I was thinking about replacing the Collections.unmodifiableList(nonSuppressed) with List.copyOf(nonSuppressed)...

[geoand]

No problem, done

[geoand]

Well, we have agreed to not include lambdas in runtime code, correct?

Measuring differences at the millisecond level is likely close to impossible.
But these changes (I've started doing them elsewhere as well in cooperation with @franz1981) do add up.
Moreover, they cut down and on the false warnings Java Mission Control reports when analyzing a Quarkus application's JFR events

[mkouba]

Well, we have agreed to not include lambdas in runtime code, correct?

These are not lambdas but method references ;-)

Measuring differences at the millisecond level is likely close to impossible.
But these changes (I've started doing them elsewhere as well in cooperation with @franz1981) do add up.
Moreover, they cut down and on the false warnings Java Mission Control reports when analyzing a Quarkus application's JFR events

My point is that we do crazy stuff like this to save some unmeasurable amount of time but then some extensions take half a second to start :-(

[geoand]

These are not lambdas but method references ;-)

True of course, but their invocation is still handled at runtime, so they do have an overhead compared to classes :)

My point is that we do crazy stuff like this to save some unmeasurable amount of time but then some extensions take half a second to start :-(

Yeah I understand, but in this case there is a known issue that the JVM thrown an exception in order to handle the control flow (which is bad for performance but there is nothing we can do to influence the JVM to do otherwise) and the fix is very easy, so I don't see the reason why to not apply it.