On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static >> methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, >> PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by >> #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be >> done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Remove unneeded qualified export from java.base to jdk.attach src/java.base/share/classes/jdk/internal/util/Architecture.java line 100: > 98: */ > 99: public static Architecture current() { > 100: return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL]; I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream. Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added to the enum to represent other architectures that are not of concern? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160193842
