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)