On 14/05/2015 8:08 PM, Jaroslav Bachorik wrote:
On 14.5.2015 03:57, David Holmes wrote:
On 13/05/2015 9:46 PM, Jaroslav Bachorik wrote:
On 1.5.2015 21:55, Martin Buchholz wrote:
On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik
mailto:jaroslav.bacho...@oracle.com>>
wrote:
On 30.4.2015
On Sat, May 16, 2015 at 2:18 AM, Jaroslav Bachorik <
jaroslav.bacho...@oracle.com> wrote:
> On 15.5.2015 22:59, Martin Buchholz wrote:
>
>>
>> Consider creating a private thread group just for the test and
>> restricting the count assertions to just threads in that thread group -
>> that should be
On 15.5.2015 22:59, Martin Buchholz wrote:
You may submit, but:
---
the @test is _NOT_ a javadoc comment - /* is more standard.
http://openjdk.java.net/jtreg/tag-spec.html#EXAMPLES
-/*
+/**
* @test
* @bug 4530538
* @summary Basic unit test of ThreadMXBean.getAllThreadIds()
@@ -32,
You may submit, but:
---
the @test is _NOT_ a javadoc comment - /* is more standard.
http://openjdk.java.net/jtreg/tag-spec.html#EXAMPLES
-/*
+/**
* @test
* @bug 4530538
* @summary Basic unit test of ThreadMXBean.getAllThreadIds()
@@ -32,9 +32,30 @@
*/
On Thu, May 14, 2015 at 3:11
On 13.5.2015 21:14, Martin Buchholz wrote:
David has given you an approval; feel free to ignore me!
I tried running the test against jdk9, but it timed out!
... and it did print nice messages, didn't it? ;) I managed to leave in
a piece of code I used for testing the error messages. Sorry abo
On 14.5.2015 03:57, David Holmes wrote:
On 13/05/2015 9:46 PM, Jaroslav Bachorik wrote:
On 1.5.2015 21:55, Martin Buchholz wrote:
On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik
mailto:jaroslav.bacho...@oracle.com>>
wrote:
On 30.4.2015 19:18, Martin Buchholz wrote:
Tests tha
On 13/05/2015 9:46 PM, Jaroslav Bachorik wrote:
On 1.5.2015 21:55, Martin Buchholz wrote:
On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik
mailto:jaroslav.bacho...@oracle.com>>
wrote:
On 30.4.2015 19:18, Martin Buchholz wrote:
Tests that sleep can almost always be better writt
David has given you an approval; feel free to ignore me!
I tried running the test against jdk9, but it timed out!
It's common for users to introduce parallelism in classloaders or
jar-loaders (we do this at google) which may cause arbitrary thread
fluctuations. That makes this particular API rat
On 13.5.2015 19:40, Martin Buchholz wrote:
toString()should never return null, I think.
It doesn't matter much here. The test would fail with an NPE and it
would be right to do so. None of the suppliers should ever return null.
52 @Override
53 public String toString()
toString() should never return null, I think.
52 @Override 53 public String toString() { 54
T resolved = val.get(); 55 return resolved != null
? resolved.toString() : null; 56 }
I expected methods like waitForCondition to include a timeout with
fa
On 1.5.2015 21:55, Martin Buchholz wrote:
On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik
mailto:jaroslav.bacho...@oracle.com>> wrote:
On 30.4.2015 19:18, Martin Buchholz wrote:
Tests that sleep can almost always be better written some other way.
In this case, I would
On Thu, Apr 30, 2015 at 11:27 AM, Jaroslav Bachorik <
jaroslav.bacho...@oracle.com> wrote:
> On 30.4.2015 19:18, Martin Buchholz wrote:
>
>> Tests that sleep can almost always be better written some other way.
>> In this case, I would prefer busy-waiting with timeout until the
>> expected conditio
Hi Jaroslav,
On 1/05/2015 12:25 AM, Jaroslav Bachorik wrote:
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8078143
Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00
The test fails intermittently due to inconsistent reporting of the live
On 30.4.2015 19:18, Martin Buchholz wrote:
Tests that sleep can almost always be better written some other way.
In this case, I would prefer busy-waiting with timeout until the
expected condition becomes true.
The thing is that in case of a real issue with the thread counters we
a/ would be bus
Tests that sleep can almost always be better written some other way.
In this case, I would prefer busy-waiting with timeout until the expected
condition becomes true.
Here's some code from jsr166 tck tests:
/**
* Spin-waits until sync.isQueued(t) becomes true.
*/
void waitForQue
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8078143
Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00
The test fails intermittently due to inconsistent reporting of the live
threads number.It is related to
https://bugs.openjdk.java.ne
16 matches
Mail list logo
