Compile everything with the javac -parameters option
Description
Environment
is related to
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.
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 theParameterNameDiscoverer
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:
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?