Discussion:
Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name
Mandy Chung
2017-04-03 18:41:03 UTC
Permalink
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/

This revisits the OS name and arch in packaging JDK modules
to extend the module descriptor with ModuleTarget class file
attribute. We considered matching with the system properties.
Linux x64 JDK can run on a system whose `os.arch` system
property value can be `amd64` or `i586` or `x86_x64`.
Similiarly, windows x86/x64 JDK can run on a system whose
`os.name` system property starts with “Windows” as the
os.name property is set to "Windows XXX" for example
"Windows Server 2012 R2”. It might be worth considering
multiple OS arch values in ModuleTarget in the future.

JDK bundle names are revised in JDK 9. This is a good
alternative to be consistent with $OS-$ARCH value in
the bundle names. This patch proposes to package JDK modules
with OS name and arch to match the values as in JDK bundle names.
jlink will generate the `release` file and set OS_NAME and
OS_ARCH to those values. This also proposes to drop
OS_VERSION to align with the ModuleTarget class file attribute.

This shows the old and new value of OS_NAME/OS_ARCH properties
in the `release` file:

JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows

OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64

Mandy
m***@oracle.com
2017-04-03 20:15:52 UTC
Permalink
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
...
This shows the old and new value of OS_NAME/OS_ARCH properties
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64
I suggest we use "amd64" instead of "x64" (or any other variants).
"x64" is confusingly close to "x86", and while it's used by some
companies (including Oracle), it's not used all that widely. "amd64" is
better known, matches the long-standing value of the "os.arch" system
property (on Linux and Windows, anyway) and, as a side benefit, honors
the originators of the architecture.

- Mark
Simon Nash
2017-04-03 20:35:30 UTC
Permalink
Post by m***@oracle.com
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
...
This shows the old and new value of OS_NAME/OS_ARCH properties
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64
I suggest we use "amd64" instead of "x64" (or any other variants).
"x64" is confusingly close to "x86", and while it's used by some
companies (including Oracle), it's not used all that widely. "amd64" is
better known, matches the long-standing value of the "os.arch" system
property (on Linux and Windows, anyway) and, as a side benefit, honors
the originators of the architecture.
- Mark
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.

Simon
Mandy Chung
2017-04-03 21:07:39 UTC
Permalink
Post by Simon Nash
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.
Just to be clear, there is no plan to change the value of the
‘os.name’ system property and its value is “Mac OS X”.
Changing the value of the system property ‘os.name’ would
break existing applications.

In JDK 8, OS_NAME in the release file is “Darwin” which is
what this patch would change.

Mandy
Simon Nash
2017-04-03 21:38:52 UTC
Permalink
Post by Mandy Chung
Post by Simon Nash
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.
Just to be clear, there is no plan to change the value of the
‘os.name’ system property and its value is “Mac OS X”.
Changing the value of the system property ‘os.name’ would
break existing applications.
In JDK 8, OS_NAME in the release file is “Darwin” which is
what this patch would change.
Mandy
I understand that the os.name property value cannot be changed for compatibility
reasons and therefore this name needs to stay as the "historic" Mac OS X.

My comment was regarding the change of value for OS_NAME. Given that there is
no compatibility issue here, does it make sense for the new value to be something
that is no longer current in Apple terminology?

Simon
Alan Bateman
2017-04-04 06:40:31 UTC
Permalink
Post by Simon Nash
My comment was regarding the change of value for OS_NAME. Given that there is
no compatibility issue here, does it make sense for the new value to be something
that is no longer current in Apple terminology?
Just on compatibility then just to say that the `release` file is a
supported interface. So changing the value of OS_NAME ("Darwin" ->
"macos" and "SunOS" -> "solaris") might mean that scripts or tools that
read it will need to be updated. Mandy will get this change documented
in the release notes and I wouldn't expect updating scripts to deal with
additional or new values should be a major issue.

-Alan.
m***@oracle.com
2017-04-03 21:39:25 UTC
Permalink
Post by Simon Nash
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
...
This shows the old and new value of OS_NAME/OS_ARCH properties
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.
Agreed -- we should change OS_NAME from "Darwin" to "macos".

- Mark
Mandy Chung
2017-04-03 21:50:52 UTC
Permalink
Post by Simon Nash
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
...
This shows the old and new value of OS_NAME/OS_ARCH properties
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.
Agreed -- we should change OS_NAME from "Darwin" to "macos”.
OK. Should the bundle names be updated to reflect this change?
In any case, it is a separate issue.

JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows

OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm32
aarch64 arm64

Mandy
m***@oracle.com
2017-04-03 23:10:00 UTC
Permalink
Post by Mandy Chung
Post by Simon Nash
...
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.
Agreed -- we should change OS_NAME from "Darwin" to "macos”.
OK. Should the bundle names be updated to reflect this change?
Probably not worth doing at this late stage in 9; let's fix these in 10.
Post by Mandy Chung
In any case, it is a separate issue.
Yep.
Post by Mandy Chung
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm32
aarch64 arm64
Looks good.

Thanks,
- Mark
Mandy Chung
2017-04-03 23:49:41 UTC
Permalink
Post by m***@oracle.com
Post by Mandy Chung
Post by Simon Nash
...
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.
Agreed -- we should change OS_NAME from "Darwin" to "macos”.
OK. Should the bundle names be updated to reflect this change?
Probably not worth doing at this late stage in 9; let's fix these in 10.
That's what I was thinking too. I created a JBS issue target for 10:

Mandy
Magnus Ihse Bursie
2017-04-04 08:04:22 UTC
Permalink
Post by Mandy Chung
Post by Simon Nash
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
...
This shows the old and new value of OS_NAME/OS_ARCH properties
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.
Agreed -- we should change OS_NAME from "Darwin" to "macos”.
OK. Should the bundle names be updated to reflect this change?
In any case, it is a separate issue.
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm32
aarch64 arm64
If we are making changes to the original proposal from JDK-8175819, then
I just want to add my few cents:

Why change from the well-established "aarch64" to the virtually unused
"arm64"? As far as I know, using the name "arm64" for the aarch64
platform is something that has only been done in the (recently opened)
closed Oracle port. This change, however, proposes to change the value
in the release file even for the open aarch64 port, which has always
been known by that name.

/Magnus
Post by Mandy Chung
Mandy
m***@oracle.com
2017-04-04 15:12:15 UTC
Permalink
Post by Magnus Ihse Bursie
Post by Mandy Chung
...
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm32
aarch64 arm64
If we are making changes to the original proposal from JDK-8175819, then
Why change from the well-established "aarch64" to the virtually unused
"arm64"? As far as I know, using the name "arm64" for the aarch64
platform is something that has only been done in the (recently opened)
closed Oracle port. This change, however, proposes to change the value
in the release file even for the open aarch64 port, which has always
been known by that name.
The trouble here is that "arm64" and "aarch64" are effectively synonyms
for the ISA, but in the JDK we've wound up using them as the names of
two different ports.

A JMOD file built for the 64-bit ARM architecture will (one hopes) run
equally well on either port. Which name should we use in JMOD files,
"arm64" or "aarch64"? My sense is that "arm64" is more immediately
understood by developers at large even if "aarch64" is more correct
in the eyes of ARM Holdings plc, but I could be wrong.

For what it's worth, the Linux distros aren't consistent: Debian-based
distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64".

- Mark
David M. Lloyd
2017-04-04 15:20:54 UTC
Permalink
Post by m***@oracle.com
Post by Magnus Ihse Bursie
Post by Mandy Chung
...
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm32
aarch64 arm64
If we are making changes to the original proposal from JDK-8175819, then
Why change from the well-established "aarch64" to the virtually unused
"arm64"? As far as I know, using the name "arm64" for the aarch64
platform is something that has only been done in the (recently opened)
closed Oracle port. This change, however, proposes to change the value
in the release file even for the open aarch64 port, which has always
been known by that name.
The trouble here is that "arm64" and "aarch64" are effectively synonyms
for the ISA, but in the JDK we've wound up using them as the names of
two different ports.
A JMOD file built for the 64-bit ARM architecture will (one hopes) run
equally well on either port. Which name should we use in JMOD files,
"arm64" or "aarch64"? My sense is that "arm64" is more immediately
understood by developers at large even if "aarch64" is more correct
in the eyes of ARM Holdings plc, but I could be wrong.
For what it's worth, the Linux distros aren't consistent: Debian-based
distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64".
If you use "arm64" instead of "aarch64" then shouldn't you use "sparc64"
instead of "sparcv9"? Same logic AFAICT.
--
- DML
Andrew Haley
2017-04-04 15:22:50 UTC
Permalink
Post by m***@oracle.com
The trouble here is that "arm64" and "aarch64" are effectively synonyms
for the ISA, but in the JDK we've wound up using them as the names of
two different ports.
A JMOD file built for the 64-bit ARM architecture will (one hopes) run
equally well on either port. Which name should we use in JMOD files,
"arm64" or "aarch64"? My sense is that "arm64" is more immediately
understood by developers at large even if "aarch64" is more correct
in the eyes of ARM Holdings plc, but I could be wrong.
I think that you are wrong.
Post by m***@oracle.com
For what it's worth, the Linux distros aren't consistent: Debian-based
distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64".
The name of the processor architecture is "AArch64". The name of the
Linux kernel architecture is "arm64"; the name of all of userspace is
"aarch64", on all distros. The kernel is out of step here, for no
better reason than Linus Torvalds didn't like "aarch64".

Andrew.
m***@oracle.com
2017-04-04 16:35:57 UTC
Permalink
Post by Andrew Haley
Post by m***@oracle.com
The trouble here is that "arm64" and "aarch64" are effectively synonyms
for the ISA, but in the JDK we've wound up using them as the names of
two different ports.
A JMOD file built for the 64-bit ARM architecture will (one hopes) run
equally well on either port. Which name should we use in JMOD files,
"arm64" or "aarch64"? My sense is that "arm64" is more immediately
understood by developers at large even if "aarch64" is more correct
in the eyes of ARM Holdings plc, but I could be wrong.
I think that you are wrong.
Post by m***@oracle.com
For what it's worth, the Linux distros aren't consistent: Debian-based
distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64".
The name of the processor architecture is "AArch64". The name of the
Linux kernel architecture is "arm64"; the name of all of userspace is
"aarch64", on all distros. The kernel is out of step here, for no
better reason than Linus Torvalds didn't like "aarch64".
Thanks for the background -- I wasn't aware of that.

Given that "os.arch" is "aarch64" for both ports, as Bob points out,
then we should use "aarch64" in JMOD files as well.

This does raise another question, though: Should we use "aarch32"
instead of "arm32" for the 32-bit ARM architecture?

- Mark
Andrew Haley
2017-04-04 16:39:17 UTC
Permalink
Post by m***@oracle.com
This does raise another question, though: Should we use "aarch32"
instead of "arm32" for the 32-bit ARM architecture?
Probably not. I believe that "aarch32" is historical revisionism
coming from ARM: it didn't exist as a name before AArch64 came out.
AFAICR...

Andrew.
Stuart Monteith
2017-04-05 08:37:32 UTC
Permalink
It is historical revisionism. AArch32 was introduced with ARMv8,
before there was no need to distinguish between 32-bit and 64-bit
execution states.
If people are selecting, say, JNI libraries, based on os.arch, then
there is every reason to be consistent.
Post by Andrew Haley
Post by m***@oracle.com
This does raise another question, though: Should we use "aarch32"
instead of "arm32" for the 32-bit ARM architecture?
Probably not. I believe that "aarch32" is historical revisionism
coming from ARM: it didn't exist as a name before AArch64 came out.
AFAICR...
Andrew.
Bob Vandette
2017-04-04 16:47:50 UTC
Permalink
Post by m***@oracle.com
Post by Andrew Haley
Post by m***@oracle.com
The trouble here is that "arm64" and "aarch64" are effectively synonyms
for the ISA, but in the JDK we've wound up using them as the names of
two different ports.
A JMOD file built for the 64-bit ARM architecture will (one hopes) run
equally well on either port. Which name should we use in JMOD files,
"arm64" or "aarch64"? My sense is that "arm64" is more immediately
understood by developers at large even if "aarch64" is more correct
in the eyes of ARM Holdings plc, but I could be wrong.
I think that you are wrong.
Post by m***@oracle.com
For what it's worth, the Linux distros aren't consistent: Debian-based
distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64".
The name of the processor architecture is "AArch64". The name of the
Linux kernel architecture is "arm64"; the name of all of userspace is
"aarch64", on all distros. The kernel is out of step here, for no
better reason than Linus Torvalds didn't like "aarch64".
Thanks for the background -- I wasn't aware of that.
Given that "os.arch" is "aarch64" for both ports, as Bob points out,
then we should use "aarch64" in JMOD files as well.
This does raise another question, though: Should we use "aarch32"
instead of "arm32" for the 32-bit ARM architecture?
32 bit ARM is a bit more challenging since OS vendors sometime encode the
architecture version (armv5, armv6, armv7) and endianess into the uname -p output.

aarch32 has special meaning (it’s the arch for running 32-bit arm instructions on an armv8
processor.) and I haven’t seen any use of arm32.

I suggest we stick with arm.

Bob.
Post by m***@oracle.com
- Mark
Bob Vandette
2017-04-04 16:03:41 UTC
Permalink
Post by m***@oracle.com
Post by Magnus Ihse Bursie
Post by Mandy Chung
...
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm32
aarch64 arm64
If we are making changes to the original proposal from JDK-8175819, then
Why change from the well-established "aarch64" to the virtually unused
"arm64"? As far as I know, using the name "arm64" for the aarch64
platform is something that has only been done in the (recently opened)
closed Oracle port. This change, however, proposes to change the value
in the release file even for the open aarch64 port, which has always
been known by that name.
The trouble here is that "arm64" and "aarch64" are effectively synonyms
for the ISA, but in the JDK we've wound up using them as the names of
two different ports.
Well sort of … We are only using arm64 as a configure option to enable building
the unified ARM32/64 port and a label in Jira to identify which port a bug or RFE is related to.

Both 64-bit ARM ports have been using aarch64 for the os.name property
since day one and I think we should stick to this name in the release file to
avoid any confusion.

Bob.
Post by m***@oracle.com
A JMOD file built for the 64-bit ARM architecture will (one hopes) run
equally well on either port. Which name should we use in JMOD files,
"arm64" or "aarch64"? My sense is that "arm64" is more immediately
understood by developers at large even if "aarch64" is more correct
in the eyes of ARM Holdings plc, but I could be wrong.
For what it's worth, the Linux distros aren't consistent: Debian-based
distros use "arm64", while Red Hat / Fedora seem to prefer "aarch64".
- Mark
Magnus Ihse Bursie
2017-04-06 08:09:20 UTC
Permalink
Post by Magnus Ihse Bursie
Post by Mandy Chung
Post by Simon Nash
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
...
This shows the old and new value of OS_NAME/OS_ARCH properties
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64
I am not sure why we would change to osx for Mac when the Mac developers
have recently dropped the Mac OS X terminology and changed it to macOS.
Agreed -- we should change OS_NAME from "Darwin" to "macos”.
OK. Should the bundle names be updated to reflect this change?
In any case, it is a separate issue.
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm32
aarch64 arm64
Having though this over real hard, I'd realized I need to make a plea
for sanity and consistency. I thought I should lay low in this
discussion, but I can't. Choosing "amd64" as the name for the 64-bit x86
platform is really, really unfortunate and a step backwards in our
effort to standardize the name of this platform.

We have continuously worked on trying to get "x64" the all-around
standard name for this platform. Since we dropped the path "lib/amd64",
I believe more or less the only place left that still has "amd64" is
os.arch, which is not easy to change due to legacy reasons (although I'd
really like to see that changed too, considering that it already is
different on different operating systems...)

I'd really hate for us to suddenly start introducing changes that once
again divert us away. :-( It's hard enough as it is with all this
converting of names. Let us not add yet another odd place!

/Magnus
Post by Magnus Ihse Bursie
If we are making changes to the original proposal from JDK-8175819,
Why change from the well-established "aarch64" to the virtually unused
"arm64"? As far as I know, using the name "arm64" for the aarch64
platform is something that has only been done in the (recently opened)
closed Oracle port. This change, however, proposes to change the value
in the release file even for the open aarch64 port, which has always
been known by that name.
/Magnus
Post by Mandy Chung
Mandy
Mandy Chung
2017-04-07 20:04:40 UTC
Permalink
Having though this over real hard, I'd realized I need to make a plea for sanity and consistency. I thought I should lay low in this discussion, but I can't. Choosing "amd64" as the name for the 64-bit x86 platform is really, really unfortunate and a step backwards in our effort to standardize the name of this platform.
I think it may be useful to see the value of `os.arch` system property on all platforms
at a glance.

32-bit 64-bit

linux i386 amd64
arm aarch64
solaris amd64
sparcv9
windows x86 amd64
macos x86_64

It's late in JDK 9. The best is to revisit OS and architecture names in JDK 10 on the
consistency and simplicity issue. In the context of JDK-8175819, these are names to
pass to jmod —-os-name —-os-arch options. The values are used at resolution time
to avoid linking modules for different target platforms into the same image.

As Mark suggests, we use the value of `os.arch` system property for JMOD file in
JDK 9 and we can change the value in JDK 10. No change to system property and
bundle names, as we said previously.

We should revisit OS and architecture names in JDK 10. I have updated
JDK-8178016 to reflect that. Are you okay with that?

Below shows the old and new values in the `release` file and the new values
are used in JMOD files.

JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows

OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm
aarch64 aarch64

Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.01/index.html

Mandy
Magnus Ihse Bursie
2017-04-11 07:40:07 UTC
Permalink
Post by Mandy Chung
On Apr 6, 2017, at 1:09 AM, Magnus Ihse Bursie
Having though this over real hard, I'd realized I need to make a plea
for sanity and consistency. I thought I should lay low in this
discussion, but I can't. Choosing "amd64" as the name for the 64-bit
x86 platform is really, really unfortunate and a step backwards in
our effort to standardize the name of this platform.
I think it may be useful to see the value of `os.arch` system property on all platforms
at a glance.
32-bit64-bit
linux i386amd64
arm aarch64
solaris amd64
sparcv9
windows x86 amd64
macos x86_64
It's late in JDK 9. The best is to revisit OS and architecture names in JDK 10 on the
consistency and simplicity issue. In the context of JDK-8175819, these are names to
pass tojmod —-os-name —-os-arch options. The values are used at
resolution time
to avoid linking modules for different target platforms into the same image.
As Mark suggests, we use the value of `os.arch` system property for JMOD file in
JDK 9 and we can change the value in JDK 10. No change to system property and
bundle names, as we said previously.
I agree. It's late in JDK 9.

I'm OK with the proposal of using os.arch for JDK 9, as long as when
we're revisiting the issue in JDK 10, we do not use the fact that it was
used in JDK 9 as an argument for not changing it...

/Magnus
Post by Mandy Chung
We should revisit OS and architecture names in JDK 10. I have updated
JDK-8178016 to reflect that. Are you okay with that?
Below shows the old and new values in the `release` file and the new values
are used in JMOD files.
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm
aarch64 aarch64
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.01/index.html
<http://cr.openjdk.java.net/%7Emchung/jdk9/webrevs/8175819/webrev.01/index.html>
Mandy
Erik Joelsson
2017-04-11 10:05:56 UTC
Permalink
Post by Magnus Ihse Bursie
Post by Mandy Chung
On Apr 6, 2017, at 1:09 AM, Magnus Ihse Bursie
Having though this over real hard, I'd realized I need to make a
plea for sanity and consistency. I thought I should lay low in this
discussion, but I can't. Choosing "amd64" as the name for the 64-bit
x86 platform is really, really unfortunate and a step backwards in
our effort to standardize the name of this platform.
I think it may be useful to see the value of `os.arch` system
property on all platforms
at a glance.
32-bit64-bit
linux i386amd64
arm aarch64
solaris amd64
sparcv9
windows x86 amd64
macos x86_64
It's late in JDK 9. The best is to revisit OS and architecture names in JDK 10 on the
consistency and simplicity issue. In the context of JDK-8175819, these are names to
pass tojmod —-os-name —-os-arch options. The values are used at
resolution time
to avoid linking modules for different target platforms into the same image.
As Mark suggests, we use the value of `os.arch` system property for JMOD file in
JDK 9 and we can change the value in JDK 10. No change to system property and
bundle names, as we said previously.
I agree. It's late in JDK 9.
I'm OK with the proposal of using os.arch for JDK 9, as long as when
we're revisiting the issue in JDK 10, we do not use the fact that it
was used in JDK 9 as an argument for not changing it...
+1
/Erik
Post by Magnus Ihse Bursie
/Magnus
Post by Mandy Chung
We should revisit OS and architecture names in JDK 10. I have updated
JDK-8178016 to reflect that. Are you okay with that?
Below shows the old and new values in the `release` file and the new values
are used in JMOD files.
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
sparcv9 sparcv9
arm arm
aarch64 aarch64
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.01/index.html
<http://cr.openjdk.java.net/%7Emchung/jdk9/webrevs/8175819/webrev.01/index.html>
Mandy
Peter Levart
2017-04-11 11:45:20 UTC
Permalink
Hi Mandy,
Post by Mandy Chung
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
i586 (i.e. 32 bit Pentium) should map to x86, not amd64 !!!

Regards, Peter
Post by Mandy Chung
sparcv9 sparcv9
arm arm32
aarch64 arm64
Mandy Chung
2017-04-12 00:33:48 UTC
Permalink
Post by Peter Levart
Hi Mandy,
Post by Mandy Chung
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin macos
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 amd64
i586 (i.e. 32 bit Pentium) should map to x86, not amd64 !!!
Oops… a typo of course (should be removed). “i586” is only used as bundle name. os.arch does not have “i586” value.

Mandy

Alan Bateman
2017-04-04 07:42:06 UTC
Permalink
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
I went through the updates to jlink, assuming test SystemModulesTest
will be aligned to the recent mails.

In DefaultImageBuilder.storeFiles then
map(ResourcePoolModule::osName).orElse(null) would be cleaner.

I'm sure Volker or someone maintaining the AIX port will ask for
jdk.tools.jlink.internal.Platform to be extended to handle that platform.

-Alan.
Mandy Chung
2017-04-04 21:13:42 UTC
Permalink
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
I went through the updates to jlink, assuming test SystemModulesTest will be aligned to the recent mails.
It’s already aligned. I updated webrev.00 in place yesterday. Maybe you need to reload it if you happened opening the old version.
In DefaultImageBuilder.storeFiles then map(ResourcePoolModule::osName).orElse(null) would be cleaner.
OK.
I'm sure Volker or someone maintaining the AIX port will ask for jdk.tools.jlink.internal.Platform to be extended to handle that platform.
I was wondering if Volker would ask that. Anyway, I have added Platform::AIX constant.

Will send out a new webrev.

Mandy
Andrew Dinn
2017-04-04 08:59:56 UTC
Permalink
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
This revisits the OS name and arch in packaging JDK modules
to extend the module descriptor with ModuleTarget class file
attribute. We considered matching with the system properties.
Linux x64 JDK can run on a system whose `os.arch` system
property value can be `amd64` or `i586` or `x86_x64`.
Similiarly, windows x86/x64 JDK can run on a system whose
`os.name` system property starts with “Windows” as the
os.name property is set to "Windows XXX" for example
"Windows Server 2012 R2”. It might be worth considering
multiple OS arch values in ModuleTarget in the future.
JDK bundle names are revised in JDK 9. This is a good
alternative to be consistent with $OS-$ARCH value in
the bundle names. This patch proposes to package JDK modules
with OS name and arch to match the values as in JDK bundle names.
jlink will generate the `release` file and set OS_NAME and
OS_ARCH to those values. This also proposes to drop
OS_VERSION to align with the ModuleTarget class file attribute.
This shows the old and new value of OS_NAME/OS_ARCH properties
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64
arm64 is *not* a correct name for the AArch64 architecture. There is in
fact no arm64 architecture. The latter name has been used to identify
the Oracle-developed port but that fact does not sanction its use for
OS_ARCH.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Erik Joelsson
2017-04-04 09:57:15 UTC
Permalink
Hello,

I don't quite understand this. In the proposition below it says osx, and
x64, but in platform.m4 you generate macos and amd64. Does this then get
translated again and why are we introducing yet another name for the
operating system on Apple computers?

/Erik
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
This revisits the OS name and arch in packaging JDK modules
to extend the module descriptor with ModuleTarget class file
attribute. We considered matching with the system properties.
Linux x64 JDK can run on a system whose `os.arch` system
property value can be `amd64` or `i586` or `x86_x64`.
Similiarly, windows x86/x64 JDK can run on a system whose
`os.name` system property starts with “Windows” as the
os.name property is set to "Windows XXX" for example
"Windows Server 2012 R2”. It might be worth considering
multiple OS arch values in ModuleTarget in the future.
JDK bundle names are revised in JDK 9. This is a good
alternative to be consistent with $OS-$ARCH value in
the bundle names. This patch proposes to package JDK modules
with OS name and arch to match the values as in JDK bundle names.
jlink will generate the `release` file and set OS_NAME and
OS_ARCH to those values. This also proposes to drop
OS_VERSION to align with the ModuleTarget class file attribute.
This shows the old and new value of OS_NAME/OS_ARCH properties
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64
Mandy
Erik Joelsson
2017-04-04 10:13:42 UTC
Permalink
Oh, I missed the further discussion before I posted this and the webrev
was apparently updated in place to reflect that discussion. Please
ignore my comment below.

/Erik
Post by Erik Joelsson
Hello,
I don't quite understand this. In the proposition below it says osx,
and x64, but in platform.m4 you generate macos and amd64. Does this
then get translated again and why are we introducing yet another name
for the operating system on Apple computers?
/Erik
Post by Mandy Chung
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
This revisits the OS name and arch in packaging JDK modules
to extend the module descriptor with ModuleTarget class file
attribute. We considered matching with the system properties.
Linux x64 JDK can run on a system whose `os.arch` system
property value can be `amd64` or `i586` or `x86_x64`.
Similiarly, windows x86/x64 JDK can run on a system whose
`os.name` system property starts with “Windows” as the
os.name property is set to "Windows XXX" for example
"Windows Server 2012 R2”. It might be worth considering
multiple OS arch values in ModuleTarget in the future.
JDK bundle names are revised in JDK 9. This is a good
alternative to be consistent with $OS-$ARCH value in
the bundle names. This patch proposes to package JDK modules
with OS name and arch to match the values as in JDK bundle names.
jlink will generate the `release` file and set OS_NAME and
OS_ARCH to those values. This also proposes to drop
OS_VERSION to align with the ModuleTarget class file attribute.
This shows the old and new value of OS_NAME/OS_ARCH properties
JDK 8 JDK 9
----- -----
OS_NAME Linux linux
SunOS solaris
Darwin osx
Windows windows
OS_ARCH i386,x86 x86
i586,amd64,x86_64 x64
sparcv9 sparcv9
arm arm32
aarch64 arm64
Mandy
Loading...