Just as a point of information:
The HotSpot team was well aware of these issues when removing the @build
flags from the HotSpot test cases. We felt these were less evils than
random failures in our test runs. After the @build removal, the
incidence of random NoClassDefFoundError in HotSpot tests has greatly
reduced (except for the few cases caused by CODETOOLS-7901986 [1]). We
have heard no complains since the removal (JDK-8157957) was pushed
almost a year ago.
I think we should take this chance to recognize that the existing use of
@library and @build has been very hard to maintain. Instead of dwelling
on how horrible the situation is, let's come up with a better, cleaner
way of using libraries in our jtreg-based test cases.
How about:
+ focus on test development productivity and ease of test maintenance
+ it should be easy to use a library with minimal effort
+ rules should be minimal - the fewer, the better
+ if a rule is violated, it should be immediately flagged
Thanks
- Ioi
[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986
On 6/5/17 4:52 PM, Jonathan Gibbons wrote:
a. That will blow up the space requirements, if every test that uses a
library gets its own compiled version of the library ... especially
with the current trend in the jdk/hotspot repos of using deep package
hierarchies.
b. Using implicit compilation will not detect changes to files that
were previously implicitly compiled ... i.e if modifying a library
while developing a test.
On 06/05/2017 04:42 PM, Igor Ignatyev wrote:
from my point of view, we expect to much works from test authors for
little benefits. as you can see in another email thread[1-2], sharing
library classes saves very little time. hence if it's the only
benefits of having correct explicit @build actions for library
classes, I'd prefer us to remove sharing of library classes from
jtreg and put all compiled classes into isolated directories
regardless location of a build target. this will significantly
simplify work on tests, test stability and eliminate those sporadic
NCDFE for good.
-- Igor
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048076.html
[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048090.html
On Jun 5, 2017, at 4:18 PM, Jonathan Gibbons
<[email protected]> wrote:
You cannot completely disable implicit compilation as a concept,
because it is built into javac, and has been since Day One.
But we could reduce its impact.
javac does have an option -implicit:none, which stops it *writing*
implicitly compiled classes, (but not stop it reading them). So the
compilation will succeed, but the runtime may fail, because some
necessary classes may not have been written. We may be able to test
(play) with that idea by using the jtreg option "-javacoption:<option>"
We could reduce the chance of it reading source files it might want
to implicitly compile by reducing what goes on the source path. That
would require changes to jtreg.
It should be easy enough to write scripts to run tests one at a time
and test for implicitly compiled classes, or you could try the
approach I suggested earlier and run blocks of tests and look for
duplicate class files, as an indication of implicit compilation.
-- Jon
On 06/05/2017 03:50 PM, Igor Ignatyev wrote:
Hi Jon,
if tests are supposed to declare all library classes they depend
on, tests start to depend on a library design, so refactoring of
the library will force us to do massive update of the tests to fix
their explicit builds, but to find all such tests, we will have to
run them one by one. so this approach does not really scale and it
is also kinda fragile.
if we can not relay on implicit compilation done by @build (and
implicit @build) actions, shouldn't we remove it completely? or at
least introduce a jtreg flag which disables it or reports all such
usage as errors? this will give us a way to find all tests to fix
and eventually will make the whole testsuite more reliable.
-- Igor
On Jun 5, 2017, at 3:39 PM, Jonathan Gibbons
<[email protected]> wrote:
On 06/05/2017 03:24 PM, Martin Buchholz wrote:
Can we find missing @build directives by running each individual
jtreg test by itself with a clean JTwork directory?
That's generally been the recommended way.
You might also be able to do run groups of tests (such as all
tests that use a given library) and then look for duplicate
classes in the compiled classes directory. Such classes will
generally be an indication of implicit compilation.
-- Jon
