Introduction
This is the seventh post in my streams series and it will be on detecting if a file exists in the current working directory with Java. I have also made a YouTube version of this post, so make sure to check that out as well.
To get things started I will be posting a code block, the code will be simple, but we are going to dive deep into the details.
public class ForDirectory {
public static void main(String[] args) {
Path doesExist= Paths.get("fish.txt");
boolean existsing = Files.exists(doesExist);
System.out.println(existsing);
}
}
Like I said, the code is very simple but we need simple code in order to dive deep.
1) public static void main(String[] args) : this is Java 101, the main method acts as the entry point for JVM. Public means that any class can access this method, static means that this method is part of the class and not the instance, void means that this method returns nothing and main is the method name. You can not change the name of the main method. The main method will lose its privileges and cease being the entry point if you change its name. String[] args is just for command line arguments but we are not using command line arguments so we don't have to worry about them.
2) Path doesExist= Paths.get("fish.txt") : when seeing this line, the first question that we should ask ourselves is, what is a Path? Good question, lets dive in.
What is a Path?
- Well a Path is a programme representation of a path in the file system, it contains the file directory name and the file name. Fancy documentation word vomit aside, what is a Path? Is it a class, object, static, what is it? If you look at the tutorial that I am basing this off ( Link Here ) of, you will notice the word class and object being used when talking about Path. However, when we look at the Path documentation it clearly states that Path is an interface. Does that mean an interface is a class?
Is an interface a class?
- Well after stumbling around stack overflow I was led to the Java specification . In the specification documentation at section 4.12.6 we can see the quote," Reference types include class types and interface types" and further down the page we get, " we often use the term type to refer to either a class or an interface". Here we clearly have two separate instances where classes and interfaces are declared as separate types. So to answer the question, no, interfaces are not classes. The tutorial also referred to Path as an object, does that mean Path is an object? Lets see if we can answer that.
Is a interface a object?
- I know this question might seem weird to ask since we just proved that an interface is not a class and objects are just instances of classes but humor me. On stack overflow, I was led to this link. Section 9.2 states, " if an interface has no direct super interface, then the interface implicitly declares a public abstract member method m with a signature s, return type r and throws clause t corresponding to each public interface method m with type s and return type r and throws clause t is explicitly declared by the interface." Now to loosely translate this technical jargon, "if an interface has no direct super interface the JVM creates all identical methods that are on the object class on the interface. So it makes the interface behave a little for like an object but no, an interface is not an object. Still no answer on what is a Path. Just to make sure we are all on the same page, lets get a better grip on what an interface is.
What is an interface?
- Simply put, an interface is a group of related methods with empty bodies. If that is all Interfaces are then why even use them? A main advantage to using an interface is that it allows a class to become more formal about the behaviour it provides. Interfaces form a contract between the class and the outside world, this "contract" is enforced at build time by the compiler. If a class claims to implement an interface, all methods defined by that interface must appear in its source code before the class will successfully compile. Now that we are on equal footing again, lets look at the code one more time.
Path doesExist = Paths.get("fish.txt");
- We know for a fact that Path is indeed an interface and here the Path interface is being used as a type for the reference variable doesExist. This is a very important fact, stated here, "if you define an reference variable whose type is an interface, any object you assign to it must be an instance of a class that implements the interface". So that tells us that doesExist must be an object that implements the Path interface. Looking at the code, one would assume that
get()
would return the object we are looking for. The documentation for Paths only states thatget()
returns a Path object, so back to square one.
Where is this object that implements the Path interface?
- The answer to this question lives here. Turns out that the actual class type that in instantiated and returned by Path classes' static methods are considered an implementation detail and is not specified in the documentation. Basically, an object is created and we just have to trust Java to implement the Path interface. Now that we have a solid understanding of what a Path object is, lets move on to Paths.get().
Paths.get("fish.txt") : first lets start off by trying to understand what Paths is and how it differs from Path. Paths is just a class that consists entirely of static methods that return a Path object. The main difference between Path and Paths is that Path is just an interface that is implemented by objects and Paths is a class whose whole existence is to return objects that implement the Path interface. I like to think of Path as the big brother to Paths.
-
get("fish.txt")
is a static method on the Paths object and it will return a Path object based on the string we give it. Paths.get() is actually just a shorthand forFileSystems.getDefault().getPath()
and understanding that code is very important to understand whatPats.get("fish.txt")
is doing.
FileSystems.getDefault() : using this method is how we get an instance of the underlying filesystem that is located on our computer. This will create an instance of the file system that the JVM can access and its default location is the current working directory. So calling this method will give the JVM access to files in the current working directory.
getPath() : this method will take a string and return a Path object. We know that the Path object is just any object that implements the Path interface.
- So when we call
Paths.get()
, it is actually callingFileSystems.getDefault().getPath()
which gets an instance of the underlying filesystem, returns the current directory and finally returns an object that implements the Path interface.
boolean existsing = Files.exists(doesExist) : first we define a variable of type boolean, remember that boolean just means true/false. Now we ask what the heck is Files? Well essentially the Files class exists to provide us with a more efficient way to do file operations. exists(doesExist)
is pretty self explanatory, it takes a Path object and returns true of false depending on if the Path object can be found in the current working directory.
System.out.println(existsing); : lastly this will use the System output stream "out" to print the boolean value that existing holds.
- Lastly if you copy the code and run it you should see the output of true. Note that true will only appear if you have a file called fish.txt in your root directory. If your code is outputting false, that means that you have fish.txt in the wrong directory.
Top comments (0)