> On Nov 24, 2021, at 5:51 AM, Michael Hall <mik3h...@gmail.com> wrote:
>
>
>
>> On Nov 24, 2021, at 2:55 AM, Alan Bateman <al...@openjdk.java.net> wrote:
>>
>> On Wed, 24 Nov 2021 01:12:01 GMT, Mandy Chung <mch...@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?
