On 08/09/2016 10:00 PM, Valerie Peng wrote:

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.

True, but I think those would be considered bad Cloneable implementations.

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

Looks good.

--Sean


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



Reply via email to