This is a leftover document fix to `String` class for the JEP 400.
Corresponding CSR has also been drafted:
https://bugs.openjdk.java.net/browse/JDK-8276238
-
Commit messages:
- 8276188: Clarify "default charset" descriptions in String class
Changes:
On Mon, 1 Nov 2021 16:51:36 GMT, Pavel Rappo wrote:
>> Please review this PR. A comprehensive test job has been scheduled; I'll
>> notify this thread once that job has completed.
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
On Mon, 1 Nov 2021 18:31:17 GMT, Naoto Sato wrote:
> This is a leftover document fix to `String` class for the JEP 400.
> Corresponding CSR has also been drafted:
> https://bugs.openjdk.java.net/browse/JDK-8276238
Diffs align with the corresponding CSR, which I have also reviewed.
Hi Jaikiran,
Thanks for writing the test case to explore the problems in this area.
Please see my comments below:
On 10/29/21 5:55 AM, Jaikiran Pai wrote:
Hello Ioi (and others),
On 22/10/21 1:39 pm, Jaikiran Pai wrote:
Hello Ioi,
On 22/10/21 12:29 pm, Ioi Lam wrote:
On 10/21/21 9:09
On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad wrote:
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
>
On Mon, 1 Nov 2021 22:27:08 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3269:
>>
>>> 3267: return false;
>>> 3268: }
>>> 3269: int val = value.intValue(); // NANO_OF_SECOND must fit in
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When
The tables are now striped, and they use row headers (which is a nice-to-have
for accessibility).
-
Commit messages:
- Striped tables and table row headers
Changes: https://git.openjdk.java.net/jdk/pull/6196/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6196=00
On Mon, 1 Nov 2021 17:10:56 GMT, Ludvig Janiuk wrote:
> The tables are now striped, and they use row headers (which is a nice-to-have
> for accessibility).
Marked as reviewed by jlaskey (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6196
On Mon, 1 Nov 2021 18:31:17 GMT, Naoto Sato wrote:
> This is a leftover document fix to `String` class for the JEP 400.
> Corresponding CSR has also been drafted:
> https://bugs.openjdk.java.net/browse/JDK-8276238
Marked as reviewed by joehw (Reviewer).
-
PR:
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
On Mon, 1 Nov 2021 15:59:22 GMT, Ludvig Janiuk wrote:
> Adds table headers to all tables in Formatter api docs. I inferred the header
> "Unicode" for the columns that contained unicode
> codepoints.
>
> Formatter api docs:
>
On Thu, 28 Oct 2021 08:58:48 GMT, Aleksey Shipilev wrote:
>> `Unsafe.storeStoreFence` currently delegates to stronger
>> `Unsafe.storeFence`. We can teach compilers to map this directly to already
>> existing rules that handle `MemBarStoreStore`. Like explicit
>> `LoadFence`/`StoreFence`, we
On Mon, 1 Nov 2021 18:44:53 GMT, Vladimir Kozlov wrote:
> Removing intrinsics for StrictMatch `min/max` methods may prevent them from
> inlining if they are not hot when caller is compiled.
Would you like me to leave them instead? That would mean we introduce these new
intrinsic definitions:
https://openjdk.java.net/jeps/421
Summary: Deprecate finalization for removal in a future
release. Finalization remains enabled by default for now, but can
be disabled to facilitate early testing. In a future release it
will be disabled by default, and in a later release it will be
On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo wrote:
> Please review this PR. A comprehensive test job has been scheduled; I'll
> notify this thread once that job has completed.
This pull request has now been integrated.
Changeset: 2eafa036
Author:Pavel Rappo
URL:
On Mon, 1 Nov 2021 16:51:36 GMT, Pavel Rappo wrote:
>> Please review this PR. A comprehensive test job has been scheduled; I'll
>> notify this thread once that job has completed.
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
On Mon, 1 Nov 2021 16:25:26 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/sun/util/resources/LocaleData.java line 248:
>>
>>> 246: private static final LocaleDataStrategy INSTANCE = new
>>> LocaleDataStrategy();
>>> 247: // TODO: avoid hard-coded Locales
>>> 248:
> Please review this PR. A comprehensive test job has been scheduled; I'll
> notify this thread once that job has completed.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Use the blessed modifiers order
-
Changes:
-
On Mon, 1 Nov 2021 15:35:36 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
On Mon, 1 Nov 2021 22:18:52 GMT, Stephen Colebourne
wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>>
On Mon, 1 Nov 2021 15:59:22 GMT, Ludvig Janiuk wrote:
> Adds table headers to all tables in Formatter api docs. I inferred the header
> "Unicode" for the columns that contained unicode
> codepoints.
>
> Formatter api docs:
>
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
Hi Anirvan,
The change looks good to me. Please go ahead with creating a pull
request. It would be easier for reviewers to pull the patch and look at
it. On first glance, test "testStoreWithSupplementaryCharacters" may be
a bit sensitive to file format. It may be solved with a roundtrip
Hello Alan,
On 01/11/21 9:22 pm, Alan Bateman wrote:
On Mon, 1 Nov 2021 03:10:45 GMT, Jaikiran Pai wrote:
Can I please get a review for this change which fixes the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8275509?
The `ModuleDescriptor.hashCode()` method uses the hash
On Mon, 1 Nov 2021 15:35:36 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers: we can
>> match
> Can I please get a review for this change which fixes the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8275509?
>
> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
> components to compute the final hash code. While doing so it ends up calling
>
On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi
wrote:
>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled
>> on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with
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
On Tue, 19 Oct 2021 20:34:55 GMT, Vamsi Parasa wrote:
>> Optimize the new Math.unsignedMultiplyHigh using the x86 mul instruction.
>> This change show 1.87X improvement on a micro benchmark.
>
> Vamsi Parasa has updated the pull request incrementally with one additional
> commit since the last
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe` interface by falling back to `fullFence` when `{load|store}Fence`
On Mon, 1 Nov 2021 02:09:19 GMT, David Holmes wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Restore RN for fullFence
>
> src/hotspot/share/classfile/vmIntrinsics.hpp line 526:
>
>> 524:do_name(
On Fri, 29 Oct 2021 12:51:46 GMT, Masanori Yano wrote:
>> Could you please review the 8276164 bug fixes?
>>
>> I suggest adding the missing javadoc of `@throws IndexOutOfBoundsException`.
>
> Masanori Yano has updated the pull request incrementally with two additional
> commits since the last
On Mon, 1 Nov 2021 02:15:04 GMT, David Holmes wrote:
> I'm not quite seeing the motivation here. Your claim is that the
> non-intrinsic implementations involve a native call and so that is too
> expensive; yet the new code still relies on the fullFence being intrinsified
> else it is still a
On Wed, 6 Oct 2021 18:40:36 GMT, Mark Reinhold wrote:
>> @mbreinhold Could you comment on this pull request?
>
>> @mbreinhold Could you comment on this pull request?
>
> This is somewhat tricky code. I’ll take a look, but give me a few days.
@mbreinhold @AlanBateman Are you aware of my
On Mon, 1 Nov 2021 07:32:18 GMT, Aleksey Shipilev wrote:
>> src/hotspot/share/classfile/vmIntrinsics.hpp line 526:
>>
>>> 524:do_name( storeFence_name,
>>> "storeFence")\
>>> 525:do_alias(
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
On Fri, 29 Oct 2021 16:17:46 GMT, Aleksei Efimov wrote:
>> This change implements a new service provider interface for host name and
>> address resolution, so that java.net.InetAddress API can make use of
>> resolvers other than the platform's built-in resolver.
>>
>> The following API
This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
giving failing intrinsics a second chance to match against the similar `Math`
intrinsics. This has interesting consequence for matchers: we can match the
native `StrictMath.sqrt` to non-native intrinsic for `Math.sqrt`.
Please review this PR. A comprehensive test job has been scheduled; I'll notify
this thread once that job has completed.
-
Commit messages:
- Fix *code* typo
- Be more immutable
- Fix typos
Changes: https://git.openjdk.java.net/jdk/pull/6191/files
Webrev:
On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad wrote:
> Prompted by a request from Volkan Yazıcı I took a look at why
> DataTimeFormatters are much less efficient for some common patterns than
> custom formatters in apache-commons and log4j. This patch address some of
> that gap, without
Prompted by a request from Volkan Yazıcı I took a look at why
DataTimeFormatters are much less efficient for some common patterns than custom
formatters in apache-commons and log4j. This patch address some of that gap,
without having looked at the third party implementations.
When printing
On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo wrote:
> Please review this PR. A comprehensive test job has been scheduled; I'll
> notify this thread once that job has completed.
LGTM, but please use `static final`
src/java.base/share/classes/sun/util/resources/LocaleData.java line 248:
> 246:
On Mon, 1 Nov 2021 11:23:16 GMT, Aleksey Shipilev wrote:
> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
> giving failing intrinsics a second chance to match against the similar `Math`
> intrinsics. This has interesting consequence for matchers: we can match the
>
On Mon, 1 Nov 2021 13:08:05 GMT, Andrew Haley wrote:
> So we have _dsqrt and_dsqrt_strict, which must be functionally identical, but
> we provide both names because they're part of a public API. I think this
> deserves an explanatory comment in the code.
Yes, no problem, added comment near
> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
> giving failing intrinsics a second chance to match against the similar `Math`
> intrinsics. This has interesting consequence for matchers: we can match the
> native `StrictMath.sqrt` to non-native intrinsic for
On Mon, 1 Nov 2021 03:10:45 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which fixes the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8275509?
>>
>> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
>> components to compute
On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo wrote:
> Please review this PR. A comprehensive test job has been scheduled; I'll
> notify this thread once that job has completed.
src/java.base/share/classes/sun/util/resources/LocaleData.java line 336:
> 334: public List
Adds table headers to all tables in Formatter api docs. I inferred the header
"Unicode" for the columns that contained unicode
codepoints.
Formatter api docs:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Formatter.html
-
Commit messages:
- Fixes
> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled
> on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.
Ichiroh Takiguchi has updated the pull request with a new
On Mon, 1 Nov 2021 15:04:16 GMT, Pavel Rappo wrote:
> Please review this PR. A comprehensive test job has been scheduled; I'll
> notify this thread once that job has completed.
Marked as reviewed by naoto (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6191
On Mon, 1 Nov 2021 15:52:51 GMT, Daniel Fuchs wrote:
>> Please review this PR. A comprehensive test job has been scheduled; I'll
>> notify this thread once that job has completed.
>
> src/java.base/share/classes/sun/util/resources/LocaleData.java line 336:
>
>> 334: public List
On Mon, 1 Nov 2021 15:23:49 GMT, Claes Redestad wrote:
>> Please review this PR. A comprehensive test job has been scheduled; I'll
>> notify this thread once that job has completed.
>
> src/java.base/share/classes/sun/util/resources/LocaleData.java line 248:
>
>> 246: private static
54 matches
Mail list logo
