Fall back to SHA-1 for base64/binary hashCode #26
Conversation
|
I don't think this is ok - changing the behaviour like this as it will affect all users You have the option of forking xmlbeans and you can make your fork do whatever you like or finding a way to make this configurable with the existing behaviour the default. |
Sure, is there a preferred method for exposing configurable properties? I didn't think these were part of the public API. |
|
Actually, this only seems to affect hash codes. Is this correct? Maybe, we could just change the code so that it tries to create a MD5 digest instance and if that throws an exception, catch it and try sha-1 instead. Could you centralise the code that creates the MessageDigest instead of having 2 places where it happens. Even if 1 class calls a shared static method that the other class hosts. |
matoro
changed the title
Yes, this affects hash codes only. From your earlier suggestion, I went ahead and made it configurable with a system property. The logic is merged with another abstract class in the hierarchy so that it's all in one place. MD5 stays as the default. |
|
No system properties please. We don't use them. |
matoro
changed the title
Sure thing. I've done the other one then, falling back in the case of |
MD5 digest algorithm is unavailable on a FIPS JVM, so fall back to SHA-1 for generating object hashCodes in this case. Only the first 32 bits are used, so the length difference will not matter.
|
Not sure where that comment went but yes, this works fine on java 8. |
|
code merged - thanks |
2 participants
MD5 digest algorithm is unavailable on a FIPS JVM, so fall back to SHA-1 for generating object hashCodes in this case. Only the first 32 bits are used, so the length difference will not matter.