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 ca
Sorry I used an internal URL. Here's the proper openjdk URL:
http://cr.openjdk.java.net/~iklam/jdk10/8188828_compiler_test_class_not_found.v01/
Thanks
- Ioi
On 10/6/17 1:19 PM, Ioi Lam wrote:
Please review this very simple change:
https://bugs.openjdk.java.net/browse/JDK-8188828
http://ioil
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
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.o
Looks good.
Thanks,
Vladimir
On 10/6/17 1:28 PM, Igor Ignatyev wrote:
Hi Ioi,
I'm really happy we found such a simple workaround for this annoying problem
and hope it'll greatly reduce CNFE in our test runs.
the fix looks good to me.
Thanks,
-- Igor
On Oct 6, 2017, at 1:19 PM, Ioi Lam wr
Hi Ioi,
I'm really happy we found such a simple workaround for this annoying problem
and hope it'll greatly reduce CNFE in our test runs.
the fix looks good to me.
Thanks,
-- Igor
> On Oct 6, 2017, at 1:19 PM, Ioi Lam wrote:
>
> Please review this very simple change:
>
> https://bugs.open
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 ClassNotFoundEx
