RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
chris.hegarty at oracle.com
Fri Jun 2 13:40:32 UTC 2017
On 02/06/17 00:14, Ioi Lam wrote:
> The gem is hidden in the compile.0.jta file. It contains something like:
> -sourcepath <blahblah>:/jdk/foobar/test/lib:<blahblah>
> So if my test refers to a class under /test/lib, such as
> jdk.test.lib.process.ProcessTools, javac will be able to locate it under
> /jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will
> build it automatically.
> So really, there's no reason why the test must explicitly do an @build
> of the library classes that it uses.
Sure, you're relying on the implicit compilation of dependencies
by javac. Look at the output, where it compiles the library
classes to. It is part of the classes directory for the
individual test. That means that the library classes will need
to be compiled many many times. The @build tag will compile
the library classes to a common output directory, where they
can be reused ( unless I'm missing something ).
More information about the core-libs-dev