Re: jdk10 RFR of JDK-8180732: add test to check temp file permission

Thank you for review Brent. I still need a official reviewer to review the change. Thank you -Hamlin On 2017/5/24 23:59, Brent Christian wrote: Looks fine to me, Hamlin. Thanks, -Brent On 5/24/17 2:18 AM, Hamlin Li wrote: Hi Roger, Brent, Thank you for reviewing, please check new webrev

Re: 9 doc-api-only RFR of JDK-8180807: java.io.Serializable class-level readObject description error

Got it, will push the change soon. Thank you -Hamlin On 2017/5/25 1:06, Roger Riggs wrote: +1 On 5/24/2017 7:53 AM, Chris Hegarty wrote: On 24 May 2017, at 10:30, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8180807 webrev

9 doc-api-only RFR of JDK-8180807: java.io.Serializable class-level readObject description error

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8180807 webrev: http://cr.openjdk.java.net/~mli/8180807/webrev.00/ Thank you -Hamlin

Re: jdk10 RFR of JDK-8180732: add test to check temp file permission

to the @bug tag I'm not sure this adds much because the bug report just is moving to test to the open repo. You will also need approval from a JDK 10 Reviewer. Roger Thanks, -Brent On 5/21/17 9:26 PM, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openj

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

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8166142 webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/ Thank you -Hamlin

jdk10 RFR of JDK-8180732: add test to check temp file permission

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8180732 webrev: http://cr.openjdk.java.net/~mli/8180732/webrev.00/ Thank you -Hamlin

Re: RFR 8087307/9, new tests for ServiceLoader updates for module

Hi Felix, I have some comments as below: 1. Possible test gaps for Locating Order 1.1 providers in named module have high priority than providers in unnamed 1.2 ServiceLoader.load​(ModuleLayer layer, Class service) is not tested 2. Possible test gap for automatic module, it i

Re: JDK 9 RFR of JDK-8174171: Move spliterator testing of BitSet into big memory tests BitSetStreamTest

Thank you for explanation Amy. you still need a reviewer. Thank you -Hamlin On 2017/4/21 12:47, Amy Lu wrote: Thank you Hamlin for your comments. On 4/20/17 6:23 PM, Hamlin Li wrote: Hi Amy, Thank you for taking this. Have some minor comments about BitSetStreamTest.java 1. is below

Re: JDK 9 RFR of JDK-8174171: Move spliterator testing of BitSet into big memory tests BitSetStreamTest

Hi Amy, Thank you for taking this. Have some minor comments about BitSetStreamTest.java 1. is below line necessary? or 2g big enough? 51 * @requires os.maxMemory >= 2g 2. I'm not sure if Xmx1024m should be a bigger value. 55 * @run testng/othervm -Xms512m -Xmx1024m 3. spliteratorOfIntDataP

Re: RFR of JDK-8145163: Test Task for Platform Logging API and Service -- for moduralization

On 2017/4/14 18:51, Daniel Fuchs wrote: On 14/04/2017 11:49, Hamlin Li wrote: Since this is a test development, I think it does not have to go through the JDK 9 ramp down 2 approval procedures, I suppose now I'm OK to push the code as usual? That's my understanding as well. Hi Da

Re: RFR of JDK-8145163: Test Task for Platform Logging API and Service -- for moduralization

They look good to me! I'm particularly happy to see that some of them tests the API with a smaller image built with jlink. None of the existing logging tests did that! best regards -- daniel On 14/04/2017 07:33, Hamlin Li wrote: Would you please review the below patch?

RFR of JDK-8145163: Test Task for Platform Logging API and Service -- for moduralization

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8145163 webrev: http://cr.openjdk.java.net/~mli/8145163/webrev.00/ Thank you -Hamlin

RFR of JDK-8176865: overridden api has a wrong since value in java.base module

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176865 webrev: http://cr.openjdk.java.net/~mli/8176865/webrev.00/ Thank you -Hamlin

Re: RFR of JDK-8176563: @since value errors in apis of java.base/java.logging module

Hi, Thank you for reviewing, as StackFramePermission was just removed in JDK-8176815, so I remove the @since change for StackFramePermission, and the rest code change is pushed. Thank you -Hamlin On 2017/3/15 19:55, Alan Bateman wrote: On 15/03/2017 11:35, Daniel Fuchs wrote: Hi Hamlin

Re: RFR of JDK-8176563: @since value errors in apis of java.base/java.logging module

BTW, I did *remove* the unnecessary @since for ObjectInputFilter.checkInput. :-) Thank you -Hamlin On 2017/3/15 11:34, Hamlin Li wrote: Hi everyone, Thanks a lot for the patient review and comments, I think you're right to remove @since when overriding methods, I will also adjust the

Re: RFR of JDK-8176563: @since value errors in apis of java.base/java.logging module

essible is just WRONG! David On 15/03/2017 2:06 AM, Martin Buchholz wrote: On Tue, Mar 14, 2017 at 12:46 AM, Hamlin Li wrote: @since *since-text* Introduced in JDK 1.1 Adds a *Since* heading with the specified since-text value to the generated documentation. The text has no special int

Re: RFR of JDK-8176721: @since value errors java.sql module

ur tool needs to somehow take this into account. I think the rest of the changes look good but one to make another pass after some coffee :-) B est Lance On Mar 14, 2017, at 2:40 AM, Hamlin Li <mailto:huaming...@oracle.com>> wrote: Would you please review the below patch? bug: htt

Re: RFR of JDK-8176566: @since value errors in types of java.base module

Hi Martin, I update the webrev in place to remove blank lines between tags, http://cr.openjdk.java.net/~mli/8176566/webrev.00/ Thank you -Hamlin On 2017/3/14 13:16, Hamlin Li wrote: Hi Martin, On 2017/3/14 11:53, Martin Buchholz wrote: Thanks, Thank you. 10 years ago I fixed most of

Re: RFR of JDK-8176563: @since value errors in apis of java.base/java.logging module

On 2017/3/14 15:46, Hamlin Li wrote: Hi Martin, On 2017/3/14 15:06, Martin Buchholz wrote: I wouldn't put a blank line between javadoc tags. Will fix it. Hi Martin, Just update webrev in place to remove blank lines, webrev still at http://cr.openjdk.java.net/~mli/8176563/webr

Re: RFR of JDK-8176563: @since value errors in apis of java.base/java.logging module

amlin I don't remember which way I went 10 years ago - you might investigate. On Mon, Mar 13, 2017 at 11:40 PM, Hamlin Li <mailto:huaming...@oracle.com>> wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176563 <h

Re: RFR of JDK-8176566: @since value errors in types of java.base module

Hi Martin, On 2017/3/14 15:09, Martin Buchholz wrote: An automated tool for detecting @since mistakes needs to be run every release. So it's important to make it available as open source. For this part, I can not give you the answer right now, I can only promise I will let you updated in case

RFR of JDK-8176563: @since value errors in apis of java.base/java.logging module

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176563 webrev: http://cr.openjdk.java.net/~mli/8176563/webrev.00/ Thank you -Hamlin

RFR of JDK-8176721: @since value errors java.sql module

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176721 webrev: http://cr.openjdk.java.net/~mli/8176721/webrev.00/ Thank you -Hamlin

Re: RFR of JDK-8176566: @since value errors in types of java.base module

it during a release rampdown. :-) Thank you -Hamlin On Mon, Mar 13, 2017 at 8:44 PM, Hamlin Li <mailto:huaming...@oracle.com>> wrote: On 2017/3/14 11:25, Martin Buchholz wrote: Hi Hamlin, You probably did this using a tool - what is it? Is the tool part of openjdk?

Re: RFR of JDK-8176566: @since value errors in types of java.base module

8164058 <https://bugs.openjdk.java.net/browse/JDK-8164058>, so consider taking ownership of that bug. Sure, I will discuss with current owner of the issue. Thank you -Hamlin On Mon, Mar 13, 2017 at 8:11 PM, Hamlin Li <mailto:huaming...@oracle.com>> wrote: Would you please review th

RFR of JDK-8176566: @since value errors in types of java.base module

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176566 webrev: http://cr.openjdk.java.net/~mli/8176566/webrev.00/ Thank you -Hamlin

9 RFR of JDK-8176337: Mark several tests as intermittently failing

Would you please review below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176337 webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/ These tests are failing intermittently, they should be marked accordingly with @key intermittent java/nio/channels/FileChannel/Transfer.j

RFR of JDK-8174698: Fix @since in module-info.java in dev/corba repo

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8174698 webrev: http://cr.openjdk.java.net/~mli/8174698/webrev.00/ Thank you -Hamlin

RFR of JDK-8174697: Fix @since in module-info.java in dev/jaxws repo

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8174697 webrev: http://cr.openjdk.java.net/~mli/8174697/webrev.00/ Thank you -Hamlin

RFR of JDK-8174696: Fix @since in module-info.java in dev/jaxp repo

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8174696 webrev: http://cr.openjdk.java.net/~mli/8174696/webrev.00/ Thank you -Hamlin

Re: RFR of JDK-8173957: Fix @since in module-info.java in dev/jdk repo

On 2017/2/9 20:22, Alan Bateman wrote: On 09/02/2017 07:24, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8173957 webrev: http://cr.openjdk.java.net/~mli/8173957/webrev.00/ Looks okay, it would be good to add it to the modules in the

RFR of JDK-8173957: Fix @since in module-info.java in dev/jdk repo

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8173957 webrev: http://cr.openjdk.java.net/~mli/8173957/webrev.00/ Thank you -Hamlin

RFR of JDK-8173326: Problem list java/rmi/registry/readTest/CodebaseTest.java on Windows

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8173326 Thank you -Hamlin diff -r a468135ebe8e test/ProblemList.txt --- a/test/ProblemList.txtTue Jan 24 18:41:36 2017 -0800 +++ b/

Re: RFR of JDK-8171142: jdk_rmi registry test fail to clean up on failure

Note: on Windows there is no difference between Process.destroy vs Process.destroyForcibly, but on Linux it it is the difference between kill -15 and kill -9. Using destroyForcibly would be more certain as to the death of the subprocess. Otherwise looks fine Thanks, Roger On 1/23/2017 1:38 AM,

RFR of JDK-8171142: jdk_rmi registry test fail to clean up on failure

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171142 webrev: http://cr.openjdk.java.net/~mli/8171142/webrev.00/ Thank you -Hamlin

RFR of JDK-7146543: TEST_BUG: java/rmi/registry/readTest/readTest.sh failing intermittently with port in use

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-7146543 webrev: http://cr.openjdk.java.net/~mli/7146543/webrev.00/ The patch rewrite the test in java, fixes the bug. Thank you -Hamlin

Re: RFR of JDK-8030950: TEST_BUG: java/rmi/registry/classPathCodebase/ClassPathCodebase.java failing intermittently

the access to the relative path. registry.security.policy: Add a comment saying how this policy is used (to distinguish it from the other security policy). added. Otherwise looks fine, code is pushed. Thank you -Hamlin Roger On 1/11/2017 11:33 PM, Hamlin Li wrote: Would you please re

RFR of JDK-8030950: TEST_BUG: java/rmi/registry/classPathCodebase/ClassPathCodebase.java failing intermittently

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8030950 webrev: http://cr.openjdk.java.net/~mli/8030950/webrev.00/ Thank you -Hamlin

Re: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64

Need to update the year in copyright, it's new year 2017, I guess lot of us do not notice it. Thank you -Hamlin On 2017/1/11 18:14, Amy Lu wrote: On 12/23/16 8:54 AM, Amy Lu wrote: On 12/20/16 8:04 PM, Wang Weijun wrote: For the failing case, the first time it calls checkNames, the "ans" (th

Re: RFR of JDK-8172347: Refactoring src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to improve testability of rmiregistry

; it just creates and exports a remote object. Otherwise, looks fine. modified as createRegistry. the code is pushed. Thank you -Hamlin Thanks, Roger On 1/9/2017 4:49 PM, Hamlin Li wrote: Hi Roger, Thank you for reviewing, please check the comments inline, and new webrev: http

Re: RFR of JDK-8172347: Refactoring src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to improve testability of rmiregistry

ality and its use. will do it in test. $.02, Roger Is this complimentary to the constructor RegistryImp(int port) or LocateRegistry.createRegistry( ..) ? regards Mark On 09/01/2017 07:56, Hamlin Li wrote: Hi Roger, Thank you for reviewing, please check new webrev: http://cr.openjdk.

Re: RFR of JDK-8172347: Refactoring src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to improve testability of rmiregistry

" method is mainly used for tests to simulate rmiregistry which is an executable released by jdk. regards Mark On 09/01/2017 07:56, Hamlin Li wrote: Hi Roger, Thank you for reviewing, please check new webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.01/ Thank you -Hamlin On 2017

Re: RFR of JDK-8172347: Refactoring src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to improve testability of rmiregistry

. @param @return, @throw, etc. I think comments should be direct about what the function does. It does not need to explain why so much. Or if so, later and in a separate paragraph; when reading the most important information should be first. Thanks, Roger On 1/6/2017 4:59 AM, Hamlin Li wrote: On

Re: RFR of JDK-8030175: java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due to timeout

: Hi Hamlin, Since it is intermittent, are there any diagnostics that can be added to the test in case it fails again. if not, ok as is. Thanks, Roger On 1/5/2017 8:55 PM, Hamlin Li wrote: On 2017/1/6 6:15, Roger Riggs wrote: On 1/4/2017 10:21 PM, Hamlin Li wrote: Hi Roger, Thank you

Re: RFR of JDK-8172314: java/rmi/registry/altSecurityManager/AltSecurityManager.java fails with "port in use"

. Same reason as above for your comment in REGISTRY(now RegistryVM). Thank you -Hamlin Roger On 12/26/2016 3:51 AM, Hamlin Li wrote: Would you please review the below patches? bug: https://bugs.openjdk.java.net/browse/JDK-8030175 webrev (version A): http://cr.openjdk.java.net/~mli/8030175/we

Re: RFR of JDK-8172347: Refactoring src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to improve testability of rmiregistry

ndled. - Either main or run should set a security manager; but not both. Roger On 1/4/2017 10:21 PM, Hamlin Li wrote: Hi Roger, Thank you for reviewing, please check comments inline. On 2017/1/5 4:18, Roger Riggs wrote: Hi Hamlin, The original issue with timeout may be due to heavily loaded sy

Re: RFR of JDK-8030175: java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due to timeout

On 2017/1/6 6:15, Roger Riggs wrote: On 1/4/2017 10:21 PM, Hamlin Li wrote: Hi Roger, Thank you for reviewing, please check comments inline. On 2017/1/5 4:18, Roger Riggs wrote: Hi Hamlin, The original issue with timeout may be due to heavily loaded systems and short timeouts. 15 sec

Re: RFR of JDK-8030175: java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due to timeout

are doubts about destroy then destroy should be fixed not avoided. Roger On 12/26/2016 3:51 AM, Hamlin Li wrote: Would you please review the below patches? bug: https://bugs.openjdk.java.net/browse/JDK-8030175 webrev (version A): http://cr.openjdk.java.net/~mli/8030175/

Re: RFR of JDK-8030175: java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due to timeout

Is some one available to review the patch? Thank you -Hamlin On 2016/12/26 16:51, Hamlin Li wrote: Would you please review the below patches? bug: https://bugs.openjdk.java.net/browse/JDK-8030175 webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/ webrev (version B): http

RFR of JDK-8030175: java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due to timeout

Would you please review the below patches? bug: https://bugs.openjdk.java.net/browse/JDK-8030175 webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/ webrev (version B): http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ There are 2 versions to

RFR of JDK-8073080: TEST_BUG: sun/rmi/transport/tcp/DeadCachedConnection.java fails due to "ConnectException: Connection refused to host"

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8073080 webrev: http://cr.openjdk.java.net/~mli/8073080/webrev.00/ Thank you -Hamlin

Re: RFR of JDK-8029360: java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing intermittently

registryPort = -1; 1. 'finished' and 'registryPort' should be volatile since they are written and read by multiple threads. 2. 'test' should be final. The rest looks reasonable to me. -- daniel On 20/12/16 07:10, Hamlin Li wrote: Would you please revie

RFR of JDK-8029360: java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing intermittently

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8029360 webrev: http://cr.openjdk.java.net/~mli/8029360/webrev.00/ * For the "connection refused" and "port in use" issue: Root Cause: consider reproducing scenario, 1. gets free port A (in main process)

RFR of JDK-8025199: java/rmi/registry/reexport/Reexport.java failed with: Port already in use

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8025199 webrev: http://cr.openjdk.java.net/~mli/8025199/webrev.00 Root cause: running registry on TestLibrary.getUnusedRandomPort() will cause "port in use" exception, as there is a time window for a interlo

Re: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..)

Hi Roger, Thank you for reviewing, removed the redundant checking and pushed the code. -Hamlin On 2016/12/16 22:13, Roger Riggs wrote: Hi Hamlin, Yes, the logic would be clearer; and I would also remove the (now) redundant checking. Roger On 12/15/2016 9:42 PM, Hamlin Li wrote: Hi

RFR of JDK-8171298: ProblemList java/rmi/registry/readTest/readTest.sh due to JDK-7146543

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171298 diff -r 63e82d0eb4f6 test/ProblemList.txt --- a/test/ProblemList.txtWed Dec 14 19:23:08 2016 -0800 +++ b/test/ProblemList.txtThu Dec 15 21:01:34 2016 -0800 @@ -205,6 +205,8 @@ java/rmi/trans

Re: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..)

more clear, maybe we could remove the check of reg != null at the same time after modify the code in createReg(...). Thank you -Hamlin Roger On 12/14/2016 10:19 PM, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171133 webrev:

RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..)

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171133 webrev: http://cr.openjdk.java.net/~mli/8171133/webrev.00/ java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..): if LocateRegistry.createRegistry(port) return null

Re: RFR of JDK-8171072: java/rmi/transport/handshake*/Handshake*.java, exception is not thrown when reach failure test case

Is some one available to review the patch? Thank you -Hamlin On 2016/12/12 16:48, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171072 webrev: http://cr.openjdk.java.net/~mli/8171072/webrev.00/ Thank you -Hamlin

RFR of JDK-8171076: improve rmi tests by replacing TestLibrary.createRegistryOnUnusedPort, getUnusedRandomPort

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171076 webrev: http://cr.openjdk.java.net/~mli/8171076/webrev.00/ There are rmi tests using TestLibrary.createRegistryOnUnusedPort, getUnusedRandomPort, registry created by these 2 methods could cause "port

RFR of JDK-8171072: java/rmi/transport/handshake*/Handshake*.java, exception is not thrown when reach failure test case

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171072 webrev: http://cr.openjdk.java.net/~mli/8171072/webrev.00/ Thank you -Hamlin

RFR of JDK-8166763: java/rmi/* tests fail intermittently with "Port already in use" in RMID.start()

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8166763 webrev: http://cr.openjdk.java.net/~mli/8166763/webrev.00/ Not all modified tests failed, the patch is to improve the test quality. Thank you -Hamlin

Re: RFR of JDK-7195382: TEST_BUG: java/rmi/activation/CommandEnvironment/SetChildEnv.java can fail

a.compiler=NONE" made me wonder why that was important to the test. I had same thought, it's removed. The code is pushed after modified as you suggested. Thank you -Hamlin Roger On 12/8/2016 10:07 PM, Hamlin Li wrote: Is some one available to review the patch? Thank you -Hamlin O

Re: RFR of JDK-7195382: TEST_BUG: java/rmi/activation/CommandEnvironment/SetChildEnv.java can fail

Is some one available to review the patch? Thank you -Hamlin On 2016/12/8 11:07, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-7195382 webrev: http://cr.openjdk.java.net/~mli/7195382/webrev.00/ what's changed?

RFR of JDK-7195382: TEST_BUG: java/rmi/activation/CommandEnvironment/SetChildEnv.java can fail

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-7195382 webrev: http://cr.openjdk.java.net/~mli/7195382/webrev.00/ what's changed? * Use createRMIDOnEphemeralPort to avoid "port in use" exception. * Because createRMIDOnEphemeralPort will choose different po

Re: RFR of JDK-8170839: failed test case is not checked in java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java

correct the subject On 2016/12/7 14:46, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170839 webrev: http://cr.openjdk.java.net/~mli/8170839/webrev.00/ Thank you -Hamlin

RFR of JDK-: failed test case is not checked in java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170839 webrev: http://cr.openjdk.java.net/~mli/8170839/webrev.00/ Thank you -Hamlin diff -r 10b191e1793b test/java/rmi/activation/

Re: RFR of JDK-8170704: java/rmi/activation/Activatable/* tests fails intermittently with "output improperly annotated"

- daniel On 06/12/16 07:18, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170704 webrev: http://cr.openjdk.java.net/~mli/8170704/webrev.00/ * Root Cause: The issue can be reproduced by adjust sleeping time to smaller values, so on busy

Re: RFR 8081390, javax/management/remote/mandatory/connection/RMIConnector_NPETest.java may leave orphaned processes

in finally, it indeed possibly leaves orphaned processes. So that is still a minor problem to fix. Thanks, Felix On 2016/12/6 11:26, Hamlin Li wrote: Hi Felix, As the issue is timeout at rmid.start(), so it does not resolve the issue to just move rmid.start() to try block. I saw the issue h

RFR of JDK-8170704: java/rmi/activation/Activatable/* tests fails intermittently with "output improperly annotated"

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170704 webrev: http://cr.openjdk.java.net/~mli/8170704/webrev.00/ * Root Cause: The issue can be reproduced by adjust sleeping time to smaller values, so on busy machine it's possible that the sleeping time

Re: RFR 8081390, javax/management/remote/mandatory/connection/RMIConnector_NPETest.java may leave orphaned processes

Hi Felix, As the issue is timeout at rmid.start(), so it does not resolve the issue to just move rmid.start() to try block. I saw the issue happened last in 2015/6, maybe we could just close it as "Not Reproduced"? Thank you -Hamlin On 2016/12/6 10:08, Felix Yang wrote: Hi, please re

Re: RFR of JDK-8170669: com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java fails after JDK-8153916

product issue. Thanks, Roger On 12/5/2016 3:12 AM, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170669 webrev: http://cr.openjdk.java.net/~mli/8170669/webrev.00/ Root Cause: 2 tests impact each other. (test/com/sun/jndi/rmi/registry

RFR of JDK-8170669: com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java fails after JDK-8153916

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170669 webrev: http://cr.openjdk.java.net/~mli/8170669/webrev.00/ Root Cause: 2 tests impact each other. (test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java, UnbindIdempotent.java

RFR of JDK-8078587: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java fails intermittently with Port already in use

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8078587 webrev: http://cr.openjdk.java.net/~mli/8078587/webrev.00/ Thank you -Hamlin diff -r 08f81d321087 test/java/rmi/server/Unrefer

RFR of JDK-8080550: java/rmi/server/useCustomRef/UseCustomRef.java failed with java.net.BindException intermittently

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8080550 webrev: http://cr.openjdk.java.net/~mli/8080550/ Thank you -Hamlin diff -r 99dd72e05060 test/java/rmi/server/useCustomRef/UseCu

RFR of JDK-8153916: com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java failed with BindException

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8153916 webrev: http://cr.openjdk.java.net/~mli/8153916/webrev.00/ Thank you -Hamlin diff -r 35c87712682f test/com/sun/jndi/rmi/registr

RFR of JDK-8170644: java/rmi/registry/interfaceHash/InterfaceHash.java failed intermittently with "Port already in use"

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170644 webrev: http://cr.openjdk.java.net/~mli/8170644/webrev.00/ Thank you -Hamlin

Re: RFR of JDK-8049316: TEST_BUG: java/nio/channels/Selector/Wakeup.java fails in same binary run b19

Hi Roger, Thank you for reviewing, fixed timeout scale and pushed. Thank you -Hamlin On 2016/12/1 3:49, Roger Riggs wrote: Hi Hamlin, On 11/29/2016 9:09 PM, Hamlin Li wrote: Hi Roger, Thank you for reviewing, please check comments in line. webrev: http://cr.openjdk.java.net/~mli/8049316

Re: RFR of JDK-8019538: TEST_BUG: java/rmi/activation/rmidViaInheritedChannel tests may fail

h me. This area is now well tested. -Chris. Stuart? Chris? Zyx Roger p.s. If you think there might be a reason to resurrect it later, attach the current webrev to the issue before updating it to remove. On 11/29/2016 9:25 PM, Hamlin Li wrote: Hi Roger, Thank you for reviewing. please

RFR of JDK-8170338: com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java failed with "Port already in use"

Would you please review the patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170338 webrev: http://cr.openjdk.java.net/~mli/8170338/webrev.00/ Thank you -Hamlin diff -r 17b7d5ac2da7 test/com/sun/jndi/rmi/registry/Re

Re: RFR of JDK-8019538: TEST_BUG: java/rmi/activation/rmidViaInheritedChannel tests may fail

Please let me know your final thought. Thank you -Hamlin Thanks, Roger On 11/23/2016 4:49 AM, Hamlin Li wrote: Would you please review the fix for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8019538 webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/ There are 4 issues

Re: RFR of JDK-8049316: TEST_BUG: java/nio/channels/Selector/Wakeup.java fails in same binary run b19

on a specific time, because I don't know what exact timeout we should use, but as you asked, I think it's ok to finish(20_000), it should be long enough. Thank you -Hamlin Thanks, Roger On 11/29/2016 4:23 AM, Hamlin Li wrote: Would you please review the below patch? bug: https://

RFR of JDK-8049316: TEST_BUG: java/nio/channels/Selector/Wakeup.java fails in same binary run b19

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8049316 webrev: http://cr.openjdk.java.net/~mli/8049316/webrev.00/ Root cause: 1. it depends on sleeping time to check failure, which is not reliable in some extreme situation 2. it mix several tests togethe

Re: RFR of JDK-8019538: TEST_BUG: java/rmi/activation/rmidViaInheritedChannel tests may fail

Is some one available to review the patch? Thank you -Hamlin On 2016/11/23 17:49, Hamlin Li wrote: Would you please review the fix for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8019538 webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/ There are 4 issues in the bug, 2

RFR of JDK-8019538: TEST_BUG: java/rmi/activation/rmidViaInheritedChannel tests may fail

Would you please review the fix for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8019538 webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/ There are 4 issues in the bug, 2 in RmidViaInheritedChannel.java: "port in use" in registry, "port in use" in rmid start. 2 InheritedC

RFR of JDK-8153543: java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java fails intermittently

Would you please review the patch for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8153543 webrev: http://cr.openjdk.java.net/~mli/8153543/webrev.00/ Root cause: between "TestLibrary.getUnusedRandomPort()" and "UnicastRemoteObject.exportObject(impl, 0);", there is time window, inte

RFR of JDK-8170049: tests under java/rmi/activation/ fail with "java.security.AccessControlException: access denied ("java.net.SocketPermission" "localhost:5281" "listen, resolve")" on windows

Would you please review the patch for below bug? bug: https://bugs.openjdk.java.net/browse/JDK-8170049 webrev: http://cr.openjdk.java.net/~mli/8170049/webrev.00/ The issue is weird, it only happens on windows, and reproducible. All the related tests passed on windows platforms in JPRT, but fail

Re: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart()

"togeter" -> "together" RMIDSelectorProvider.java: - 121, 125 I would have just used System.out.printf directly without introducing a trivial function. Looks fine, Roger Roger On 11/17/2016 1:46 AM, Hamlin Li wrote: Hi Chris, Joe, Roger, Thank you for reviewing. Pleas

Re: RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart()

ased on jtreg time factor. Thanks, -Joe On 11/16/2016 9:01 AM, Chris Hegarty wrote: On 16 Nov 2016, at 07:36, Hamlin Li wrote: Would you please review below fix? bug: https://bugs.openjdk.java.net/browse/JDK-8168975 webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ The approach build

RFR of JDK-8168975: java/rmi/activation/Activatable tests fail due to "Port already in use" in RMID.restart()

Would you please review below fix? bug: https://bugs.openjdk.java.net/browse/JDK-8168975 webrev: http://cr.openjdk.java.net/~mli/8168975/webrev.00/ Root Cause: There is a time window between RMID.start() and RMID.restart(), interloper can step in and bind to the port used by RMID in RMID.start

RFR of JDK 8168505: Remove the intermittent keyword from java/util/Arrays/ParallelPrefix.java

bug: https://bugs.openjdk.java.net/browse/JDK-8168505 webrev: http://cr.openjdk.java.net/~mli/8168505/webrev.00/ Test ( java/util/Arrays/ParallelPrefix.java) was failing intermittently, related bug (JDK-8080165 ) has been proved not reproduced

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hi Joe, Roger, Modified based on your latest comments, please check the new webrev: http://cr.openjdk.java.net/~mli/8085192/webrev.02/ At the same time, I think Chris's idea is great. Thank you -Hamlin On 2016/9/30 7:14, Joseph D. Darcy wrote: If Hamlin's approach is taken in the end, I think

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

itespace changes.) Fixed, thank you for the tip, new webrev is generated with "-b". :-) Thank you -Hamlin Thanks, -Brent On 9/27/16 2:22 AM, Hamlin Li wrote: Please review the fix for JDK-8085192. The fix checks whether it fails to launch rmid due to "Port already in use"

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

be a little bit complicated to use ProcessTools and OutputAnalyzer in this situation, need to modify these classes, because they will block until process terminates. So I prefer to use current implementation, as it's simple and clear. Thank you -Hamlin Roger On 9/27/2016 5:22 AM,

[9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Please review the fix for JDK-8085192. The fix checks whether it fails to launch rmid due to "Port already in use" error, it will launch rmid again and again(20 times at most) until no such issue. bug: https://bugs.openjdk.java.net/browse/JDK-8085192 webrev: http://cr.openjdk.java.net/~

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On 2016/8/24 12:53, David Holmes wrote: On 24/08/2016 1:39 PM, Hamlin Li wrote: On 2016/8/24 11:02, Martin Buchholz wrote: On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz mailto:marti...@google.com>> wrote: I didn't see this thread before updating the bug. I think th

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On 2016/8/24 11:02, Martin Buchholz wrote: On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz > wrote: I didn't see this thread before updating the bug. I think this is Not a Bug, because """The current atomic addAll is a tradeoff; it's efficient, but a

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On 2016/8/24 9:22, David Holmes wrote: Hi Hamlin, On 23/08/2016 10:53 PM, Hamlin Li wrote: On 2016/8/23 17:10, David Holmes wrote: Hi Hamlin, On 23/08/2016 6:55 PM, Hamlin Li wrote: Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

cost of potential loss of concurrency if the other collection is slow. It's reasonable for a subclass to override addAll to add elements eagerly and non-atomically.""" OTOH it would be reasonable to document the atomicity of the implementation in CLD and CLQ as @implNote.

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On 2016/8/23 17:10, David Holmes wrote: Hi Hamlin, On 23/08/2016 6:55 PM, Hamlin Li wrote: Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic operation. No it is not! There is no bug here. Are you perhaps confusing thread-safe with

<    1   2   3   >