On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Thu, 7 Mar 2024 19:53:35 GMT, Andrew John Hughes 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
On Thu, 7 Mar 2024 19:53:35 GMT, Andrew John Hughes 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
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Thu, 7 Mar 2024 17:32:02 GMT, Frederic Thevenet
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
On Thu, 7 Mar 2024 17:07:05 GMT, Magnus Ihse Bursie 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
>
On Thu, 7 Mar 2024 17:11:18 GMT, Magnus Ihse Bursie 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
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Wed, 6 Mar 2024 18:01:00 GMT, Aleksey Shipilev 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
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Wed, 6 Mar 2024 17:17:28 GMT, Magnus Ihse Bursie 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
On Wed, 6 Mar 2024 15:24:59 GMT, Andrew John Hughes 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
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Wed, 6 Mar 2024 13:57:37 GMT, Erik Joelsson 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
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes 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
>
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
22 matches
Mail list logo
