On Thu, 14 Apr 2022 09:28:17 GMT, Andrey Turbanov wrote:
>> Found various typos of expected: `exepected`, `exept`, `epectedly`,
>> `expeced`, `Unexpeted`, etc.
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8284853: Fi
On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to fix the issue
>> reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>>
>> As noted in that issue, trying to class load
>> `sun.util.calendar.CalendarSystem` and `sun.
On Wed, 8 Sep 2021 06:22:38 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, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg
wrote:
> This PR fixes the following spelling errors:
>
> choosen -> chosen
> commad -> command
> hiearchy -> hierarchy
> leagacy -> legacy
> minium -> minimum
> subsytem -> subsystem
> unamed -> unnamed
Hi, I've filed https://bugs
On Tue, 13 Jul 2021 03:06:12 GMT, Yi Yang wrote:
> Hi all,
>
> this pull request contains a backport of commit 07e90524 from the openjdk/jdk
> repository.
>
> The commit being backported was authored by Yi Yang on 13 Jul 2021 and was
> reviewed by Mandy Chung.
>
>
Hi all,
this pull request contains a backport of commit 07e90524 from the openjdk/jdk
repository.
The commit being backported was authored by Yi Yang on 13 Jul 2021 and was
reviewed by Mandy Chung.
Thanks!
-
Commit messages:
- Backport 07e90524576f159fc16523430f1db62327c89a3b
On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Yi Yang has
On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote:
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
This pull request has now been integrat
On Thu, 8 Jul 2021 02:32:45 GMT, Yi Yang wrote:
> Generated lambda class can not access protected static method of the target
> class. The following exception is thrown when executing the attached
> reproducible program:
>
>
> Exception in thread "main" java.la
On Mon, 12 Jul 2021 02:57:26 GMT, Yi Yang wrote:
>> Generated lambda class can not access protected static method of the target
>> class. The following exception is thrown when executing the attached
>> reproducible program:
>>
>>
>> Exception in thread
On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Yi Yang has
s to the resolved method) and 2)
> does not force accepting an implClass as the first argument when invoking a
> static method.
>
> Testing:
> - test/jdk/java/ with release mode
> - presubmit tests
Yi Yang has updated the pull request incrementally with one additional commit
since th
s to the resolved method) and 2)
> does not force accepting an implClass as the first argument when invoking a
> static method.
>
> Testing:
> - test/jdk/java/ with release mode
> - presubmit tests
Yi Yang has updated the pull request incrementally with one additional commit
since
After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
the whole JDK codebase.
As Mandy suggested, I create this PR for changes involving JUC changes.
-
Commit messages:
- replace
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has refreshed the contents of this pull request, and previous commits
have bee
On Wed, 7 Jul 2021 17:08:19 GMT, Mandy Chung wrote:
>>> Does "client changes" means changes involving src/java.desktop and
>>> test/java/awt?
>>
>> src/java.desktop, test/java/awt, and test/javax/imageio
>
>> > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
>> > nee
Generated lambda class can not access protected static method of the target
class. The following exception is thrown when executing the attached
reproducible program:
Exception in thread "main" java.lang.IllegalAccessError: class
AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x000800b8
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with two additional commits
since the
On Tue, 6 Jul 2021 19:06:43 GMT, Mandy Chung wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> tests rely on IOOBE exception message
>
> test/jdk/java/lang/StringBuffer/Exc
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with four additional commits
since the
On Mon, 5 Jul 2021 06:01:23 GMT, Yi Yang wrote:
>> Class loading order is different to class initialization order.
>>
>> There are a lot more tests than just tier1. :) I don't expect many, if any,
>> tests to be looking for a specific IOOBE message, and I can'
On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Class loading order is different to class ini
On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang wrote:
> Prefer using ByteOrder to compute byte order for StringUTF16 to determining
> byte order by native method StringUTF16.isBigEndian.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.n
On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang wrote:
> Prefer using ByteOrder to compute byte order for StringUTF16 to determining
> byte order by native method StringUTF16.isBigEndian.
Thanks for the detailed clarification!
The purpose of this PR is to skip the native call and use ByteOrde
On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang wrote:
> Hi, can I have a review of this change that adds two new utility methods for
> java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of
> ByteOrder.nativeOrder() is to check if the underlying platform is
> littl
On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang wrote:
> Hi, can I have a review of this change that adds two new utility methods for
> java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of
> ByteOrder.nativeOrder() is to check if the underlying platform is
> littl
On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang wrote:
> Prefer using ByteOrder to compute byte order for StringUTF16 to determining
> byte order by native method StringUTF16.isBigEndian.
Hi Aleksey, do you have a concrete issue/discussion about bootstrapping
problems? I don't see it be
25, 2021 at 8:45 AM Yi Yang wrote:
>
> Hi, can I have a review of this change that adds two new utility methods for
> java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of
> ByteOrder.nativeOrder() is to check if the underlying platform is
> little-endian/big-e
On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang wrote:
> Hi, can I have a review of this change that adds two new utility methods for
> java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of
> ByteOrder.nativeOrder() is to check if the underlying platform is
> littl
Prefer using ByteOrder to compute byte order for StringUTF16 to determining
byte order by native method StringUTF16.isBigEndian.
-
Commit messages:
- replace
Changes: https://git.openjdk.java.net/jdk/pull/4596/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4596&range=
Hi, can I have a review of this change that adds two new utility methods for
java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of
ByteOrder.nativeOrder() is to check if the underlying platform is
little-endian/big-endian. There is no reason to only provide
ByteOrder.nativeO
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
On Tue, 22 Jun 2021 02:39:01 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Y
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
On Mon, 21 Jun 2021 20:49:56 GMT, Paul Sandoz wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> more replacement 2
>
> src/java.base/share/classes/jdk/internal/util/Precon
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the last re
On Fri, 18 Jun 2021 18:03:44 GMT, Paul Sandoz wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> restore IndexOfOufBoundsException; split exception line
>
> src/java.base/share/classes/
On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang wrote:
>> After JDK-8265518(#3615), it's possible to replace all variants of
>> checkIndex by
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
>> the whole JDK codebase.
>
> Y
On Thu, 17 Jun 2021 15:45:47 GMT, Paul Sandoz wrote:
>> src/java.base/share/classes/java/util/Base64.java line 934:
>>
>>> 932: if (closed)
>>> 933: throw new IOException("Stream is closed");
>>> 934: Preconditions.checkFromIndexSize(len, off, b.length, (x
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
Yi Yang has updated the pull request incrementally with one additional commit
since the
On Thu, 17 Jun 2021 10:19:43 GMT, Alan Bateman wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> restore IndexOfOufBoundsException; split exception line
>
> src/jav
On Thu, 17 Jun 2021 01:51:41 GMT, David Holmes wrote:
> I skimmed through all these and the changes seem fine in principal.
> I have two mild concerns:
>
> 1. How does this change the class initialization order on VM startup?
> 2. Do any tests need adjusting due to potential changes in the exact
After JDK-8265518, it's possible to replace all variants of checkIndex by
Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the
whole JDK codebase.
-
Commit messages:
- use checkIndex globally
Changes: https://git.openjdk.java.net/jdk/pull/4507/files
Webre
On Sat, 12 Jun 2021 08:22:32 GMT, Thomas Stuefe wrote:
> Hi Yi,
>
> you may need to add the option to the obsolete-flags-table though as
> described in arguments.cpp:
>
> https://github.com/openjdk/jdk/blob/5cee23a9ed0b7fe2657be7492d9c1f78fcd02ebf/src/hotspot/share/runtime/arguments.cpp#L489-L
On Sat, 12 Jun 2021 06:50:48 GMT, Thomas Stuefe wrote:
> This change removed a product flag so I wonder how it could be integrated
> without a CSR?
It's a diagnostic product flag, so it’ okay to remove it without issuing CSR.
But I am not 100% sure.
@dholmes-ora, do you have any comment about
On Fri, 11 Jun 2021 18:05:45 GMT, Igor Veresov wrote:
> I guess you need to do the "integrate" command again.
Okay,thank you all for taking time to look at this
-
PR: https://git.openjdk.java.net/jdk/pull/3615
On Thu, 22 Apr 2021 06:55:41 GMT, Yi Yang wrote:
> The JDK codebase re-created many variants of checkIndex(`grep -I -r
> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which
> annotated with @IntrinsicCandidate and it only has a corresponding C1
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
On Tue, 1 Jun 2021 17:43:45 GMT, Igor Veresov wrote:
>> Thank you @veresov!
>>
>> I'm glad to have more comments from hotspot-compiler group.
>>
>> Later, I'd like to integrate it if there are no more comments/objections.
>>
>> Thanks!
>> Yang
>
> @kelthuzadx Sorry about the delay. Could you
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> better check1-4
>
> Looks like now the test fails in the pre-submit tests?
Thank you @ve
On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> better check1-4
>
> Looks like now the test fails in the pre-submit tests?
Hi @veresov, may
On Fri, 30 Apr 2021 19:20:54 GMT, Igor Veresov wrote:
> Looks like now the test fails in the pre-submit tests?
Hi Igor,
Can you take a look at the latest version? Now it passes all pre-submit tests.
Best Regards,
Yang
-
PR: https://git.openjdk.java.net/jdk/pull/3615
On Fri, 30 Apr 2021 17:30:33 GMT, Paul Sandoz wrote:
> It was my hope this would eventually happen when we added
> `Objects.checkIndex` and the underlying intrinsic. Very good!
Hi Paul,
Thank you for noticing this PR.
> It was my hope this would eventually happen when we added
> `Objects.chec
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
On Thu, 29 Apr 2021 10:13:05 GMT, Daniel Fuchs wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> AssertionError when expected exception was not thrown
>
> test/hotspot/jtreg/compiler/c1/
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
On Thu, 29 Apr 2021 09:30:50 GMT, Daniel Fuchs wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove extra newline
>
> test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate
On Wed, 28 Apr 2021 17:32:18 GMT, Igor Veresov wrote:
> Do we need to keep this flag?
Exactly, the flag should be removed.
Thanks,
Yang
-
PR: https://git.openjdk.java.net/jdk/pull/3615
On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang wrote:
>> The JDK codebase re-created many variants of checkIndex(`grep -I -r
>> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which
>> annotated with @IntrinsicCandidate and it only has a correspond
widely in JDK code, I think we
> can firstly implement its C1 counterpart. There are also a few kinds of stuff
> we can do later:
>
> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK
> codebase.
> 2. Remove Buffer.checkIndex and obsolete/deprecate Inl
On Mon, 5 Apr 2021 08:37:15 GMT, Сергей Цыпанов
wrote:
> Hello,
>
> to avoid cases detected in
> [https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pull/2992)
> I propose to modify JavaDoc of `ByteArray*Stream` to explicitly mention
> redundancy of wrapping with `Buff
On Fri, 26 Feb 2021 10:48:33 GMT, Сергей Цыпанов
wrote:
> The usage of `LinkedList` is senseless and can be replaced with either
> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>
> jdk:tier1 and jdk:tier2 are both ok
src/java.base/share/classes/jdk/internal/loader/URL
On Sat, 13 Mar 2021 11:35:48 GMT, Сергей Цыпанов
wrote:
>> Nice cleanup. I can help file a JBS issue if @c-cleary doesn't notice your
>> comment.
>
> @kelthuzadx hi! I'd appreciate this, as there's no JBS issue for this (
Hi @stsypanov, I've created it
https://bugs.openjdk.java.net/browse/JDK
On Mon, 22 Feb 2021 12:04:14 GMT, Conor Cleary wrote:
>> This is a very simple and trivial improvement about getting rid of pointless
>> char wrapping into array
>
> src/java.base/share/classes/java/io/ObjectStreamClass.java line 833:
>
>> 831: String fname = in.readUTF();
>> 832:
75 matches
Mail list logo