RFR: 8279800: isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards

[Valerie Peng]

On Wed, 12 Jan 2022 14:50:37 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 111:
>> 
>>> 109:     <T extends AlgorithmParameterSpec> T getParameterSpec(Class<T> paramSpec)
>>> 110:         throws InvalidParameterSpecException {
>>> 111:         if (paramSpec.isAssignableFrom(IvParameterSpec.class)) {
>> 
>> The call to cast() is confusing.   But if the paramSpec is AlgorithmParameterSpec.class or Object.class, what's the expected behavior?  There are potential casting exception, I guess.  Maybe, a exactly class matching could be better.
>
> If so, then the `if` block will be true and the spec object is casted to your specified class (`AlgorithmParameterSpec.class` or `Object.class`) and it always succeeds.
> 
> This is exactly what I want to achieve. In fact, this bug and the other `getInstance(oid)` bug have the same root. I was trying to decode an algorithm identifier from its encoding. First, the encoding of the algorithm is in OID so `AlgorithmParameters.getInstance()` must support OID. Second, I want to get the spec from the parameters without knowing the algorithm name and the child `AlgorithmParametersSpec` class type, so `AlgorithmParameters::getParameterSpec` must support `AlgorithmParameterSpec.class` as the argument.
> 
> Otherwise, the program needs to know name and parameter spec type on all supported algorithms.

Interesting... In hindsight, the cast call sort of confirms that the intended ordering is the suggested one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7037