RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached

Claes Redestad redestad at openjdk.java.net
Fri Dec 18 15:29:25 UTC 2020


On Fri, 18 Dec 2020 14:59:10 GMT, PROgrm_JARvis <github.com+7693005+JarvisCraft at openjdk.org> wrote:

>> A more general issue is that this patch assumes the `MessageDigest` object returned is statically shareable, which implies it being stateless and thread-safe.
>> 
>> This doesn't seem to be the case. See [MD5.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/MD5.java) and the [DigestBase.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/DigestBase.java) base class, which both have mutating buffers for doing the digest.
>
>> A more general issue is that this patch assumes the `MessageDigest` object returned is statically shareable, which implies it being stateless and thread-safe.
>> 
>> This doesn't seem to be the case. See [MD5.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/MD5.java) and the [DigestBase.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/DigestBase.java) base class, which both have mutating buffers for doing the digest.
> 
> Wow, this is interesting. In this case I will check if there is a way to implement a thread-safe mechanism there. Will report here once there is some result.

Might be fun to try, but it looks like rewriting to have MD5 to only use transient state will be a significant effort, and might just end up shuffling over allocations from `getInstance` to `digest`, which could regress code that reuse a digest instance (in a thread safe manner).

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

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


More information about the core-libs-dev mailing list