The java.util.Scanner class is a handy way to get input from the console. To do so, you will declare a variable like this:
However, IDEs like Eclipse will often issue a warning that you have a "Resource leak: 'kbd' is never closed"
You might be tempted to get rid of this warning by calling the Scanner.close() method when you're done using the Scanner. Here are some things we've seen people do (note that these are things you SHOULD NOT DO):
We've also seen people take the extra step to wrap a try-finally statement around the code that uses Scanner:
You might even try to use the fact that Scanner implements the Closeable interface and use it with a try-with-resources statement, like so:
Reason for not doing any of the above: Since the System.in object is opened by the JVM, you should leave it to the JVM to close it. If you close it and later on try to use System.in for any other reason, then you'll probably be surprised that you no longer can. Therefore, when it comes to closing a Scanner that is tied to System.in, DON'T. Leaving the closing of System.in to the JVM.
(Thanks to member Omkar Shetkar for pointing this out in this post)
How do I get rid of the warning then?
Here are a few approaches you can take to deal with this type of warning:
1. Just ignore these kinds of warnings. You probably have other real and more pressing problems to address anyway. The downside to this approach is that there's a danger in getting into a habit of ignoring warnings. Some warnings are legitimate and should be addressed. However, if you have more warnings that can be safely ignored than not, these will make it harder to see the warnings that you should address. If you choose to ignore the former, make sure you stay on top of the latter.
2. Suppress the warning with an annotation. You can use the @SuppressWarnings("resource") annotation to get rid of the warning. Put the annotation above the method where the Scanner is declared, like so:
The downside to this approach is that you could end up with a lot of @SuppressWarnings("resource") annotations in your code, increasing the visual clutter. To most people, that's not a biggie but if you'd rather not clutter up code with this type of annotation, see the next approach.
3. Declare the Scanner variable as a class (static) field. You will not get a warning about closing the Scanner(System.in) resource if you declare it as a class field. This makes the most sense because you really only need to create a Scanner that's tied to System.in one time and use it for all console input. After all, there's only one keyboard, so why would you need more than one Scanner to get input from it? So, your code would look like this:
Notice that in the example above, the Scanner variable, kbd, is declared as private. You can declare the field as public but that will likely lead you to creating less encapsulated designs. Keeping the Scanner tied to System.in in one class that is responsible for all input from the console allows you to follow the principle of separation of concerns and keep your design encapsulated and well-factored.
Do the next thing next. That’s a pretty good rule. Read the tiny ad, that’s a pretty good rule, too.