RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
ioi.lam at oracle.com
Tue Jun 6 01:48:53 UTC 2017
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 ). 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.
+ 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
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
> 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
>>> On Jun 5, 2017, at 4:18 PM, Jonathan Gibbons
>>> <jonathan.gibbons at oracle.com> 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
>>>>> <jonathan.gibbons at oracle.com> 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
More information about the core-libs-dev