Compile everything with the javac -parameters option

Description

From Spring Framework 6.0.2 (I think) I started seeing things like this:

[java] WARN - Using deprecated '-debug' fallback for parameter name resolution. Compile the affected code with '-parameters' instead or avoid its introspection: net.shibboleth.shared.spring.httpclient.resource.HTTPResource

We’ve gone round the houses with Spring and constructor parameters before, resulting in https://shibboleth.atlassian.net/browse/IDP-1047 and a @ParameterName annotation that is, in fact, part of the constructor for the particular named class. So, it’s at least possible that I wouldn’t have seen this warning if my MDA configuration included the ParameterNameDiscoverer bean we wrote to process it.

More interestingly, though, a lot of people did start seeing similar warnings from Spring around the same time, even when there were no parameter names to be introspected; that turned out to be a bug which I believe was fixed in 6.0.3.

However, in the associated ticket, Juergen said this in passing:

We intend to remove debug symbol introspection completely in 6.1, exclusively relying on -parameters. That's the main reason for that warn logging. Aside from missing -parameters, we also found quite a few places where parameter names were introspected but effectively not used - which is quite costly since we are unnecessarily parsing the class file for every affected class there. We'd like to identify and fix all such remaining cases.

I think this is worth thinking about whether this might affect us: I don’t think I know whether we can say for sure that we have used @ParameterName everywhere we’d need to have in order to dodge the consequences of this.

  • Should we start just using -parameters when compiling everything? (there’s a Maven compiler plugin option for that)

  • If Spring changes its approach, is it worth our rethinking whether @ParameterName and the associated bean is even needed any more?

Environment

None

Activity

Ian YoungSeptember 14, 2023 at 9:35 AM

Actually, this did get done for 17.0.0, but apparently I forgot to update the issue.

Done, commit 45b2977e2087d8fd32d0af4ed1af066e5a501f33.

Scott CantorSeptember 13, 2023 at 12:47 PM

I don’t think we did this yet, right? Bumping version out…

Ian YoungFebruary 7, 2023 at 4:13 PM

Marked this as to be fixed in 17.0.0 only, as this isn’t relevant to the 5.x version of Spring Framework that the v11 parent uses.

Ian YoungFebruary 7, 2023 at 2:11 PM

It’s interesting that you should mention that, because yes and no. The debug flag is only explicitly set in the “release” profile, but my research in https://shibboleth.atlassian.net/browse/JPAR-195 claims that it’s on by default.

For the experiment, I added “parameters” to the default configuration as well as to the “release” profile, on the basis that this is a functional change and it shouldn’t be enabled only in a release build. The one I tested didn’t use the release profile and things still worked for me in terms of Spring being able to introspect the constructor name on that particular bean. But as I say I think that’s probably implicitly using “debug” as well.

You’re probably right that “debug” isn’t required for introspection any more; I guess I’m nevertheless reluctant to explicitly disable something that’s on by default on the basis that it might have other implications.

I do think that we should try and push https://shibboleth.atlassian.net/browse/JPAR-195 to completion for v5, though, so that we’re not having this discussion again next time round. I’ll add a note there to indicate that we should reconsider whether we should disable “debug” there.

Scott CantorFebruary 7, 2023 at 1:21 PM

Is that with the debug flag also on? I presume we could omit that if we were doing that to get the parameter names to show up before.

Fixed

Details

Assignee

Reporter

Fix versions

Affects versions

Created February 1, 2023 at 5:48 PM
Updated September 14, 2023 at 12:31 PM
Resolved September 14, 2023 at 9:36 AM