Re: RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

Hi Bob, Adding build-dev. On 26/02/2020 6:37 am, Bob Vandette wrote: Please review this RFE that alters the visibility of JNI entrypoints to hidden when a shared library is created using static JDK libraries. RFE: https://bugs.openjdk.java.net/browse/JDK-8239563 WEBREV:

Re: VM crashed at StringTable expansion

Hi, cc'ing core-libs-dev as this seems to me like a case of "don't do that!". Reflection can be used to "shoot oneself in the foot" and I think that is the case here. That said, if we can make the VM more resilient without penalizing all the well behaved code, then we should probably do

Re: RFR [15] 8161558: ListIterator should not discard cause on exception

On 2/25/20 8:01 AM, fo...@univ-mlv.fr wrote: If the IOOBE is noise, it can be ignored. You are forcing all primary users to ignore something that is useful only for the secondary users. Given that the ratio between primary vs secondary users is at least 100 000 for 1 if not more, that's a

RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

Please review this RFE that alters the visibility of JNI entrypoints to hidden when a shared library is created using static JDK libraries. RFE: https://bugs.openjdk.java.net/browse/JDK-8239563 WEBREV: http://cr.openjdk.java.net/~bobv/8239563/webrev.00/ CSR:

Re: RFR 8214245 : (regex) Case insensitive matching doesn't work correctly for some character classes

Thank you Roger for reviewing CSR and the release note! On 2/11/20 12:49 PM, Roger Riggs wrote: Hi Ivan, Will this have enough of a compatibility concern to warrant a CSR? It will change the behavor of these cases. In the RegExTest, the failures should print which case is failing. (Line

Re: RFR 8214245 : (regex) Case insensitive matching doesn't work correctly for some character classes

Hi Ivan, The CSR and release note look fine. Roger On 2/24/20 8:54 PM, Ivan Gerasimov wrote: Thank you Roger and Joe for the feedback! May I please ask you to review the CSR draft [1] and the Release Notes [2] for this issue: [1] https://bugs.openjdk.java.net/browse/JDK-8238984 [2]

Re:

Wonder if you should not move the test into StringLatin1.newString and StringUTF16.newString to return "" if subLen [len] == 0. Then there would be an across the board benefit. > On Feb 25, 2020, at 11:43 AM, Сергей Цыпанов > wrote: > > Hello, > > current implementation of

Re: [TRIVIAL] Fast-path for String.subsring(n,n)

Hi Sergei! Wouldn't it make sense to incorporate this fast path into StringUTF16.newString/StringLatin1.newString? This way other callers of these methods will also benefit from it. In particular, StringLatin1/StringUTF16.stripLeading(), StringLatin1/StringUTF16.stripTrailing() and maybe

Re: RFR [15] 8161558: ListIterator should not discard cause on exception

- Mail original - > De: "Stuart Marks" > À: "Remi Forax" > Cc: "Martin Buchholz" , "Kiran Ravikumar" > , "core-libs-dev" > > Envoyé: Vendredi 21 Février 2020 22:53:36 > Objet: Re: RFR [15] 8161558: ListIterator should not discard cause on > exception > On 2/14/20 2:34 PM,

[no subject]

Hello, current implementation of String.substring(int,int) has a fast-path for the case when beginIndex = 0 and endIndex = length. I think there should be similar fast-path for the case beginIndex = endIndex (asuming both are valid): diff --git

[TRIVIAL] Fast-path for String.subsring(n,n)

Hello, current implementation of String.substring(int,int) has a fast-path for the case when beginIndex = 0 and endIndex = length. I think there should be similar fast-path for the case beginIndex = endIndex (asuming both are valid):

Re: [jpackage] Issue with upgrading from javapackager to jpackage on Windows

Hi James, all, Thank you for your feedback. I did try around and I think there is a jpackage upgrade ID option now. --win-upgrade-uuid — UUID associated with upgrades for this package In my case though, I think I run into some other issues. The InnoSetup installer seems not to provide any

RE: RFR: 8239559: Cgroups: Incorrect detection logic on some systems

Hi Severin, makes sense ! Maybe you could adjust the comment and add a bit of info about this . I do not need to see a new webrev . Best regards, Matthias > > What you are seeing here is a hybrid system[1]. My workstation is > hybrid as well. Legacy and hybrid systems are being detected as

Re: RFR: 8239559: Cgroups: Incorrect detection logic on some systems

Hi Matthias, On Tue, 2020-02-25 at 14:01 +, Baesken, Matthias wrote: > Hi Severin, 8239559/02 looks generally good . Thanks for the review! > However I wonder about this : > > I have a SLES15 aarch64 system with these settings : > > more /proc/cgroups > #subsys_name hierarchy

Re: jpackage current status

> On Feb 24, 2020, at 4:07 PM, Andy Herrick wrote: > > > > > then in app you can find any of the tools by using > System.getProperty("java.home") and looking in "bin" subdir. > > So in the app you can refer to any of the tools by their full path. > Not to keep dragging this on. But I

RE: RFR: 8239559: Cgroups: Incorrect detection logic on some systems

Hi Severin, 8239559/02 looks generally good . However I wonder about this : I have a SLES15 aarch64 system with these settings : more /proc/cgroups #subsys_namehierarchy num_cgroups enabled cpuset 6 1 1 cpu 8 1 1 cpuacct 8 1 1 blkio

RFE JDK-8181769 Introduce interface with type-safe equals

Hello, Is there any chance to reopen RFE JDK-8181769 https://bugs.openjdk.java.net/browse/JDK-8181769 Introduce interface with type-safe equals It was closed as Duplicate to JDK-6270657 (coll) remove/contains and "Equators" other than .equals() However it looks like misunderstanding: in fact,