We cannot change how the registration works here because we rely on this internally. You could, however, glue BLAKE3 into this with following steps:

1. Write a class that implements java.security.MessageDigest for BLAKE3. This is the class that interact with JNI and call into c code.
2. Register the MessageDigest from step 1 by implementing a java.security.Provider and add it with java.security.Security.addProvider(...). So that when you call MessageDigest.getInstance("BLAKE3"), you can get back the instance from the provider.
3. Adapt DigestMessage for BLAKE3 into HashFunction by calling MessageDigestHashFunction.
4. Create a DigestHashFunction by calling DigestHashFunction.register(...) using the HashFunction from step 3.

I know this is verbose and not fun but we have to write it in this way.

nit: Use Blake3MessageDigest.class.getName() to make refactor easier in the future.

Done.

I think you can just use new MessageDigestHashFunction("BLAKE3") (doc) instead of implementing HashFunction by yourself in Blake3HashFunction.

As mentioned above, we don't want put BLAKE3 code in the common code path. Neither the registration here nor the provider below.

I suggest we have a utility class BazelHashFunctions which installs the provider and register the hash function, e.g.:

class BazelHashFunctions {
    static {
        addProvider(...);
    }

    public static final DigestHashFunction BLAKE3 = DigestHashFunction.register(...);
}

In a following PR when we want to create a file system based on BLAKE3, we could do that in BazelFileSystemModule with code like:

new UnixFileSystem(BazelHashFunctions.BLAKE3, ...);

I'm trying to read between the lines here and figure out where you want stuff / how you want it to be injected -- let me know what I got wrong.

I moved blake3 stuff into a bazel subdir of vfs. The provider is statically registered when BazelHashFunctions is loaded by the classloader in src/main/java/com/google/devtools/build/lib/bazel/Bazel.java. Re the MessageDigestHashFunction -- addressed above, but that's not public afaict.

Yes, we want the provider to be statically registered by the classloader when it is loading class BazelHashFunctions. But we don't want to have it implementing BlazeModule and put it in src/main/java/com/google/devtools/build/lib/bazel/Bazel.java.

What I proposed above is we could add the code

new UnixFileSystem(BazelHashFunctions.BLAKE3, ...);

to somewhere like here so that when we want to use BLAKE3, it registers it.

We don't need to do it in this CL as we haven't focused on integrating BLAKE3 into Bazel's VFS. Let's limit the scope of this CL to only adapt BLAKE3 as a DigestHashFunction.

Can you give a little more context on what else is required to add the digest function to vfs? I'm a little unclear on that part and it will help me for the next cl. Thanks!

Well, I think I overcomplicated that. The only necessary part is we want to register BLAKE3 for Bazel only. We can just force loading BazelHashFunctions by adding following code block in BazelFilesystemModule

class BazelFilesystemmodule {
    static {
        BazelHashFunctions.ensureRegistered();
    }
}

where BazelHashFunctions.ensureRegistered is just an empty static function whose sole purpose is to let JVM load class BazelHashFunctions and run the static block there.

Thanks, this is just what I needed. Done.

If you use MessageDigestHashFunction as suggested below, you can remove implements Hasher.

MessageDigestHashFunction is not public, and copying it in is prohibitive because it brings like 5 other classes.

Sorry, I missed that. Can we then create a separate class to implement Hasher? I found it is confusing to combine these two especially when we have update, engineUpdate and share the underlying buffer.

Done.

One optimization here is we could avoid copying if the size of data is larger than ONESHOT_THRESHOLD. But this is totally optional and we could leave that for a separate PR.

Yeah I was trying to keep this simple for now -- enough complexity already :) Agree on deferring this for a followup (where we measure perf).

Optional: avoid creating a new object, put the byte into buffer directly.

Done.

I think we need to copy/use the argument b now instead of saving it for use later. I believe the contract of the interface is the caller is free to use the passed buffer after the function is returned.

Right you are.

Do we need this line since blake3_jni is already in the deps?

Done.

I see BALKE3 code can be compiled on Windows. Are there any blockers for running the tests on windows?

Done.

@meteorcloudy FYI, this is an unfortunate consequence of the old versions running in CI.

Related: #18784 (comment)

This returns long while the corresponding Java method returns int. It should also the JNIEnv * and jobject parameters.

Done.

That usage is fine as it comes after the loadJni call. The failing test bootstraps Bazel and may not honor BUILD files, maybe the new JNI sources need to be listed somewhere else?