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
