Chris,
excuse me, I'm not a reviewer but have some questions.
at line 209, classes is actually trying to resolve a path like
"c:\jdk1.9.0\modules", which never exists in JDK directory. It should be
"c:\jdk1.9.0\lib\modules".
207 if (home.resolve("lib").toFile().exists()) {
208 // either an exploded build or an image
*209 File classes = home.resolve("modules").toFile();*
210 if (classes.isDirectory()) {
211 return Stream.of(classes.toPath());
212 } else {
213 return JrtPaths();
214 }
The test works because it always go to JrtPaths method. The jimages have been
mounted at initializing of Jrt file system.
There may be two issues here:
1. the naming*J*rtPaths doesn't follow common rules. Is it more suitable
with*j*rtPaths()?
2. Even when changing classes to "lib/modules", it is still probably unable to
process class files. I tried last code and failed.
*File classes = home.resolve("lib/modules").toFile();*
Because, com.sun.tools.jdeps.ClassFileReader hasn't been upgraded to correctly
handle Jrt image files.
So this logic is either unnecessary (as stated above, the jimages have been
mounted at initializing of Jrt file system) or unable to work now.
Thanks,
-Felix
On 1/15/2015 12:31 AM, Chris Hegarty wrote:
On 14/01/15 16:18, Mandy Chung wrote:
On 1/14/2015 8:04 AM, Chris Hegarty wrote:
http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/
Looks okay to me.
In CallerSensitiveFinder.java line 57, 80, 137 - not sure if you were
thinking to pass "pool" to the CallerSensitiveFinder constructor. Looks
like some editing you meant to cleanup.
nit: line 76 a space between "classes" and "=="
line 207 can be removed.
D'oh! Fixed both of these. Webrev updated in place.
-Chris.
Mandy
