On Tue, 13 Apr 2021 18:56:22 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the following patch which adds additional permissions needed
>> for when JTREG upgrades to a newer version of TestNG.
>>
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with o
On Fri, 9 Apr 2021 09:41:19 GMT, Aleksey Shipilev wrote:
> SonarCloud reports:
> Cast one of the operands of this subtraction operation to a "long".
>
> Here:
>
> Spliterator makeSplitsSpliterator(long index,
> long fence, SplittableGenerator source) {
> ...
>
On Tue, 13 Apr 2021 18:11:37 GMT, Claes Redestad wrote:
> This patch reduces work done initializing VarForms - mostly observed when
> loading each VarHandle implementation class.
>
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes
> crea
> The results from Class.getDeclaredMethods can include bridge and other
> synthetic methods, which can be unexpected by users (JDK-6815786,
> JDK-8142904) and appear to be inherited methods. The javadoc for
> Class.getDeclaredMethods should be updated to explicitly mention the
> possibility of
On Tue, 13 Apr 2021 17:56:12 GMT, Naoto Sato wrote:
>Have you run regression tests in java.time? If I am not mistaken, your changes
>simply seem to nullify the day period support.
Hello @naotoj, my tier1 test run passed without issues locally with this change:
==
T
Hello there,
I'm Kengo TODA, an engineer learning about the Record feature.
Today I found a nonintentional behavior, and it seems that the bug database
has no info about it.
Let me ask here to confirm it's by-design or not. If it's a bug, I want to
try to send a patch to OpenJDK.
Here is the cod
On Wed, 14 Apr 2021 00:35:38 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/invoke/VarForm.java line 130:
>>
>>> 128: } catch (NoSuchMethodException | IllegalAccessException e) {
>>> 129: throw new UnsupportedOperationException();
>>> 130: }
>>
>
On Tue, 13 Apr 2021 23:09:12 GMT, Paul Sandoz wrote:
>> This patch reduces work done initializing VarForms - mostly observed when
>> loading each VarHandle implementation class.
>>
>> - Lazily resolve MemberNames.
>> - Streamline MethodType creation. This reduces the number of MethodTypes
>> c
On Tue, 13 Apr 2021 22:50:12 GMT, Andy Herrick wrote:
>> two changes:
>> One to jpackage, when recursively removing directory, when IOException
>> occurs, record it and continue (deleting as much as possible) before
>> throwing the exception.
>> The other to tests, when running jpackage via Pro
On Tue, 13 Apr 2021 18:11:37 GMT, Claes Redestad wrote:
> This patch reduces work done initializing VarForms - mostly observed when
> loading each VarHandle implementation class.
>
> - Lazily resolve MemberNames.
> - Streamline MethodType creation. This reduces the number of MethodTypes
> crea
> two changes:
> One to jpackage, when recursively removing directory, when IOException
> occurs, record it and continue (deleting as much as possible) before throwing
> the exception.
> The other to tests, when running jpackage via ProcessBuilder.execute(), set
> the "TMP" environment variable
On Tue, 13 Apr 2021 22:00:57 GMT, Remi Forax wrote:
> About your benchmark, did you test with some strings going into "default",
> because it is usually in that case that you need a proper lookup switch,
another way to say it is that, your results are too good when you use a cascade
of guardWit
On Tue, 13 Apr 2021 22:00:57 GMT, Remi Forax wrote:
> About your benchmark, did you test with some strings going into "default",
> because it is usually in that case that you need a proper lookup switch,
another way to say it is that, your results are too good when you use a cascade
of guardWit
The results from Class.getDeclaredMethods can include bridge and other
synthetic methods, which can be unexpected by users (JDK-6815786, JDK-8142904)
and appear to be inherited methods. The javadoc for Class.getDeclaredMethods
should be updated to explicitly mention the possibility of synthetic
- Mail original -
> De: "Jorn Vernee"
> À: "core-libs-dev"
> Envoyé: Mardi 13 Avril 2021 16:59:58
> Objet: Re: RFR: 8263087: Add a MethodHandle combinator that switches over a
> set of MethodHandles
> On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee wrote:
>
>> This patch adds a `tableSwi
> De: "John Rose"
> À: "Remi Forax"
> Cc: "Jorn Vernee" , "core-libs-dev"
>
> Envoyé: Samedi 10 Avril 2021 01:43:49
> Objet: Re: [External] : Re: RFR: 8263087: Add a MethodHandle combinator that
> switches over a set of MethodHandles
> On Apr 9, 2021, at 4:00 PM, John Rose < [ mailto:john.r.r..
On Tue, 13 Apr 2021 18:56:22 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the following patch which adds additional permissions needed
>> for when JTREG upgrades to a newer version of TestNG.
>>
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with o
On Mon, 12 Apr 2021 20:18:46 GMT, Alexander Matveev
wrote:
> This is regression from JDK-8242302. Fixed by setting java.library.path to
> same values as it was before JDK-8242302.
This pull request has now been integrated.
Changeset: 55d56495
Author:Alexander Matveev
URL: https://g
On Tue, 13 Apr 2021 19:59:30 GMT, Naoto Sato wrote:
>> Please review the changes for the subject issue. This has been suggested in
>> a recent discussion thread for the JEP 400
>> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>> A CSR has also been draft
On Tue, 13 Apr 2021 18:56:22 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the following patch which adds additional permissions needed
>> for when JTREG upgrades to a newer version of TestNG.
>>
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with o
On Mon, 12 Apr 2021 22:10:06 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Java-based JIT compiler (Graal) from JDK:
>>
>> - `jdk.internal.vm.compiler` — the Graal compiler
>> - `jdk.internal.vm.compiler.management` — Graal's `M
On Tue, 13 Apr 2021 21:05:26 GMT, Andy Herrick wrote:
>> two changes:
>> One to jpackage, when recursively removing directory, when IOException
>> occurs, record it and continue (deleting as much as possible) before
>> throwing the exception.
>> The other to tests, when running jpackage via Pro
> two changes:
> One to jpackage, when recursively removing directory, when IOException
> occurs, record it and continue (deleting as much as possible) before throwing
> the exception.
> The other to tests, when running jpackage via ProcessBuilder.execute(), set
> the "TMP" environment variable
On Tue, 13 Apr 2021 20:31:38 GMT, Andy Herrick wrote:
>> That seems like overkill. walkFileTree must call visitFile,
>> preVisitDirectory, and postVisitDirectory synchronously, because their
>> return value tells walkFileTree where to go next.
>
> I can use AtomicReference instead of Array to
On Tue, 13 Apr 2021 20:26:56 GMT, Andy Herrick wrote:
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java line 59:
>>
>>> 57:
>>> 58: public static void deleteRecursive(Path directory) throws
>>> IOException {
>>> 59: final IOException [] exception = { (IOException
On Tue, 13 Apr 2021 19:48:24 GMT, Alexey Semenyuk wrote:
>> two changes:
>> One to jpackage, when recursively removing directory, when IOException
>> occurs, record it and continue (deleting as much as possible) before
>> throwing the exception.
>> The other to tests, when running jpackage via
> Please review the changes for the subject issue. This has been suggested in
> a recent discussion thread for the JEP 400
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
> A CSR has also been drafted, and comments are welcome
> [[2](https://bugs.openjdk.
On Tue, 13 Apr 2021 19:30:53 GMT, Joe Wang wrote:
>> Although the code path is different, the logic to determine the encoding is
>> not changed, as `sun.stdout/err.encoding` are only set if the VM is invoked
>> from a terminal (in fact, there's a bug where they aren't set even in a
>> terminal
On Tue, 13 Apr 2021 18:57:20 GMT, Andy Herrick wrote:
> two changes:
> One to jpackage, when recursively removing directory, when IOException
> occurs, record it and continue (deleting as much as possible) before throwing
> the exception.
> The other to tests, when running jpackage via ProcessB
On Tue, 13 Apr 2021 18:24:55 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/lang/System.java line 2020:
>>
>>> 2018: setIn0(new BufferedInputStream(fdIn));
>>> 2019: setOut0(newPrintStream(fdOut, cs));
>>> 2020: setErr0(newPrintStream(fdErr, cs));
>>
>> It wa
two changes:
One to jpackage, when recursively removing directory, when IOException occurs,
record it and continue (deleting as much as possible) before throwing the
exception.
The other to tests, when running jpackage via ProcessBuilder.execute(), set the
"TMP" environment variable to the curre
> Hi all,
>
> Please review the following patch which adds additional permissions needed
> for when JTREG upgrades to a newer version of TestNG.
>
> Best,
> Lance
Lance Andersen has updated the pull request incrementally with one additional
commit since the last revision:
TestNG updates Per
On Tue, 13 Apr 2021 18:01:49 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review the following patch which adds additional permissions needed
> for when JTREG upgrades to a newer version of TestNG.
>
> Best,
> Lance
test/jdk/java/lang/ProcessHandle/PermissionTest.java line 215:
> 213:
On Tue, 13 Apr 2021 13:04:17 GMT, Alan Bateman wrote:
> 1. I think method name "charset()" is too short. It's not called frequently.
> This method name should explain functionality.
As for this one, I am open for suggestions. I thought `consoel()` was concise,
and analogous to `Charset.default
On Tue, 13 Apr 2021 02:34:15 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reverted PrintStream changes
>
> src/java.base/share/classes/java/lang/System.java line 2020:
>
>> 2018: setIn0(new
This patch reduces work done initializing VarForms - mostly observed when
loading each VarHandle implementation class.
- Lazily resolve MemberNames.
- Streamline MethodType creation. This reduces the number of MethodTypes
created.
Net effect is a reduction in bytecode executed per VH class by
Hi all,
Please review the following patch which adds additional permissions needed for
when JTREG upgrades to a newer version of TestNG.
Best,
Lance
-
Commit messages:
- TestNG updates
Changes: https://git.openjdk.java.net/jdk/pull/3471/files
Webrev: https://webrevs.openjdk.java
> Please review the changes for the subject issue. This has been suggested in
> a recent discussion thread for the JEP 400
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
> A CSR has also been drafted, and comments are welcome
> [[2](https://bugs.openjdk.
On Tue, 13 Apr 2021 15:03:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed fix for
>> https://bugs.openjdk.java.net/browse/JDK-8262108?
>>
>> As noted in a comment in that issue, the bug relates to the return value of
>> `Calendar.getDisplayNames` for the `Calendar.AM
On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon wrote:
>> We would definitely like to be able to continue testing of GraalVM with the
>> JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like
>> it does today is important.
>
>> @dougxc I restored Compiler::isGraalEnabled().
>
On Tue, 13 Apr 2021 16:33:21 GMT, Jim Laskey wrote:
> Move makeXXXSpilterator from public (@hidden) to protected. No API ch
This looks exactly like my proposed solution!
+1 Thanks!
Just my question: Is `@hidden` not needed to remove the documentation from
protected method? Or is this automati
Move makeXXXSpilterator from public (@hidden) to protected. No API ch
-
Commit messages:
- Move makeXXXSpilterator from public (@hidden) to protected. No API change.
Changes: https://git.openjdk.java.net/jdk/pull/3469/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3469
On Tue, 13 Apr 2021 12:25:20 GMT, Jorn Vernee wrote:
>> This patch implements 2 leftover TODOs for implementing var handle invoker
>> MH caching (lambda forms for those were already shared/cached).
>>
>> This piggybacks on the existing mechanism for method handle invoker caching.
>>
>> Testing
Hi, Sergey!
Have you measured the code change in the java.lang.Class itself or just
equivalent code in the JMH test as you show us?
The JMH test may show better results as it is compiled to bytecode that
uses special invokedynamic-based string concatenation with optimal MH
based underlying
On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt wrote:
> Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a
> tier1 test) until JDK-8262897 is fixed.
This pull request has now been integrated.
Changeset: 2aae29c9
Author:Mikael Vidstedt
URL: https://git.ope
> Can I please get a review for this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8262108?
>
> As noted in a comment in that issue, the bug relates to the return value of
> `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation
> has started returning inval
On Thu, 8 Apr 2021 18:51:21 GMT, Jorn Vernee wrote:
> This patch adds a `tableSwitch` combinator that can be used to switch over a
> set of method handles given an index, with a fallback in case the index is
> out of bounds, much like the `tableswitch` bytecode. Here is a description of
> how
On Tue, 13 Apr 2021 12:47:50 GMT, Сергей Цыпанов
wrote:
> In mentioned method this code snippet
>
> int len = baseName.length() + 1 + name.length();
> StringBuilder sb = new StringBuilder(len);
> name = sb.append(baseName.replace('.', '/'))
> .append('/')
> .append(name)
>
On Tue, 13 Apr 2021 12:54:51 GMT, Ichiroh Takiguchi
wrote:
> 1. I think method name "charset()" is too short. It's not called frequently.
> This method name should explain functionality.
> 2. Sometimes stderr may be redirected to stdout by shell. Why do we need to
> set different encodings for
On Mon, 12 Apr 2021 23:01:24 GMT, Naoto Sato wrote:
>> Please review the changes for the subject issue. This has been suggested in
>> a recent discussion thread for the JEP 400
>> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>> A CSR has also been draft
On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt wrote:
> Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a
> tier1 test) until JDK-8262897 is fixed.
Looks good and trivial.
Harold
-
Marked as reviewed by hseigel (Reviewer).
PR: https://git.openjdk.java
In mentioned method this code snippet
int len = baseName.length() + 1 + name.length();
StringBuilder sb = new StringBuilder(len);
name = sb.append(baseName.replace('.', '/'))
.append('/')
.append(name)
.toString();
can be simplified with performance improvement as
name =
On Mon, 12 Apr 2021 20:18:46 GMT, Alexander Matveev
wrote:
> This is regression from JDK-8242302. Fixed by setting java.library.path to
> same values as it was before JDK-8242302.
Marked as reviewed by herrick (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3443
> This patch implements 2 leftover TODOs for implementing var handle invoker MH
> caching (lambda forms for those were already shared/cached).
>
> This piggybacks on the existing mechanism for method handle invoker caching.
>
> Testing: Local testing `java/lang/invoke` tests. Tier 1-3
>
> Thank
On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee wrote:
> This patch implements 2 leftover TODOs for implementing var handle invoker MH
> caching (lambda forms for those were already shared/cached).
>
> This piggybacks on the existing mechanism for method handle invoker caching.
>
> Testing: Loca
On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8262108?
>
> As noted in a comment in that issue, the bug relates to the return value of
> `Calendar.getDisplayNames` for the `Calendar.AM_PM`
Can I please get a review for this proposed fix for
https://bugs.openjdk.java.net/browse/JDK-8262108?
As noted in a comment in that issue, the bug relates to the return value of
`Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation
has started returning invalid values fo
On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8262108?
>
> As noted in a comment in that issue, the bug relates to the return value of
> `Calendar.getDisplayNames` for the `Calendar.AM_PM`
On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee wrote:
> This patch implements 2 leftover TODOs for implementing var handle invoker MH
> caching (lambda forms for those were already shared/cached).
>
> This piggybacks on the existing mechanism for method handle invoker caching.
>
> Testing: Loca
On Tue, 13 Apr 2021 10:04:19 GMT, Conor Cleary wrote:
>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code,
>> the details of which can be seen in
>> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number
>> JNDI methods under `java
On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt wrote:
> Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a
> tier1 test) until JDK-8262897 is fixed.
Marked as reviewed by akozlov (no project role).
-
PR: https://git.openjdk.java.net/jdk/pull/3452
On Mon, 12 Apr 2021 11:47:43 GMT, Jorn Vernee wrote:
>> Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual
>> is a cleanup and minimal startup improvement on apps spinning up
>> MethodHandles.
>
> Marked as reviewed by jvernee (Committer).
@JornVernee @mlchung - thank
On Mon, 12 Apr 2021 10:45:20 GMT, Claes Redestad wrote:
> Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual
> is a cleanup and minimal startup improvement on apps spinning up
> MethodHandles.
This pull request has now been integrated.
Changeset: 7006070f
Author:
On Tue, 13 Apr 2021 10:04:19 GMT, Conor Cleary wrote:
>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code,
>> the details of which can be seen in
>> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number
>> JNDI methods under `java
On Mon, 12 Apr 2021 16:24:37 GMT, Jorn Vernee wrote:
> This patch implements 2 leftover TODOs for implementing var handle invoker MH
> caching (lambda forms for those were already shared/cached).
>
> This piggybacks on the existing mechanism for method handle invoker caching.
>
> Testing: Loca
This patch implements 2 leftover TODOs for implementing var handle invoker MH
caching (lambda forms for those were already shared/cached).
This piggybacks on the existing mechanism for method handle invoker caching.
Testing: Local testing `java/lang/invoke` tests. Tier 1-3
Thanks,
Jorn
---
On Tue, 13 Apr 2021 10:00:51 GMT, Conor Cleary wrote:
>> Good idea, also would fit in with the style of the method just after,
>> `priviligedHasNext()` as that also uses a functional interface.
>
> Changes included as described in commit
> [5d6ecd3](https://github.com/openjdk/jdk/pull/3416/comm
> ### Description
> This fix is part of a previous effort to both cleanup/modernise JNDI code,
> the details of which can be seen in
> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number
> JNDI methods under `java.naming` use Anonymous Inner Classes in cases where
> only a
On Tue, 13 Apr 2021 09:34:15 GMT, Conor Cleary wrote:
>> src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java line
>> 223:
>>
>>> 221: */
>>> 222: private final ClassLoader getContextClassLoader() {
>>> 223: PrivilegedAction pa = () ->
>>> Thread.currentThread(
On Mon, 12 Apr 2021 16:44:16 GMT, Aleksei Efimov wrote:
>> Conor Cleary has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update copyright headers
>> - Tidied up lambdas
>
> src/java.naming/share/classes/javax/naming/ldap/StartTlsReques
On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon wrote:
>> Vladimir Kozlov 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 three additional
>> commi
Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a
tier1 test) until JDK-8262897 is fixed.
-
Commit messages:
- 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java
on macosx-aarch64
Changes: https://git.openjdk.java.net/jdk/pull/3452
72 matches
Mail list logo
