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 >
