From andrew at openjdk.org  Wed Mar  6 12:01:56 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 6 Mar 2024 12:01:56 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
Message-ID: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>

The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284

~~~
$ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
~~~

It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.

In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.

It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.

This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 

With this patch:

~~~
$ ~/builder/23/images/jdk/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826

$ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
<vm crashes>
$ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
~~~

The above are from a fastdebug build but I also built a product build with no issues.

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

Commit messages:
 - 8327389: Remove use of HOTSPOT_BUILD_USER

Changes: https://git.openjdk.org/jdk/pull/18136/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327389
  Stats: 10 lines in 5 files changed: 0 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18136/head:pull/18136

PR: https://git.openjdk.org/jdk/pull/18136

From jwaters at openjdk.org  Wed Mar  6 12:16:46 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 6 Mar 2024 12:16:46 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <68sOoQYqsniLbh3fFnXf85BuvGFDqqPLw0MZWNpCvCo=.683ab03d-c216-4370-a1a7-7097f4c37b00@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

Leaving a comment here as a reminder for myself to come back to this, this intrigues me

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1980739523

From andrew at openjdk.org  Wed Mar  6 13:20:45 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 6 Mar 2024 13:20:45 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <2ag19ZWOvHpgkyZeMDZ8BFhZeaLaAzRR0C5geJo0iao=.4bdb1b20-8fc6-46dd-9d8d-165667802264@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

cross-compile failure is an unrelated risc download issue:
~~~
W: Failure while installing base packages.  This will be re-attempted up to five times.
W: See /home/runner/work/jdk/jdk/sysroot/debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/libssl3t64_3.1.5-1.1_riscv64.deb is at fault)
~~~

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1980856666

From erikj at openjdk.org  Wed Mar  6 13:59:46 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Mar 2024 13:59:46 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <iCh9DTSGQNO9Gzpm9ZthWyoMsXHQulrdWjc6OvZJjdg=.9c45cdfc-db1a-4bb9-85c3-4f6f6e77e0fe@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

I'm fine with this change. I wasn't around when this was introduced, but my guess is that it was relevant back when Hotspot and the rest of the JDK were often built separately. We have the username in the default $OPT string for personal builds, so the HOTSPOT_BUILD_USER is just redundant information. There is no reason to have the build user recorded in non personal builds.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18136#pullrequestreview-1919834395

From andrew at openjdk.org  Wed Mar  6 15:27:45 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 6 Mar 2024 15:27:45 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <iCh9DTSGQNO9Gzpm9ZthWyoMsXHQulrdWjc6OvZJjdg=.9c45cdfc-db1a-4bb9-85c3-4f6f6e77e0fe@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
 <iCh9DTSGQNO9Gzpm9ZthWyoMsXHQulrdWjc6OvZJjdg=.9c45cdfc-db1a-4bb9-85c3-4f6f6e77e0fe@github.com>
Message-ID: <ZAqUd0bLngqgXXOaklQ4bWJO9RkAg-DeWvPorkeclVU=.01513381-d1f0-41fc-b10a-8b88adffe006@github.com>

On Wed, 6 Mar 2024 13:57:37 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I'm fine with this change. I wasn't around when this was introduced, but my guess is that it was relevant back when Hotspot and the rest of the JDK were often built separately. We have the username in the default $OPT string for personal builds, so the HOTSPOT_BUILD_USER is just redundant information. There is no reason to have the build user recorded in non personal builds.

Thanks Erik. I'll leave this open a little longer for others to comment, but I also can't see a reason why this would be needed, especially in non-personal builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1981126634

From ihse at openjdk.org  Wed Mar  6 17:19:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 17:19:47 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <0xgoI47fdqsPHnjiCtHKO72SeGA_PGu3CAgBYZs-gBc=.8d390c92-1642-4dfd-8527-4b4b36715915@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

I agree that it is good to get rid of this. However, the reason it has stuck around for so long is, eh, that it has been around for so long, so it is a bit unclear what or who could be relying on this.

Let's not be too eager to push this, and collect a bit more information about this.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18136#pullrequestreview-1920369274

From ihse at openjdk.org  Wed Mar  6 17:24:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 17:24:49 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <ZAqUd0bLngqgXXOaklQ4bWJO9RkAg-DeWvPorkeclVU=.01513381-d1f0-41fc-b10a-8b88adffe006@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
 <iCh9DTSGQNO9Gzpm9ZthWyoMsXHQulrdWjc6OvZJjdg=.9c45cdfc-db1a-4bb9-85c3-4f6f6e77e0fe@github.com>
 <ZAqUd0bLngqgXXOaklQ4bWJO9RkAg-DeWvPorkeclVU=.01513381-d1f0-41fc-b10a-8b88adffe006@github.com>
Message-ID: <0_NOdLGVPh_j1qEa_VtTcYXqWhFMr4cUD67cL-TQNiI=.87cf982f-e9f4-4929-9a9f-ff3bf82b44dd@github.com>

On Wed, 6 Mar 2024 15:24:59 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> I'm fine with this change. I wasn't around when this was introduced, but my guess is that it was relevant back when Hotspot and the rest of the JDK were often built separately. We have the username in the default $OPT string for personal builds, so the HOTSPOT_BUILD_USER is just redundant information. There is no reason to have the build user recorded in non personal builds.
>
>> I'm fine with this change. I wasn't around when this was introduced, but my guess is that it was relevant back when Hotspot and the rest of the JDK were often built separately. We have the username in the default $OPT string for personal builds, so the HOTSPOT_BUILD_USER is just redundant information. There is no reason to have the build user recorded in non personal builds.
> 
> Thanks Erik. I'll leave this open a little longer for others to comment, but I also can't see a reason why this would be needed, especially in non-personal builds.

@gnu-andrew You might also want to draw specific attention to this change on hotspot-dev, to reach all developers who might know or care about the user name. It is worth making sure to point out that the big change here is that the hotspot version string format changes; that worries me more than the removal of the user name. 

(In fact, a safer change might be to hardcode the user name to a dummy value like `openjdk`).

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1981393909

From ihse at openjdk.org  Wed Mar  6 17:24:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Mar 2024 17:24:50 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <1WzRK8Trhlpv0c_S2vGScX1xG9LBP9KPWg0QDloBjf8=.e3b34f7a-d2e2-40c0-8dd4-f53dc90507f3@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

What testing have you run? I imagine there are tests that check/read the Hotspot version string.

In fact, the more I think about it, the more I believe a better approach is to replace the variable user name with a fixed dummy replacement as a first step. That would only need for verification that nobody really cares about the user name.

Then we can, as a follow up, change the version string (if we really care) -- this has a much higher chance of breakage, and it is not by far as important to solve, so it can easily be dropped if it causes problems.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1981394987

From shade at openjdk.org  Wed Mar  6 18:03:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Mar 2024 18:03:46 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <0xgoI47fdqsPHnjiCtHKO72SeGA_PGu3CAgBYZs-gBc=.8d390c92-1642-4dfd-8527-4b4b36715915@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
 <0xgoI47fdqsPHnjiCtHKO72SeGA_PGu3CAgBYZs-gBc=.8d390c92-1642-4dfd-8527-4b4b36715915@github.com>
Message-ID: <TygWFY3p4c4kmX3EU7OLZvNeZJPFUeHL0f7e4I6F2hQ=.635fb8cf-e393-4719-a92c-ecfd6aa94a30@github.com>

On Wed, 6 Mar 2024 17:17:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I agree that it is good to get rid of this. However, the reason it has stuck around for so long is, eh, that it has been around for so long, so it is a bit unclear what or who could be relying on this.

The example I know is to get a signal that test infrastructures actually picked up my ad-hoc binary build, not some other build from somewhere else. Maybe we should revisit the `git describe` hash idea we kicked along for a while now: https://bugs.openjdk.org/browse/JDK-8274980?focusedId=14452017 -- which would cover that case too.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1981482991

From dholmes at openjdk.org  Thu Mar  7 07:14:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 7 Mar 2024 07:14:54 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <SsMH1EGF_xYWNF8Om6JJ6JPx_CrGCNH5wgEIfS9zM7A=.c1422206-7f71-42e6-a525-429b8941f0c0@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

The internal version is reported in crash reports (hs_err file) as well as via `-Xinternalversion`.

My recollection is that the username was needed/used to identify whether a hs_err report came from an official build, back when official builds were created via a very specific build process and a specific user name. These days it seems redundant given the way the rest of the version string is constructed both for "official" builds and personal builds.

I can't see any tests that look at the output from `-Xinternalversion`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1982679336

From ihse at openjdk.org  Thu Mar  7 17:09:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 7 Mar 2024 17:09:54 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <TygWFY3p4c4kmX3EU7OLZvNeZJPFUeHL0f7e4I6F2hQ=.635fb8cf-e393-4719-a92c-ecfd6aa94a30@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
 <0xgoI47fdqsPHnjiCtHKO72SeGA_PGu3CAgBYZs-gBc=.8d390c92-1642-4dfd-8527-4b4b36715915@github.com>
 <TygWFY3p4c4kmX3EU7OLZvNeZJPFUeHL0f7e4I6F2hQ=.635fb8cf-e393-4719-a92c-ecfd6aa94a30@github.com>
Message-ID: <_VYHW1CbGYLclRcXgqUcbViq_jZ2TygGmv0Woq49zXI=.30df5674-40f9-4264-849c-61ddacb0b7b2@github.com>

On Wed, 6 Mar 2024 18:01:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I agree that it is good to get rid of this. However, the reason it has stuck around for so long is, eh, that it has been around for so long, so it is a bit unclear what or who could be relying on this.
> 
> The example I know is to get a signal that test infrastructures actually picked up my ad-hoc binary build, not some other build from somewhere else. Maybe we should revisit the `git describe` hash idea we kicked along for a while now: https://bugs.openjdk.org/browse/JDK-8274980?focusedId=14452017 -- which would cover that case too.

That bug was resolved with a different patch; presumably it conflated several issues.

There is an inherent conflict with creating a version string that is very much up-to-date and includes ephemeral build data, and creating a robustly reproducible build. If this patch were to remove HOTSPOT_BUILD_USER, and we would later on store `git describe` in the version string, I'm not sure we actually gained anything in terms of reproducability. :-(

As I see it, given this PR, we have a few different options:

1) We can agree that stable and robust reproducibility trumps any automatic inclusion of build situation metadata, and accept this PR and drop the idea of using `git describe`

2) We can agree that reproducibility has its limits, and we need to include (technically irrelevant) metadata in builds to facilitate development. This means dropping this PR since it is used to verify that the correct build was tested, and possibly also adding `git describe` later on.

3) We can agree to disagree about reproducibility limits, but accept that HOTSPOT_BUILD_USER is silly, and accept this PR, but open a separate JBS issue to discuss if adding `git describe` is desirable, and if it can be done in an opt-in manner, with the understanding that it might not be added if we can't agree on it.

4) We can agree to disagree about reproducibility limits, but accept that HOTSPOT_BUILD_USER is silly, and accept this PR, but require that we first implement a substitute functionality using `git describe`, before we can get rid of HOTSPOT_BUILD_USER.

My personal preference would be 3) above, but I am willing to accept any of the paths.

@gnu-andrew and @shipilev, what do you think? I recon you are the one most opinionated about this.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1984021748

From shade at openjdk.org  Thu Mar  7 17:13:56 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Mar 2024 17:13:56 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <q7sI1lxa0x4NDy55E4tuiTan_MSKWfX0N0gCfzgYNvc=.1a53cc05-60c3-4a54-819f-c5ca9481bd3a@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

I am okay with either (3) or (4). That is, I agree `HOTSPOT_BUILD_USER` is silly. I think we can survive without `git describe` thing for a while too.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1984028130

From ihse at openjdk.org  Thu Mar  7 17:13:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 7 Mar 2024 17:13:56 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <PLOkWdXVcpEx_gwT6xMpiQzCJ01KtcnSjQGULWU5Sdg=.ec37a4d1-1a55-4e99-bdde-dc86ea0c9245@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

Also, it might be worth repeating one of my long-standing wishes: that the version string should not be hard-coded into the build, but e.g. stored as a string in the `release` file, and read from there. If we did that, the cost of changing the version string would be negligible, and we wouldn't need to worry as much about it. It would also be simple to compare different builds which end up with the same bits since they are built from the same sources, but by different version flags (e.g. -ea vs GA). (In fact, we'd turn a -ea build into a GA just by updating the version string, so we'd know for sure we are publishing what we tested.)

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1984028842

From fthevenet at openjdk.org  Thu Mar  7 17:34:55 2024
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Thu, 7 Mar 2024 17:34:55 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <PLOkWdXVcpEx_gwT6xMpiQzCJ01KtcnSjQGULWU5Sdg=.ec37a4d1-1a55-4e99-bdde-dc86ea0c9245@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
 <PLOkWdXVcpEx_gwT6xMpiQzCJ01KtcnSjQGULWU5Sdg=.ec37a4d1-1a55-4e99-bdde-dc86ea0c9245@github.com>
Message-ID: <v6ijYY6PUX4_RuWPB_prVlCzlzv5M-MQ64HTOeg2fLI=.8ef0dc56-287c-449c-9233-ffb3f8a76848@github.com>

On Thu, 7 Mar 2024 17:11:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Also, it might be worth repeating one of my long-standing wishes: that the version string should not be hard-coded into the build, but e.g. stored as a string in the `release` file, and read from there. If we did that, the cost of changing the version string would be negligible, and we wouldn't need to worry as much about it. It would also be simple to compare different builds which end up with the same bits since they are built from the same sources, but by different version flags (e.g. -ea vs GA). (In fact, we'd turn a -ea build into a GA just by updating the version string, so we'd know for sure we are publishing what we tested.)

+1
This would be a great step in making comparability (beyond reproducibility) of builds of OpenJDK at lot simpler.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1984065312

From andrew at openjdk.org  Thu Mar  7 19:37:55 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 7 Mar 2024 19:37:55 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <_VYHW1CbGYLclRcXgqUcbViq_jZ2TygGmv0Woq49zXI=.30df5674-40f9-4264-849c-61ddacb0b7b2@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
 <0xgoI47fdqsPHnjiCtHKO72SeGA_PGu3CAgBYZs-gBc=.8d390c92-1642-4dfd-8527-4b4b36715915@github.com>
 <TygWFY3p4c4kmX3EU7OLZvNeZJPFUeHL0f7e4I6F2hQ=.635fb8cf-e393-4719-a92c-ecfd6aa94a30@github.com>
 <_VYHW1CbGYLclRcXgqUcbViq_jZ2TygGmv0Woq49zXI=.30df5674-40f9-4264-849c-61ddacb0b7b2@github.com>
Message-ID: <-NDzF1_xs06l1V1ZhUbWvJtNNolSByasBTwrAiszrtQ=.1550d475-a8a2-4211-b5d3-c18b93f54e5a@github.com>

On Thu, 7 Mar 2024 17:07:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There is an inherent conflict with creating a version string that is very much up-to-date and includes ephemeral build data, and creating a robustly reproducible build. If this patch were to remove HOTSPOT_BUILD_USER, and we would later on store `git describe` in the version string, I'm not sure we actually gained anything in terms of reproducability. :-(

It's worth remembering that there are essentially two potential forms of version string at play; those for "adhoc" builds and those for release builds, which depends on whether `NO_DEFAULT_VERSION_PARTS` ends up being set to `true` or not.

This change does nothing to remove the username used in the "adhoc" version of `--with-version-opt` i.e. `adhoc.$USERNAME.$basedirname`:

>From the patched build:

~~~
$ /home/andrew/builder/23/images/jdk/bin/java -version
openjdk version "23-internal" 2024-09-17
OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.andrew.jdk)
OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.andrew.jdk, mixed mode, sharing)

$ /home/andrew/builder/23/images/jdk/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
~~~

What we aim to get rid of is the duplicate username copy which trickles into the `-Xinternalversion` via `HOTSPOT_BUILD_USER`. From an unpatched build of 22:

~~~
$ /home/andrew/build/openjdk22/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (22.0.1-internal-adhoc.andrew.jdk) for linux-amd64 JRE (22.0.1-internal-adhoc.andrew.jdk), built on 2024-03-05T19:52:35Z by "andrew" with gcc 13.2.1 20230826
~~~

The only difference between the two is my username is there twice, instead of thrice.

The problem with the `HOTSPOT_BUILD_USER` one is that it also turns up when you do a build for release:

~~~
$ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
~~~

Because `NO_DEFAULT_VERSION_PARTS` has been set, the two instances of the username from the adhoc build string are gone. However, the one from `HOTSPOT_BUILD_USER` being set to `mockbuild` still remains.

Regarding the conflict between very accurate version information and reproducibility, it is possible to support both scenarios by having "adhoc" builds provide one and release builds the other. The problem with `HOTSPOT_BUILD_USER` as it stands is it ends up in both.

I don't see an issue with including `git describe` output in adhoc builds. It may well not even be a problem for reproducibility in release builds as they are likely built from a set tag without local changes or even from a bare source tree without repository information at all. It does seem like a separate issue from this PR though.

>     3. We can agree to disagree about reproducibility limits, but accept that HOTSPOT_BUILD_USER is silly, and accept this PR, but open a separate JBS issue to discuss if adding `git describe` is desirable, and if it can be done in an opt-in manner, with the understanding that it might not be added if we can't agree on it.
> 
> 
> My personal preference would be 3) above, but I am willing to accept any of the paths.
> 
> @gnu-andrew and @shipilev, what do you think? I recon you are the one most opinionated about this.

I would go for 3. As I say, I don't see why this change would depend on a `git describe` change. 

Would you still prefer to hardcode a value for `HOTSPOT_BUILD_USER` or remove it altogether? I have a slight preference for the cleanliness of removing it altogether, especially as this is early in the 23 development cycle, so there is some time to see how it pans out.  Alternatively, we can hardcode it to `unknown` (the current default if `HOTSPOT_BUILD_USER is undefined). Not only is this accurate (we don't know who the user was as we haven't recorded the information) but it is already a possible value for compatibility. Changing to this would simply be a matter of removing only the `#ifndef` in `abstract_vm_version.cpp` and leaving the actual version string alone.

Looking further ahead, it would be preferable for us to backport this to 21, as that is where we are trying to achieve comparability between Red Hat & Temurin builds, but there is no rush for that and we could even hardcode it only in the backport.

As regards testing, I have built this in release and fastdebug builds and checked the output where it is used in `-Xinternalversion` and the `vm info` line of a crash dump. Like David, I can't see any tests that pertain to this. The only ones that mention `-Xinternalversion` are `test/hotspot/jtreg/runtime/CommandLine/TestNullTerminatedFlags.java` and `test/hotspot/jtreg/sanity/BasicVMTest.java` and both of those only check the option works, not its output. This seems correct for something that is *internal* version data. To me, relying on a certain structure for this is something I would regard as a bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1984286305

From andrew at openjdk.org  Thu Mar  7 19:55:55 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 7 Mar 2024 19:55:55 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <v6ijYY6PUX4_RuWPB_prVlCzlzv5M-MQ64HTOeg2fLI=.8ef0dc56-287c-449c-9233-ffb3f8a76848@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
 <PLOkWdXVcpEx_gwT6xMpiQzCJ01KtcnSjQGULWU5Sdg=.ec37a4d1-1a55-4e99-bdde-dc86ea0c9245@github.com>
 <v6ijYY6PUX4_RuWPB_prVlCzlzv5M-MQ64HTOeg2fLI=.8ef0dc56-287c-449c-9233-ffb3f8a76848@github.com>
Message-ID: <F-j6Ar1xAfb5rcmTyBXT6olwMU9LlyGIG1ZLkBb2WtE=.b8637241-1091-4699-8148-bf170785afea@github.com>

On Thu, 7 Mar 2024 17:32:02 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> Also, it might be worth repeating one of my long-standing wishes: that the version string should not be hard-coded into the build, but e.g. stored as a string in the `release` file, and read from there. If we did that, the cost of changing the version string would be negligible, and we wouldn't need to worry as much about it. It would also be simple to compare different builds which end up with the same bits since they are built from the same sources, but by different version flags (e.g. -ea vs GA). (In fact, we'd turn a -ea build into a GA just by updating the version string, so we'd know for sure we are publishing what we tested.)

This certainly sounds like it has the potential to solve a lot of these kind of problems. I would point out that, if you can flip the EA status in the text file, someone could also easily masquerade a build as something completely different from what it is. However, it is already possible to create a build like this via the `configure` options so it's really only a slight change in accessibility.

For example, if I specify `--with-version-feature=11`, I can produce:

~~~
$ /home/andrew/builder/fake11/images/jdk/bin/java -version
openjdk version "11-internal" 2024-09-17
OpenJDK Runtime Environment (fastdebug build 11-internal-adhoc.andrew.jdk)
OpenJDK 64-Bit Server VM (fastdebug build 11-internal-adhoc.andrew.jdk, mixed mode, sharing)

$ /home/andrew/builder/fake11/images/jdk/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (fastdebug 11-internal-adhoc.andrew.jdk) for linux-amd64 JRE (11-internal-adhoc.andrew.jdk), built on 2024-03-07T19:41:08Z with gcc 13.2.1 20230826
~~~

despite the fact that the source code I've built is actually an in-development JDK 23.  All we'd be doing is moving that into a text file.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1984317603

From erikj at openjdk.org  Thu Mar  7 20:50:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Mar 2024 20:50:54 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <IDjqw-_2AiYTziydVoL4LjviGacog80RrHSI1ldBKHY=.5fb6460e-3062-42c9-bc04-e22524cdf7c2@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

I agree with Andrew. We aren't removing the username from adhoc builds, just the copy in the hotspot internal version string, so the concern about that part seems baseless to me. I don't see the connection to the `git describe` discussion, I think that should move to a separate thread. I definitely don't think we need to add a fake HOTSPOT_BUILD_USER to the _internal_ hotspot version string. Lets just get rid of it by accepting this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1984415570

From jwaters at openjdk.org  Fri Mar  8 06:03:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 8 Mar 2024 06:03:55 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <F-j6Ar1xAfb5rcmTyBXT6olwMU9LlyGIG1ZLkBb2WtE=.b8637241-1091-4699-8148-bf170785afea@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
 <PLOkWdXVcpEx_gwT6xMpiQzCJ01KtcnSjQGULWU5Sdg=.ec37a4d1-1a55-4e99-bdde-dc86ea0c9245@github.com>
 <v6ijYY6PUX4_RuWPB_prVlCzlzv5M-MQ64HTOeg2fLI=.8ef0dc56-287c-449c-9233-ffb3f8a76848@github.com>
 <F-j6Ar1xAfb5rcmTyBXT6olwMU9LlyGIG1ZLkBb2WtE=.b8637241-1091-4699-8148-bf170785afea@github.com>
Message-ID: <R5ZUPaRXWyqhNHwRw_Ojfw5osXJ5B9hlx-MKESAjfa4=.9e29a165-01d5-4ca4-8b40-fed92162d2f8@github.com>

On Thu, 7 Mar 2024 19:53:35 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Also, it might be worth repeating one of my long-standing wishes: that the version string should not be hard-coded into the build, but e.g. stored as a string in the `release` file, and read from there. If we did that, the cost of changing the version string would be negligible, and we wouldn't need to worry as much about it. It would also be simple to compare different builds which end up with the same bits since they are built from the same sources, but by different version flags (e.g. -ea vs GA). (In fact, we'd turn a -ea build into a GA just by updating the version string, so we'd know for sure we are publishing what we tested.)

Why not store the version string inside HotSpot, and have it as the one source of truth for the version string so it doesn't need to be hardcoded in other places? A text file seems too easy to modify to set the version string to a rubbish value

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1985087876

From fthevenet at openjdk.org  Fri Mar  8 10:43:54 2024
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Fri, 8 Mar 2024 10:43:54 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <F-j6Ar1xAfb5rcmTyBXT6olwMU9LlyGIG1ZLkBb2WtE=.b8637241-1091-4699-8148-bf170785afea@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
 <PLOkWdXVcpEx_gwT6xMpiQzCJ01KtcnSjQGULWU5Sdg=.ec37a4d1-1a55-4e99-bdde-dc86ea0c9245@github.com>
 <v6ijYY6PUX4_RuWPB_prVlCzlzv5M-MQ64HTOeg2fLI=.8ef0dc56-287c-449c-9233-ffb3f8a76848@github.com>
 <F-j6Ar1xAfb5rcmTyBXT6olwMU9LlyGIG1ZLkBb2WtE=.b8637241-1091-4699-8148-bf170785afea@github.com>
Message-ID: <FBJYNpp9e6LBrD5U96Z75DPhp4byoE61Yy4V7Lrzw-8=.df9b33b8-2f9d-4eb4-a36c-f6ccd7a6b652@github.com>

On Thu, 7 Mar 2024 19:53:35 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>>> Also, it might be worth repeating one of my long-standing wishes: that the version string should not be hard-coded into the build, but e.g. stored as a string in the `release` file, and read from there. If we did that, the cost of changing the version string would be negligible, and we wouldn't need to worry as much about it. It would also be simple to compare different builds which end up with the same bits since they are built from the same sources, but by different version flags (e.g. -ea vs GA). (In fact, we'd turn a -ea build into a GA just by updating the version string, so we'd know for sure we are publishing what we tested.)
>> 
>> +1
>> This would be a great step in making comparability (beyond reproducibility) of builds of OpenJDK at lot simpler.
>
>> Also, it might be worth repeating one of my long-standing wishes: that the version string should not be hard-coded into the build, but e.g. stored as a string in the `release` file, and read from there. If we did that, the cost of changing the version string would be negligible, and we wouldn't need to worry as much about it. It would also be simple to compare different builds which end up with the same bits since they are built from the same sources, but by different version flags (e.g. -ea vs GA). (In fact, we'd turn a -ea build into a GA just by updating the version string, so we'd know for sure we are publishing what we tested.)
> 
> This certainly sounds like it has the potential to solve a lot of these kind of problems. I would point out that, if you can flip the EA status in the text file, someone could also easily masquerade a build as something completely different from what it is. However, it is already possible to create a build like this via the `configure` options so it's really only a slight change in accessibility.
> 
> For example, if I specify `--with-version-feature=11`, I can produce:
> 
> ~~~
> $ /home/andrew/builder/fake11/images/jdk/bin/java -version
> openjdk version "11-internal" 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 11-internal-adhoc.andrew.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 11-internal-adhoc.andrew.jdk, mixed mode, sharing)
> 
> $ /home/andrew/builder/fake11/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 11-internal-adhoc.andrew.jdk) for linux-amd64 JRE (11-internal-adhoc.andrew.jdk), built on 2024-03-07T19:41:08Z with gcc 13.2.1 20230826
> ~~~
> 
> despite the fact that the source code I've built is actually an in-development JDK 23.  All we'd be doing is moving that into a text file.

I agree with @gnu-andrew : the version string reported by the JVM, as it stands today, is only really useful if taken in good faith.
If we wanted - or needed - to make it temper-proof from an adversarial threat model standpoint, then we couldn't spare the need for a cryptographically strong solution (which by design would render any direct comparison impossible). 
Right now, it feels like we are kind of stuck somewhere in-between, incurring all of the drawbacks and none of the benefits.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1985459372

From ihse at openjdk.org  Fri Mar  8 16:06:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 16:06:59 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <GTy6VG6zLJ_iVFdnmz21fUUK8pBlUlm6QNioMXfufSM=.f5bfe6c3-5203-4a17-b501-20d0e6d2c80a@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18136#pullrequestreview-1925213033

From ihse at openjdk.org  Fri Mar  8 16:09:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Mar 2024 16:09:53 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <kMd1kfRuYIgQYWaEHdY-Sv1rnZiWhHmRvGNW-vJHdv0=.d267d267-a452-4db1-9211-bd6cf0f5a35b@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

This bug spurred several interesting discussions:

1) Should we store the version string in a text file instead of compiling it into a binary library?

2) Should we store `git describe` information in the version string?

I think both are worth discussing (and likely worth implementing, too), but it also seems out of scope for this PR.

My main concern here was that tests were looking at the internal string format, but if that is not the case then I see no reason to keep a dummy "unknown" value -- better to get rid of it entirely. 

So I'd say, just go ahead and integrate this.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1985965596

From andrew at openjdk.org  Sat Mar  9 13:32:58 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 9 Mar 2024 13:32:58 GMT
Subject: RFR: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <istzGkEDoiBbyyQ4AxJlTSXeG38R3l0wyDVl5_YIQwU=.7062ab7b-b25e-4e95-939f-52eed9b57b21@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

Thanks all for the interesting discussion. Integrating this change now.

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

PR Comment: https://git.openjdk.org/jdk/pull/18136#issuecomment-1986857857

From andrew at openjdk.org  Sat Mar  9 13:32:58 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 9 Mar 2024 13:32:58 GMT
Subject: Integrated: 8327389: Remove use of HOTSPOT_BUILD_USER
In-Reply-To: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
References: <bWfb0FMB7NywkN2NkcS2P1eqpy6t4KkIdM1IS_gFMaA=.b305a34f-55d2-4605-8d85-42ca36d5fe7e@github.com>
Message-ID: <Y2A40UgoImclWyVt5sLuXnmvvCD4O7b1PixDxQ0HdgY=.443ebe85-7864-4128-a026-ae8c698a4cad@github.com>

On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the internal version string since before the JDK was open-sourced, so the reasoning for this is not in the public history. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
> 
> ~~~
> $ /usr/lib/jvm/java-21-openjdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (21.0.2+13) for linux-amd64 JRE (21.0.2+13), built on 2024-01-19T16:39:52Z by "mockbuild" with gcc 8.5.0 20210514 (Red Hat 8.5.0-20)
> ~~~
> 
> It is not clear what value this provides. By default, the value is set to the system username, but it can be set to a static value using `--with-build-user`.
> 
> In trying to compare builds, this is a source of difference if the builds are produced under different usernames and `--with-build-user` is not set to the same value.
> 
> It may also be a source of information leakage from the host system. It is not clear what value it provides to the end user of the build.
> 
> This patch proposes removing it altogether, but at least knowing why it needs to be there would be progress from where we are now. We could also consider a middle ground of only setting it for "adhoc" builds, those without set version information, as is the case with the overall version output. 
> 
> With this patch:
> 
> ~~~
> $ ~/builder/23/images/jdk/bin/java -Xinternalversion
> OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> 
> $ ~/builder/23/images/jdk/bin/java -XX:ErrorHandlerTest=1
> <vm crashes>
> $ grep '^vm_info' /localhome/andrew/projects/openjdk/upstream/jdk/hs_err_pid1119824.log
> vm_info: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.andrew.jdk) for linux-amd64 JRE (23-internal-adhoc.andrew.jdk), built on 2024-03-06T00:23:37Z with gcc 13.2.1 20230826
> ~~~
> 
> The above are from a fastdebug build but I also built a product build with no issues.

This pull request has now been integrated.

Changeset: 243cb098
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/243cb098d48741e9bd6308ef7609c9a4637a5e07
Stats:     10 lines in 5 files changed: 0 ins; 8 del; 2 mod

8327389: Remove use of HOTSPOT_BUILD_USER

Reviewed-by: erikj, ihse

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

PR: https://git.openjdk.org/jdk/pull/18136

From jwaters at openjdk.org  Fri Mar 15 07:15:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Mar 2024 07:15:55 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v3]
In-Reply-To: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
Message-ID: <i1JQliVazZyKqRhEfUTV_DOhqTpm7E_pDcT4OrjEN5s=.b330355f-2c56-4772-af0c-ee4c445b01a7@github.com>

> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-15
 - Refresh documentation
 - Remove Shared Workspaces entirely
 - Remove shared targets
 - 8326964

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18046/files
  - new: https://git.openjdk.org/jdk/pull/18046/files/0d29a355..46dee2b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18046&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18046&range=01-02

  Stats: 101532 lines in 2067 files changed: 16945 ins; 79335 del; 5252 mod
  Patch: https://git.openjdk.org/jdk/pull/18046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18046/head:pull/18046

PR: https://git.openjdk.org/jdk/pull/18046

From jwaters at openjdk.org  Fri Mar 15 07:15:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Mar 2024 07:15:55 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v2]
In-Reply-To: <TgAWzSJQjhuVkzSxqd3VYKrHdpArOO4LvZMU3nwbaws=.25893aac-970c-480c-9339-776f4862a7c0@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <TgAWzSJQjhuVkzSxqd3VYKrHdpArOO4LvZMU3nwbaws=.25893aac-970c-480c-9339-776f4862a7c0@github.com>
Message-ID: <eq60NPOLsbSf68HALTUHn328VJEgvMdOTaFQDbYI2FM=.a58e6cae-d381-4f52-940b-7b2ae95b3186@github.com>

On Wed, 28 Feb 2024 15:19:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove shared targets

This should be ready for review now

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

PR Comment: https://git.openjdk.org/jdk/pull/18046#issuecomment-1999062238

From erikj at openjdk.org  Fri Mar 15 12:46:39 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 15 Mar 2024 12:46:39 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v3]
In-Reply-To: <i1JQliVazZyKqRhEfUTV_DOhqTpm7E_pDcT4OrjEN5s=.b330355f-2c56-4772-af0c-ee4c445b01a7@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <i1JQliVazZyKqRhEfUTV_DOhqTpm7E_pDcT4OrjEN5s=.b330355f-2c56-4772-af0c-ee4c445b01a7@github.com>
Message-ID: <NEMuXQ4j1UCPTn4Y9KZLLG1UAhCwpaoOyrXcR7ZDqyk=.ede2ba82-c173-406c-ab85-b3c1104e0b87@github.com>

On Fri, 15 Mar 2024 07:15:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-15
>  - Refresh documentation
>  - Remove Shared Workspaces entirely
>  - Remove shared targets
>  - 8326964

make/ide/eclipse/CreateWorkspace.gmk line 192:

> 190:     # make dist-clean omitted since it would delete the Workspace as well
> 191:     # $1_PLAIN_MAKE_TARGETS += reconfigure
> 192:     # $1_PLAIN_MAKE_TARGETS += dist-clean

Why leave these additions commented out and not just remove them? If you think the comment is important, you can just put it above the PLAIN_MAKE_TARGETS definition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18046#discussion_r1526233930

From jwaters at openjdk.org  Fri Mar 15 13:17:26 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Mar 2024 13:17:26 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v3]
In-Reply-To: <NEMuXQ4j1UCPTn4Y9KZLLG1UAhCwpaoOyrXcR7ZDqyk=.ede2ba82-c173-406c-ab85-b3c1104e0b87@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <i1JQliVazZyKqRhEfUTV_DOhqTpm7E_pDcT4OrjEN5s=.b330355f-2c56-4772-af0c-ee4c445b01a7@github.com>
 <NEMuXQ4j1UCPTn4Y9KZLLG1UAhCwpaoOyrXcR7ZDqyk=.ede2ba82-c173-406c-ab85-b3c1104e0b87@github.com>
Message-ID: <WvYSBErp3SJwjTx9fyGeaSJhqAUgqevVL1iF9x5BDMw=.ad3c1d5a-a776-4f51-b8e9-5338c875c7e2@github.com>

On Fri, 15 Mar 2024 12:42:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-15
>>  - Refresh documentation
>>  - Remove Shared Workspaces entirely
>>  - Remove shared targets
>>  - 8326964
>
> make/ide/eclipse/CreateWorkspace.gmk line 192:
> 
>> 190:     # make dist-clean omitted since it would delete the Workspace as well
>> 191:     # $1_PLAIN_MAKE_TARGETS += reconfigure
>> 192:     # $1_PLAIN_MAKE_TARGETS += dist-clean
> 
> Why leave these additions commented out and not just remove them? If you think the comment is important, you can just put it above the PLAIN_MAKE_TARGETS definition.

Fair point, I'll address this now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18046#discussion_r1526271085

From jwaters at openjdk.org  Fri Mar 15 13:17:24 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Mar 2024 13:17:24 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v4]
In-Reply-To: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
Message-ID: <ro5lmoRMKG4hh82YaGpNSVKpHANg_M88qegBB-QixvA=.cd68e30d-61ee-49a0-9744-303b74d9bd18@github.com>

> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments in CreateWorkspace.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18046/files
  - new: https://git.openjdk.org/jdk/pull/18046/files/46dee2b7..212fc3c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18046&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18046&range=02-03

  Stats: 7 lines in 1 file changed: 2 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/18046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18046/head:pull/18046

PR: https://git.openjdk.org/jdk/pull/18046

From erikj at openjdk.org  Fri Mar 15 15:47:31 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 15 Mar 2024 15:47:31 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v4]
In-Reply-To: <ro5lmoRMKG4hh82YaGpNSVKpHANg_M88qegBB-QixvA=.cd68e30d-61ee-49a0-9744-303b74d9bd18@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <ro5lmoRMKG4hh82YaGpNSVKpHANg_M88qegBB-QixvA=.cd68e30d-61ee-49a0-9744-303b74d9bd18@github.com>
Message-ID: <Nf6wK4bifzG6aaCgnJclPQnXQNOqE-Lmvq2MVSKcUY0=.d480aaca-a986-4772-9aeb-4e6052076864@github.com>

On Fri, 15 Mar 2024 13:17:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments in CreateWorkspace.gmk

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18046#pullrequestreview-1939277862

From jwaters at openjdk.org  Sat Mar 16 22:20:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 16 Mar 2024 22:20:53 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]
In-Reply-To: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
Message-ID: <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>

> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Remove SHARED definition in Main.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18046/files
  - new: https://git.openjdk.org/jdk/pull/18046/files/212fc3c1..4287082a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18046&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18046&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18046/head:pull/18046

PR: https://git.openjdk.org/jdk/pull/18046

From jwaters at openjdk.org  Sat Mar 16 22:21:18 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 16 Mar 2024 22:21:18 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v4]
In-Reply-To: <Nf6wK4bifzG6aaCgnJclPQnXQNOqE-Lmvq2MVSKcUY0=.d480aaca-a986-4772-9aeb-4e6052076864@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <ro5lmoRMKG4hh82YaGpNSVKpHANg_M88qegBB-QixvA=.cd68e30d-61ee-49a0-9744-303b74d9bd18@github.com>
 <Nf6wK4bifzG6aaCgnJclPQnXQNOqE-Lmvq2MVSKcUY0=.d480aaca-a986-4772-9aeb-4e6052076864@github.com>
Message-ID: <3f1iFVpzVPEQrtuzGWWYrrtKfOmyxjqPhVX5mcLw_lM=.fe5dfcaa-63cf-4a3d-b7d6-0589407644e7@github.com>

On Fri, 15 Mar 2024 15:44:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments in CreateWorkspace.gmk
>
> Marked as reviewed by erikj (Reviewer).

@erikj79 Sorry it seems I forgot to remove the SHARED definition from the Makefile, could I get a re-review? Thanks
@magicus Also waiting for your approval

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

PR Comment: https://git.openjdk.org/jdk/pull/18046#issuecomment-2001849914

From ihse at openjdk.org  Mon Mar 18 09:12:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Mar 2024 09:12:29 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]
In-Reply-To: <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
Message-ID: <R9L20dFPq6nAt3SwcTpsHb6WVqJG3t_bJYGZWC29vEk=.1a5d4c90-bafc-466b-b315-16070ba8cdb3@github.com>

On Sat, 16 Mar 2024 22:20:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove SHARED definition in Main.gmk

Except for the .gitignore part, this looks good to me.

.gitignore line 22:

> 20: /.settings/
> 21: /.project
> 22: /.classpath

`.project` is repeated so that is fine to remove, but why are you removing the other two? `.cproject` sounds like it could come from CDT.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18046#pullrequestreview-1942337344
PR Review Comment: https://git.openjdk.org/jdk/pull/18046#discussion_r1528125183

From jwaters at openjdk.org  Mon Mar 18 09:21:30 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 18 Mar 2024 09:21:30 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]
In-Reply-To: <R9L20dFPq6nAt3SwcTpsHb6WVqJG3t_bJYGZWC29vEk=.1a5d4c90-bafc-466b-b315-16070ba8cdb3@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
 <R9L20dFPq6nAt3SwcTpsHb6WVqJG3t_bJYGZWC29vEk=.1a5d4c90-bafc-466b-b315-16070ba8cdb3@github.com>
Message-ID: <EluyGA3tCM_UPMAFm1gOaru8jvSnJeO3EEffzGLGv5M=.ab4c0be7-9fb8-4e6f-807e-c54953be2ac9@github.com>

On Mon, 18 Mar 2024 09:07:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove SHARED definition in Main.gmk
>
> .gitignore line 22:
> 
>> 20: /.settings/
>> 21: /.project
>> 22: /.classpath
> 
> `.project` is repeated so that is fine to remove, but why are you removing the other two? `.cproject` sounds like it could come from CDT.

With the Shared Workspaces removed, the Workspace created no longer exists in the JDK's top level source directory. This means the .gitignore entries are now obsolete, and can be removed, since they only ignore .cproject and .classpath in the top level source directory. They were added way back when I introduced support for Eclipse, and was less familiar with how multiple different JDK builds are contained

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18046#discussion_r1528154027

From jwaters at openjdk.org  Mon Mar 18 09:24:34 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 18 Mar 2024 09:24:34 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]
In-Reply-To: <EluyGA3tCM_UPMAFm1gOaru8jvSnJeO3EEffzGLGv5M=.ab4c0be7-9fb8-4e6f-807e-c54953be2ac9@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
 <R9L20dFPq6nAt3SwcTpsHb6WVqJG3t_bJYGZWC29vEk=.1a5d4c90-bafc-466b-b315-16070ba8cdb3@github.com>
 <EluyGA3tCM_UPMAFm1gOaru8jvSnJeO3EEffzGLGv5M=.ab4c0be7-9fb8-4e6f-807e-c54953be2ac9@github.com>
Message-ID: <-8QXyIQY_sk0KyMWB_I2FC_D0cFBriCz9LBsFKoL1sE=.11df7366-9428-4502-9faa-126ee07db2a6@github.com>

On Mon, 18 Mar 2024 09:18:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> .gitignore line 22:
>> 
>>> 20: /.settings/
>>> 21: /.project
>>> 22: /.classpath
>> 
>> `.project` is repeated so that is fine to remove, but why are you removing the other two? `.cproject` sounds like it could come from CDT.
>
> With the Shared Workspaces removed, the Workspace created no longer exists in the JDK's top level source directory. This means the .gitignore entries are now obsolete, and can be removed, since they only ignore .cproject and .classpath in the top level source directory. They were added way back when I introduced support for Eclipse, and was less familiar with how multiple different JDK builds are contained

Side tangent: How are the Workspaces for the other IDEs set up? Are they contained entirely in the ide subdirectory in the build directory or do they end up leaving their metadata in the top level directory like the Shared Workspaces used to do? I plan to improve Eclipse support over time, and these details might potentially be important to that effort

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18046#discussion_r1528161453

From ihse at openjdk.org  Mon Mar 18 10:09:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Mar 2024 10:09:28 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]
In-Reply-To: <-8QXyIQY_sk0KyMWB_I2FC_D0cFBriCz9LBsFKoL1sE=.11df7366-9428-4502-9faa-126ee07db2a6@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
 <R9L20dFPq6nAt3SwcTpsHb6WVqJG3t_bJYGZWC29vEk=.1a5d4c90-bafc-466b-b315-16070ba8cdb3@github.com>
 <EluyGA3tCM_UPMAFm1gOaru8jvSnJeO3EEffzGLGv5M=.ab4c0be7-9fb8-4e6f-807e-c54953be2ac9@github.com>
 <-8QXyIQY_sk0KyMWB_I2FC_D0cFBriCz9LBsFKoL1sE=.11df7366-9428-4502-9faa-126ee07db2a6@github.com>
Message-ID: <rhZ4k-_L8GM3DGT4AwLpAcmj_lH3lmNLNQ3uXgAX414=.0e18bc89-41a4-4ed4-93df-edd2a54cb0fe@github.com>

On Mon, 18 Mar 2024 09:21:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> With the Shared Workspaces removed, the Workspace created no longer exists in the JDK's top level source directory. This means the .gitignore entries are now obsolete, and can be removed, since they only ignore .cproject and .classpath in the top level source directory. They were added way back when I introduced support for Eclipse, and was less familiar with how multiple different JDK builds are contained
>
> Side tangent: How are the Workspaces for the other IDEs set up? Are they contained entirely in the ide subdirectory in the build directory or do they end up leaving their metadata in the top level directory like the Shared Workspaces used to do? I plan to improve Eclipse support over time, and these details might potentially be important to that effort

Ok, it's fine for integration then.

As for other IDEs: there is very little coordination on this; most IDE integrations are like barely kept alive by some enthusiast. I would really love to see some better grip on this, unifying IDE support and making it more of a first-class citizen of the build, but this has unfortunately kept being pushed down the prio list. :-(

If you feel so inclined, please try out the different IDEs supported. The very first step, I believe, is to have proper documentation in docs/ide.md. Even if we have a process that requires several manual steps, it is better to have it formalized and documented in a single place. Then it can form the basis for a more automated approach.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18046#discussion_r1528246098

From jwaters at openjdk.org  Mon Mar 18 12:48:28 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 18 Mar 2024 12:48:28 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]
In-Reply-To: <rhZ4k-_L8GM3DGT4AwLpAcmj_lH3lmNLNQ3uXgAX414=.0e18bc89-41a4-4ed4-93df-edd2a54cb0fe@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
 <R9L20dFPq6nAt3SwcTpsHb6WVqJG3t_bJYGZWC29vEk=.1a5d4c90-bafc-466b-b315-16070ba8cdb3@github.com>
 <EluyGA3tCM_UPMAFm1gOaru8jvSnJeO3EEffzGLGv5M=.ab4c0be7-9fb8-4e6f-807e-c54953be2ac9@github.com>
 <-8QXyIQY_sk0KyMWB_I2FC_D0cFBriCz9LBsFKoL1sE=.11df7366-9428-4502-9faa-126ee07db2a6@github.com>
 <rhZ4k-_L8GM3DGT4AwLpAcmj_lH3lmNLNQ3uXgAX414=.0e18bc89-41a4-4ed4-93df-edd2a54cb0fe@github.com>
Message-ID: <dGepRWcYymI9BYDrnHwMyCcn0XLOBQq8HExKM2At74Y=.e7a42a77-4242-4e5c-8c86-1366c3be10b4@github.com>

On Mon, 18 Mar 2024 10:06:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Side tangent: How are the Workspaces for the other IDEs set up? Are they contained entirely in the ide subdirectory in the build directory or do they end up leaving their metadata in the top level directory like the Shared Workspaces used to do? I plan to improve Eclipse support over time, and these details might potentially be important to that effort
>
> Ok, it's fine for integration then.
> 
> As for other IDEs: there is very little coordination on this; most IDE integrations are like barely kept alive by some enthusiast. I would really love to see some better grip on this, unifying IDE support and making it more of a first-class citizen of the build, but this has unfortunately kept being pushed down the prio list. :-(
> 
> If you feel so inclined, please try out the different IDEs supported. The very first step, I believe, is to have proper documentation in docs/ide.md. Even if we have a process that requires several manual steps, it is better to have it formalized and documented in a single place. Then it can form the basis for a more automated approach.

Sorry I think I may not understand what you mean by unifying IDE support "and making it more of a first class citizen of the build", do you mean a central Setup IDE function in make of some sort, much like SetupNativeCompilation? I don't see how that might be possible given how each IDE has wildly varying requirements and save data formats

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18046#discussion_r1528469422

From erikj at openjdk.org  Mon Mar 18 13:19:29 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 18 Mar 2024 13:19:29 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]
In-Reply-To: <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
Message-ID: <pox6Rm8HUKwN74_TnQ--eqfj4dN6I2u7I75rXL7bpoc=.b84ac855-2776-4c69-b91d-b07165979f38@github.com>

On Sat, 16 Mar 2024 22:20:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove SHARED definition in Main.gmk

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18046#pullrequestreview-1942934758

From ihse at openjdk.org  Mon Mar 18 16:01:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Mar 2024 16:01:29 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]
In-Reply-To: <dGepRWcYymI9BYDrnHwMyCcn0XLOBQq8HExKM2At74Y=.e7a42a77-4242-4e5c-8c86-1366c3be10b4@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
 <R9L20dFPq6nAt3SwcTpsHb6WVqJG3t_bJYGZWC29vEk=.1a5d4c90-bafc-466b-b315-16070ba8cdb3@github.com>
 <EluyGA3tCM_UPMAFm1gOaru8jvSnJeO3EEffzGLGv5M=.ab4c0be7-9fb8-4e6f-807e-c54953be2ac9@github.com>
 <-8QXyIQY_sk0KyMWB_I2FC_D0cFBriCz9LBsFKoL1sE=.11df7366-9428-4502-9faa-126ee07db2a6@github.com>
 <rhZ4k-_L8GM3DGT4AwLpAcmj_lH3lmNLNQ3uXgAX414=.0e18bc89-41a4-4ed4-93df-edd2a54cb0fe@github.com>
 <dGepRWcYymI9BYDrnHwMyCcn0XLOBQq8HExKM2At74Y=.e7a42a77-4242-4e5c-8c86-1366c3be10b4@github.com>
Message-ID: <V1q7JSvdfvEbjrBYIH26-90L__kmZP_cuV9928S1DLE=.fcd99acc-5ef9-46c9-99cf-be6fff9efa03@github.com>

On Mon, 18 Mar 2024 12:45:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Ok, it's fine for integration then.
>> 
>> As for other IDEs: there is very little coordination on this; most IDE integrations are like barely kept alive by some enthusiast. I would really love to see some better grip on this, unifying IDE support and making it more of a first-class citizen of the build, but this has unfortunately kept being pushed down the prio list. :-(
>> 
>> If you feel so inclined, please try out the different IDEs supported. The very first step, I believe, is to have proper documentation in docs/ide.md. Even if we have a process that requires several manual steps, it is better to have it formalized and documented in a single place. Then it can form the basis for a more automated approach.
>
> Sorry I think I may not understand what you mean by unifying IDE support "and making it more of a first class citizen of the build", do you mean a central Setup IDE function in make of some sort, much like SetupNativeCompilation? I don't see how that might be possible given how each IDE has wildly varying requirements and save data formats

I think the most confusing part is how different all IDE setup procedures are. The unification I'd like to see is rather like `make ide-setup IDE=vscode AREA=hotspot,jdk` or something like that. That is, a clear and easy to understand way for the user to call a make target to create an environment for their IDE of choice. I realize that the actual implementation will be very varying for different IDEs, but I also think many share similar parts (like creating e.g. an xml file describing the project), and that there certainly are room for even some unification in that part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18046#discussion_r1528837809

From jwaters at openjdk.org  Tue Mar 19 06:30:27 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 19 Mar 2024 06:30:27 GMT
Subject: RFR: 8326964: Remove Eclipse Shared Workspaces [v5]
In-Reply-To: <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
 <PexK9U2nYXOQLxlC2ZXeHSeVhoBvVPKAOB9FkVhntk4=.8a2fc34f-31fe-47a1-9c12-6b965eb2987d@github.com>
Message-ID: <HYzLfwB4W-AZAgsoULIFC6kr8m8wPZKUlMbkz_Qc0tA=.1b546b15-9240-40df-823b-71d27a868f29@github.com>

On Sat, 16 Mar 2024 22:20:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove SHARED definition in Main.gmk

Thanks Erik and Magnus for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/18046#issuecomment-2005907236

From jwaters at openjdk.org  Tue Mar 19 06:30:28 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 19 Mar 2024 06:30:28 GMT
Subject: Integrated: 8326964: Remove Eclipse Shared Workspaces
In-Reply-To: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
References: <rOJhLEi2OVRreCl6maVUQXAUG5dF1g_ad2N-_rT2Myk=.8cc1d080-544c-4ced-956c-e62939da1e6a@github.com>
Message-ID: <m0SW_ZLAvBqIrNgzMspxVu-MHw-wW-eyRThyRBxFA6M=.d40089de-204c-4b68-83bb-4b25953bc7b9@github.com>

On Wed, 28 Feb 2024 15:07:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Eclipse Shared Workspaces share the same directory as the JDK itself, which does not make much sense since there can be multiple different configurations of the JDK which Eclipse does depend on (as minimalistic as it is), and there is no one true JDK configuration, unlike what this setting suggests. This feature was created when I was much less familiar with the structure of how the JDK handles different builds, and should be removed

This pull request has now been integrated.

Changeset: 4ef591f7
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ef591f71f62ee6ea8a603ed7a3e568b348b2c16
Stats:     120 lines in 5 files changed: 1 ins; 75 del; 44 mod

8326964: Remove Eclipse Shared Workspaces

Reviewed-by: erikj, ihse

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

PR: https://git.openjdk.org/jdk/pull/18046