-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b69
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8018729 | 7u45 | Stuart Marks | P4 | Closed | Fixed | b01 |
JDK-8005027 | 7u40 | Stuart Marks | P4 | Closed | Fixed | b08 |
JDK-8010567 | 7u25 | Stuart Marks | P4 | Closed | Fixed | b03 |
JDK-8008845 | 7u21 | Stuart Marks | P4 | Closed | Fixed |
The @build tags are used quite haphazardly in the RMI regression tests. Several things need to be done.
1) Tests that uses TestLibrary should list TestLibrary first. This is because of order dependencies in jtreg that might cause subsequent tests to break. See CODETOOLS-7900024. Briefly, if a test uses library classes, jtreg is supposed to compile those library classes and store the results in a place where they can be reused by subsequent tests. Unfortunately, if the test's @build tags compile test classes first, the library classes get compiled implicitly and get stored in the wrong location. Apparently jtreg remembers that it compiled them but since they're in the wrong location, subsequent tests may fail with NoClassDefFoundError. The workaround is to list library classes first in @build directives.
2) Classes that are explicitly depended upon by the test should be listed in @build, but not second-level dependencies in the library (e.g. StreamPipe).
3) It is not necessary to list the main test class in a @build tag, since the @run tag will build it implicitly.
4) Several classes should be consolidated onto a single @build line where possible, as this seems to speed up the test run a bit.
5) Every test should have a @run tag. This isn't strictly necessary, but it helps to avoid errors. If a test has no @run tag, jtreg will implicitly just run it. But if a maintainer were to add a @build tag (shorthand for @run build) the build step will be executed and jtreg's implicit run behavior will not occur. Thus the test will not be run!
1) Tests that uses TestLibrary should list TestLibrary first. This is because of order dependencies in jtreg that might cause subsequent tests to break. See CODETOOLS-7900024. Briefly, if a test uses library classes, jtreg is supposed to compile those library classes and store the results in a place where they can be reused by subsequent tests. Unfortunately, if the test's @build tags compile test classes first, the library classes get compiled implicitly and get stored in the wrong location. Apparently jtreg remembers that it compiled them but since they're in the wrong location, subsequent tests may fail with NoClassDefFoundError. The workaround is to list library classes first in @build directives.
2) Classes that are explicitly depended upon by the test should be listed in @build, but not second-level dependencies in the library (e.g. StreamPipe).
3) It is not necessary to list the main test class in a @build tag, since the @run tag will build it implicitly.
4) Several classes should be consolidated onto a single @build line where possible, as this seems to speed up the test run a bit.
5) Every test should have a @run tag. This isn't strictly necessary, but it helps to avoid errors. If a test has no @run tag, jtreg will implicitly just run it. But if a maintainer were to add a @build tag (shorthand for @run build) the build step will be executed and jtreg's implicit run behavior will not occur. Thus the test will not be run!
- backported by
-
JDK-8005027 TEST_BUG: clean up @build tags in RMI tests
-
- Closed
-
-
JDK-8008845 TEST_BUG: clean up @build tags in RMI tests
-
- Closed
-
-
JDK-8010567 TEST_BUG: clean up @build tags in RMI tests
-
- Closed
-
-
JDK-8018729 TEST_BUG: clean up @build tags in RMI tests
-
- Closed
-
- relates to
-
CODETOOLS-7900024 jtreg can mishandle implicitly compiled library classes, causing subsequent tests to fail with NoClassDefFoundError
-
- Open
-