Re: Fix for Javadoc errors in java.base

Hi Joe, I ran an IntelliJ inspection to find these errors. Regards, Vipin Virus-free. www.avast.com

Re: RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

Hi Joe, Thank you for the review! On 7/27/20 6:04 PM, Joe Wang wrote: Hi Naoto, Looks good to me, using the correct supplementary-aware implementation is an improvement for the impl to handle the situation. A note (probably a workaround) for the user's case, to replace invalid surrogate ch

Re: RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

Hi Naoto, Looks good to me, using the correct supplementary-aware implementation is an improvement for the impl to handle the situation. A note (probably a workaround) for the user's case, to replace invalid surrogate characters, he could have used Unicode escape sequences [\ud800-\udfff] in

Re: Fix for Javadoc errors in java.base

Hello Vipin, What tooling was used to find these errors? Running doclint against private methods too? Thanks, -Joe On 7/27/2020 12:37 PM, Vipin Sharma wrote: Hi, This patch fixes Javadoc errors in java.base, please sponsor this patch and help to create a bug id for this. I have signed OCA,

Re: RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

On 7/27/20 11:51 AM, naoto.s...@oracle.com wrote: Apart from the original issue, there was a bug in Range() method (Pattern.java:5795), so it is fixed along. Created a test case for this: --- a/test/jdk/java/util/regex/SupplementaryTestCases.txt +++ b/test/jdk/java/util/regex/SupplementaryTest

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

Thank you Erik! Regards, Ningsheng On 7/23/20 9:06 PM, Erik Joelsson wrote: Hello Ningsheng, Build change looks good. /Erik On 2020-07-23 01:02, Ningsheng Jian wrote: Hi Vladimir, Thanks for pointing out this. Yes, I missed that change in shared code. I've regenerated the webrev, with Gen

Re: RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

So from your (and Alan's and Lance's) point of view does it still make sense to create a JEP for this enhancement and have a broader discussion about its usefulness on the "discuss" list? Or is your rejection definitive, no matter what the outcome of such a discussion will be? I think it's

Fix for Javadoc errors in java.base

Hi, This patch fixes Javadoc errors in java.base, please sponsor this patch and help to create a bug id for this. I have signed OCA, this is my third patch. --- old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java 2020-07-25 23:46:21.233726447 +0530 +++ new/src/java.base/shar

RFR: 8247546: Pattern matching does not skip correctly over supplementary characters

Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8247546 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8247546/webrev.00/ On compiling the regex pattern, the start node is chosen based on the pattern, i.e, whether it involv

Re: [15] RFR(S) : 6501010 : test/java/io/File/GetXSpace.java fails on Windows

ping? -- Igor > On Jul 20, 2020, at 11:28 AM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//6501010/webrev.00 >> 98 lines changed: 18 ins; 31 del; 49 mod; > > Hi all, > > could you please review this small fix to make java/io/File/GetXSpace.java > work again on windows? >

Re: No way to disable Java Container Metrics

On Mon, 2020-07-27 at 11:52 -0400, Bob Vandette wrote: > > On Jul 27, 2020, at 11:32 AM, Severin Gehwolf wrote: > > > > Hi Bob, > > > > On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote: > > > I’ve been monitoring the discussion on your jdk8u alias and I can’t help > > > wondering if > > >

Re: No way to disable Java Container Metrics

> On Jul 27, 2020, at 11:32 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote: >> I’ve been monitoring the discussion on your jdk8u alias and I can’t help >> wondering if >> my original decision to provide two different implementations of this

Re: No way to disable Java Container Metrics

Hi Bob, On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote: > I’ve been monitoring the discussion on your jdk8u alias and I can’t help > wondering if > my original decision to provide two different implementations of this > container detection > logic was the best way to go. > > I didn’t wan

Re: Type inference: bug or feature?

Hello, Thank you for your input! Indeed, the reason of such a choice sounds legit and confirms the idea of having more safety. I just came with this situation while playing around with Java, and I was surprised; But it definitely was an academic example that was not planned for real use cases! ;-

Re: Type inference: bug or feature?

- Mail original - > De: "Maurizio Cimadamore" > À: "Justin Dekeyser" , "core-libs-dev" > > Envoyé: Lundi 27 Juillet 2020 12:26:40 > Objet: Re: Type inference: bug or feature? > CC'ing compiler-dev > > Hi Justin, > the behavior you are observing is normal. For a Java expression to be >

Re: Type inference: bug or feature?

Dear all, Okay, thank you very much for the many references you gave me! Indeed I wasn't aware of this specificity of cast expressions you mentioned, very interesting ! Sorry for the long email chain, though! Have a nice day, Justin Dekeyser On Mon, Jul 27, 2020 at 12:26 PM Maurizio Cimadamor

Re: RFR(M): 8249963: Make the zlib implementation selectively configurable at startup

Hi Brian, thanks a lot for your detailed answer. I've replied to some of your comments inline but I don't expect another answer because it seems that all arguments have been exchanged and we're happily agreeing to disagree :) There's just a single remaining question for which I would appreciate a

Re: Type inference: bug or feature?

On 27/07/2020 11:26, Maurizio Cimadamore wrote: CC'ing compiler-dev Hi Justin, the behavior you are observing is normal. For a Java expression to be able to be influenced by type inference it has to be a poly expression (where poly stands for _many_ as in, the same expression can have many

Re: Type inference: bug or feature?

CC'ing compiler-dev Hi Justin, the behavior you are observing is normal. For a Java expression to be able to be influenced by type inference it has to be a poly expression (where poly stands for _many_ as in, the same expression can have many types). At the time we did Java 8 we briefly cons

[PATCH] Use byte[] instead of char[] in Integer.digits

Hello, I'd like to contribute this trivial patch to JDK. The idea behind it is that with compact strings we don't need char[] when all symbols are ASCII. This allows to slightly reduce footprint of java.lang.Integer.class and drop casts from char to byte. I've measured performance of patched c

Re: Type inference: bug or feature?

Hello, Again, thanks for the prompt response! Well, I'm not really sure about the answer but, to my understanding, if this: List x = emptyList(Number.class); compiles correctly (thus U inferred as Number, V inferred as Integer as expected), then why this List x = (List) emptyList(Number.class); d

Re: Type inference: bug or feature?

* Justin Dekeyser: > Nevertheless, the point was not really about list stuffs, and is not > related to the lack of co/contra variance. > You may replace List with any other generic class Foo and Integer > and Number with any other class satisfying the same inheritance > relations. Ahh, well, but

Re: Type inference: bug or feature?

Hello, Thanks for the answer. Nevertheless, the point was not really about list stuffs, and is not related to the lack of co/contra variance. You may replace List with any other generic class Foo and Integer and Number with any other class satisfying the same inheritance relations. The behavior

Re: Type inference: bug or feature?

* Justin Dekeyser: > Then the following codes does not compile (for the same reason): > > var x = (List) emptyList(Number.class); > List x = (List) emptyList(Number.class); > > incompatible types: List cannot be converted to List > > however, the following do compile: > > var x = emptyList(Number.