RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
ioi.lam at oracle.com
Fri Jun 2 15:44:36 UTC 2017
On 6/2/17 6:40 AM, Chris Hegarty wrote:
> 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 ).
Yes, @build will compile classes so that they can be reused. But why
should it be the responsibility of every test to do this?
To reuse my malloc metaphore -- is it reasonable for every program that
uses malloc to explicitly build libc?
By the way, jtreg arranges the output directory of the test by the
directory they sit in, so
will all output their .class files to the same directory. Therefore, the
amount of duplicated classes is not as bad as you might think. We've
been omitting the @build tags in the hotspot tests and we haven't seen
More information about the core-libs-dev