RFR: JDK-8277375: jdeps errors on a class path with a file path with no permission

[Michael Hall]

> On Nov 24, 2021, at 5:51 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Nov 24, 2021, at 2:55 AM, Alan Bateman <alanb at openjdk.java.net> wrote:
>> 
>> On Wed, 24 Nov 2021 01:12:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>> 
>>> This changes jdeps -cp to ignore files/directories with no permission to access.  This is consistent with the runtime behavior.
>> 
>> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 235:
>> 
>>> 233:                     @Override
>>> 234:                     public FileVisitResult visitFileFailed(Path file, IOException exc) throws IOException {
>>> 235:                         return FileVisitResult.CONTINUE;
>> 
>> The bug report may be pilot error in that they seem to have specified a root directory as the class path. If the scan is changed then maybe it should minimally emit a warning rather than silently ignoring the non-accessible files.
>> 
>> -------------
>> 
>> PR: https://git.openjdk.java.net/jdk/pull/6531
> 
> This was testing against a simple unpackaged class in my home directory. All the dependencies were javafx modular ones.
> There was definitely no dependency on a /Pictures package where there would be any need to look any further on this path.
> Is this scanning every directory off a class path one on the chance there might be a java class file that is a dependency?
> 
Given this invocation
jdeps --module-path ~/Documents/javafx-sdk-17.0.1/lib --print-module-deps -cp . PushMe.class 

Would there be any need to scan class path at all? That would mean a module would have a class path dependency wouldn’t it? Is that possible? 
Yes, I shouldn’t of included -cp at all but shouldn’t jeeps ignore it?