Add darwin_arm64 java_tools

[hvadehra]

trafficstars

Build a fat universal binary for java_tools_prebuilt on darwin

Work towards: https://github.com/bazelbuild/java_tools/issues/57 and https://github.com/bazelbuild/bazel/issues/13944

[hvadehra]

Is there a reason to build a fat binary and move away from the previously used pattern where 3 prebuilt repositories are released? Technically you should be able to extend for the 4th repository, build for that platform and select the correct prebuilt.

That's what I tried first, but it was a more invasive change. If we were to have add a new repo for apple silicon, I think we should rename the existing one to "darwin_intel" or "darwin_x86_64" (leaving it as "darwin" would be misleading/incorrect). So I tried that, and it ended up getting very messy. There are a lot of assumptions in code and tests that there is only a single darwin platform (i.e. platform == OS).

That option looks less complex as the current one, because it doesn't involve additional rule and this makes it probably easier to maintain.

I feel the opposite. Going down that route seems less extensible in general, requiring a lot more updates whenever something changes. At least, not without significant refactoring of all BUILD, BUILD.tools, BUILD.java_tools, etc

[comius]

Is there a reason to build a fat binary and move away from the previously used pattern where 3 prebuilt repositories are released? Technically you should be able to extend for the 4th repository, build for that platform and select the correct prebuilt.

That's what I tried first, but it was a more invasive change. If we were to have add a new repo for apple silicon, I think we should rename the existing one to "darwin_intel" or "darwin_x86_64" (leaving it as "darwin" would be misleading/incorrect). So I tried that, and it ended up getting very messy. There are a lot of assumptions in code and tests that there is only a single darwin platform (i.e. platform == OS).

That option looks less complex as the current one, because it doesn't involve additional rule and this makes it probably easier to maintain.

I feel the opposite. Going down that route seems less extensible in general, requiring a lot more updates whenever something changes. At least, not without significant refactoring of all BUILD, BUILD.tools, BUILD.java_tools, etc

This sounds reasonable, let's have a single binary then.

Since you've already seen the assumptions and tests for darwin platform, would you mind reviewing and updating them, if needed?