RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9]

Glavo duke at openjdk.org
Tue Apr 11 11:53:42 UTC 2023


On Sat, 8 Apr 2023 18:00:53 GMT, Roger Riggs <rriggs at 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, AARCH64, RISCV64, S390, PPC64`
>> Note that `amd64` and `x86_64` in the build are represented by `X64`.
>> The value 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 unused static and import of Stabile

src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 68:

> 66:     // The variables are named to match the Architecture value names, and
> 67:     // the values are named to match the build variables.
> 68:     static final boolean TARGET_ARCH_IS_X64         = "@@OPENJDK_TARGET_CPU@@" == "x86_64";

Would it be better to rename the enum entry to `X86_64`? I personally prefer the name x86-64 because I feel it is more regular than x64..

src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 82:

> 80:     private static Architecture initArch(String archName) {
> 81:         try {
> 82:             String mapped = switch (archName) {

How about mapping names in the build script instead of at runtime?

I suggest placing only the mapped arch name in `PlatformProps` and moving the `CURRENT_ARCH` to `Architecture`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162686875
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162695586


More information about the serviceability-dev mailing list