Is there a way to use the standard library class Scanner without an import statement?
My professor is the type to include overly difficult problems that you are not expected to actually complete but aside from decompiling the standard library and adding all of the .java files to the project I am at a bit of a loss.
Edit: to clarify, this is the exact wording of the lab description:
"Use a scanner to get an integer value from the user. Your program may not use any import statements."
Yes. You can fully qualify them on usage:
java.util.Scanner scanner = new java.util.Scanner(System.in);
The import statement is not about the compiler asking where can I find the class?, but rather which class do you mean?
With the import statement you say to the compiler: "Everytime I say Scanner, I actually mean java.util.Scanner. So please save me some typing.
So indeed, as Andreas already mentioned in the comments. import is not necessary, it's just convenience.
Also note that all classes from the java.lang package (for example System in the abovementioned example) are implicitly imported (JLS § 7.3), so you can always use them without an import statement.
Related
java.util.* import all the class under it, while java.util.Scanner only imports Scanner class.
So, is there any difference between them in time of execution between them?
Unlike the #include thingy in C, importing stuff in Java does not actually copy stuff, so performance-wise, java.util.* and java.util.Scanner are practically the same.
However, importing everything from a package can cause name conflicts. Look at how many classes there are that are called Scanner:
If you just so happens to import everything from both java.util and sun.tools.java. The compiler will not be able to infer which Scanner you are referring to.
java.util.* will import the entire utility classes whereas java.util.Scanner will import only Scanner class. Now, it is up to you as if you want to take input from user then import only java.util.Scanner class specifically.
It is always best practice to import specific class because importing entire package may confuse you.
Eg java has 2 Date classes in two different packages
1)java.util.Date
2)java.sql.Date
When we import an entire package using '*' and if any error occurs then we don't understand because of which class this error has occurred that's why it is always best practice to import specific class according to the requirement.
Thank you.
Rupesh R. Bharuka
This question already has answers here:
Meaning of the import statement in a Java file
(5 answers)
Closed 6 years ago.
What does java.util.*; do? Why do we include it at the beginning of our files?
The statement java.util.*; imports all of the java.util package members so that you don't have to use a package member's fully qualified name. According to the JavaDocs here the package java.util
Contains the collections framework, legacy collection classes, event
model, date and time facilities, internationalization, and
miscellaneous utility classes (a string tokenizer, a random-number
generator, and a bit array)
Although this approach can seem more convenient and is sometimes appropriate you shouldn't always be including an import java.util.*; statement at the beginning of all of your files unless you are using a substantial amount of the members contained in the java.util package. Only include the members that you use like so:
import java.util.ArrayList;
import java.util.LinkedList;
By doing so it helps make you more familiar with each package member that you're using instead of blindly importing the whole package. The most important reason is that by using the wildcard character(*) you have a greater chance of coming across name ambiguities which can lead to errors.
import java.awt.*;
import java.util.*;
In the above code example, the class List becomes ambiguous because both packages have a List class.
Think of it like a library of methods that you now have access to. You are basically importing more functionality into your project
When you do
import java.util.*
you now have the ability to do things like create arrays, manipulate dates and so on... (https://docs.oracle.com/javase/7/docs/api/java/util/package-summary.html)
The .* means you are importing all of the util functions like java.util.Arrays or java.util.Date...
I am a novice high school Java programmer and I am having an internal conflict as to which of the following methods is more efficient in Java. If you are importing a single class in Java, is it more efficient to import it as per usual, e.g., import java.util.Scanner; or to use that import statement as part of the Scanner's declaration, as in java.util.Scanner scan = new java.util.Scanner(System.in);.
I know the first is more common and looks nicer, but what if you only need one scanner object? I am sorry if this question is a duplicate; I did not know how to properly word this question in my searches to see if it already existed.
import statements create a compiler-time alias to the symbol imported. That is, it's just a shortcut for typing the full name out - it has no effect on the program while it's running. The compiled code is identical in both cases.
There is no added expense to importing a class, so it makes sense to put all of your imports in the header where anyone looking at your code can easily see what classes are utilized in the program. If you decide later that you want to have more than one scanner object or more than one class from java.util you can use import java.util.* as well.
Pick the more readable of the two. There is no difference in performance, at the end of the day they both get compiled to exactly the same bytecode.
The efficiency lies in how often you might need to write out the package/class/symbol path to the type. If you are certain that you will use it only once, not using an import would work.
But, that is the only upside. There are multiple downsides to avoiding an import statement, including readability, ease of seeing which classes are used in this code file, and extra typing if adding more references becomes necessary. The compiler is completely neutral in all of it, as source either way will compile to the same JVM code.
When you declare an import like this:
import com.microsoft.azure.storage.*;
Does that include everything in its subpackages too? For example, does it include this?
import com.microsoft.azure.storage.blob.*
If not, why not? (Edit: the "why" question is basically off topic. ignoring that bit when considering a correct answer.)
No it does not. It only imports everything in the package (i.e. the directory itself). Sub-directories are considered to be different packages, so you would need to:
import com.microsoft.azure.storage.*
import com.microsoft.azure.storage.blob.*
As to why the language designers chose to go this route, one can only guess, but the system that they decided to go with does allow for a more fine-grained approach.
yes you can import all the classes from an import but it does not make it possible to import multiple packages with similar names. For example import java.util*; does not also import java.util.prefs or .jar you have to import these all separately. I don't know if that answers your question, and to the why I am not really sure it just makes sense to do it this way. If you were to import similar packages that had the same static variables, but you only need two or three of the packages then you would get errors or code that does not run properly.
There's a name for these - type import on demand.
A type-import-on-demand declaration allows all accessible types of a named package or type to be imported as needed.
They're only also importing the package itself, and not any subpackages, as clarified by the example, emphasis mine:
import java.util.*;
causes the simple names of all public types declared in the package java.util to be available within the class and interface declarations of the compilation unit. Thus, the simple name Vector refers to the type Vector in the package java.util in all places in the compilation unit where that type declaration is not shadowed (§6.4.1) or obscured (§6.4.2).
does that include everything in / subdirectories too? including
something like this?
* stands for all the compilation units inside the package com.microsoft.azure.storage where sub packages are actually not compilation units and thus not fetched when you write myPack.*. Compilation unit includes class, interface, enum etc.
I can't understand why I'm getting the following error - cannot find symbol - class Line2D - when I try to compile this code:
import java.awt.*;
public class KochSegment
{
public Line2D base = new Line2D(); public Line2D[] Lines = new Line2D[4]; //error is on this line
etc.
}
It's in a subpackage:
java.awt.geom.Line2D
So you'd need either
import java.awt.geom.Line2D;
or
import java.awt.geom.*;
Some lessons that should be learned from this:
Star imports only import classes from a package. They do not import from sub-packages as well. In fact, sub-packages in Java are purely syntactic. As far as the Java language is concerned, there is NO semantic relationship between classes in different packages or sub-packages.
Star imports tend to obscure problems. A lot of people recommend not using them. Write the imports out in full. Or better still, use an IDE that can do classname completion, and generate missing imports. (Granted, you do need to be a bit careful when for example the IDE offers you multiple completions for (say) Date or List.)
Searching and reading the javadoc is a good way to help with problems like this. A javadoc search (or a class list scan) would tell you what the fully qualified name for the Line2D class is.