Re: RFR: 8260265: UTF-8 by Default [v9]

On Fri, 27 Aug 2021 23:14:58 GMT, Naoto Sato wrote: >> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of >> the changes is `Charset.defaultCharset()` returning `UTF-8` and >> `file.encoding` system property being added in the spec, but another notable >> modification i

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hello Roger, On 28/08/21 12:16 am, Roger Riggs wrote: Hi, I'm finding the idea of removing the hardcoded timestamp and adding a property to restore compatibility strangely attractive.  I don't think we've yet found a case where the timestamp was needed (but need to keep looking). (Adding a ti

RFR: 8273092: Sort classlist in JDK image

When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. We should sort the generated classlist to make the JDK image's contents more deterministic. Tested with Mach5 tier1, tier2, builds-tier5 ---

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]

> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified > unexpected messages from a child Java VM > as the cause of the test failure. Attempts to control the output of the > child VM have failed, the VM is unrepentant . > > There is no functionality in the child except to

Re: RFR: 8271302: Regex Test Refresh [v4]

On Fri, 20 Aug 2021 21:17:50 GMT, Ian Graves wrote: >> 8271302: Regex Test Refresh > > Ian Graves has updated the pull request incrementally with one additional > commit since the last revision: > > Additional cleanup Marked as reviewed by smarks (Reviewer). Whew! Changes to GraphemeTest.ja

Re: RFR: 8260265: UTF-8 by Default [v9]

> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of > the changes is `Charset.defaultCharset()` returning `UTF-8` and > `file.encoding` system property being added in the spec, but another notable > modification is in `java.io.PrintStream` where it continues to use the

Integrated: 8273091: Doc of [Strict]Math.floorDiv(long, int) erroneously documents int in @return tag

On Fri, 27 Aug 2021 20:02:48 GMT, Raffaello Giulietti wrote: > This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`. This pull request has now been integrated. Changeset: 51167846 Author:Raffaello Giulietti Committer: Brian Burkhalter URL: https://git.openjd

Re: RFR: 8260265: UTF-8 by Default [v8]

> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of > the changes is `Charset.defaultCharset()` returning `UTF-8` and > `file.encoding` system property being added in the spec, but another notable > modification is in `java.io.PrintStream` where it continues to use the

Re: RFR: 8268788: Annotations with lambda expressions can still cause AnnotationFormatError [v4]

On Wed, 25 Aug 2021 17:53:52 GMT, Sergei Ustimenko wrote: >> Change #3294 helps to avoid `AnnotaionFormatException` in >> `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. >> While it fixes the case with e.g. `Runnable` that generates the synthetic >> method wit

Re: RFR: 8273091: Doc of [Strict]Math.floorDiv(long, int) erroneously documents int in @return tag

On Fri, 27 Aug 2021 20:02:48 GMT, Raffaello Giulietti wrote: > This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5287

Re: RFR: 8273091: Doc of [Strict]Math.floorDiv(long, int) erroneously documents int in @return tag

On Fri, 27 Aug 2021 20:02:48 GMT, Raffaello Giulietti wrote: > This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5287

RFR: 8273091: Doc of [Strict]Math.floorDiv(long, int) erroneously documents int in @return tag

This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`. - Commit messages: - 8273091: Doc of [Strict]Math.floorDiv(long,int) erroneously documents int in @return tag Changes: https://git.openjdk.java.net/jdk/pull/5287/files Webrev: https://webrevs.openjdk.java

RFR: 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family

Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()` methods do `j.l.[Strict]Math`. Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`, this PR also corrects small typos in it and exercises tests that were already present but which were never invoked

Integrated: JDK-8272866 java.util.random package summary contains incorrect mixing function in table

On Fri, 27 Aug 2021 14:20:32 GMT, Jim Laskey wrote: > The table 'LXM Multipliers' at the end of the javadoc for the > java.util.random package states that the mixing function is mixLea32 for all > the 64/128-bit LCG based generators. This should be updated to mixLea64 for > the 64/128-bit LCG

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hi, I'm finding the idea of removing the hardcoded timestamp and adding a property to restore compatibility strangely attractive.  I don't think we've yet found a case where the timestamp was needed (but need to keep looking). (Adding a timestamp to the comment by the caller of store() is alrea

Re: Replace StringBuffers to StringBuilders in tests

Hi Daniel and David, Thanks for your opinions and for sharing more context - it is definitely clearer now! I am glad that I reached out to the mailing list first instead of going ahead with the changes! :) Regards, Sergei Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On F

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

I've dropped this topic on the Maven Dev mailinglist as well[1]. The responses are mixed, so I'd prefer to refer to the mailinglist instead of summarizing the responses here. This will prevent that those opinions are considered my opinions. Thanks, Robert [1] https://lists.apache.org/thread.h

Integrated: 8272541: Incorrect overflow test in Toom-Cook branch of BigInteger multiplication

On Mon, 16 Aug 2021 21:00:00 GMT, Brian Burkhalter wrote: > Please consider this change which would modify a conditional `a + b > c` > where the left side variables are `int`s and the right side is > `(long)Integer.MAX_VALUE + 1`. The change is to cast the left side variables > to `long`s. Th

Re: RFR: JDK-8272866 java.util.random package summary contains incorrect mixing function in table

On Fri, 27 Aug 2021 14:20:32 GMT, Jim Laskey wrote: > The table 'LXM Multipliers' at the end of the javadoc for the > java.util.random package states that the mixing function is mixLea32 for all > the 64/128-bit LCG based generators. This should be updated to mixLea64 for > the 64/128-bit LCG

Re: Possible ClassCastException in java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...)

Has that method been ever used? If nothing else its name seems strange. To me, a union has OR semantics, not AND. > On 27 Aug 2021, at 15:37, Andrey Turbanov wrote: > > Hello. > I found suspicious code in the method > "java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharP

Re: RFR: 8266936: Add a finalization JFR event [v9]

On Tue, 24 Aug 2021 12:58:29 GMT, Markus Grönlund wrote: >> Greetings, >> >> Object.finalize() was deprecated in JDK9. There is an ongoing effort to >> replace and mitigate Object.finalize() uses in the JDK libraries; please see >> https://bugs.openjdk.java.net/browse/JDK-8253568 for more info

Re: RFR: 8266936: Add a finalization JFR event [v10]

> Greetings, > > Object.finalize() was deprecated in JDK9. There is an ongoing effort to > replace and mitigate Object.finalize() uses in the JDK libraries; please see > https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. > > We also like to assist users in replacing and mit

Re: what does the spec say about file paths that are too long?

> On Aug 26, 2021, at 8:57 AM, Alan Bateman wrote: > > On 26/08/2021 15:43, Alan Snyder wrote: >> As I said, I think it's great that we agree an exception should be thrown >> when an over-length path is used in an actual file operation. >> >> However, would it not be better to have that in t

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hi, It would seem useful in the long term to move the inclusion of the date to be part of the comment and it would be up to the caller of store() to include a date (as a string) where ever appropriate. And drop the writing hardcoded date; but its not clear how to get there given compatibility

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 27/08/21 8:12 pm, Jaikiran Pai wrote: Hello Daniel, On 27/08/21 8:05 pm, Daniel Fuchs wrote: Hi Jaikiran, What about writing the keys in natural ordering? Has that been abandoned, or will the implementation silently do it, or will it require a new API? In the discussion so far, there has

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hello Daniel, On 27/08/21 8:05 pm, Daniel Fuchs wrote: Hi Jaikiran, What about writing the keys in natural ordering? Has that been abandoned, or will the implementation silently do it, or will it require a new API? In the discussion so far, there has been no opposition to changing the impleme

Possible ClassCastException in java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...)

Hello. I found suspicious code in the method "java.util.regex.Pattern.BmpCharPredicate#union(java.util.regex.Pattern.CharPredicate...)" https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/regex/Pattern.java#L5639 static CharPredicate union(CharPredicate... predicates)

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

Hi Jaikiran, What about writing the keys in natural ordering? Has that been abandoned, or will the implementation silently do it, or will it require a new API? AFAIU there are two problems that are hostile to reproducible builds: - date comments differ from store to store - property ordering

RFR: JDK-8272866 java.util.random package summary contains incorrect mixing function in table

The table 'LXM Multipliers' at the end of the javadoc for the java.util.random package states that the mixing function is mixLea32 for all the 64/128-bit LCG based generators. This should be updated to mixLea64 for the 64/128-bit LCG generators. Only the L32X64MixRandom which uses a 32-bit LCG w

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

On 26/08/21 5:06 pm, Alan Bateman wrote: On 25/08/2021 15:57, Jaikiran Pai wrote: : Introducing an overloaded "store" which takes the timestamp or implicitly using the SOURCE_DATE_EPOCH environment variable would mean that the Properties.store(...) APIs will continue to always write out a

Replace StringBuffers to StringBuilders in tests

Hi all, Some tests use StringBuffers instead of StringBuilders where additional thread-safety is not required as e.g. in test/jdk/sun/util/resources/TimeZone/Bug4640234.java:82 : ... StringBuffer errors = new StringBuffer( "" ); StringBuffer warnings = new StringBuffer( "" ); ... Th

Re: StringBuilder OOMs earlier with JRE 11 compared to JRE 8

- Original Message - > From: "David Holmes" > To: "S" , "core-libs-dev" > > Cc: "Andrey Loskutov" > Sent: Vendredi 27 Août 2021 15:25:25 > Subject: Re: StringBuilder OOMs earlier with JRE 11 compared to JRE 8 > Hi Simeon, > > Redirecting this to core-libs-dev as it is not a serviceabi

Re: StringBuilder OOMs earlier with JRE 11 compared to JRE 8

On 8/27/21 3:25 PM, David Holmes wrote: Is this something that should be looked into or it can be safely ignored (from JDK users POV)? That is the unfortunate but expected trade-off from the Compact Strings work in JDK 9. That reworked the String storage to hold byte[] instead of char[]. When

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v3]

On Sat, 21 Aug 2021 22:37:05 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

Re: StringBuilder OOMs earlier with JRE 11 compared to JRE 8

Hi Simeon, Redirecting this to core-libs-dev as it is not a serviceability issue. (bcc serviceabillity-dev) Thanks, David On 27/08/2021 8:53 pm, S A wrote: Hi all, while working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=575641 ,

Re: Replace StringBuffers to StringBuilders in tests

On 27/08/2021 8:42 pm, Daniel Fuchs wrote: Hi Sergei, I wouldn't bother replacing StringBuffers with StringDuilders in tests. It seems a bit gratuitous - and possibly could complicate future tests backports. But that's my personal opinion. Others might disagree. I agree with you. Complete was

Re: Replace StringBuffers to StringBuilders in tests

Hi Sergei, I wouldn't bother replacing StringBuffers with StringDuilders in tests. It seems a bit gratuitous - and possibly could complicate future tests backports. But that's my personal opinion. Others might disagree. best regards, -- daniel On 27/08/2021 11:00, Sergei Ustimenko wrote: Hi