Roger,
Thanks for the reply. I agree completely with your explanation.
I understand there are multiple efforts running to address this issue,
so I'll leave it to yourselves to work out the details, but as far as a
point fix, yours is good.
-Chris.
On 11/19/2013 01:09 AM, roger riggs wrote:
Hi Chris,
Here's an example from a failing test run:
-J-Dtest.classes=/export/jdk8-tl-test/JTwork/classes/0/sun/management/jmxremote/bootstrap
\\
-J-Dtest.class.path=/export/jdk8-tl-test/JTwork/classes/0/sun/management/jmxremote/bootstrap:/export/jdk8-tl-test/JTwork/classes/0/lib/testlibrary
Note that test.classes does not include the @library path lib/testlibrary.
So if lib/testlibrary is supposed to be available to the spawned process
then using test.class.path is needed.
Including @build will compile the library classes into /lib/testlibrary
but that's not enough.
It happens that if the classes are not already compiled in
lib/testlibrary (and there is no @build)
then the files will be compiled on demand by javac into the test.classes
directory.
And in that case they are 'accidentally' available to the spawned
process but by using @library
that does not seem to be the intention.
The test fails if the lib/testlibrary classes have been compiled by a
previous test.
Yes, there are other tests using jdk.testlibrary that do not have the
@build;
there maybe some tests that fail to pass the full test.class.path.
I'll recheck , but that's out of scope for the particular issue.
Thanks, Roger
On 11/18/2013 5:25 PM, Chris Hegarty wrote:
On 18 Nov 2013, at 21:59, roger riggs <[email protected]> wrote:
Please review this fix to improve the reliability of the
jmxRemote/LocalManagementTest and CustomLauncherTest. The solution
may apply to other tests that fail with ClassNotFound.
The tests did not include the jdk.testlibrary in the classpath when
it spawns a new process. The failure mode is dependent on the order
that tests had been run.
Also note that if a test depends on classes in the jdk.testlibrary it
should include @build <classname> to ensure they are built in the
@library directory
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-localmanagement-8028141/
I've come across some of these before. The changes to the tags make
sense.
About the change to the property, test.class.path, I thought
test.classes was right. Is this different from what other tests are
doing?
-Chris.
Thanks, Roger
