I think the core of your confusion is that a Path
does not necessarily represent a file on your computer. It is simply a Java object that represents a conceptual object in a file system. In the same way that you could construct a new Person("John", "Smith")
without actually knowing anyone named 'John Smith', you can construct a Path
regardless of whether or not a file exists at the given location.
Once you have a Path
there are a number of things you can do with it, including check if it exists via Files.exists()
, or create it with Files.createFile()
. Generally speaking, the Files
class lets you inspect and work with the actual file system objects a Path
represents.
The intent of a PathMatcher
is similarly disconnected from the actual file system; it exists to to determine if a given Path
fits the PathMatcher
's pattern - it's basically a Path
-specific regular expression engine.
So what your code is actually doing is:
- Creating a glob that will match any path which ends in
.java
or .class
(regardless of whether such a path exists anywhere).
- Constructing a relative
Path
to a file called Go,mvDep.java
. Implicitly this path is relative to the current working directory, but you could pass it to Path.resolve()
to create a new Path
referring to a file in a different location.
- Checking if the path
Go,mvDep.java
matches your glob, which it does since it ends in .java
, so it prints the path.
It sounds like what you actually want is to find an existing file with the name Go,mvDep.java
. If so, you want to use Files.find()
to search a directory and return a stream of the files that match a BiPredicate<Path, BasicFileAttributes> matcher
you define. Your matcher
might look something like this:
new BiPredicate<Path, BasicFileAttributes>() {
public boolean test(Path path, BasicFileAttributes attributes) {
return matcher.matches(path);
}
}
Or in Lambda syntax simply:
(p, a) -> matcher.matches(p)