Another possibility is to design the libraries so that they can be built
with a wildcard build, as in @build mypackage.*
I don't see that we will (or want to) ever get to a point in jtreg where
each library class can identify its own dependencies, such as suggested
below.
If the libraries can be prebuilt ahead of time, I don't see why they
can't be built by jtreg.
-- Jon
On 10/9/17 10:54 AM, Ioi Lam wrote:
There are several possibilities. One is to pre-compile a bunch of
libraries during the build time, and put them in the classpath using
the jtreg -cpa: option.
Another possibility is to change jtreg to better express the
dependency between different classes compiled by jtreg.
Thanks
- Ioi
On 10/8/17 6:33 PM, David Holmes wrote:
Hi Ioi,
This seems like a temporary workaround - fine for now - but what is
the real fix here? It's crazy that one test library class can't use
another class from the same test library!
Thanks,
David
On 7/10/2017 6:19 AM, Ioi Lam wrote:
Please review this very simple change:
https://bugs.openjdk.java.net/browse/JDK-8188828
http://ioilinux.us.oracle.com/webrev/jdk10/8188828_compiler_test_class_not_found.v01/
The dependency of
FileInstaller -> Utils -> JDKToolLauncher -> Platform
has caused many intermittent ClassNotFoundException in the hotspot
nightly runs.
While this fix does not address the root cause (proper dependencies
are not
specified in the test cases -- which we are planning to fix), we
will hopefully
see much fewer occurrences of this annoying failure scenario.
Thanks a lot to Igor for suggesting the simple fix!
- Ioi
