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

[Jonathan Gibbons]

On 05/31/2017 01:38 AM, Alan Bateman wrote:
> On 31/05/2017 09:05, Felix Yang wrote:
>
>> Hi Alan
>>
>>     even with explicit compilation, I also observed failures. I'm 
>> curious what is the best practice here. IMO, there could be a 
>> potential jtreg bug.
> One of the tests listed in JDK-8181299 is 
> java/net/URLConnection/6212146/TestDriver.java. In jdk10/jdk10 the 
> test description has:
>
> @build jdk.test.lib.JDKToolFinder jdk.test.lib.process.ProcessTools Test
>
> but the test fails intermittently with:
>
> java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
> at jdk.test.lib.process.ProcessTools.getOutput(ProcessTools.java:85)
> at jdk.test.lib.process.OutputAnalyzer.<init>(OutputAnalyzer.java:47)
> at 
> jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:397)
> at 
> jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:425)
> at 
> jdk.test.lib.process.ProcessTools.executeCommand(ProcessTools.java:475)
> at TestDriver.main(TestDriver.java:61)
>
> I assume changing the @build to jdk.test.lib.process.* will fix this, 
> assuming all the classes needed for ProcessTools are in this package.
>
> As to why it's intermittent then I think it's a side effect of test 
> library classes being compiled by one test and then re-used by a test 
> that runs sometime later in the same VM. Combine that with implicit 
> compilation, varied @build usages, and concurrently should explain why 
> it's intermittent. I see you've cc'ed Jon Gibbons and he is the best 
> person to comment on this. Now seems a good time to get to the bottom 
> of these issues, esp. with Igorchanging lots of tests to drop the 
> explicit compilation of test library classes.
>
> -Alan

That's a Big Red Flag with a Titanic-sized fog-horn warning of the danger.

jtreg is no different from make. If you want concurrency, you *must* 
provide accurate dependency information.  As a general rule, each test 
should accurately define what library classes need to be built in order 
for it to be executed reliably and correctly in a multi-threaded 
environment.

The one exception/clarification to make to that rule is that as a 
general rule, you can/should replace @compile with @build.  @compile 
always performs a compilation, @build only performs the compilation if 
the .class file is out of date.

I'll echo Alan's comment, which hit the nail on the head:
> As to why it's intermittent then I think it's a side effect of test 
> library classes being compiled by one test and then re-used by a test 
> that runs sometime later in the same VM. Combine that with implicit 
> compilation, varied @build usages, and concurrently should explain why 
> it's intermittent. 

If you want a tip for seeing if you have the correct set o0f @build 
directives for a test ... use jtreg to build/run just that one test by 
itself in a *clean*/empty work directory.   Look at the classes that 
were compiled. Were any of the generated classes compiled implicitly, 
i.e. not mentioned in @build directives?  If so, add suitable @build 
directives.

-- Jon