XMLSignatureSigningStage.ShaVariant should be SHAVariant
Description
Environment
Activity
Done, commits a5c8f8cdf94bbe3936e1178c250fc28a1a086510 and 845b70b897ae3e13c067b78a0e71778abb6eb35b.
Remembering that Spring is smart enough to figure out what p:SHAVariant="SHA384"
means without an explicit reference to the enum’s type, I decided to add migration support to the accessors in the form of deprecation warnings. As long as XML configurations work that way, they will still work (with those warnings).
I was hoping to provide some migration assistance, but even on a case-sensitive file system, the compiler claims there’s a classfile collision between ShaVariant
and SHAVariant
. So this ends up being a breaking change, one way or another. Given that, I don’t think there’s much value in providing migration assistance for the accessors, although that would be possible in principle.
On the question of accessor names, the design patterns section of the original beans spec says:
8.8 Capitalization of inferred names.
When we use design patterns to infer a property or event name, we need to decide what rules to follow for capitalizing the inferred name. If we extract the name from the middle of a normal mixedCase style Java name then the name will, by default, begin with a capital letter.
Java programmers are accustomed to having normal identifiers start with lower case letters. Vigorous reviewer input has convinced us that we should follow this same conventional rule for property and event names.
Thus when we extract a property or event name from the middle of an existing Java name, we normally convert the first character to lower case. However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. So for example,
“FooBah” becomes “fooBah” “Z” becomes “z”
“URL” becomes “URL”We provide a method Introspector.decapitalize which implements this conversion rule.
I think this means that the normal rules will work fine with, e.g., getSHAVariant
inferring a property name of SHAVariant
which is appropriately capitalised. I need to check that Spring does the right thing too, though.
There’s no need for the corresponding field to change, as it’s just an internal implementation detail. It can continue as shaVariant
as before.
Shibboleth convention is to use all-upper-case for acronyms when used in names. We should change this part of the API.
Not clear how that will apply to the associated field and accessors.