RFR(S) : 8180805 : move RandomFactory to the top level testlibrary

http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/index.html > 308 lines changed: 110 ins; 40 del; 158 mod Hi all, this changeset introduces jdk.test.lib.RandomFactory in the top level testlibrary and updates all but java/time/ tests to use it instead of jdk.testlibrary.RandomFactory fr

Re: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in java.base & java.datatransfer module

On 27/05/2017 02:14, Hamlin Li wrote: Is someone available to review the change? I skimmed through it, crossing checking several against the docs for JDK 1.0, JDK 1.1, and JDK 1.2. I didn't spot any mistakes but I agree with Sergey, it would be good to know if this was done by creating the

RFR(S) : 8180887: move FileUtils to top level testlibrary

http://cr.openjdk.java.net/~iignatyev//8180887/webrev.00/index.html > 567 lines changed: 231 ins; 252 del; 84 mod; Hi all, could you please review this changeset which moves FileUtils class from the jdk testlibrary to the top level testlibary? webrev: http://cr.openjdk.java.net/~iignatyev/81808

Re: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in java.base & java.datatransfer module

The changes in datatransfer module looks fine. But how did you check when these classes were added? - huaming...@oracle.com wrote: > Is someone available to review the change? > > Thank you > > -Hamlin > > > On 2017/5/25 17:19, Hamlin Li wrote: > > Would you please review below patch? >

Re: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in java.base & java.datatransfer module

Is someone available to review the change? Thank you -Hamlin On 2017/5/25 17:19, Hamlin Li wrote: Would you please review below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8181082 webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/ Thank you -Hamlin

Re: RFR 8166139/10, Refactor java/net shell cases to java

Hi Roger, thanks for the comments. Please see the new webrev http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/ -Felix On 2017/5/27 3:50, Roger Riggs wrote: Hi Felix, fyi, there is a new version of webrev.ksh that provides convenient next and previous links. http://hg.openjdk.java.

Re: (10) RFR of JDK-8166142: Refactor java.io.serialization shell tests to java

Hi Roger, Thank you for catching it, new webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.02/ Thank you -Hamlin On 2017/5/27 3:30, Roger Riggs wrote: Hi Hamlin, SubclassTest.java:37: typo" excepiton" -> exception SubclassDataLossTest.java: 103/104: Adding the class loader close()

Re: JDK 10 RFR of JDK-8181126: Refactor shell test java/nio/Buffer/LimitDirectMemory.sh to java

That all looks fine to me, Amy. (You'll also need a JDK 10 Reviewer). Thanks, -Brent On 5/25/17 7:42 PM, Amy Lu wrote: java/nio/Buffer/LimitDirectMemory.sh Please review this patch to refactor the shell test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8181126 webrev: http://cr.ope

Re: RFR(XS) : 8180895 : java/security/AccessController/DoPrivAccompliceTest.java has to be improved

@summary doesn't seem to be correct, the test uses user.name system property. Otherwise, looks good for me. Artem On 05/23/2017 10:17 PM, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html 81 lines changed: 37 ins; 23 del; 21 mod; Hi all, could you pl

Re: Request Review JDK-8180574: tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failed in upgradeHashedModule() and patchHashedModule() intermittently

The test is not supposed to be intermittent. I like it to be fixed properly. Mandy > On May 26, 2017, at 1:14 PM, Brent Christian > wrote: > > Hi, Mandy > > Should "@key intermittent" be added, or is this pretty likely to resolve the > problem ? > > Thanks, > -Brent > > On 5/26/17 11:17 A

Re: Request Review JDK-8180574: tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failed in upgradeHashedModule() and patchHashedModule() intermittently

On 26/05/2017 19:17, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180574/webrev.00/ The test fails intermittently that the hash of new_m1.jar might be the same value as m1.jar that is hashed in m2. Unfortunately I haven’t managed to reproduce the test failure with my ins

Re: RFR(XS) : 8180890: move c.o.testlibrary.jsr292 classes to jdk/test/java/lang/invoke directory

Hi Igor, Looks good. Can you wrap the too long lines in: LFGarbageCollectedTest.java LFCaching/LambdaFormTestCase.java MethodHandlesTest.java PermuteArgsTest.java no need for another review. Thanks, Roger On 5/26/2017 1:39 PM, Igor Ignatyev wrote: Hi Roger, I'm fine w/ doing

Re: Request Review JDK-8180574: tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failed in upgradeHashedModule() and patchHashedModule() intermittently

Hi, Mandy Should "@key intermittent" be added, or is this pretty likely to resolve the problem ? Thanks, -Brent On 5/26/17 11:17 AM, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180574/webrev.00/ The test fails intermittently that the hash of new_m1.jar might be the s

Re: RFR 8166139/10, Refactor java/net shell cases to java

Hi Felix, fyi, there is a new version of webrev.ksh that provides convenient next and previous links. http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not make sense. Ditto: closetest/GetResourc

Re: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

On May 26, 2017, at 12:34 PM, Stuart Marks wrote: > On 5/26/17 9:17 AM, Brian Burkhalter wrote: >> Here’s one more attempt: >> >> * http://cr.openjdk.java.net/~bpb/6791812/webrev.01/ >> * http://cr.openjdk.java.net/~bpb/6791812/File.html >> >> Similar verbal de-obfuscation of other methods m

Re: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

On 5/26/17 9:17 AM, Brian Burkhalter wrote: Here’s one more attempt: * http://cr.openjdk.java.net/~bpb/6791812/webrev.01/ * http://cr.openjdk.java.net/~bpb/6791812/File.html Similar verbal de-obfuscation of other methods may be handled under other yet-to-be-file issues. OK, this looks goo

Re: (10) RFR of JDK-8166142: Refactor java.io.serialization shell tests to java

Hi Hamlin, SubclassTest.java:37: typo" excepiton" -> exception SubclassDataLossTest.java: 103/104: Adding the class loader close() calls isn't very effective since if there is an exception they are not closed and the creation in a static initializer is mismatched with main() code. It would

Re: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o) implementation efficiency

Hi Doug, >However, this technique might apply more usefully to TreeSet. True. The more I think about it, it is probably applicable to CSLS under the context where it is concurrently added to and then reaches some idle state (shutdown) and then performs the equality test. It could be port it t

Re: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for UTF-8

Indeed I did... Oh well, another day... /Claes On 2017-05-26 20:12, Martin Buchholz wrote: I think you've fallen into the trap of confusing UTF-8 and Modified UTF-8. The prevailing pattern seems to be to write an entirely new UTF-8 implementation for any performance problem involving UTF-8

Re: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for UTF-8

Isn't UNICODE::as_utf8 the version of modified-utf8? -sherman On 5/26/17, 10:58 AM, Claes Redestad wrote: Hi, various JNI methods in the JDK converts from java Strings to native encoding using JNI_GetStringPlatformChars, which has long standing optimizations for dealing with various default c

Request Review JDK-8180574: tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failed in upgradeHashedModule() and patchHashedModule() intermittently

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180574/webrev.00/ The test fails intermittently that the hash of new_m1.jar might be the same value as m1.jar that is hashed in m2. Unfortunately I haven’t managed to reproduce the test failure with my instrumented test to confirm. I propose to

Re: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for UTF-8

On 2017-05-26 20:07, Aleksey Shipilev wrote: On 05/26/2017 07:58 PM, Claes Redestad wrote: However, UTF-8 is missing, which is a shame since we have optimized utilities for converting from a String to UTF-8-encoded char* (since this is the native encoding used by HotSpot internally). Webrev: h

Re: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for UTF-8

I think you've fallen into the trap of confusing UTF-8 and Modified UTF-8. The prevailing pattern seems to be to write an entirely new UTF-8 implementation for any performance problem involving UTF-8 :-( e.g. in StringCoding. On Fri, May 26, 2017 at 10:58 AM, Claes Redestad wrote: > Hi, > > va

Re: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o) implementation efficiency

On 05/26/2017 12:51 PM, Jason Mehrens wrote: > So it should be safe to do an ordered 'list' type element comparison > if and only if you have determined that both sets/maps use the same > ordering. In your example code you are missing the check to make sure > the comparators are both null or equa

Re: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for UTF-8

On 05/26/2017 07:58 PM, Claes Redestad wrote: > However, UTF-8 is missing, which is a shame since we have optimized > utilities for converting from a String to UTF-8-encoded char* (since > this is the native encoding used by HotSpot internally). > > Webrev: http://cr.openjdk.java.net/~redestad/818

RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for UTF-8

Hi, various JNI methods in the JDK converts from java Strings to native encoding using JNI_GetStringPlatformChars, which has long standing optimizations for dealing with various default charsets. However, UTF-8 is missing, which is a shame since we have optimized utilities for converting from a

Re: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Jason, No, there is not. If there is any special formatting I almost always actually build the javadoc and test the links, etc., and these work as intended. Thanks, Brian On May 26, 2017, at 10:02 AM, Jason Mehrens wrote: > Brian, > > Is there a dangling '}' after Files.readAttributes or mi

Re: RFR(XS) : 8180890: move c.o.testlibrary.jsr292 classes to jdk/test/java/lang/invoke directory

Hi Roger, I'm fine w/ doing more clean up. I have normalized @library and reorganized imports in the all touched files. could you please take a look at new webrev: http://cr.openjdk.java.net/~iignatyev/8180890/webrev.01/index.html

Request Review: JDK-8181148: Update the jdeps tool to list exported packages instead of just internal APIs

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181148/webrev.00/ This updates an existing tool to take an option to list exported packages. This tool is not run during the build but instead used to generate a resource file checked in in the source. It’s relevant to the build tools in build.to

Re: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Brian, Is there a dangling '}' after Files.readAttributes or missing '{@link '? Jason From: core-libs-dev on behalf of Brian Burkhalter Sent: Friday, May 26, 2017 11:17 AM To: Stuart Marks Cc: core-libs-dev Subject: Re: [REVISED] JDK 9 doc-api-only RFR

Re: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o) implementation efficiency

Tenghuan He, You are correct if 'this' is a SortedMap/Set and 'o' is a SortedMap/Set then both interfaces list a clause in the top level documentation of: "This order is reflected when iterating over the sorted map's collection views" and "The set's iterator will traverse the set in ascending el

Re: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o) implementation efficiency

Thanks for the suggestion! I filed https://bugs.openjdk.java.net/browse/JDK-8181146 On Fri, May 26, 2017 at 7:21 AM, Tenghuan He wrote: > Hi, all > > I found that the equalsimplementation of > java.util.concurrent.ConcurrentSkipListSet in JDK as follows: > > public boolean equals(Object o) { >

Re: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Here’s one more attempt: http://cr.openjdk.java.net/~bpb/6791812/webrev.01/ http://cr.openjdk.java.net/~bpb/6791812/File.html Similar verbal de-obfuscation of other methods may be handled under other yet-to-be-file issues. Thanks, Brian

Re: [XS] RFR : JDK-8181145 : add platforms to test java/nio/ByteOrder/NativeOrder.java (test change)

Looks good to me! On Fri, May 26, 2017 at 7:43 AM, Baesken, Matthias wrote: > Please review this small test change . > It adds a number of platforms to the existing test jdk10 jtreg test > java/nio/ByteOrder/NativeOrder.java . > > Especially the porting platforms ppc64/ppc64le/s390x are added

[XS] RFR : JDK-8181145 : add platforms to test java/nio/ByteOrder/NativeOrder.java (test change)

Please review this small test change . It adds a number of platforms to the existing test jdk10 jtreg test java/nio/ByteOrder/NativeOrder.java . Especially the porting platforms ppc64/ppc64le/s390x are added . Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8181145/ bug : https://

Re: RFR(XS) : 8180890: move c.o.testlibrary.jsr292 classes to jdk/test/java/lang/invoke directory

Hi Igor, It would be nice if all of the @library source lines were the same (not mixed in the order). Since this is a cleanup task, I might be inclined to make the order of imports consistent within those tests but that goes beyond the simple goal of the issue. +1 Roger On 5/25/2017 9:28

JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o) implementation efficiency

Hi, all I found that the equalsimplementation of java.util.concurrent.ConcurrentSkipListSet in JDK as follows: public boolean equals(Object o) { // Override AbstractSet version to avoid calling size() if (o == this) return true; if (!(o instanceof Set)) return false;