Defect in IBM Java SDK affects MultithreadedTC (Thread.getState())

[GoogleCodeExporter]

We are using MultithreadedTC for some weeks now and are very happy with it.
Unfortunately we had some difficulties running it on IBM JREs.

What steps will reproduce the problem?
1. Get a IBM Java 5 Runtime (unfortunately dififcult to get, bundled with
IBM PC or with IBM Java products, for example "Rational Application
Developer for WebSphere Software", which has a trial version
(http://www-01.ibm.com/software/awdtools/developer/application/))
2. Run Example BoundedBufferTest

What is the expected output? What do you see instead?
This test should run without errors. Instead it fails with "no progress".
When started with debug info ("-Dtunit.trace=true"), it prints:
thread 1 is in state RUNNABLE
thread 2 is in state WAITING
... and so on

Thread 1 is actually waiting because of "buf.put(17);", but reported as
runnable by an IBM JRE.

What version of the product are you using? On what operating system?
MultiThreadedTC 1.01

java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511
(SR2))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32
j9vmwi3223-20060504 (JIT enabled)

Also tested with newer version
Java(TM) 2 Runtime Environment, Standard Edition (build
pwi32devifx-20090506 (SR9-SSU +PK76176+IZ44410+IZ44495))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows Server 2003 x86-32
j9vmwi3223ifx-20090225 (JIT enabled)

Microsoft Windows XP Professional [Version 5.1.2600]

Please provide any additional information below.

This bug is known to IBM, but will not be fixed in 1.5. As we are bound to
a special Websphere Application Server version, we cannot switch to Java 6.
Documentation of the bug can be found at
http://www-01.ibm.com/support/docview.wss?uid=swg21293565
The test works if the system property is faked to 1.4 ("-Djava.version=1.4.0")
Javadoc for Thread.getState() mentions it should not be used for
synchronization control, so this could be considered a bug in
MultithreadedTC, as you are using this method to control threads. Maybe you
could offer another possibility to handle Threads "the old way" than
checking the system property ("isJDK14" in class edu.umd.cs.mtc.TestFramework)

Thank you and best regards
Marcel Freese

Original issue reported on code.google.com by marcel.f...@googlemail.com on 4 Nov 2009 at 9:58

[GoogleCodeExporter]

This looks like it might be difficult to solve. But I will download the IBM JDK 
and
investigate what states the treads are in.

Original comment by nat.aye...@gmail.com on 4 Nov 2009 at 5:07

[GoogleCodeExporter]

Is there any chance that this will be fixed? As we are now running more tests 
in IBM JVMs, we will otherwise have to work around this.

Thank you!
Marcel Freese

Original comment by marcel.f...@googlemail.com on 18 Jun 2010 at 7:09

[GoogleCodeExporter]

Sorry for the delay. I have not been able to download the IBM JDK or find a 
workaround. Any ideas?

I will have a little more time to look at this once I complete my dissertation 
in August.

Thanks,
Nat

Original comment by nat.aye...@gmail.com on 18 Jun 2010 at 12:36

[GoogleCodeExporter]

Hello Nat, thank you for your quick reply. For us it would be best to switch 
back to the old behaviour, at least for Java 1.5. I think there won't be any 
perfect fix for this.
Thanks
Marcel

Original comment by marcel.f...@googlemail.com on 22 Jun 2010 at 8:39

[GoogleCodeExporter]

Hi Marcel, 

We have only had two releases, so feel free to download the original version 
(1.0) to see if this works for you (just search for deprecated downloads). I 
don't think there is any other applicable version. Otherwise you may need to 
use a workaround.

I will take a closer look at this in mid-August, once I graduate.

Cheers,
Nat

Original comment by nat.aye...@gmail.com on 25 Jun 2010 at 2:18

[GoogleCodeExporter]

Hi Nat,
sorry for the late reply. I hope your graduation was successful. I tried 
version 1.0 (I compliled it myself as it was compiled for Java 6) and the 
problem was already there. In fact, the workaround was introduced in 1.01, 
because if you are running the JDK-1.4-Code (// JVM does not support 
Thread.State), it works.
It is annoying, because it's not MTC's fault, but a defect in IBM's JDK. The 
only problem in MTC is maybe that it's not using the Thread API as documented 
(getState(): "This method is designed for use in monitoring of the system 
state, not for synchronization control."
Thanks and best regards
Marcel

Original comment by marcel.f...@googlemail.com on 25 Aug 2010 at 7:04