Test after JDK-8181761, the explicit @build actions

Jonathan Gibbons jonathan.gibbons at oracle.com
Thu Jul 6 14:31:24 UTC 2017

On 7/6/17 2:45 AM, Alan Bateman wrote:
> On 06/07/2017 10:02, Weijun Wang wrote:
>> Hi Igor
>> I’ve about to add a new test that uses jdk.test.lib.SecurityTools and 
>> I see in your fix for JDK-8181761 that a lot of seemingly-unrelated 
>> classes are added into a @build action.
>> How do I determine what classes are needed? Or shall I just copy it 
>> from a test nearby?
>> I remember this was due to a jtreg bug(?). Has it been resolved? Do 
>> we need to add the @build action forever?
> Yeah, it's very messy just now. My understanding is that Igor is 
> planning to clean up the dependences in the test infrastructure 
> classes so much of this can go away.
> Separately, there are changes in flight for jtreg to improve the 
> reliability of tests running with agentvm + concurrency. Jon pushed 
> CODETOOLS-7902003 to the jtreg code a few days ago so that each test 
> gets a unique test.classes. That should avoid a lot of the issues that 
> Igor was initially working around by trying to change the tests to 
> depend on implicit compilation. This change exposes a few issues with 
> the handling of test.classes in a few tests so they have been fixed too.
> In summary, you might have to temporarily add some annoying @build 
> tags but they will go away, and hopefully soon.
> -Alan

It has always been the case that it is recommended to use @build tags 
for library classes. The recent jtreg work makes jtreg better able to 
run tests reliably that have insufficient @build tags, but a 
contributing factor to the issues here has been the growing complexity 
of the library (test infrastructure) classes. If nothing else, it would 
be helpful for someone to analyze those library classes (jdeps?) to 
determine the dependencies that each class has. That would be a good 
first step to understanding the dependencies, such that they can be 
eliminated or documented.

I note that jtreg does have short forms for @build, such as to compile 
all the classes in a package or module, that could be used effectively 
if the library is designed appropriately.

-- Jon

More information about the core-libs-dev mailing list