5 Replies Latest reply on Feb 18, 2006 5:32 PM by Adrian Brock

    jsr166 tck issues

    ryan.campbell Expert

      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.

        • 1. Re: jsr166 tck issues
          ryan.campbell Expert

          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 Expert

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

            • 3. Re: jsr166 tck issues
              ryan.campbell Expert

              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 Master

                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 Master

                  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.