RFR: 8327389: Remove use of HOTSPOT_BUILD_USER

[Andrew John Hughes]

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