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

On 20/09/2018 01:34, Joe Wang wrote: : The purpose of toRealPath is so that we can do a quick Path comparison by following symlinks if any, I'll add a test to compare a file and its symbolic link. You don't need it. If two non-equals paths locate the same file then mismatch will do the right

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

On 19/09/2018 22:02, Roger Riggs wrote: This came up in off-line discussions, it seems unlikely that two files will differ only in the last of 100Mb and it will require a separate code path that will very infrequently be exercised.  So I'd still to a single technique even if it is slightly slowe

Re: [12] RFR 8210339: Add 10 JNDI tests to com/sun/jndi/dns/FedTests/

Hi Chris, tests  looks good to me. Thanks, On Tuesday 04 September 2018 12:00 PM, Chris Yin wrote: Please review the changes to add 10 JNDI tests to com/sun/jndi/dns/FedTests/ in OpenJDK, thanks bug: https://bugs.openjdk.java.net/browse/JDK-8210339 webrev: http://cr.openjdk.java.net/~xyin/

Re: [12] RFR 8210339: Add 10 JNDI tests to com/sun/jndi/dns/FedTests/

Thank you, Vyom Regards, Chris > On 20 Sep 2018, at 4:55 PM, vyom tewari wrote: > > Hi Chris, > > tests looks good to me. > > Thanks, > > > > On Tuesday 04 September 2018 12:00 PM, Chris Yin wrote: >> Please review the changes to add 10 JNDI tests to com/sun/jndi/dns/FedTests/ >> in Open

[12] RFR 8199931: java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"

Please review below minor change for 8199931, thanks A little explanation about the change here, since the failure samples are too less (seems too hard to repro), so below scenario which caused the failure is a guess. MultcastSocket constructor set reuse address true by default, when call “new

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

Hi Joe, The spec reads very well to me. On the implementation side: 114 } else if (nRead1 != nRead2) { 115 int len = Math.min(nRead1, nRead2); 116 // there's always a mismatch when nRead1 != nRead2 117 return totalRead + 118

Re: RFR - JDK-8202442 - String::unescape (Code Review)

> On 19 Sep 2018, at 23:21, Stuart Marks wrote: > > ... > > 2979 * Each unicode escape in the form \u is translated to the > 2980 * unicode character whose code point is {@code 0x}. Care should > be > 2981 * taken when using UTF-16 surrogate pairs to ensure that the hig

[12] RFR 8199931: java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"

Loop net-dev since the test is under java/net, thanks > On 20 Sep 2018, at 5:30 PM, Chris Yin wrote: > > Please review below minor change for 8199931, thanks > > A little explanation about the change here, since the failure samples are too > less (seems too hard to repro), so below scenario wh

Re: [12] RFR 8199931: java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"

Thank you for looking at this issue Chris Y. I don’t disagree with the changes, but if you want to confirm your suspicion, that the same port is being reused, then printing out the client’s bound port would do that ( since the servers port is already printed in the logs ). If such a change was i

Re: RFR - JDK-8202442 - String::unescape (Code Review)

> On Sep 19, 2018, at 7:21 PM, Stuart Marks wrote: > > > > On 9/18/18 10:51 AM, Jim Laskey wrote: >> Please review the code for String::unescape. Used to translate escape >> sequences in a string, typically in a raw string literal, into characters >> represented by those escapes. >> webrev

Re: RFR - JDK-8202442 - String::unescape (Code Review)

Modified as per Stuart's suggestion. > On Sep 20, 2018, at 7:45 AM, Chris Hegarty wrote: > > >> On 19 Sep 2018, at 23:21, Stuart Marks wrote: >> >> ... >> >> 2979 * Each unicode escape in the form \u is translated to the >> 2980 * unicode character whose code point is {@code 0x

Re: RFR - JDK-8210717 String::detab, String::entab (Code Review)

Caught that. Thx. > On Sep 19, 2018, at 5:12 PM, Jonathan Gibbons > wrote: > > It should really be "if n is less than or equal to zero" (equal, not equals) > > -- Jon > > > On 09/19/2018 05:35 AM, Jim Laskey wrote: >> Thank you. Updated. >> >>> On Sep 19, 2018, at 4:20 AM, Andrej Golovnin

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

Thanks Roger , Naoto and Stephen for the review and valuable inputs. Here is the updated webrev for review : http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/ Thanks, Pallavi Sonal -Original Message- From: Stephen Colebourne Sent: Thursday, September 20, 2018 2:50 AM To: core-libs

Re: RFR - JDK-8203703 String::transform (CSR Review)

On Wed, 19 Sep 2018 at 14:51, Jim Laskey wrote: > HTMLDocument html = ` > > >Hello World. > > > `.transform(HTMLDocument::parse); I can

Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

Thanks for the update. The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid. eg. a negative offset at MAX or a positive offset at MIN. The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to c

Re: RFR - JDK-8202442 - String::unescape (Code Review)

revised webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev-02/index.html > On Sep 19, 2018, at 11:57 AM, Jim Laskey wrote: > > Will do. > > >> On Sep 19, 2018, at 11:42 AM, Jonathan Gibbons >> wrote: >> >> If you're making the change, then you might add a test case based on Jan's >

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Ping! Could I please get a review of this latest version of the JEP? This includes responses to all previous comments with changes made both to the JEP and the draft implementation. I would like to get this into JDK12 if at all possible regards, Andrew Dinn --- Senior Principal Softwa

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

On Sep 19, 2018, at 5:59 PM, Joe Wang wrote: > I'll do some performance testing for both cases, FileChannel/direct buffer > and possible checksum comparison, although, as you said, the later might not > work since we need to be 100%. The probability of false positives is likely > extremely l

Re: RFR(XS): 8210925 : move bytecode testlibrary to top-level testlibrary

As the bytecode library is evolving, I'd recommend to move the bytecode library when we start using it in the hotspot tests and update it with the latest version. Mandy On 9/19/18 3:54 PM, Igor Ignatyev wrote: Hi Mandy, yes, eventually I'd like to see this library being used in place of ASM i

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

On 9/20/18, 12:07 AM, Alan Bateman wrote: On 20/09/2018 01:34, Joe Wang wrote: : The purpose of toRealPath is so that we can do a quick Path comparison by following symlinks if any, I'll add a test to compare a file and its symbolic link. You don't need it. If two non-equals paths locate

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Hi Alan I'm a middleware engineer (transaction engine, message queues, etc) and I evolved the current API design whilst making some of Red Hat's Jakarta EE stack work with persistent memory. It's a good fit for our needs because it pretty much matches they way we currently do off-heap and p

Re: Source file launcher - Handling of pre-compiled classes of the source file

This is tracked as JDK-8210839 https://bugs.openjdk.java.net/browse/JDK-8210839 -- Jon On 09/15/2018 10:04 AM, Jonathan Gibbons wrote: Jaikiran, This issue is on our radar; there is no need for any additional action on your part at this point. -- Jon On 9/14/18 7:50 PM, Jaikiran Pai wrote:

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

On 9/20/18, 12:12 AM, Alan Bateman wrote: On 19/09/2018 22:02, Roger Riggs wrote: This came up in off-line discussions, it seems unlikely that two files will differ only in the last of 100Mb and it will require a separate code path that will very infrequently be exercised. So I'd still to a

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

Hi Daniel, You're right, line 115 is not needed. I'll add a couple of test cases to cover the route. Best, Joe On 9/20/18, 2:36 AM, Daniel Fuchs wrote: Hi Joe, The spec reads very well to me. On the implementation side: 114 } else if (nRead1 != nRead2) { 115

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

On 9/20/18, 8:10 AM, Brian Burkhalter wrote: On Sep 19, 2018, at 5:59 PM, Joe Wang > wrote: I'll do some performance testing for both cases, FileChannel/direct buffer and possible checksum comparison, although, as you said, the later might not work since we

RFR: 8210275: Source Launcher should fail if --source is used without a source file

Please review a small fix to the source launcher that showed up as the launcher sometimes ignoring the --source option and finding/running a class on the class path. The problem occurs when the classpath is set after the --source option, causing LM_CLASS mode to override the setting of LM_SOURCE.

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

On 9/19/18 7:46 PM, Jaikiran Pai wrote: Thank you. More of a FYI and if it matters from a process point of view - in a couple of my earlier contributions, the sponsors have used the "Contributed-by" line to be "Jaikiran Pai " like here http://hg.openjdk.java.net/jdk/jdk/rev/6c394ed56b07. I don

Re: SSL session cache default maximum number of entries

I've filed https://bugs.openjdk.java.net/browse/JDK-8210985. Thanks for looking into this. Paul On 9/17/18, 8:37 AM, "Sean Mullan" wrote: On 9/12/18 2:25 PM, Hohensee, Paul wrote: > Thanks very much for investigating. We're aware that the cache size can be set by the user, but many o

Re: RFR: 8210275: Source Launcher should fail if --source is used without a source file

On 9/20/18 12:08 PM, Jonathan Gibbons wrote: Please review a small fix to the source launcher that showed up as the launcher sometimes ignoring the --source option and finding/running a class on the class path. The problem occurs when the classpath is set after the --source option, causing LM_CL

[12] RFR: 8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8210633 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8210633/webrev.00/ As the submitter pointed out, the overload method that takes Chronology needs to be overridden in t

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

On 9/19/18 11:48 AM, Joe Wang wrote: After much discussion and 10 iterations of reviews, this proposal has evolved from what was the original isSameContent method to a mismatch method. API-wise, a compare method was also considered as it looked like just a short step forward from mismatch, h

Re: [12] RFR 8199931: java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"

Hi, Chris H Thanks for your suggestion, changed as below to just print client bound port as you mentioned. Certainly, this is not a fix, just add some debug info, hope we could get next failure sample to prove the guess :) New Changes: diff -r c26fbf1434c4 test/jdk/java/net/MulticastSocket/Un

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

On 21/09/18 1:04 AM, Stuart Marks wrote: > > > Since you mentioned it I'll proceed with "Jaikiran Pai > " since that looks a bit more "official". Sounds fine to me and yes it indeed is a bit more official one. Thank you. -Jaikiran

Re: [PATCH] JDK-7033681 - Improve the documentation of Arrays.asList

On 9/20/18 7:01 PM, Jaikiran Pai wrote: Since you mentioned it I'll proceed with "Jaikiran Pai " since that looks a bit more "official". Sounds fine to me and yes it indeed is a bit more official one. Thank you. OK, CSR request posted: https://bugs.openjdk.java.net/browse/JDK-8210991 Ca

Re: [12] RFR 8199931: java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"

Looks good. Thanks. -Chris > On 21 Sep 2018, at 02:51, Chris Yin wrote: > > Hi, Chris H > > Thanks for your suggestion, changed as below to just print client bound port > as you mentioned. Certainly, this is not a fix, just add some debug info, > hope we could get next failure sample to prov