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
