Please review the integration of tzdata2021e (including tzdata2021d) to the JDK.
The fix has passed all relevant JTREG regression tests and JCK tests.
8275754: (tz) Update Timezone Data to 2021d
8275849: TestZoneInfo310.java fails with tzdata2021e
-
Commit messages:
- 8275754:
On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote:
> Please review the integration of tzdata2021e (including tzdata2021d) to the
> JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests.
>
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java
How reliable would it be to use qemu to run the cross-compiled binaries?
Has anyone tried that recently?
On 10/23/21 5:48 AM, Thomas Stüfe wrote:
Hi Alan,
On Sat, Oct 23, 2021 at 9:58 AM Alan Bateman
wrote:
On 23/10/2021 07:57, Thomas Stüfe wrote:
Hi,
when I crossbuild (for linux
On Thu, 28 Oct 2021 17:01:46 GMT, Magnus Ihse Bursie wrote:
>> Current adhoc version build strings are not ideal. Some of the problems:
>> * A build number of "0" is inserted, which make the version string look
>> like it's an official build, at least when not reading carefully
>> * The
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version string gives little indication on what source code the build
>
On Thu, 28 Oct 2021 13:12:54 GMT, Erik Joelsson wrote:
> The setting of build_number to 0 is done from jib-profiles.js so we can
> definitely change that if we want to differentiate between 0 and empty.
Never mind me, Jib assumed that build-number must have a value and defaults to
0 a long
On Thu, 28 Oct 2021 12:58:35 GMT, Magnus Ihse Bursie wrote:
>> Current adhoc version build strings are not ideal. Some of the problems:
>> * A build number of "0" is inserted, which make the version string look
>> like it's an official build, at least when not reading carefully
>> * The
On Thu, 28 Oct 2021 09:34:07 GMT, Magnus Ihse Bursie wrote:
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version string gives little indication on what source code the build
>
On Thu, 28 Oct 2021 09:48:13 GMT, Aleksey Shipilev wrote:
>> Current adhoc version build strings are not ideal. Some of the problems:
>> * A build number of "0" is inserted, which make the version string look
>> like it's an official build, at least when not reading carefully
>> * The version
On Thu, 28 Oct 2021 09:34:07 GMT, Magnus Ihse Bursie wrote:
> Current adhoc version build strings are not ideal. Some of the problems:
> * A build number of "0" is inserted, which make the version string look like
> it's an official build, at least when not reading carefully
> * The version
Current adhoc version build strings are not ideal. Some of the problems:
* A build number of "0" is inserted, which make the version string look like
it's an official build, at least when not reading carefully
* The version string gives little indication on what source code the build was
based
On Wed, 27 Oct 2021 12:28:16 GMT, Aleksey Shipilev wrote:
> Time to update the devkit to the latest JMH.
>
> Additional testing:
> - [x] Devkit generation works
> - [x] Sample benchmarks run
This pull request has now been integrated.
Changeset: a2f2d8fc
Author:Aleksey Shipilev
URL:
On Wed, 27 Oct 2021 12:28:16 GMT, Aleksey Shipilev wrote:
> Time to update the devkit to the latest JMH.
>
> Additional testing:
> - [x] Devkit generation works
> - [x] Sample benchmarks run
Thanks!
-
PR: https://git.openjdk.java.net/jdk/pull/6139
14 matches
Mail list logo
