Hello Stuart,
On 08/09/21 6:49 am, Stuart Marks wrote:
On 9/7/21 8:27 AM, Jaikiran Pai wrote:
On 07/09/21 8:35 pm, Roger Riggs wrote:
Though java.util.Date is used in the current implementation, its use
is discouraged in new code
in favor of java.time.ZonedDateTime.
Consider if
On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan
wrote:
> Fix the copyright header of SVML files to match others.
>
> This was brought up on jdk-dev mailing list:
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
Marked as reviewed by psandoz (Reviewer).
Hello Robert,
On 07/09/21 11:24 pm, Robert Scholte wrote:
On Sat, 4 Sep 2021 18:30:06 GMT, Andrey Turbanov
wrote:
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
use @implNote to explain the use of the environment variable
On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
On 9/7/21 8:27 AM, Jaikiran Pai wrote:
On 07/09/21 8:35 pm, Roger Riggs wrote:
Though java.util.Date is used in the current implementation, its use is
discouraged in new code
in favor of java.time.ZonedDateTime.
Consider if java.time.format.DateTimeFormatter.RFC_1123_DATE_TIME can be
On Wed, 8 Sep 2021 00:37:41 GMT, Naoto Sato wrote:
>> Simple spec clarification. A CSR has also been drafted
>> (https://bugs.openjdk.java.net/browse/JDK-8273296).
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refined
On Fri, 3 Sep 2021 14:41:45 GMT, Vladimir Ivanov wrote:
>> `MethodHandle.asTypeCache` keeps a strong reference to adapted
>> `MethodHandle` and it can introduce a class loader leak through its
>> `MethodType`.
>>
>> Proposed fix introduces a 2-level cache (1 element each) where 1st level can
On Tue, 7 Sep 2021 23:39:54 GMT, David Holmes wrote:
>> @dholmes-ora I am from Intel so editing the Intel copyright line should be
>> ok?
>
> @sviswa7 My apologies, I hadn't realized you worked for Intel. But note that
> other Intel files i.e. ./hotspot/cpu/x86/macroAssembler_x86_*.cpp also do
> Simple spec clarification. A CSR has also been drafted
> (https://bugs.openjdk.java.net/browse/JDK-8273296).
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Refined wordings.
-
Changes:
- all:
On Wed, 8 Sep 2021 00:15:46 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Moved the constant to LocalTime for consistency.
>
> test/jdk/java/time/test/java/time/TestInstant.java line 102:
>
>> 100:
> Please review the fix to the issue. Avoiding overflow by not calling
> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
> in nano unit.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Added comments for
On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic
wrote:
> GraalVM Native Image supports loading classes at runtime if they are known
> during image build (class predefinition). This is achieved by the JVMTI agent
> that registers dynamically generated classes in a regular HotSpot run. The
>
On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they
>> take
On Tue, 7 Sep 2021 20:29:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic
wrote:
> GraalVM Native Image supports loading classes at runtime if they are known
> during image build (class predefinition). This is achieved by the JVMTI agent
> that registers dynamically generated classes in a regular HotSpot run. The
>
On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan
wrote:
> Fix the copyright header of SVML files to match others.
>
> This was brought up on jdk-dev mailing list:
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
Marked as reviewed by dholmes (Reviewer).
On Tue, 7 Sep 2021 23:19:37 GMT, Sandhya Viswanathan
wrote:
>> Hi Sandhya,
>>
>> You must not change another company's copyright line, so "All rights
>> reserved" needs to be removed again.
>>
>> Thanks,
>> David
>
> @dholmes-ora I am from Intel so editing the Intel copyright line should be
On Tue, 7 Sep 2021 23:08:08 GMT, David Holmes wrote:
>> Fix the copyright header of SVML files to match others.
>>
>> This was brought up on jdk-dev mailing list:
>> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
>
> Hi Sandhya,
>
> You must not change another
On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan
wrote:
> Fix the copyright header of SVML files to match others.
>
> This was brought up on jdk-dev mailing list:
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
Hi Sandhya,
You must not change another
On Fri, 3 Sep 2021 20:32:20 GMT, Mark Sheppard wrote:
> A number of nio DatagramChannel tests are intermittently failing on
> macosx-aarch64.
> In some instances this is a receive call blocking indefinitely waiting on
> data which has
> already been sent, and should be available immediately to
On Wed, 1 Sep 2021 16:37:24 GMT, Roger Riggs wrote:
> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel
> arrays are hard to keep in sync.
> This cleanup converts to use TestNG DataProviders and other improvements.
Looks good Roger.
A couple trivial
Fix the copyright header of SVML files to match others.
This was brought up on jdk-dev mailing list:
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
-
Commit messages:
- 8273450: Fix the copyright header of SVML file
Changes:
On Wed, 1 Sep 2021 16:37:24 GMT, Roger Riggs wrote:
> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel
> arrays are hard to keep in sync.
> This cleanup converts to use TestNG DataProviders and other improvements.
LGTM.
On Tue, 7 Sep 2021 20:29:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
> Please review the fix to the issue. Avoiding overflow by not calling
> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
> in nano unit.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Moved the constant
On Tue, 7 Sep 2021 19:21:21 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
> Please review the fix to the issue. Avoiding overflow by not calling
> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
> in nano unit.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Corrected the
On Tue, 7 Sep 2021 18:46:56 GMT, Roger Riggs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added a constant for nanos per micro.
>
> src/java.base/share/classes/java/time/Instant.java line 1170:
>
>> 1168:
> Please review the fix to the issue. Avoiding overflow by not calling
> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
> in nano unit.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Added a constant for
On Tue, 7 Sep 2021 18:18:49 GMT, Naoto Sato wrote:
> Please review the fix to the issue. Avoiding overflow by not calling
> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
> in nano unit.
Marked as reviewed by rriggs (Reviewer).
On Tue, 7 Sep 2021 18:18:49 GMT, Naoto Sato wrote:
> Please review the fix to the issue. Avoiding overflow by not calling
> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
> in nano unit.
Looks OK to me
-
Marked as reviewed by lancea (Reviewer).
PR:
Please review the fix to the issue. Avoiding overflow by not calling
nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference in
nano unit.
-
Commit messages:
- 8273369: Computing micros between two instants unexpectedly overflows for
some cases
Changes:
On Sat, 4 Sep 2021 18:30:06 GMT, Andrey Turbanov
wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use @implNote to explain the use of the environment variable
>
>
On Tue, 7 Sep 2021 07:12:29 GMT, Alan Bateman wrote:
>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the
>> JAR index support in URLClassPath,
>> and don’t need to do anything to the jar tool in the short
On Tue, 7 Sep 2021 16:38:25 GMT, Maurizio Cimadamore
wrote:
>> I can, but it seems to me that `/manual` is for marking GUI tests that
>> require user interaction. Let me see if there are keywords we can use.
>> Something like "developer", so that you can pass `jtreg -k:developer` or
>>
On Tue, 7 Sep 2021 15:53:20 GMT, Aleksey Shipilev wrote:
>> test/jdk/java/foreign/TestMatrix.java line 7:
>>
>>> 5: * @build NativeTestHelper CallGeneratorHelper TestUpcallHighArity
>>> 6: *
>>> 7: * @run testng/othervm/native
>>
>> can you please throw in a `/manual` in here as well - so
On Tue, 7 Sep 2021 07:03:20 GMT, Alan Bateman wrote:
>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the
>> JAR index support in URLClassPath,
>> and don’t need to do anything to the jar tool in the short
On Tue, 7 Sep 2021 11:26:01 GMT, Masanori Yano wrote:
>> Hi all,
>>
>> Could you please review the 8269373 bug fixes?
>>
>> These tests call java.lang.ProcessBuilder in direct, so not used jtreg
>> command option. To run non-localized tests, -Duser.language=en and
>> -Duser.country=US
It does look incorrect. I will take a look.
Naoto
On 9/6/21 12:16 AM, Andrey Turbanov wrote:
Hello.
I found suspicious condition in the method
java.util.regex.Grapheme#isExcludedSpacingMark
It's detected by IntelliJ IDEA inspection 'Condition is covered by
further condition'
On Tue, 7 Sep 2021 15:04:31 GMT, Maurizio Cimadamore
wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
>
On 07/09/2021 16:05, Roger Riggs wrote:
Hi,
The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the
protections you are applying.
The doPriv only exposes the value of that specific environment
variable and in the usual case, it is undefined.
The complexity in the specification
On 07/09/21 8:35 pm, Roger Riggs wrote:
Hi,
The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the
protections you are applying.
The doPriv only exposes the value of that specific environment
variable and in the usual case, it is undefined.
The complexity in the
Hi,
The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the
protections you are applying.
The doPriv only exposes the value of that specific environment variable
and in the usual case, it is undefined.
The complexity in the specification and implementation seem unnecessary
in
On Tue, 7 Sep 2021 14:30:41 GMT, Maurizio Cimadamore
wrote:
> So, what is the policy for defining developers tests that are not meant to be
> ran on every build infra, but are meant to be run on a more casual basis by
> developers working in a particular area? When we added TestMatrix we made
On Wed, 18 Aug 2021 07:28:57 GMT, Andrey Turbanov
wrote:
> After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510)
> (eed3a536c0) this condition is always `false`. Empty package name is handled
> separately.
> Found by IntelliJ inspection.
Marked as reviewed by rriggs
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
>
After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510)
(eed3a536c0) this condition is always `false`. Empty package name is handled
separately.
Found by IntelliJ inspection.
-
Commit messages:
- [PATCH] Remove redundant zero-length check in ClassDesc.of
Changes:
On Wed, 18 Aug 2021 07:28:57 GMT, Andrey Turbanov
wrote:
> After [JDK-8215510](https://bugs.openjdk.java.net/browse/JDK-8215510)
> (eed3a536c0) this condition is always `false`. Empty package name is handled
> separately.
> Found by IntelliJ inspection.
Marked as reviewed by
On Sun, 5 Sep 2021 12:38:20 GMT, Jaikiran Pai wrote:
> Do you mean that converting the keySet() of an
>existing Map into an array and then sorting that array and then using
>that sorted array to iterate and using these keys to do an additional
>lookup for value against the original Map would be
On Tue, 7 Sep 2021 14:05:46 GMT, Maurizio Cimadamore
wrote:
> if you still want to pursue the improvement, we can do that too.
Yes, I still want to pursue this test improvement.
-
PR: https://git.openjdk.java.net/jdk/pull/5358
> The commit in this PR implements the proposal for enhancement that was
> discussed in the core-libs-dev mailing list recently[1], for
> https://bugs.openjdk.java.net/browse/JDK-8231640
>
> At a high level - the `store()` APIs in `Properties` have been modified to
> now look for the
On Tue, 7 Sep 2021 13:58:48 GMT, Maurizio Cimadamore
wrote:
> How is this test executed? I think when this was added the idea was that this
> had to be an advanced test which had to be run explicitly by users, but would
> not be picked up in the various test groups/tiers. I'm defo not seeing
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
>
On 05/09/21 6:01 pm, Jaikiran Pai wrote:
Hello Alan,
On 05/09/21 1:46 pm, Alan Bateman wrote:
On 04/09/2021 16:50, Jaikiran Pai wrote:
The commit in this PR implements the proposal for enhancement that
was discussed in the core-libs-dev mailing list recently[1], for
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
>
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Tue, 7 Sep 2021 06:44:22 GMT, Alan Bateman wrote:
> I guess a question here will be whether this should be contributed to the
> upstream Xalan project to keep the changes in the JDK in sync, or maybe the
> JDK has diverged too much already for this to matter.
It seems that both
Bug submitted on your behalf.
https://bugs.openjdk.java.net/browse/JDK-8273430
> On Sep 6, 2021, at 4:16 AM, Andrey Turbanov wrote:
>
> Hello.
> I found suspicious condition in the method
> java.util.regex.Grapheme#isExcludedSpacingMark
> It's detected by IntelliJ IDEA inspection 'Condition is
On 2021-09-07 13:48, Stefan Zobel wrote:
On this blog entry (year 2017), Lemire is not giving any technical or
scientific argument in favor or against PCG.
He also refers to, and quotes from, a blog entry (year 2015) of an
influential researcher (whose work he respects) suggesting the entry
>
> On this blog entry (year 2017), Lemire is not giving any technical or
> scientific argument in favor or against PCG.
>
> He also refers to, and quotes from, a blog entry (year 2015) of an
> influential researcher (whose work he respects) suggesting the entry has
> harsh words about PCG. The
> Hi all,
>
> Could you please review the 8269373 bug fixes?
>
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg
> command option. To run non-localized tests, -Duser.language=en and
> -Duser.country=US options should be added in ProcessBuilder.
Masanori Yano has updated
> Hi all,
>
> Could you please review the 8269373 bug fixes?
>
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg
> command option. To run non-localized tests, -Duser.language=en and
> -Duser.country=US options should be added in ProcessBuilder.
Masanori Yano has updated
On Tue, 7 Sep 2021 11:12:56 GMT, Masanori Yano wrote:
>> Hi all,
>>
>> Could you please review the 8269373 bug fixes?
>>
>> These tests call java.lang.ProcessBuilder in direct, so not used jtreg
>> command option. To run non-localized tests, -Duser.language=en and
>> -Duser.country=US
> Hi all,
>
> Could you please review the 8269373 bug fixes?
>
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg
> command option. To run non-localized tests, -Duser.language=en and
> -Duser.country=US options should be added in ProcessBuilder.
Masanori Yano has updated
Hello,
On 2021-09-05 16:43, Andrew Haley wrote:
On 9/3/21 12:35 AM, John Rose wrote:
The reference I’d like to give here is to Dr. Melissa O’Neill’s
website and articles:
I'm quite sceptical. Anyone who says a (non-cryptographic) random-
number generator is "hard to predict" is either
On Mon, 6 Sep 2021 12:02:12 GMT, Alan Bateman wrote:
> Ah yes, I think you are right. In that case JDK-8255878 can be closed as WNF
> or else FilterInputStream provides implementations of these methods that
> don't directly delegate.
We could set a boolean in the constructor if
On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they
>> take
On Tue, 7 Sep 2021 03:34:27 GMT, wxiang
wrote:
> There is a bug for URLClassPath.findResources with JarIndex.
> With some discussions about the bug, the current priority is to remove the
> JAR index support in URLClassPath,
> and don’t need to do anything to the jar tool in the short term,
On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic
wrote:
> GraalVM Native Image supports loading classes at runtime if they are known
> during image build (class predefinition). This is achieved by the JVMTI agent
> that registers dynamically generated classes in a regular HotSpot run. The
>
70 matches
Mail list logo
