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 ).
-Chris.
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
jdk/test/foo/bar/XTest.java
jdk/test/foo/bar/YTest.java
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
any problems.
- Ioi
