On Fri, 28 Jul 2023 10:05:01 GMT, Claes Redestad <redes...@openjdk.org> wrote:

> I think we could consider dropping `vectorized` from `vectorizedHashCode`: 
> there's nothing in the library-side implementation for this that is 
> explicitly setting up for vectorization of each case (unlike the 
> `mismatch/vectorizedMismatch` pair).

Sounds good; I specifically dislike "vectorized" being in the name of the 
method that is called by clients who don't seem to require that behaviour. It's 
misleading.

Method naming aside, `ArraysSupport.vectorizedHashCode` has one additional 
wrinkle. One of its arguments, `int basicType`, accepts untyped constants whose 
names might be so counterintuitive that a reviewer might insist on adding an 
inline comment to indicate that a particular combination of arguments is not a 
typo, but an intended case of _unsigned bytes_, for example:

https://github.com/openjdk/jdk/blob/2bdfa836adbeba3319bee4ee61017907d6d84d58/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L801-L811

Could we hide that `int basicType` behind overloads that have static safety 
better than `Object array` and are appropriately named? For example:

    public static int hashCode(byte[] array, int fromIndex, int length, int 
initialValue);
    public static int unsignedHashCode(byte[] array, int fromIndex, int length, 
int initialValue);

Related, I assume this is a typo

    jdk.internal.util.ArraysSupport#signedHashCode

and it should've been

    jdk.internal.util.ArraysSupport#unsignedHashCode
                                    ^^^
?

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655477396

Reply via email to