Test after JDK-8181761, the explicit @build actions
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.
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.
More information about the core-libs-dev