-
1. Re: jsr166 tck issues
ryan.campbell Feb 18, 2006 1:35 PM (in response to 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) -
2. Re: jsr166 tck issues
ryan.campbell Feb 18, 2006 1:44 PM (in response to ryan.campbell)The atomic types don't implement getLazySet, so I have removed those tests from Atomic*Test.
-
3. Re: jsr166 tck issues
ryan.campbell Feb 18, 2006 3:35 PM (in response to 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? -
4. Re: jsr166 tck issues
adrian.brock Feb 18, 2006 5:26 PM (in response to ryan.campbell)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. -
5. Re: jsr166 tck issues
adrian.brock Feb 18, 2006 5:32 PM (in response to ryan.campbell)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.