RFR of JDK-8202291,java/rmi/Naming/LookupIPv6.java failed with Connection refused

would you please review the patch? bug: https://bugs.openjdk.java.net/browse/JDK-8202291 webrev: http://cr.openjdk.java.net/~mli/8202291/webrev.00/ In original code, there is a window between get registry and rebind which could cause connection refuse. Thank you -Hamlin

Re: RFR: 8201650: Move iteration order randomization of unmodifiable Set and Map to iterators

On 4/18/18 8:20 AM, Claes Redestad wrote: please review this change that moves the use of SALT to iterator creation, which would allow for certain startup optimizations in the future. Bug: https://bugs.openjdk.java.net/browse/JDK-8201650 Webrev:

Re: Review Request JDK-8201793: (ref) Reference object should not support cloning

On 4/28/18 6:08 AM, Kim Barrett wrote: On Apr 26, 2018, at 10:16 AM, mandy chung wrote: The semantics of cloning a Reference object is not clearly defined. In addition, it is questionable whether it can be meaningfully supported in particular with concurrent

Re: jdk-submit is offline until Monday

I should have added that the CI testing system is also offline, so any pushes won't hit our internal testing until sometime Monday. David On 28/04/2018 9:19 AM, David Holmes wrote: Just a heads up that due to scheduled maintenance the systems used by jdk-submit will be offline until Monday

jdk-submit is offline until Monday

Just a heads up that due to scheduled maintenance the systems used by jdk-submit will be offline until Monday morning Pacific Time US. David

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

On 4/27/2018 12:50 PM, fo...@univ-mlv.fr wrote: - Mail original - De: "Joe Wang" À: "Remi Forax" , "Alan Bateman" Cc: "nio-dev" , "core-libs-dev" Envoyé:

Re: Review Request JDK-8201793: (ref) Reference object should not support cloning

> On Apr 26, 2018, at 10:16 AM, mandy chung wrote: > > The semantics of cloning a Reference object is not clearly defined. In > addition, it is questionable whether it can be meaningfully supported in > particular with concurrent reference processing. > > The

Re: RFR 8197388: Added not existing bug id in jdk/ProblemList.txt

Hi, Could you CC any client alias? —Thanks, Andrei > On 26 Apr 2018, at 11:51, Andrey Nazarov wrote: > > Hi, > > Please review patch that fixes typo in bug id. > > diff -r 3661f31c6df4 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Thu Apr 26

Re: [11] RFR:JDK-8179071:Month value is inconsistent between CLDR and Java in some special locales

Looks good. Naoto On 4/27/18 5:32 AM, Rachna Goel wrote: One correction: E.g "pa-PK" wil be replaced by "pa-Arab-PK", as former is a deprecated/legacy tag. On 4/27/18 12:05 PM, Rachna Goel wrote: Hi, Kindly review the fix for JDK-8179071. Bug :

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

- Mail original - > De: "Joe Wang" > À: "Remi Forax" , "Alan Bateman" > Cc: "nio-dev" , "core-libs-dev" > > Envoyé: Vendredi 27 Avril 2018 21:21:01 > Objet: Re:

Re: Update to the Double::toString(double) Javadoc

Hi Joe, so I beg Brian to get in touch with me for the CSR review. I'm familiar with the paper of Steele and White. For background on the design of my contribution see [1]. Greetings Raffaello [1] https://9b7022c5f9.files.wordpress.com/2018/04/todec.pdf On 2018-04-27 20:58, joe darcy

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

Hi Rémi, Alan, I'm not sure we'd want to replace system dependent line separators with '\n'. There are cases as you described where the replacement makes sense. However,  there are other cases too. For example, the purpose is to read, edit a text file and then write it back. If this is on

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

On 4/27/2018 4:13 AM, Alan Bateman wrote: On 27/04/2018 05:50, Joe Wang wrote: Hi, We're looking into adding methods to Files to read a file into a String/write a String to a file. Below is the current proposal. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8201276

Re: Update to the Double::toString(double) Javadoc

Hello Raffaello, On 4/27/2018 7:39 AM, raffaello.giulie...@gmail.com wrote: Hi, as may be known, the current Javadoc for Double::toString(double) is not specific enough. As a consequence, different implementations can return different results. To see this, here are some quotes from the

Re: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

Hei Alan and David, thanks for pointing me to the issue, I have only searched the release notes for u172 by accident. The issue is mainly during builds. I run my library on multiple CI servers to cover Windows/Linux and different Java versions from 6-11. Unfortunately, I have not full control

Re: Review Request JDK-8201793: (ref) Reference object should not support cloning

> On Apr 26, 2018, at 11:03 PM, mandy chung wrote: > > > > On 4/27/18 3:35 AM, Paul Sandoz wrote: >> Hi Mandy, >> >> This looks reasonable. I suspect external subtypes of the j.l.ref types are >> extremely rare (grep code reports no derived types) and of those it

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

On Fri, Apr 27, 2018 at 5:01 PM, Baesken, Matthias wrote: >> I see tons of exports listed, most of which do not have the static >> keyword. So, I would expect them to be exported from their compilation >> unit, but not from the linked shared library? Am I making a

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

> I see tons of exports listed, most of which do not have the static > keyword. So, I would expect them to be exported from their compilation > unit, but not from the linked shared library? Am I making a thinking > error here? Hi Thomas , I see "a ton" of exported symbols as well when looking

Update to the Double::toString(double) Javadoc

Hi, as may be known, the current Javadoc for Double::toString(double) is not specific enough. As a consequence, different implementations can return different results. To see this, here are some quotes from the Javadoc. It asks: "How many digits must be printed for the fractional part of m or

Re: [11] RFR:JDK-8179071:Month value is inconsistent between CLDR and Java in some special locales

One correction: E.g "pa-PK" wil be replaced by "pa-Arab-PK", as former is a deprecated/legacy tag. On 4/27/18 12:05 PM, Rachna Goel wrote: Hi, Kindly review the fix for JDK-8179071. Bug : https://bugs.openjdk.java.net/browse/JDK-8179071 Patch:

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

Hi Alan, People do not read the documentation. So adding something in the documentation about when a method should be used or not is never a solution. Here the user want a String and provides a charset so you have no way but to decode the content to substitute the line separator. cheers, Rémi

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

This seems to promote the wrong way to do such thing, the usual use case is that you want to compare the content of a well know file with the content of a bunch of other files, so hashing is better. Rémi - Mail original - > De: "Joe Wang" > À: "nio-dev"

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

On 27/04/2018 12:29, Remi Forax wrote: I think that having a readString that includes OS dependent line separators is a mistake, Java does a great job to try to shield the developer from the kind of things that makes programs behave differently on different platforms. readString should

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

On 27/04/2018 05:51, Joe Wang wrote: Hi, Considering extending isSameFile to add isSameContent to Files. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 webrev: http://cr.openjdk.java.net/~joehw/jdk11/8202285/webrev/ specdiff:

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

I think that having a readString that includes OS dependent line separators is a mistake, Java does a great job to try to shield the developer from the kind of things that makes programs behave differently on different platforms. readString should subtitute (\r)?\n to \n otherwise either people

Re: RFR (JDK11/NIO) 8201276: (fs) Add methods to Files for reading/writing a string from/to a file

On 27/04/2018 05:50, Joe Wang wrote: Hi, We're looking into adding methods to Files to read a file into a String/write a String to a file. Below is the current proposal. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8201276 webrev:

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

Hi Joe, I wonder if the method `isSameContent` should be named `haveSameContents` so as to read more fluently in English. Cheers, Jonathan On 27 April 2018 at 11:58, Daniel Fuchs wrote: > Hi Joe, > > On the specification side, I think I would reword the API >

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

Hi Joe, On the specification side, I think I would reword the API documentation to first explain how the method checks the content of the two files. The fact that it doesn't check the actual content if the two files are 'the same' is kind of an optimization. So I would suggest to invert the

Re: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

On 27/04/2018 10:10, David Holmes wrote: Hi Rafael, On 27/04/2018 6:12 PM, Rafael Winterhalter wrote: Hello, I was wondering if the change in ParameterizedType::toString was intended. https://bugs.openjdk.java.net/browse/JDK-8054213 See also the discussion from June 2016 [1] on this

Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

If this really stays this way and reads all bytes into memory it should at least state so, as this can easily overflow heap. Besides the Javadoc is pretty specific but fails to mention the size comparison. Greetings Bernd Gruss Bernd -- http://bernd.eckenfels.net

Re: Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

Hi Rafael, On 27/04/2018 6:12 PM, Rafael Winterhalter wrote: Hello, I was wondering if the change in ParameterizedType::toString was intended. https://bugs.openjdk.java.net/browse/JDK-8054213 Cheers, David - I just found my to break after an update due to a test relying on a certain

Changed behavior of ParameterizedTypeImpl::toString in 1.8.0_171

Hello, I was wondering if the change in ParameterizedType::toString was intended. I just found my to break after an update due to a test relying on a certain value for this method. My example is: public abstract class AbstractTypeDescriptionGenericTest { public static class

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph wrote: > Hi Thomas, > > let me cite one section from the article: > > -- > > Visibility attribute and backward compatibility on AIX > > As we know from the previous article, on

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

Hi Thomas, let me cite one section from the article: -- Visibility attribute and backward compatibility on AIX As we know from the previous article, on AIX, symbols are not visible by default unless we export them at the linking stage, either

Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

Hi Christoph On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph wrote: > Hi Thomas, > > Look at this blog: > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html > > if I understand it correctly, the xlc 12 default behavior should be

Re: (M) RFR: 8200167: Validate more special case invocations

Hi David, On 27.04.2018 00:04, David Holmes wrote: >> src/hotspot/share/c1/c1_Canonicalizer.cpp >> ... >>   void Canonicalizer::do_CheckCast  (CheckCast*   x) { >> -  if (x->klass()->is_loaded()) { >> +  if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check()) >> >> It seems

[11] RFR:JDK-8179071:Month value is inconsistent between CLDR and Java in some special locales

Hi, Kindly review the fix for JDK-8179071. Bug : https://bugs.openjdk.java.net/browse/JDK-8179071 Patch: http://cr.openjdk.java.net/~rgoel/JDK-8179071/webrev.03/index.html Fix is to parse and store language aliases( Deprecated and Legacy ) from CLDR's SupplemetalMetaData file. At run time,

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

Hi Thomas, Look at this blog: https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html if I understand it correctly, the xlc 12 default behavior should be like what we'd expect from -qvisibility=hidden. Best regards Christoph > -Original Message- >

Re: Review Request JDK-8201793: (ref) Reference object should not support cloning

On 4/27/18 3:35 AM, Paul Sandoz wrote: Hi Mandy, This looks reasonable. I suspect external subtypes of the j.l.ref types are extremely rare (grep code reports no derived types) and of those it would likely be even rarer for those subtypes to implement Cloneable, and for that functionality