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

Roger Riggs rriggs at openjdk.org
Thu Apr 6 20:27:22 UTC 2023


On Thu, 6 Apr 2023 19:55:07 GMT, Glavo <duke at openjdk.org> wrote:

>> 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?

There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters.
The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause.
Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed.

The template file used in the implementation could be renamed to be more agnostic to OS or arch.

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

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



More information about the client-libs-dev mailing list