> 8267630: Start of release updates for JDK 18
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains 24 commits:
- Update copyright year.
- Merge branch 'master' into 8267630
- Merge branch 'master' into 8267630
- Merge
> During annotation parsing, the parser assumes that a declared property is of
> an array type if the parsed annotation property is defined as an array. In
> this case, the component type is `null`, and a `NullPointerException` is
> thrown. This change discovers the mismatch and throws an
>
On Thu, 10 Jun 2021 04:17:37 GMT, David Holmes wrote:
>> Rafael Winterhalter has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR.
>
>
> Hi,
>
> Could someone please review my code for updating the code in the `java.lang`
> packages to make use of the switch expressions?
>
> Kind regards,
> Patrick
Patrick Concannon has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev
> There is a few JDK classes duplicating the contents of Long.hashCode() for
> hash code calculation. They should explicitly delegate to Long.hashCode().
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated
On Mon, 7 Jun 2021 16:38:01 GMT, Jorn Vernee wrote:
> Hi,
>
> ~This is part 2 of a two part upstreaming process of the patch mentioned in
> the subject line. The patch was split into 2 in order to document 2 separate
> specification changes that arose from a change in the implementation, with
> If a type is changed from a type that can be a member of an annotation which
> is used in an array, changing it to a type that cannot be an array member
> will be treated as if the type is an annotation type. As a result, no
> exception proxy is created and the type is returned as if it was
> During annotation parsing, the parser assumes that a declared property is of
> an array type if the parsed annotation property is defined as an array. In
> this case, the component type is `null`, and a `NullPointerException` is
> thrown. This change discovers the mismatch and throws an
>
On Wed, 9 Jun 2021 23:59:45 GMT, Joe Darcy wrote:
> To aid future maintainers, please add a short summary comment with an outline
> of what the test is doing before integrating.
I added a comment to the test to explain what is done in it.
-
PR:
On Tue, 8 Jun 2021 19:25:36 GMT, Paul Sandoz wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Suggest try/catch Throwable in upcallStub javadoc
>
> test/jdk/java/foreign/TestUpcallException.java line 70:
>
>> 68:
On Tue, 8 Jun 2021 10:29:44 GMT, Jatin Bhateja wrote:
>> Current VectorAPI Java side implementation expresses rotateLeft and
>> rotateRight operation using following operations:-
>>
>> vec1 = lanewise(VectorOperators.LSHL, n)
>> vec2 = lanewise(VectorOperators.LSHR, n)
>> res =
> Hi,
>
> Could someone please review my code for updating the code in the `java.time`
> packages to make use of the switch expressions?
>
> Kind regards,
> Patrick
Patrick Concannon has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev
> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found
> out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like
> `baseName.replace('.', '/') + '/' + name` are not compiled into
> `invokedynamic`-based code, but into one using `StringBuilder`. This
On Thu, 22 Apr 2021 14:07:20 GMT, Сергей Цыпанов
wrote:
> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found
> out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like
> `baseName.replace('.', '/') + '/' + name` are not compiled into
>
On Thu, 10 Jun 2021 08:29:46 GMT, Rafael Winterhalter
wrote:
>> If a type is changed from a type that can be a member of an annotation which
>> is used in an array, changing it to a type that cannot be an array member
>> will be treated as if the type is an annotation type. As a result, no
Hi all,
could you please review this small patch that does $subj?
Thanks,
-- Igor
attn: @plummercj
-
Commit messages:
- 8267448
Changes: https://git.openjdk.java.net/jdk/pull/4451/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4451=00
Issue:
> 8267630: Start of release updates for JDK 18
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains 25 commits:
- Merge branch 'master' into 8267630
- Update copyright year.
- Merge branch 'master' into 8267630
- Merge
On Thu, 10 Jun 2021 14:42:24 GMT, Joe Darcy wrote:
>> 8267630: Start of release updates for JDK 18
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The pull request now contains 25 commits:
>
> - Merge branch 'master' into 8267630
> - Update
On Thu, 10 Jun 2021 00:15:24 GMT, Joe Darcy wrote:
> Please add an overview to test before integrating; thanks.
Sorry, I missed that one. Not sure what you mean by *overview*?
-
PR: https://git.openjdk.java.net/jdk/pull/3940
On Tue, 8 Jun 2021 23:42:13 GMT, Sandhya Viswanathan
wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixing review comments. Adding notes about isMIME parameter for other
>> architectures; clarifying
> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration.
> Also allows for performance improvement for non-AVX-512 enabled platforms.
> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to
> accept an additional parameter (isMIME) for fast-path MIME
On Thu, 10 Jun 2021 06:26:53 GMT, Igor Ignatyev wrote:
> Hi all,
>
> could you please review this small patch that does $subj?
>
> Thanks,
> -- Igor
>
> attn: @plummercj
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/4451
On Thu, 10 Jun 2021 06:26:53 GMT, Igor Ignatyev wrote:
> Hi all,
>
> could you please review this small patch that does $subj?
>
> Thanks,
> -- Igor
>
> attn: @plummercj
closing in favor of openjdk/jdk17#2
-
PR: https://git.openjdk.java.net/jdk/pull/4451
On Thu, 10 Jun 2021 08:11:42 GMT, Rafael Winterhalter
wrote:
>> Please add an overview to test before integrating; thanks.
>
>> Please add an overview to test before integrating; thanks.
>
> Sorry, I missed that one. Not sure what you mean by *overview*? I was not
> sure if there's an
On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote:
> 8267630: Start of release updates for JDK 18
This pull request has now been integrated.
Changeset: b018c450
Author:Joe Darcy
URL:
https://git.openjdk.java.net/jdk/commit/b018c450e5e4737ccd08ed505fd06cee16c42648
Stats: 5352
On Fri, 7 May 2021 18:58:02 GMT, Rafael Winterhalter
wrote:
> If a type is changed from a type that can be a member of an annotation which
> is used in an array, changing it to a type that cannot be an array member
> will be treated as if the type is an annotation type. As a result, no
>
On Wed, 2 Jun 2021 15:25:16 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.lang`
> packages to make use of the switch expressions?
>
> Kind regards,
> Patrick
This pull request has now been integrated.
Changeset: d43c8a74
On Wed, 9 Jun 2021 10:33:34 GMT, Maurizio Cimadamore
wrote:
> This tests fails intermittently but very rarely, on Windows it seems. The
> subtest in question is `testLockSharedMultiThread`. This test is spawning a
> number of threads, each of which:
>
> * increments a counter atomically
> *
Hello, in the pipeline of my JDK fork the mentioned build step constantly fails
even providing I modify only Java code
I see this message in the log
Compiling 2 files for BUILD_JVMTI_TOOLS
LINK : fatal error LNK1104: cannot open file 'libcpmt.lib'
make[3]: *** [gensrc/GensrcAdlc.gmk:63:
On Thu, 10 Jun 2021 08:36:42 GMT, Rafael Winterhalter
wrote:
>> During annotation parsing, the parser assumes that a declared property is of
>> an array type if the parsed annotation property is defined as an array. In
>> this case, the component type is `null`, and a `NullPointerException`
> During annotation parsing, the parser assumes that a declared property is of
> an array type if the parsed annotation property is defined as an array. In
> this case, the component type is `null`, and a `NullPointerException` is
> thrown. This change discovers the mismatch and throws an
>
On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote:
> Looks like the test does not verify the cases specified by `valueOf(int
> refKind, boolean isInterface)`.
> i.e. For most values of refKind, there is an exact match regardless of the
> value of isInterface except `REF_invokeStatic` and
On Thu, 27 May 2021 22:05:55 GMT, Leonid Mesnik wrote:
> EFH is improved to process cores and get mixed stack traces with jhsdb and
> native stack traces with gdb/lldb. It might be useful because hs_err doesn't
> contain info about all threads, sometimes it is even not generated.
This pull
On Thu, 10 Jun 2021 23:26:21 GMT, Vicente Romero wrote:
>> Please review this PR which is just syncing the implementation of
>> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
>> method's spec is that if the value of the `refKind` parameter is:
>>
On Thu, 10 Jun 2021 23:23:23 GMT, Vicente Romero wrote:
>> test/jdk/java/lang/constant/MethodHandleDescTest.java line 362:
>>
>>> 360: public void testKind() {
>>> 361: for (Kind k : Kind.values()) {
>>> 362: assertEquals(Kind.valueOf(k.refKind),
>>>
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote:
> More loudly and precise warning messages when a security manager is either
> enabled at startup or installed at runtime.
This pull request has been closed without being integrated.
-
PR:
On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> addressing review changes
>
> test/jdk/java/lang/constant/MethodHandleDescTest.java line 362:
>
>> 360: public
> Please review this PR which is just syncing the implementation of
> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
> method's spec is that if the value of the `refKind` parameter is:
> MethodHandleInfo.REF_invokeInterface, then
>
38 matches
Mail list logo
