On Wed, 12 Jan 2022 14:50:37 GMT, Weijun Wang <wei...@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
