jsr166 tck issues

[ryan.campbell]

I have checked in the jsr166 tck from Doug Lea's site into jbossretro/src/test. There are plenty of compile errors as it looks like not all of the proposed API made it in to jdk5 (some will be in Mustang). I'm starting this thread so that I can document the changes I am making to fix the compile errors.

In general, I plan to use the backport tests as a guide, but any other advice is appreciated.

[ryan.campbell]

The following tests were removed since the classses they test aren't present in java 5.

- AbstractQueuedLongSynchronizerTest
- ArrayDequeTest
- ConcurrentSkipList*
- LinkedBlockingDequeTest
- TreeSubMapTest & TreeSubSetTest (NavigableMap doesn't exist)

[ryan.campbell]

The atomic types don't implement getLazySet, so I have removed those tests from Atomic*Test.

[ryan.campbell]

Ok, I'm going to stop until I get some agreement on the changes I'm making. I haven't documented them all in this thread, but I they are all listed here:

http://anoncvs.forge.jboss.com/changelog/JBoss/jbossretro/src/test/org/jboss/test/concurrent

There are a lot of methods tested here that aren't in java5, presumably because this version of the TCK was released after the spec was approved or java 1.5 was released.

Specifically, perhaps someone could look at ThreadPoolExecutorSubclassTest.java and ScheduledExecutorSubclassTest.java. These won't compile because they rely on RunnableScheduledFuture, but more importantly, the classes under test (the Executors) seemed to have changed their interface significantly. Like dropping decorateTask...

Or just tell me to remove the non-compiling code and get on with running the tests :-) But I know we want to understand the diffs between the backport and java.util.concurrent.

The backport is generally a superset of java.util.Concurrent, but there are some interface/contract changes such as with the executors.
So just deleting some of these tests might result in us not catching some things of these contract changes.

Thoughts?

[adrian.brock]

Start with running the tests that are done explicitly for the backport tests.
The backport has a lot more tests than it actually runs.

The main thing we are trying to test is how good the weaving is
since the backport implementation is not generified.

What is missing is secondary since those will be caught by retrocheck.
The backport tests themselves are testing the implementation.

Even if you can only get a subset to compile under java5 it will be start
on accessing how good the weaving is.

[adrian.brock]

You might want to revert to my initial option.
i.e. reverse weave the backport tests to use JDK5 classes.

But this won't catch generics issues.