RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

[FELIX YANG]

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
>>
>>