Re: Why stream from BufferedReader::lines is not closing the reader?
Another idea to solve the long-standing issue with checked IOExceptions in
close() calls is to
add a method to java.io.Closeable, now possible thanks to default methods:
/**
* Invokes #close() and wraps IOExceptions with UncheckedIOExceptions.
*/
default void closeUnchecked() {
try { close(); } catch(IOException e) { throw new
UncheckedIOException(e); }
}
This would at least make it possible to pass
closeableInstance::closeUnchecked to Stream.onClose(Runnable).
2013/11/18 Peter Levart peter.lev...@gmail.com
On 11/18/2013 03:28 PM, Brian Goetz wrote:
Which means that, if your stream holds non-memory resources, the
flatMapper should create a stream that closes the underlying stream, like:
blah.flatMap(path - {
BufferedReader br = new BufferedReader(path);
return br.lines.onClose(br::close);
}
...
...the only problem with above code is that it doesn't compile, because of
IOException declared on BufferedReader (FileReader actually!) constructor
and BufferedReader.close() method. The solutions to this have already been
discussed on the list some time ago, and one of the propositions was to
create interfaces like:
public interface IOFunctionT, R extends FunctionT, R {
default R apply(T t) {
try {
return applyIO(t);
} catch (IOException e) {
throw new UncheckedIOException(e);
}
}
R applyIO(T t) throws IOException;
}
public interface IORunnable extends Runnable {
default void run() {
try {
runIO();
} catch (IOException e) {
throw new UncheckedIOException(e);
}
}
void ruinIO() throws IOException;
}
...etc, and use them in code like this:
ListString paths = ...
paths
.stream()
.flatMap((IOFunctionString, StreamString) path - {
BufferedReader br = new BufferedReader(new FileReader(path));
return br.lines().onClose((IORunnable) br::close);
})
.forEach(System.out::println);
Regards, Peter
RFR: 8028185 - XMLFormatter.format emits incorrect year
Hi, Please find below a webrev for: 8028185: XMLFormatter.format emits incorrect year https://bugs.openjdk.java.net/browse/JDK-8028185 The fix is trivial: http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/ best regards, -- daniel
hg: jdk8/tl/jdk: 8028505: Put sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh on ProblemList.txt
Changeset: d6195774dd1f Author:egahlin Date: 2013-11-19 11:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6195774dd1f 8028505: Put sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh on ProblemList.txt Reviewed-by: alanb ! test/ProblemList.txt
.split(:).length?
Is this just changed? jdk8b118 shows 1 and now it's 0. Thanks Max
Re: .split(:).length?
On 11/19/13, 19:48, Weijun Wang wrote: Is this just changed? jdk8b118 shows 1 and now it's 0. Typo. b114. Thanks Max
Re: .split(:).length?
On 19/11/2013 11:48, Weijun Wang wrote: Is this just changed? jdk8b118 shows 1 and now it's 0. b118 or your own build? I wonder if you have 6559590 but not the un-do. -Alan.
Re: .split(:).length?
b114: 1 my (previous) own build: 0 I fetched changes for JDK-8028321 (the un-do) and now it's back to 1. So we are keeping this compatibility even if it does not look correct? Thanks Max On 11/19/13, 20:03, Alan Bateman wrote: On 19/11/2013 11:48, Weijun Wang wrote: Is this just changed? jdk8b118 shows 1 and now it's 0. b118 or your own build? I wonder if you have 6559590 but not the un-do. -Alan.
Re: RFR: 8028185 - XMLFormatter.format emits incorrect year
On 19/11/2013 10:23, Daniel Fuchs wrote: Hi, Please find below a webrev for: 8028185: XMLFormatter.format emits incorrect year https://bugs.openjdk.java.net/browse/JDK-8028185 The fix is trivial: http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/ This one is a good reminder as to how fixing warnings can break things. The change looks good. The test looks okay too (checking for year rollover during the test seems excessive but harmless). -Alan.
Re: .split(:).length?
On 19/11/2013 12:09, Weijun Wang wrote: b114: 1 my (previous) own build: 0 I fetched changes for JDK-8028321 (the un-do) and now it's back to 1. So we are keeping this compatibility even if it does not look correct? I think it will require careful analysis to see what is possible (as there were several problems when this was pushed due to a dependency on the long standing behavior). -Alan.
RFR: 8028583 :Add helper methods to test libraries
Looking to add two helper methods to the OpenJDK test libraries. I'm looking to clean up a closed src test case but these methods should be of use for future testcase development. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8028583/webrev/ bug report : https://bugs.openjdk.java.net/browse/JDK-8028583 regards, Sean.
Request to review JDK-8028094
Hi, Here is one possible solution for the issue JDK-8028094. http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ I am not sure pkill is available in all Unix flavor at /usr/bin directory, but it is present in Solaris and OEL 6. I have tested on Solaris and OEL and sleep is no longer left over. Thanks Balchandra
hg: jdk8/tl/jdk: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Changeset: 2e574350a2b6 Author:alanb Date: 2013-11-19 14:08 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e574350a2b6 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Reviewed-by: dholmes, sla, tbell ! test/Makefile
hg: jdk8/tl: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests
Changeset: 9937f406e27e Author:alanb Date: 2013-11-19 14:11 + URL: http://hg.openjdk.java.net/jdk8/tl/rev/9937f406e27e 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Reviewed-by: dholmes, sla, tbell ! make/jprt.properties ! test/Makefile
Re: RFR: 8028583 :Add helper methods to test libraries
Looks good to me Sean, thanks for adding deleteFileIfExistsWithRetry.
Trivially, you can replace oneLoopRun with a do {} while loop.
-Chris.
On 11/19/2013 01:31 PM, Seán Coffey wrote:
Looking to add two helper methods to the OpenJDK test libraries. I'm
looking to clean up a closed src test case but these methods should be
of use for future testcase development.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8028583/webrev/
bug report : https://bugs.openjdk.java.net/browse/JDK-8028583
regards,
Sean.
Re: Request to review JDK-8028094
Look ok to me Balchandra. I can sponsor this for you. -Chris. On 11/19/2013 02:07 PM, Balchandra Vaidya wrote: Hi, Here is one possible solution for the issue JDK-8028094. http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ I am not sure pkill is available in all Unix flavor at /usr/bin directory, but it is present in Solaris and OEL 6. I have tested on Solaris and OEL and sleep is no longer left over. Thanks Balchandra
8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java
Hi folks, Looking for a quick review for a test failure we're encountering. Seemingly no bar is too high for our test infrastructure. Hopefully this will put this particular failure to rest. http://cr.openjdk.java.net/~robm/8022206/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8022206 -Rob
Re: RFR: 8028583 :Add helper methods to test libraries
Thanks for review Chris. Will take your do while loop suggestion on
board and push changes.
regards,
Sean.
On 19/11/13 14:19, Chris Hegarty wrote:
Looks good to me Sean, thanks for adding deleteFileIfExistsWithRetry.
Trivially, you can replace oneLoopRun with a do {} while loop.
-Chris.
On 11/19/2013 01:31 PM, Seán Coffey wrote:
Looking to add two helper methods to the OpenJDK test libraries. I'm
looking to clean up a closed src test case but these methods should be
of use for future testcase development.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8028583/webrev/
bug report : https://bugs.openjdk.java.net/browse/JDK-8028583
regards,
Sean.
8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures
The test tools/jar/JarEntryTime.java has been failing intermittently (but very rarely) for some time. The failure seems to be that the extracted time it out by more than 10 seconds compared to the original file time but it isn't always so (esp. when the test runs in a fraction of a second). I'd like to add instrumentation to the test so that if it fails again (and someone is good enough to report it) then we at least have the timestamps in the logs. The webrev with the proposed change is here: http://cr.openjdk.java.net/~alanb/8028589/webrev/ Thanks, Alan.
Re: 8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures
Looks good to me Alan. It will be nice to see why this test is actually failing. -Chris. On 11/19/2013 02:43 PM, Alan Bateman wrote: The test tools/jar/JarEntryTime.java has been failing intermittently (but very rarely) for some time. The failure seems to be that the extracted time it out by more than 10 seconds compared to the original file time but it isn't always so (esp. when the test runs in a fraction of a second). I'd like to add instrumentation to the test so that if it fails again (and someone is good enough to report it) then we at least have the timestamps in the logs. The webrev with the proposed change is here: http://cr.openjdk.java.net/~alanb/8028589/webrev/ Thanks, Alan.
hg: jdk8/tl/jdk: 8028583: Add helper methods to test libraries
Changeset: d1bb85f0a45a Author:coffeys Date: 2013-11-19 14:47 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1bb85f0a45a 8028583: Add helper methods to test libraries Reviewed-by: chegar ! test/java/rmi/testlibrary/TestLibrary.java ! test/lib/testlibrary/jdk/testlibrary/FileUtils.java
Re: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java
The change looks ok to me. If for no reason other than to eliminate the timeout if this tests fails again in the future. -Chris. On 11/19/2013 02:28 PM, Rob McKenna wrote: Hi folks, Looking for a quick review for a test failure we're encountering. Seemingly no bar is too high for our test infrastructure. Hopefully this will put this particular failure to rest. http://cr.openjdk.java.net/~robm/8022206/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8022206 -Rob
Re: Request to review JDK-8028094
Thanks Chris. Regards Balchandra On 19/11/2013 14:23, Chris Hegarty wrote: Look ok to me Balchandra. I can sponsor this for you. -Chris. On 11/19/2013 02:07 PM, Balchandra Vaidya wrote: Hi, Here is one possible solution for the issue JDK-8028094. http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ I am not sure pkill is available in all Unix flavor at /usr/bin directory, but it is present in Solaris and OEL 6. I have tested on Solaris and OEL and sleep is no longer left over. Thanks Balchandra
Re: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java
On 19/11/2013 14:28, Rob McKenna wrote: Hi folks, Looking for a quick review for a test failure we're encountering. Seemingly no bar is too high for our test infrastructure. Hopefully this will put this particular failure to rest. http://cr.openjdk.java.net/~robm/8022206/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8022206 It's hard to believe that the 10s is exceeded but the change is harmless (and hence okay). -Alan
Re: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java
Hi Rob, May I suggest changing System.out.println in Basic.fail into System.err.println? Or possibly printing the message on both out and err? This would ensure that the error message appears on System err before the stack trace - which might be better for diagnosis. -- daniel On 11/19/13 3:28 PM, Rob McKenna wrote: Hi folks, Looking for a quick review for a test failure we're encountering. Seemingly no bar is too high for our test infrastructure. Hopefully this will put this particular failure to rest. http://cr.openjdk.java.net/~robm/8022206/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8022206 -Rob
hg: jdk8/tl/jdk: 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm
Changeset: 40462a41b41b Author:ksrini Date: 2013-11-19 07:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40462a41b41b 8023978: [TEST_BUG] launcher tests must exclude platforms without server vm Reviewed-by: dholmes, mchung ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java
hg: jdk8/tl/jdk: 8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves sleep 6666 processes behind
Changeset: cfbee8ee71bf Author:bvaidya Date: 2013-11-19 15:31 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfbee8ee71bf 8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves sleep processes behind Reviewed-by: chegar ! test/java/lang/ProcessBuilder/Basic.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: e8daf5a83e42
Author:vinnie
Date: 2013-11-19 15:39 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8daf5a83e42
8028377: test/sun/security/provider/KeyStore/DKSTest.sh attempts to write to
${test.src}
Reviewed-by: alanb, weijun
! test/sun/security/provider/KeyStore/DKSTest.java
! test/sun/security/provider/KeyStore/domains.cfg
Changeset: bfd4e632eeda
Author:vinnie
Date: 2013-11-19 15:42 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfd4e632eeda
Merge
RFR : 8016728: TEST_BUG: test/java/rmi/transport/closeServerSocket/CloseServerSocket.java failing intermittently with Address already in use
Hope this is a simple one. This issue is a rare intermittent one : - port 48250 is free - exported registry: RegistryImpl[UnicastServerRef [liveRef: [endpoint:[10.169.79.100:48250](local),objID:[0:0:0, 0 - port 48250 is in use - unexported registry java.net.BindException: Address already in use at java.net.PlainSocketImpl.socketBind(Native Method) Even though we've just unexported the registry, the socket is still in use. I believe 1ms is too short a time to sleep to handle any environment issues. Let's try 1 second. bug report : https://bugs.openjdk.java.net/browse/JDK-8016728 proposed change : t4 $hg diff test/java/rmi/transport/closeServerSocket/CloseServerSocket.java diff --git a/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java b/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java --- a/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java +++ b/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java @@ -58,7 +58,7 @@ verifyPortInUse(PORT); UnicastRemoteObject.unexportObject(registry, true); System.err.println(- unexported registry); -Thread.sleep(1);// work around BindException (bug?) +Thread.sleep(1000);// work around BindException (bug?) verifyPortFree(PORT); regards, Sean.
Re: .split(:).length?
Yes, I have to pull it back due to the compatibility concern. It appears the jdk source code itself has couple places depending on this incorrect behavior. The typical usage is .split(...)[0], in which the code tries to access the 0th element without even checking the return length. I may re-visit this in jdk9, and may have to provide some mechanism for any possible compatibility complain, if we decide to fix it. -Sherman On 11/19/13 4:09 AM, Weijun Wang wrote: b114: 1 my (previous) own build: 0 I fetched changes for JDK-8028321 (the un-do) and now it's back to 1. So we are keeping this compatibility even if it does not look correct? Thanks Max On 11/19/13, 20:03, Alan Bateman wrote: On 19/11/2013 11:48, Weijun Wang wrote: Is this just changed? jdk8b118 shows 1 and now it's 0. b118 or your own build? I wonder if you have 6559590 but not the un-do. -Alan.
hg: jdk8/tl/jdk: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java
Changeset: 63b696dafc8a Author:robm Date: 2013-11-19 15:36 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63b696dafc8a 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java Reviewed-by: chegar, alanb ! test/java/lang/ProcessBuilder/Basic.java
Re: RFR : 8016728: TEST_BUG: test/java/rmi/transport/closeServerSocket/CloseServerSocket.java failing intermittently with Address already in use
Looks ok to me. -Chris. On 11/19/2013 03:58 PM, Seán Coffey wrote: Hope this is a simple one. This issue is a rare intermittent one : - port 48250 is free - exported registry: RegistryImpl[UnicastServerRef [liveRef: [endpoint:[10.169.79.100:48250](local),objID:[0:0:0, 0 - port 48250 is in use - unexported registry java.net.BindException: Address already in use at java.net.PlainSocketImpl.socketBind(Native Method) Even though we've just unexported the registry, the socket is still in use. I believe 1ms is too short a time to sleep to handle any environment issues. Let's try 1 second. bug report : https://bugs.openjdk.java.net/browse/JDK-8016728 proposed change : t4 $hg diff test/java/rmi/transport/closeServerSocket/CloseServerSocket.java diff --git a/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java b/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java --- a/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java +++ b/test/java/rmi/transport/closeServerSocket/CloseServerSocket.java @@ -58,7 +58,7 @@ verifyPortInUse(PORT); UnicastRemoteObject.unexportObject(registry, true); System.err.println(- unexported registry); -Thread.sleep(1);// work around BindException (bug?) +Thread.sleep(1000);// work around BindException (bug?) verifyPortFree(PORT); regards, Sean.
hg: jdk8/tl/jdk: 8016728: TEST_BUG: test/java/rmi/transport/closeServerSocket/CloseServerSocket.java failing intermittently
Changeset: f2ccd3530476 Author:coffeys Date: 2013-11-19 16:22 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2ccd3530476 8016728: TEST_BUG: test/java/rmi/transport/closeServerSocket/CloseServerSocket.java failing intermittently Reviewed-by: chegar ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java
Re: Building sorted Spliterators for library authors
On Nov 19, 2013, at 4:50 PM, Louis Wasserman lowas...@google.com wrote: Is there a convenient way of building a Spliterator SORTED by a given Comparator, from, say, an array? Unfortunately not. There are no factory methods in j.u.Splitrerators that accept Comparator as a parameter, and as you note below we do not expose the Spliterator impls. You could wrap/proxy a Spliterator instance, but i suspect you will find that ugly, so you probably need to roll your own implementation and duplicate as appropriate from the JDK impls. From what I can tell, SortedSet's default implementation uses a private IteratorSpliterator API. Yes, and that is a poorly splitting Spliterator since the default implementation can only obtain elements from the Iterator. If your Spliterator covers an array you will probably want to implement better splitting. Hth, Paul.
RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug
Hi folks, Running this test with fastdebug binaries results in a few warning messages getting lumped into the commandOutput. I've decided to filter these test wide. https://bugs.openjdk.java.net/browse/JDK-6703075 http://cr.openjdk.java.net/~robm/6703075/webrev.01/ -Rob
Re: RFR: 8028185 - XMLFormatter.format emits incorrect year
On 11/19/13 2:23 AM, Daniel Fuchs wrote: Hi, Please find below a webrev for: 8028185: XMLFormatter.format emits incorrect year https://bugs.openjdk.java.net/browse/JDK-8028185 The fix is trivial: http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/ Looks good. Nit: the test can use StringBuilder which is generally in preference to StringBuffer unless synchronization is required. The kind of warning fix [1] causing this regression should probably have a regression test to go with it to verify the change. thanks Mandy [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f129f62f36
hg: jdk8/tl/jdk: 8028581: [TESTBUG] java/net/Socket/LingerTest.java failing
Changeset: 79e975dfeb8a Author:michaelm Date: 2013-11-19 17:49 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79e975dfeb8a 8028581: [TESTBUG] java/net/Socket/LingerTest.java failing Reviewed-by: alanb ! test/java/net/Socket/LingerTest.java
RFR [6968459] JNDI timeout fails before timeout is reached
Hello all! Would you please help review a fix for the bug? https://bugs.openjdk.java.net/browse/JDK-6968459 It was reported that creating new InitialLdapContext() can fail with javax.naming.NamingException: LDAP response read timed out, timeout used:3ms, even though the specified timeout hadn't been elapsed. The fix was provided by the filer of the bug some time ago. Here's the webrev with this fix: http://cr.openjdk.java.net/~igerasim/6968459/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR [6968459] JNDI timeout fails before timeout is reached
Hello all! Would you please help review a fix for the bug? https://bugs.openjdk.java.net/browse/JDK-6968459 It was reported that creating new InitialLdapContext() can fail with javax.naming.NamingException: LDAP response read timed out, timeout used:3ms, even though the specified timeout hadn't been elapsed. The fix was provided by the filer of the bug some time ago. A correction: the fix was recently provided by IBM. Here's the webrev with this fix: http://cr.openjdk.java.net/~igerasim/6968459/0/webrev/ Sincerely yours, Ivan Gerasimov
hg: jdk8/tl/jdk: 8027900: pack200 option is broken due to the incorrect makefile definition for its driver
Changeset: 5aa853ca08a8 Author:kizune Date: 2013-11-19 22:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aa853ca08a8 8027900: pack200 option is broken due to the incorrect makefile definition for its driver Reviewed-by: ksrini, ihse ! make/CompileLaunchers.gmk
Re: RFR: 8028185 - XMLFormatter.format emits incorrect year
On 11/19/13 6:40 PM, Mandy Chung wrote: On 11/19/13 2:23 AM, Daniel Fuchs wrote: Hi, Please find below a webrev for: 8028185: XMLFormatter.format emits incorrect year https://bugs.openjdk.java.net/browse/JDK-8028185 The fix is trivial: http://cr.openjdk.java.net/~dfuchs/webrev_8028185/webrev.00/ Thanks for the review Mandy! Looks good. Nit: the test can use StringBuilder which is generally in preference to StringBuffer unless synchronization is required. Oh yes good catch - I will change it before pushing... The kind of warning fix [1] causing this regression should probably have a regression test to go with it to verify the change. thanks Mandy [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f129f62f36
hg: jdk8/tl/jdk: 8015571: OCSP validation fails if ocsp.responderCertSubjectName is set
Changeset: f8b24e1a609e Author:vinnie Date: 2013-11-19 17:55 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b24e1a609e 8015571: OCSP validation fails if ocsp.responderCertSubjectName is set Reviewed-by: mullan, xuelei ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/x509/X509CertImpl.java
hg: jdk8/tl/jdk: 8028565: Remove java/lang/management/ThreadMXBean/ThreadStateTest.java from ProblemList.txt
Changeset: 48c61808374f Author:mchung Date: 2013-11-19 10:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48c61808374f 8028565: Remove java/lang/management/ThreadMXBean/ThreadStateTest.java from ProblemList.txt Reviewed-by: sla ! test/ProblemList.txt
hg: jdk8/tl/jdk: 8028141: test/sun/management/jmxremote/bootstrap/LocalManagementTest|CustomLauncherTest.java failing again
Changeset: 3f47e393e1dd Author:rriggs Date: 2013-11-19 13:20 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f47e393e1dd 8028141: test/sun/management/jmxremote/bootstrap/LocalManagementTest|CustomLauncherTest.java failing again Summary: Correct to use the test.class.path instead of test.classes Reviewed-by: alanb, chegar ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java
hg: jdk8/tl/langtools: 6726154: javadoc generated with incorrect version in comment
Changeset: f42a22e2b2cd Author:kizune Date: 2013-11-19 22:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f42a22e2b2cd 6726154: javadoc generated with incorrect version in comment Reviewed-by: jjg, bpatel, erikj, tbell ! make/BuildLangtools.gmk ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
Re: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2'
Hi, Attachments are stripped. Please post on cr.openjdk.java.net (get a colleague to host this if you don't have an account yet.) Thanks, David On 19/11/2013 4:12 PM, srikalyan chandrashekar wrote: Hi all, I am working on bug JDK-6772009 https://bugs.openjdk.java.net/browse/JDK-6772009 . Root Cause: The timeout value gives too much grace period on faster machines on which the TO BE INTERRUPTED threads complete faster before being interrupted at right time. Suggested Fix: a) Decrease the timeout from 100 to 50ms which will ensure that the test will pass even on faster machines , and ensures the threads will be canceled when running and anyways there is a Barrier to ensure the test threads all complete gracefully. Miscellaneous fixes b) Convert result from int to long(possible integer overflow otherwise) c) Catch BrokenBarrierException in more granular fashion in ReentrantLockLoop to update and print the results (which will be missed otherwise) Add more diagnostics d) Assign names to threads e) Print which threads update the 'completed' variable. I have attached the webrev for convenience as the changes are interleaved and is best viewed as sdiff. Please let me know if you have any comments or suggestions. Thank you
RFR: JDK-8028631 - Improve the test coverage to the pathname handling on unix-like platforms
Hi All, We have java/io/pathNames/GeneralWin32.java testcase to do the general exhaustive test of pathname handling on windows. I am adding a new test GeneralSolaris.java to test the pathname handling in unix-like platforms. In the changes, I also make sure the test can run successfully in concurrency mode. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8028631 Webrev: http://cr.openjdk.java.net/~dxu/8028631/webrev/ -Dan
hg: jdk8/tl/jdk: 8028185: XMLFormatter.format emits incorrect year
Changeset: 67d742c75971 Author:dfuchs Date: 2013-11-19 20:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67d742c75971 8028185: XMLFormatter.format emits incorrect year Summary: Fixes a regression where the year in the date was increased by 1900. Reviewed-by: alanb, mchung ! src/share/classes/java/util/logging/XMLFormatter.java + test/java/util/logging/XMLFormatterDate.java
Re: RFR: JDK-8028631 - Improve the test coverage to the pathname handling on unix-like platforms
The changes seem OK. I did not run the tests though On Nov 19, 2013, at 2:08 PM, Dan Xu wrote: Hi All, We have java/io/pathNames/GeneralWin32.java testcase to do the general exhaustive test of pathname handling on windows. I am adding a new test GeneralSolaris.java to test the pathname handling in unix-like platforms. In the changes, I also make sure the test can run successfully in concurrency mode. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8028631 Webrev: http://cr.openjdk.java.net/~dxu/8028631/webrev/ -Dan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
hg: jdk8/tl/jdk: 8028049: Tidy warnings cleanup for packages java.nio/java.io
Changeset: 19ff80da8283 Author:yan Date: 2013-11-18 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19ff80da8283 8028049: Tidy warnings cleanup for packages java.nio/java.io Reviewed-by: alanb, darcy Contributed-by: Sergey Lugovoy sergey.lugo...@oracle.com ! src/share/classes/java/io/EOFException.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/package.html
Re: declaring class of a default method Was: Bug 8027734
Thanks.
I will look back in hotspot.
Yumin
On 11/12/2013 6:25 AM, Joel Borggren-Franck wrote:
Hi Yumin,
Basically this is due to a difference in declaring class for a Method
representing a default method vs a normal Method.
On 2013-11-11, Yumin Qi wrote:
Hi, Joel
This bug is a SQE testing bug, see
https://bugs.openjdk.java.net/browse/JDK-8027734
https://bugs.openjdk.java.net/browse/JDK-8027734
I have commented with the exception stacktrace.
This is easy to reproduce without VM sqe frameworks:
p1/I.java:
package p1;
interface I {
default void m() {
System.out.println(Foo!);
}
}
p2/J.java:
package p1;
public interface J extends I {}
p2/C.java:
package p2;
import p1.J;
import java.lang.reflect.*;
public class C {
public static void main(String[] args) throws Exception {
Method m = J.class.getMethod(m, (Class?[])null);
System.out.println(m + declaring class: + m.getDeclaringClass());
m.invoke(new J() {});
}
}
Compiling and running this will print:
$ java p2.C
public default void p1.I.m() declaring class: interface p1.I
Exception in thread main java.lang.IllegalAccessException: Class p2.C
can not access a member of class p1.I with modifiers public
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:101)
at
java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:295)
at
java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:287)
at java.lang.reflect.Method.invoke(Method.java:476)
at p2.C.main(C.java:8)
Note that the delcaring class of m is interface p1.I.
Changing this to classes instead:
package p3;
class A {
public void m() {
System.out.println(Foo!);
}
}
package p3;
public class B extends A {}
package p4;
import p3.B;
import java.lang.reflect.*;
public class C2 {
public static void main(String[] args) throws Exception {
Method m = B.class.getMethod(m, (Class?[])null);
System.out.println(m + declaring class: + m.getDeclaringClass());
m.invoke(new B() {});
}
}
And running this gives:
java p4.C2
public void p3.B.m() declaring class: class p3.B
Foo!
Note that even though m is lexically declared in class A
m.getDeclaringClass() outputs _p3.B_ as it's declaring class.
I'm not sure how we should fix this, but my first impression is that the
VM is wrong here when creating the default method Method in the
interface example.
cheers
/Joel
Request to review JDK-8028094
Hi, Here is one possible solution for the issue JDK-8028094. http://cr.openjdk.java.net/~bvaidya/8/8028094/webrev/ I am not sure pkill is available in all Unix flavor at /usr/bin directory, but it is present in Solaris and OEL 6. I have tested on Solaris and OEL and sleep is no longer left over. Thanks Balchandra
Bug 8027734
Hi, Joel
This bug is a SQE testing bug, see
https://bugs.openjdk.java.net/browse/JDK-8027734
https://bugs.openjdk.java.net/browse/JDK-8027734
I have commented with the exception stacktrace.
It only fails when defmeth set call through reflection and passed
with other two modes: -mode invoke and -mode direct
The problem I got is from this part: Reflection.java:118
(verifyMemberAccess)
if (!Modifier.isPublic(getClassAccessFlags(memberClass)))
{ // here memberClass is p1.I which is
not a public
isSameClassPackage = isSameClassPackage(currentClass,
memberClass); // Not in same class
gotIsSameClassPackage = true;
if (!isSameClassPackage) {
return false; // so we return false.
}
}
// At this point we know that currentClass can access memberClass.
if (Modifier.isPublic(modifiers)) {
return true;
}
memberClass is p1.I is a private interface, but its sub p1.J is a public
interface. The default method is in I:
/* In package1:
* package p1;
* interface I {
* default int m() { return 10; };
* }
* public interface J extends I {};
*
* In package2:
* class A implements p1.J {}
* A myA = new A;
* myA.m(); // should return 10, not throw IllegalAccessError
* B myB = new B; // not related
*/
Now defmeth caller is TestContext, which is not in same package with
interface I, this leads verify failed.
'modifiers' is public, but we check if the caller class and calee class
in same package first and returned false, since they do not exist in
same package. If we check the following statement first, we will return
true. I am not familiar with this code, can you or some other people on
the list give comments?
Thanks
Yumin
On 10/10/2013 6:02 AM, Joel Borggren-Franck wrote:
Hi Karen,
I agree with the others, the code looks good though I like Paul's
suggestion.
Silly question perhaps, do you know if we have good test coverage on
actually reflectively invoking a Method more than 15 times?
cheers
/Joel
On 2013-10-09, Karen Kinnear wrote:
Please review:
webrev: http://cr.openjdk.java.net/~acorn/8026213/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8026213
Summary:
Reflection generates code dynamically to speed up reflection processing after
startup. The first
15 runs of a reflection call use the vm code path, after that we use the
generated code path, which
needs to use invokespecial on private methods in interfaces.
Tested:
Test attached to the bug
Also - all the 8011311 private method testing was run with this in the build:
Robert Field's TypeTest
8025475 test
defmeth privatemethodstest with reflection
John Rose's intfbug
jtreg: java.util, java.lang
jck vm, lang
thanks,
Karen
Re: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug
On 19/11/2013 16:46, Rob McKenna wrote: Hi folks, Running this test with fastdebug binaries results in a few warning messages getting lumped into the commandOutput. I've decided to filter these test wide. https://bugs.openjdk.java.net/browse/JDK-6703075 http://cr.openjdk.java.net/~robm/6703075/webrev.01/ -Rob Having warning messages emitted by the VM and interfering with application or test output is annoying. What you have is okay for now but perhaps there is an option to redirect them to elsewhere. -Alan
RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10
Hi, Please find below a fix for: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10 This bug complains that java/util/logging/CheckLockLocationTest.java has been seen failing on a solaris 10 machine, with message: java.lang.RuntimeException: Test failed: should not have been able to create FileHandler for %t/non-writable-dir/log.log in non-writable directory. at CheckLockLocationTest.runTests(CheckLockLocationTest.java:84) at CheckLockLocationTest.main(CheckLockLocationTest.java:57) ... I have no idea why this test failed as I have never seen it failing myself. I suspect however that for some reason the 'non-writable-dir' that the test attempted to create was in fact writable. I am therefore proposing to add an additional check in the test's setUp() method, in order to verify that the directory is indeed not writable. webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/ caveat: I haven't tested my changes on Solaris yet, but I will do so before pushing :-) -- daniel
Re: RFR: JDK-8028631 - Improve the test coverage to the pathname handling on unix-like platforms
On 19/11/2013 19:08, Dan Xu wrote: Hi All, We have java/io/pathNames/GeneralWin32.java testcase to do the general exhaustive test of pathname handling on windows. I am adding a new test GeneralSolaris.java to test the pathname handling in unix-like platforms. In the changes, I also make sure the test can run successfully in concurrency mode. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8028631 Webrev: http://cr.openjdk.java.net/~dxu/8028631/webrev/ This looks okay to me and I'm happy to see this test fixed to no longer walk into other directories when running tests concurrently. -Alan.
Re: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10
On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
I am therefore proposing to add an additional check in the test's
setUp() method, in order to verify that the directory is indeed
not writable.
It may be useful to print the owner of the directory in case if it's
running with root permission.
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/
175 final boolean nonWritable = nonWritableDir.setWritable(false);
176 final boolean isWritable = Files.isWritable(path);
177 if (nonWritable !isWritable) {
Perhaps it should assert isWriteable if File.setWriteable returns true.
Mandy
Re: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10
On 11/19/13 9:04 PM, Mandy Chung wrote:
On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
I am therefore proposing to add an additional check in the test's
setUp() method, in order to verify that the directory is indeed
not writable.
It may be useful to print the owner of the directory in case if it's
running with root permission.
OK - I assume I can find that by foraging into the nio Files API?
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/
175 final boolean nonWritable =
nonWritableDir.setWritable(false);
176 final boolean isWritable = Files.isWritable(path);
177 if (nonWritable !isWritable) {
Perhaps it should assert isWriteable if File.setWriteable returns true.
I'm not sure we want to fail in that case. I mean - the bug
is complaining that the test fails in the first place ;-)
I would be inclined to have the test simply skip the non-writable
test in both cases where it detects that it didn't manage to create
a non-writable dir.
-- daniel
Mandy
Re: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10
On 11/19/2013 12:12 PM, Daniel Fuchs wrote:
On 11/19/13 9:04 PM, Mandy Chung wrote:
On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
I am therefore proposing to add an additional check in the test's
setUp() method, in order to verify that the directory is indeed
not writable.
It may be useful to print the owner of the directory in case if it's
running with root permission.
OK - I assume I can find that by foraging into the nio Files API?
I think you could use
java.nio.file.attribute.FileOwnerAttributeView.getOwner() while you may
need to deal with acl vs posix.
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/
175 final boolean nonWritable =
nonWritableDir.setWritable(false);
176 final boolean isWritable = Files.isWritable(path);
177 if (nonWritable !isWritable) {
Perhaps it should assert isWriteable if File.setWriteable returns true.
I'm not sure we want to fail in that case. I mean - the bug
is complaining that the test fails in the first place ;-)
I would be inclined to have the test simply skip the non-writable
test in both cases where it detects that it didn't manage to create
a non-writable dir.
If File.setWriteable returns true and isWriteable is false, it'd be a
bug that we want to know about. Perhaps you want to log if the
directory is writeable or not instead of adding it to the check.
Mandy
RFR [8027348] (process) Enhancement of handling async close of ProcessInputStream
Hello all! May I have a review for the improvement contributed by Martin Buchholz? https://bugs.openjdk.java.net/browse/JDK-8027348 First, it the change performs the code cleanup, and second it makes the test much faster. This should also help to resolve the issue with the current version of the test, which was reported to fail intermittently by timeout. https://bugs.openjdk.java.net/browse/JDK-8028574 Here's the webrev with the change: http://cr.openjdk.java.net/~igerasim/8027348/0/webrev/ Sincerely yours, Ivan Gerasimov
Re: RFR: JDK-8027413: Clarify javadoc for j.l.a.Target and j.l.a.ElementType
Hi Joel, The change looks good; approved to go back. Thanks, -Joe On 11/15/2013 04:26 AM, Joel Borggren-Franck wrote: Hi Please review this javadoc clarification for j.l.annnotation.Target and j.l.annotation.ElementType as part of the type annotations work. Webrev: http://cr.openjdk.java.net/~jfranck/8027413/webrev.00/ JBS:https://bugs.openjdk.java.net/browse/JDK-8027413 This is based on the update to JLS from Alex: http://cr.openjdk.java.net/~abuckley/308.pdf (section 1.6). cheers /Joel
Re: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10
Hi,
I have modified the test to print the user name as well:
http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.01/
-- daniel
On 11/19/13 9:26 PM, Mandy Chung wrote:
On 11/19/2013 12:12 PM, Daniel Fuchs wrote:
On 11/19/13 9:04 PM, Mandy Chung wrote:
On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
I am therefore proposing to add an additional check in the test's
setUp() method, in order to verify that the directory is indeed
not writable.
It may be useful to print the owner of the directory in case if it's
running with root permission.
OK - I assume I can find that by foraging into the nio Files API?
I think you could use
java.nio.file.attribute.FileOwnerAttributeView.getOwner() while you may
need to deal with acl vs posix.
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/
175 final boolean nonWritable =
nonWritableDir.setWritable(false);
176 final boolean isWritable = Files.isWritable(path);
177 if (nonWritable !isWritable) {
Perhaps it should assert isWriteable if File.setWriteable returns true.
I'm not sure we want to fail in that case. I mean - the bug
is complaining that the test fails in the first place ;-)
I would be inclined to have the test simply skip the non-writable
test in both cases where it detects that it didn't manage to create
a non-writable dir.
If File.setWriteable returns true and isWriteable is false, it'd be a
bug that we want to know about. Perhaps you want to log if the
directory is writeable or not instead of adding it to the check.
Mandy
Re: RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10
On 11/19/2013 12:58 PM, Daniel Fuchs wrote:
Hi,
I have modified the test to print the user name as well:
http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.01/
Looks good to me. As we discussed offline, Files.isWritable may return
true on a non-writable directory if running with root permission. The
check you added was fine.
thanks
Mandy
-- daniel
On 11/19/13 9:26 PM, Mandy Chung wrote:
On 11/19/2013 12:12 PM, Daniel Fuchs wrote:
On 11/19/13 9:04 PM, Mandy Chung wrote:
On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
I am therefore proposing to add an additional check in the test's
setUp() method, in order to verify that the directory is indeed
not writable.
It may be useful to print the owner of the directory in case if it's
running with root permission.
OK - I assume I can find that by foraging into the nio Files API?
I think you could use
java.nio.file.attribute.FileOwnerAttributeView.getOwner() while you may
need to deal with acl vs posix.
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/
175 final boolean nonWritable =
nonWritableDir.setWritable(false);
176 final boolean isWritable = Files.isWritable(path);
177 if (nonWritable !isWritable) {
Perhaps it should assert isWriteable if File.setWriteable returns
true.
I'm not sure we want to fail in that case. I mean - the bug
is complaining that the test fails in the first place ;-)
I would be inclined to have the test simply skip the non-writable
test in both cases where it detects that it didn't manage to create
a non-writable dir.
If File.setWriteable returns true and isWriteable is false, it'd be a
bug that we want to know about. Perhaps you want to log if the
directory is writeable or not instead of adding it to the check.
Mandy
hg: jdk8/tl/jdk: 8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10
Changeset: 059530c5ae9a Author:dfuchs Date: 2013-11-19 22:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/059530c5ae9a 8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10 Summary: this test has been seen failing on Solaris 10, presumably because it was run as root. The fix will skip the non-writable case if it can't make a non-writable dir. Reviewed-by: mchung ! test/java/util/logging/CheckLockLocationTest.java
Re: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug
Great, thanks Martin. I totally overlooked that flag while hunting
around globals.hpp. I've added your contribution here:
http://cr.openjdk.java.net/~robm/6703075/webrev.02/
-Rob
On 19/11/13 19:58, Martin Buchholz wrote:
I propose a fix like the diff below, that asks the VM to separate
regular output and JVM output into stdout and stderr, so that we can
do matching on each independently, and so that we can rely on stdout
not being corrupted by JVM output.
@@ -555,9 +555,10 @@
System.getProperty(java.class.path);
private static final ListString javaChildArgs =
-Arrays.asList(new String[]
-{ javaExe, -classpath, absolutifyPath(classpath),
- Basic$JavaChild});
+Arrays.asList(javaExe,
+ -XX:+DisplayVMOutputToStderr,
+ -classpath, absolutifyPath(classpath),
+ Basic$JavaChild);
private static void testEncoding(String encoding, String tested) {
try {
@@ -1593,8 +1594,8 @@
javaExe));
list.add(ArrayOOME);
ProcessResults r = run(new ProcessBuilder(list));
- check(r.out().contains(java.lang.OutOfMemoryError:));
-check(r.out().contains(javaExe));
+ check(r.err().contains(java.lang.OutOfMemoryError:));
+check(r.err().contains(javaExe));
check(r.err().contains(System.getProperty(java.version)));
equal(r.exitValue(), 1);
} catch (Throwable t) { unexpected(t); }
On Tue, Nov 19, 2013 at 11:29 AM, Martin Buchholz marti...@google.com
mailto:marti...@google.com wrote:
Hold on - I'll try to get you alternate fix.
On Tue, Nov 19, 2013 at 11:27 AM, Alan Bateman
alan.bate...@oracle.com mailto:alan.bate...@oracle.com wrote:
On 19/11/2013 16:46, Rob McKenna wrote:
Hi folks,
Running this test with fastdebug binaries results in a few
warning messages getting lumped into the commandOutput.
I've decided to filter these test wide.
https://bugs.openjdk.java.net/browse/JDK-6703075
http://cr.openjdk.java.net/~robm/6703075/webrev.01/
http://cr.openjdk.java.net/%7Erobm/6703075/webrev.01/
-Rob
Having warning messages emitted by the VM and interfering with
application or test output is annoying. What you have is okay
for now but perhaps there is an option to redirect them to
elsewhere.
-Alan
Re: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java
On 19/11/2013 20:14, Martin Buchholz wrote: In jsr166 tests we have mostly switched to 10 second timeouts to mean forever. But in ProcessBuilder tests we are starting up new java processes with their well-known startup problems, so using a much larger value of forever seems reasonable. I vote for 1 minute. You can write waitFor(1, TimeUnit.MINUTES); I agree that a timeout on that order might be needed when starting process. However I think this one is just starting a thread that exercises the new waitFor method. -Alan.
Re: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug
On 19/11/2013 19:58, Martin Buchholz wrote: I propose a fix like the diff below, that asks the VM to separate regular output and JVM output into stdout and stderr, so that we can do matching on each independently, and so that we can rely on stdout not being corrupted by JVM output. Good, it's DisplayVMOutputToStderr or an option to redirect the warnings that I was wondering about. So do you want to take this one? -Alan.
hg: jdk8/tl/jdk: 8028631: Improve the test coverage to the pathname handling on unix-like platforms
Changeset: f496565c4eec Author:dxu Date: 2013-11-19 13:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f496565c4eec 8028631: Improve the test coverage to the pathname handling on unix-like platforms Summary: Add GeneralSolaris.java testcase and fix the concurrency issue Reviewed-by: lancea, chegar, alanb ! test/java/io/pathNames/General.java + test/java/io/pathNames/GeneralSolaris.java ! test/java/io/pathNames/GeneralWin32.java
RFR: 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails
Hi all, Please review this small fix for an intermittent timeout. Nothing seems to be going wrong except that if the machine running the test is exceptionally slow, spurious timeouts will occur. The solution is to raise the timeout in the RMI test infrastructure. Bug: https://bugs.openjdk.java.net/browse/JDK-8028638 Diff: (appended below) Thanks, s'marks # HG changeset patch # User smarks # Date 1384899795 28800 # Node ID ebbfb1b45a4e6b37d339942568a662268dcb18fe # Parent 67d742c759717ca17518aaadb17725cac85c5897 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails Reviewed-by: XXX diff -r 67d742c75971 -r ebbfb1b45a4e test/java/rmi/testlibrary/RMID.java --- a/test/java/rmi/testlibrary/RMID.java Tue Nov 19 20:10:58 2013 +0100 +++ b/test/java/rmi/testlibrary/RMID.java Tue Nov 19 14:23:15 2013 -0800 @@ -74,6 +74,10 @@ // + // -Djava.security.debug=all ; +// Set execTimeout to 60 sec (default is 30 sec) +// to avoid spurious timeouts on slow machines. +options += -Dsun.rmi.activation.execTimeout=6; + return options; }
Re: RFR: 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails
looks fine On Nov 19, 2013, at 5:24 PM, Stuart Marks wrote: Hi all, Please review this small fix for an intermittent timeout. Nothing seems to be going wrong except that if the machine running the test is exceptionally slow, spurious timeouts will occur. The solution is to raise the timeout in the RMI test infrastructure. Bug: https://bugs.openjdk.java.net/browse/JDK-8028638 Diff: (appended below) Thanks, s'marks # HG changeset patch # User smarks # Date 1384899795 28800 # Node ID ebbfb1b45a4e6b37d339942568a662268dcb18fe # Parent 67d742c759717ca17518aaadb17725cac85c5897 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails Reviewed-by: XXX diff -r 67d742c75971 -r ebbfb1b45a4e test/java/rmi/testlibrary/RMID.java --- a/test/java/rmi/testlibrary/RMID.java Tue Nov 19 20:10:58 2013 +0100 +++ b/test/java/rmi/testlibrary/RMID.java Tue Nov 19 14:23:15 2013 -0800 @@ -74,6 +74,10 @@ // + // -Djava.security.debug=all ; +// Set execTimeout to 60 sec (default is 30 sec) +// to avoid spurious timeouts on slow machines. +options += -Dsun.rmi.activation.execTimeout=6; + return options; } Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
hg: jdk8/tl/jdk: 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails
Changeset: 19d2e9649138 Author:smarks Date: 2013-11-19 15:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19d2e9649138 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails Reviewed-by: lancea ! test/java/rmi/testlibrary/RMID.java
RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
Hi All, Please review the simple fix towards Size.java testcase. It failed once on windows platform in the recent same binary run, which is mostly due to some interferences and the special delete handling on windows. In the fix, I remove the delete operation in initTestFile() method because FileOutputStream will truncate the file content and it is not necessary to delete it first. Thanks! Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ http://cr.openjdk.java.net/%7Edxu/8028628/webrev/ -Dan
hg: jdk8/tl/langtools: 8028504: javac generates LocalVariableTable even with -g:none
Changeset: 66bcd5d4b3d1 Author:vromero Date: 2013-11-19 23:35 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/66bcd5d4b3d1 8028504: javac generates LocalVariableTable even with -g:none Reviewed-by: jjg, jlahoda ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/T8028504/DontGenerateLVTForGNoneOpTest.java
答复: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port
Hi Stuart Did you get chance to review it again. Let me know if you have any new comments or suggestions. Thanks Tristan -邮件原件- 发件人: Tristan Yan 发送时间: Thursday, November 14, 2013 11:09 PM 收件人: Stuart Marks 抄送: core-libs-dev@openjdk.java.net 主题: 答复: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port Thank you Stuart It took me a little time to correct the code. sorry be late. This is new webrev for the code change. Please help to review it again. Description: 1. Convert shell script test to Java program test. 2. Using random server port by reusing Darryl Mocek's work(TestLibrary.getUnusedRandomPort) to replace fixed server port. 3. Because TestLibrary doesn't have package. Here is using reflection to call TestLibrary.getUnusedRandomPort. This is going to change when TestLibrary moves to named package. 4. Using java Process class to start client process. Client and server are sharing IO. 5. Also convert other shell script test runSerialBench.sh to java program test also. 6. ProblemList has been changed to get back java/rmi/reliability/benchmark/runRmiBench.sh test. http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ Thank you so much Tristan -邮件原件- 发件人: Stuart Marks 发送时间: Tuesday, November 12, 2013 11:38 PM 收件人: Tristan Yan 抄送: core-libs-dev@openjdk.java.net; Alexandre (Shura) Iline 主题: Re: RFR for JDK-7190106 RMI benchmark fails intermittently because of use of fixed port Unfortunately we can't use jdk.testlibrary.Utils.getFreePort() for the RMI tests, since RMI's TestLibrary.getUnusedRandomPort() respects a reserved port range that's used by some RMI tests that have to used fixed ports. s'marks On 11/11/13 2:39 PM, Tristan Yan wrote: Hi Stuart Also there is one more solution, which is there is one jdk.testlibrary.Utils.getFreePort() method under test/lib. It's same function as TestLibrary.getUnusedRandomPort() and it has named package. Do you mind I use this one? Since these two functions provide same functionality. Maybe we should think about to merge them at the same time. Thank you Tristan On 11/10/2013 11:19 AM, Tristan Yan wrote: Hi Stuart I tried your suggestion but unfortunately all the benchmarks have dependencies to Main class because they need get stub from server. I suggest we move the benchmark tests to unnamed package unless we do want to put TestLibrary into a named package right now. Please let me know if you have objection on this. Thank you Tristan On 11/09/2013 02:28 AM, Stuart Marks wrote: Hi Tristan, Yes, it's kind of a problem that the RMI TestLibrary is in the unnamed package. Classes in a named package cannot import classes from the unnamed package. We've run into problems with this before. Eventually, we should move TestLibrary a named package. I think it's possible to work around this without too much difficulty. Note that classes in the unnamed package can import classes from named packages. So, perhaps you can put the RmiBench main class in the unnamed package so it has access to TestLibrary. Then have the benchmarks themselves in the bench.rmi package. The config file already references the benchmarks by fully qualified class name (e.g., bench.rmi.NullCalls) so with a bit of tinkering you ought to be able to get this to work. s'marks On 11/8/13 3:00 AM, Tristan Yan wrote: Thank you, Stuart There is one review point I want to ask you opinion. Which is the reason that I moved from test/java/rmi/reliability/benchmark/bench/rmi to test/java/rmi/reliability/benchmark is Main.java need access class TestLibrary for supporting random port. TestLibrary is a unpackage class, I couldn't find a way to let a class which has Package to access the class without package. Do you have suggestion on that? Thank you so much. Tristan On 11/06/2013 09:50 AM, Stuart Marks wrote: On 11/1/13 9:18 AM, Tristan Yan wrote: Hi Everyone http://cr.openjdk.java.net/~pzhang/Tristan/7190106/webrev/ Description: 1. Convert shell script test to Java program test. 2. Using random server port by reusing Darryl Mocek's work to replace fixed server port. 3. Using java Process class to start client process. 4. Also convert other shell script test runSerialBench.sh to java program test also Hi Tristan, Several comments on this webrev. ** The original arrangement within the test/java/rmi/reliability/benchmark directory had the main benchmark files (scripts) at the top, some benchmark framework files in the bench subdirectory, and the actual RMI and serialization benchmarks in bench/rmi and bench/serial subdirectories. The webrev moves all the RMI benchmarks to the top benchmark directory but leaves the serial benchmarks in bench/serial. The RMI benchmarks are now all cluttering the top directory, but the main serial benchmark test is now buried in the bench/serial directory. The nice organization that was there before is now
Re: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2'
Hi Martin, i incorporated the recent changes from the pointer as well. I have reproduced the failure, the logs of which are attached to the bug JDK-6772009 https://bugs.openjdk.java.net/browse/JDK-6772009 . The failed log is especially interesting . -- Thanks kalyan On 11/18/13 10:15 PM, Martin Buchholz wrote: Thanks for working on this. There have been some recent upstream changes to this test as well. Please incorporate them. http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/jtreg/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java?view=co The jsr166 maintainers haven't been able to reproduce any failures in this test. Do you have any hints that might help us? On Mon, Nov 18, 2013 at 10:12 PM, srikalyan chandrashekar srikalyan.chandrashe...@oracle.com mailto:srikalyan.chandrashe...@oracle.com wrote: Hi all, I am working on bug JDK-6772009 https://bugs.openjdk.java.net/browse/JDK-6772009 . Root Cause: The timeout value gives too much grace period on faster machines on which the TO BE INTERRUPTED threads complete faster before being interrupted at right time. Suggested Fix: a) Decrease the timeout from 100 to 50ms which will ensure that the test will pass even on faster machines , and ensures the threads will be canceled when running and anyways there is a Barrier to ensure the test threads all complete gracefully. Miscellaneous fixes b) Convert result from int to long(possible integer overflow otherwise) c) Catch BrokenBarrierException in more granular fashion in ReentrantLockLoop to update and print the results (which will be missed otherwise) Add more diagnostics d) Assign names to threads e) Print which threads update the 'completed' variable. I have attached the webrev for convenience as the changes are interleaved and is best viewed as sdiff. Please let me know if you have any comments or suggestions. Thank you -- -- Thanks kalyan
Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
Looks ok Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Nov 19, 2013, at 6:57 PM, Dan Xu dan...@oracle.com wrote: Hi All, Please review the simple fix towards Size.java testcase. It failed once on windows platform in the recent same binary run, which is mostly due to some interferences and the special delete handling on windows. In the fix, I remove the delete operation in initTestFile() method because FileOutputStream will truncate the file content and it is not necessary to delete it first. Thanks! Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ http://cr.openjdk.java.net/%7Edxu/8028628/webrev/ -Dan
Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
On 11/19/2013 3:57 PM, Dan Xu wrote: Hi All, Please review the simple fix towards Size.java testcase. It failed once on windows platform in the recent same binary run, which is mostly due to some interferences and the special delete handling on windows. In the fix, I remove the delete operation in initTestFile() method because FileOutputStream will truncate the file content and it is not necessary to delete it first. Thanks! Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ http://cr.openjdk.java.net/%7Edxu/8028628/webrev/ The patch itself is okay. Would you think if writing to a file in the current directory rather than temp is less prone to the interference? Mandy
Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
Hi Mandy, I think that writing to the current directory and writing to the temp directory will get the same interference in this testcase. Because the interference is mostly coming from the anti-virus software or some windows system services. Any file changes in the file system may trigger them. Due to the interference, if a test deletes a file and then immediately create a file with the same name, the create operation may fail with access denied exception. I have described it in detail when discussing Chris's webrev, http://openjdk.5641.n7.nabble.com/RFR-8022213-Intermittent-test-failures-in-java-net-URLClassLoader-Add-jdk-testlibrary-FileUtils-java-td165561.html. Thanks! -Dan On 11/19/2013 07:08 PM, Mandy Chung wrote: On 11/19/2013 3:57 PM, Dan Xu wrote: Hi All, Please review the simple fix towards Size.java testcase. It failed once on windows platform in the recent same binary run, which is mostly due to some interferences and the special delete handling on windows. In the fix, I remove the delete operation in initTestFile() method because FileOutputStream will truncate the file content and it is not necessary to delete it first. Thanks! Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ http://cr.openjdk.java.net/%7Edxu/8028628/webrev/ The patch itself is okay. Would you think if writing to a file in the current directory rather than temp is less prone to the interference? Mandy
RFR for JDK-6933803 Bring back test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java
Hi Everyone We have a test java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java that was put into ProblemList because of bug JDK-6933803, this test has been fixed in http://hg.openjdk.java.net/jdk8/tl/jdk/diff/cb3ecb5e4ce5/test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java. We have run a 1000 times loop test for making sure there is no issue in this test anymore and we don't see any failure . I think it's good time to bring this test back from ProblemList. http://cr.openjdk.java.net/~ewang/tristan/JDK-6933803/webrev.00/test/ProblemList.txt.sdiff.html Please let me know if you have comment on this. Thank you. Tristan Yan(Haibo Yan)
Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
Thanks for the details Dan [1]. It is useful. The reason why I was wondering the difference with temp dir is that the test workdir might be excluded from the anti-virus scanner on that test machine. Now you have explained it. thanks Mandy [1] http://mail.openjdk.java.net/pipermail/net-dev/2013-November/007783.html On 11/19/2013 8:13 PM, Dan Xu wrote: Hi Mandy, I think that writing to the current directory and writing to the temp directory will get the same interference in this testcase. Because the interference is mostly coming from the anti-virus software or some windows system services. Any file changes in the file system may trigger them. Due to the interference, if a test deletes a file and then immediately create a file with the same name, the create operation may fail with access denied exception. I have described it in detail when discussing Chris's webrev, http://openjdk.5641.n7.nabble.com/RFR-8022213-Intermittent-test-failures-in-java-net-URLClassLoader-Add-jdk-testlibrary-FileUtils-java-td165561.html. Thanks! -Dan On 11/19/2013 07:08 PM, Mandy Chung wrote: On 11/19/2013 3:57 PM, Dan Xu wrote: Hi All, Please review the simple fix towards Size.java testcase. It failed once on windows platform in the recent same binary run, which is mostly due to some interferences and the special delete handling on windows. In the fix, I remove the delete operation in initTestFile() method because FileOutputStream will truncate the file content and it is not necessary to delete it first. Thanks! Bug:https://bugs.openjdk.java.net/browse/JDK-8028628 Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/ http://cr.openjdk.java.net/%7Edxu/8028628/webrev/ The patch itself is okay. Would you think if writing to a file in the current directory rather than temp is less prone to the interference? Mandy
jar command shows bit length overflow
I just rebuild jdk8/tl on Windows and calling jar uvf shows a lot of bit length overflow code ?? bits ?-? A little grep shows jdk/src/share/native/java/util/zip/zlib-1.2.5/trees.c could print this. Something goes wrong or is it just me? Said that, it looks like the jar file is fine. Thanks Max
