RFR(S) : 8180805 : move RandomFactory to the top level testlibrary

[Ioi Lam]

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 
>>> <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
>