Many times I'm writing my java code, import statements be like
import java.util.Scanner;
import java.util.ArrayList;
But when it is required to import more classes from java.util (or any other package), is there a way to import all the required classes in one line.
Like the code below
import java.util.Scanner,ArrayList; OR
import java.util.{Scanner,ArrayList};
Anyhow the above two lines didn't work. Is there a way to do so ?
Java language does not support that.
As far as importing top level classes is concerned, you have two options:
import package.path.ExactClass
or
import package.path.*
First one imports one and only one class, second one is wildcard import that imports all classes in that package.
import package.name.Class; // Import a single class,
// "its called Importing a Package Member"
import package.name.*; // Import the whole package,
// its called "Importing an Entire Package"
For your case,
import java.util.*;
Learn more at official doc
Related
My professor gave me the java.util.Arrays.sort static method and it shows an error that the import cannot be resolved. This does not happen to any of my other methods. Is this written right?
import java.util.Arrays.sort;
Edit: Does the .sort need to do something? I changed it to
import java.util.Arrays;
and there were no errors.
Importing in Java involves either importing a member class of a package, in this case (java.util is the package, Arrays is the class)
import java.util.Arrays;
or importing the entire package, which would be
import java.util.*;
There is no concept of importing an individual class method, which is what
import java.util.Arrays.sort;
was attempting to do , because sort is just one method of the java.util.Arrays class (there are many other methods of that class).
So if you attempt to do that, you will get the error message you did.
This question already has answers here:
Import package.* vs import package.SpecificType [duplicate]
(10 answers)
Closed 7 years ago.
In an exercise program I'm working on right now, it calls for a handful of imports, like so:
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.HyperlinkEvent;
import javax.swing.event.HyperlinkListener;
import java.net.URL;
ELI5: My question (I'm slightly past the newbie beginner tutorials, and getting into intermediate? now.) is just as the title suggests. Am I actually required to import java.awt.event.* if I've already covered it with java.awt.*?
If not, why is this the seeming convention?
An import statement ending in an asterisk only imports all classes from that package, not any subpackages. So if you have class A living in com.example, and class B living in com.example.subtype, an import statement like
import com.example.*;
will import class A but not class B. In order to import class B you'd have to add
import com.example.subtype.*;
This is to ensure that if you need a number of classes from a 'higher' package (hierarchically speaking), you don't import all classes from every subpackage beneath it which you might not need or want, some of which could have the same name leading to classname conflicts.
ie, if there is a class com.example.subtype.Type and a class com.example.order.Type you don't want an import statement like import com.example.*; to import both Types.
This is also why it is generally better to explicitly import certain classes instead of all classes from a package (as you do with the asterisk), unless you need so many classes from that package the load of imports will only serve to confuse.
You don't have to use .*
For Example, you only want to use an JFrame, you can import
import javax.swing.*;
but why import all functions of the package (not subpackages), if you only need one?
Better use this (in this Example):
import javax.swing.JFrame;
See also here: Import package.* vs import package.SpecificType
// imports all classes of util package
import java.util.*;
// imports Scanner class of util package
import java.util.Scanner;
// what does this do?
import java.util.Scanner.*;
Is Scanner a package here?
Edit: Ok so import java.util.Scanner.* imports the public nested classes. But what if there was also a package called Scanner? What would the statement import java.util.Scanner.* do then?
import java.util.Scanner;
This imports Scanner (as you already know).
import java.util.Scanner.*;
This imports any public nested classes defined within Scanner.
This particular import statement is useless, as Scanner does not define any nested classes (and the import does not import Scanner itself). However, this can be used with something like import java.util.Map.*, in which case Entry (an interface nested in Map that is commonly used when dealing with maps) will be imported. I'm sure there are better examples, this is just the one that came to mind.
All of this is specified in JLS §7.5 (specifically, see §7.5.1: Single-Type-Import Declarations).
In response to the OP's edit:
Ok so import java.util.Scanner.* imports the public nested classes. But what if there was also a package called Scanner? What would the statement import java.util.Scanner.* do then?
In this case there would be a compilation error, since the package java.util.Scanner would collide with the type java.util.Scanner.
The asterisk after the classname imports public nested classes.
From the Java Tutorials:
Note: Another, less common form of import allows you to import the
public nested classes of an enclosing class. For example, if the
graphics.Rectangle class contained useful nested classes, such as
Rectangle.DoubleWide and Rectangle.Square, you could import Rectangle
and its nested classes by using the following two statements.
import graphics.Rectangle;
import graphics.Rectangle.*;
Be aware that the second import statement will not import Rectangle.
This question already has answers here:
Is this how Java package imports are supposed to work?
(4 answers)
Closed 8 years ago.
I wrote this command line:
Field [] field=Hello_World.class.getFields();
and I used the import java.lang.*; sentnce, that suppose to import all of the classes in the lang package. even so when i wrote this command line it throw me an errow and suggested to use the following import sentence: import java.lang.reflect.Field; which, to my understing, import the speciefic field class from the lang package. I dont understand why does my orginal import sentence doesn't solve this problem(It supposed to import all of the classes, doesn't it?)
You have two misconceptions:
You don't need to import java.lang. It is implicitly imported.
Importing xxx.* imports only the classes and interfaces in xxx. It does NOT import any "subpackages" of xxx; e.g. xxx.yyy or xxx.yyy.zzz.
So what you should do is get rid of import java.lang.*, and add import java.lang.reflect.*.
Aside: A lot of people (myself included) think that "star" importing classes and interfaces is a bad idea. It can cause source-level fragility; e.g. if someone unexpectedly adds a class to some package that collides with a same-named class you've imported from another package.
The java.lang.* import all classes of lang packages but not its subpackages subclass. so to import the subclasses of reflect, you have to import java.lang.reflect.Field.
Yes, that is how package imports work (and are supposed to work) in Java. For example, doing import javax.swing.; will import all classes within javax.swing. but not sub-packages and their classes.
Reflection is not in lang.* package. its subpackage to language package. You need import java.lang.reflect.* it ll work. As other answers imply that import doesn't import subpackages.
Is there a succinct way to import in Java which would be equivalent to the following statement:
import static android.view.View.GONE;
import static android.view.View.INVISIBLE;
import static android.view.View.VISIBLE;
I know about this:
import android.view.View.*;
But I would like to be able to control what I import, and not just import everything in the View namespace.
ANSWER: The answer is No.
No, there's no quicker way to only import some constants. You can get them all, or you can list each one you want separately.
Actually there is technically a third option, not that it's necessarily better. You do have the option to import none of them and use their fully qualified name each time you refer to them.