[9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed on solaris12(sparcv9 and x86)

[Valerie Peng]

OracleUcrypto provider already separates them in two classes: The 
cloneable libMD digest impls are encapsulated by a class which 
implements Cloneable and the new un-cloneable Ucrypto digest impls are 
in a class which does not.
I wasn't sure if we can safely assume that an instance supports clone 
when it implements Cloneable. So I thought better call clone() to be 
sure. Given your feedback, I have replaced the clone() calls with 
instanceof checks.

Webrev updated: http://cr.openjdk.java.net/~valeriep/8157579/webrev.02

Thanks,
Valerie


On 8/9/2016 10:43 AM, Sean Mullan wrote:
> Or better yet, just change the ucrypto impl to not implement Cloneable 
> regardless what Solaris version you are on. Then you can just check 
> each MessageDigest impl to see if it is an instanceof Cloneable rather 
> than calling clone on each.
>
> --Sean
>
> On 08/09/2016 09:38 AM, Sean Mullan wrote:
>> Is there any way to split the Ucrypto MessageDigest implementation into
>> 2 classes, one that implements Cloneable and the other which doesn't,
>> and use the appropriate one depending on which OS version you are on?
>>
>> This way, instead of calling clone and catching
>> CloneNotSupportedException, you could just check each MessageDigest
>> object to see if it implements Cloneable.
>>
>> --Sean
>>
>>
>> On 08/04/2016 10:01 PM, Valerie Peng wrote:
>>>
>>> Anyone has time to review this fix? The code change is in only one file
>>> and straightforward if you agree with the approach.
>>> Starting S11.3 and S12, OracleUcrypto provider switched to new Ucrypto
>>> APIs for message digest operations and there is no clone support.
>>> This affects the MAC impls of SunJCE provider which delegates the 
>>> digest
>>> operation to the most preferred provider.
>>> To ensure the clone support, I will switch to getting the digest impl
>>> from SUN provider if the most preferred one does not.
>>> In the case of SUN provider is not available, it will then goes through
>>> provider list.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157579
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8157579/webrev.00/
>>>
>>> No new test as it's covered by existing regression test.
>>>
>>> Thanks,
>>> Valerie
>>>
>>>