On 6/21/11 7:12 PM, Chris Hegarty wrote:
[...]
> I'm not sure the extra check in checkThreadState that the thread must
> be RUNNABLE is valid. What if you are transitioning the thread from a
> blocked to non-blocked state, you may still see it blocked on the
> first call to getState.
> L130-11
On 06/21/2011 12:32 PM, Xueming Shen wrote:
OK, it's a nit-pick and it has nothing to do with this fix, and it
probably has been there from day
one. But just wonder if those "%n" should be replaced by "/n" in
those properties file, otherwise
I meant to say "the /n should be replaced by %n".
On 06/21/2011 12:32 PM, Xueming Shen wrote:
OK, it's a nit-pick and it has nothing to do with this fix, and it
probably has been there from day
one. But just wonder if those "%n" should be replaced by "/n" in those
properties file, otherwise
I meant to say "the /n should be replaced by %n".
m
OK, it's a nit-pick and it has nothing to do with this fix, and it
probably has been there from day
one. But just wonder if those "%n" should be replaced by "/n" in those
properties file, otherwise
my guess is that the result of java -help will not have the correct
line-end on Windows platform.
Kumar Srinivasan wrote:
Hi,
Please review ...
http://cr.openjdk.java.net/~ksrini/7046007/webrev.0/
http://cr.openjdk.java.net/~ksrini/7046007/cmt.txt
I think this is actually a 2 character fix :-)
Looks good to me.
-Alan
On 6/21/2011 11:23 AM, Kumar Srinivasan wrote:
Hi,
Please review ...
http://cr.openjdk.java.net/~ksrini/7046007/webrev.0/
http://cr.openjdk.java.net/~ksrini/7046007/cmt.txt
Thanks
Kumar
Approved!
-Joe
Hi,
Please review ...
http://cr.openjdk.java.net/~ksrini/7046007/webrev.0/
http://cr.openjdk.java.net/~ksrini/7046007/cmt.txt
Thanks
Kumar
Changeset: 70f14c2db078
Author:alanb
Date: 2011-06-21 16:11 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70f14c2db078
7056815: test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh times out
intermittently on busy machine
Reviewed-by: mchung
! test/java/lang/ClassLoad
On 06/21/11 12:12 PM, Chris Hegarty wrote:
Thanks Alan, David, Mandy for you comments.
> The retry loop in checkThreadState make sense. Is the 100ms sleep a
> bit excessive? The thread will likely get to the expected state in a
> fraction of that time.
True, reduced to 10ms.
Oh, I also inc
Thanks Alan, David, Mandy for you comments.
> The retry loop in checkThreadState make sense. Is the 100ms sleep a
> bit excessive? The thread will likely get to the expected state in a
> fraction of that time.
True, reduced to 10ms.
> I'm not sure the extra check in checkThreadState that the th
Mandy Chung said the following on 06/21/11 20:08:
On 6/20/11 8:54 PM, Chris Hegarty wrote:
java/lang/Thread/ThreadStateTest.java can fail with when
checkThreadState finds an unexpected state.
Exception in thread "main" java.lang.RuntimeException: MyThread
expected to have TERMINATED but got R
Hi Chris,
On 6/20/11 8:54 PM, Chris Hegarty wrote:
java/lang/Thread/ThreadStateTest.java can fail with when
checkThreadState finds an unexpected state.
Exception in thread "main" java.lang.RuntimeException: MyThread
expected to have TERMINATED but got RUNNABLE
at ThreadStateTest.checkTh
Apologies for overlooking the core-libs audience.
On 06/20/11 23:42, Joe Darcy wrote:
> Vincent Ryan wrote:
>> On 06/20/11 16:08, Alan Bateman wrote:
>>
>>> Vincent Ryan wrote:
>>>
:
Thanks Alan. JNDI applications are encouraged to call close() rather
than
rely on GC to f
13 matches
Mail list logo
