Let's say, I have the following structure:
src.main.java
first
one.java
two.java
three.java
second
alpha.java
beta.java
gamma.java
I want all classes from first package to be imported in all classes in my second package.
Now I'm just specifying for every class in second package:
import first.*;
Can I import once for all classes in package?
No, it cannot be done.
I don't see why this is such a hardship.
A better solution would be to use an IDE that can add the imports as you need them.
I'd also recommend spelling each one out individually rather than using the star notation, even if you need to import all of them. It documents your intent better, and that IDE can make it transparent to you.
No, you can't do that in Java.
One thing that you might think of doing is moving classes from second package to first so you won't need the imports. But I understand that that is not always possible/desirable.
Can I import once for all classes in package?
No you can't. Imports only apply to the class source file in which they are declared.
Maybe I can create some superclass with import statements and then extend it every time?
That will only work if the code in the subclasses does not mention the names of the external types at all ... which is rarely possible.
As I said imports only apply to the class source file in which they are declared.
Actually, the import was deliberately designed to work this way. The idea is to allow you to easily figure out what class a classname refers to. (It works best if you don't use star imports ...)
Related
I was working on a little Java program and was using arrays so I had done:
import java.util.Arrays;
Later I started expanding on what I had previously done and decided I wanted to get input from the user, so at that point I added:
import java.util.Scanner;
Now a thought occurred. I know that I could just do:
import java.util.*
Then I'd just need 1 import line instead of two (or however many I end up needing), but does the wildcard in the import mean that it will import everything from that package regardless of if it's needed or not, or will only the selective functionality be pulled?
My instinct here is to write more code and only include the packages I know I need, but if it doesn't make a difference why would anyone import more levels/packages then they need to? (I'd rather just be lazy and write less code)
Be clear about what import is doing. It does NOT mean loading .class files and byte code.
All import does is allow you to save typing by using short class names.
So if you use java.sql.PreparedStatement in your code, you get to use PreparedStatement when you import java.sql.PreparedStatement. You can write Java code forever without using a single import statement. You'll just have to spell out all the fully-resolved class names.
And the class loader will still bring in byte code from .class files on first use at runtime.
It saves you keystrokes. That's all.
It has nothing to do with class loading.
Personally, I prefer to avoid the * notation. I spell each and every import out. I think it documents my intent better. My IDE is IntelliJ, so I ask it to insert imports on the fly.
Laziness is usually a virtue for developers, but not in this case. Spell them out and have your IDE insert them for you individually.
if you type
import java.util.*;
you'll get to refer to Scanner and List by their short names.
But if you want to do the same for FutureTask and LinkedBlockingQueue you'll have to have this:
import java.util.concurrent.*;
The wildcard imports everything in that package. However, use an IDE like Eclipse and it offers you the possibility to organize the imports.
The wildcard imports all classes and interfaces in that package.
However, the wildcard import does not import other packages that start with the same name.
For example, importing java.xml.* does not import the java.xml.bind package.
I was just curious which is the preferred way of coding as I've seen code written both of these ways.
import java.util.ArrayList;
import java.util.List;
/**
*Rest of code
*/
List<Blah> blahs = new ArrayList();
or
import java.util.List;
/**
*Rest of code
*/
List<Blah> blahs = new java.util.ArrayList();
So, which is preferred and why? What are the advantages & disadvantages of both methods? Just curious.
So, which is preferred and why?
First one should be prefered. Code clarity is the most important concern.
What are the advantages & disadvantages of both methods?
Well, compiler will anyway convert the first approach to the later one, by replacing all the classes and types, with their fully qualified names. Both the codes would lead to the same byte code. As such you should really not bother about these stuffs. (You can check the byte code by running javap command)
The only reason you would use the fully qualified name is to resolve name clashes in different packages that you have imported. For e.g., if you are importing both java.util.* and java.sql.*, then you would need to use fully qualified name of Date class.
Related post:
Does an unused import declaration eat memory, in Java?
Fully-qualified names are preffered when you have several classes with the same simple name.
In all the other cases, the preffered and easy-to-read approach would be importing the fully-quallified name and using the simple class names.
Probably the former because the latter looks kind of obscure. You should only use the latter (specifying package names before classes) if you are using multiple classes found in different packages.
I was working on a little Java program and was using arrays so I had done:
import java.util.Arrays;
Later I started expanding on what I had previously done and decided I wanted to get input from the user, so at that point I added:
import java.util.Scanner;
Now a thought occurred. I know that I could just do:
import java.util.*
Then I'd just need 1 import line instead of two (or however many I end up needing), but does the wildcard in the import mean that it will import everything from that package regardless of if it's needed or not, or will only the selective functionality be pulled?
My instinct here is to write more code and only include the packages I know I need, but if it doesn't make a difference why would anyone import more levels/packages then they need to? (I'd rather just be lazy and write less code)
Be clear about what import is doing. It does NOT mean loading .class files and byte code.
All import does is allow you to save typing by using short class names.
So if you use java.sql.PreparedStatement in your code, you get to use PreparedStatement when you import java.sql.PreparedStatement. You can write Java code forever without using a single import statement. You'll just have to spell out all the fully-resolved class names.
And the class loader will still bring in byte code from .class files on first use at runtime.
It saves you keystrokes. That's all.
It has nothing to do with class loading.
Personally, I prefer to avoid the * notation. I spell each and every import out. I think it documents my intent better. My IDE is IntelliJ, so I ask it to insert imports on the fly.
Laziness is usually a virtue for developers, but not in this case. Spell them out and have your IDE insert them for you individually.
if you type
import java.util.*;
you'll get to refer to Scanner and List by their short names.
But if you want to do the same for FutureTask and LinkedBlockingQueue you'll have to have this:
import java.util.concurrent.*;
The wildcard imports everything in that package. However, use an IDE like Eclipse and it offers you the possibility to organize the imports.
The wildcard imports all classes and interfaces in that package.
However, the wildcard import does not import other packages that start with the same name.
For example, importing java.xml.* does not import the java.xml.bind package.
In Java, imports are related to an (outer) class, as every (outer) class is supposed to be coded in a separate file. Thus, one could claim that the import ...; directives before a class definition are associated with the class (somewhat like annotations are).
Now, if one could inherit a parent class' imports, that would greatly reduce the clutter of source files. Why should this not be possible? i.e. why should the Java compiler not consider also the imports of base classes?
Notes:
There's probably more than one answer.
I know this is not much of an issue if you let eclipse organize your imports, no need to mention that. This is about the 'why', not the 'how' (a-la-this).
Firstly, it is important to note that not every class must be coded in a separate file - but rather that every public, top level class must be. And no, imports are not really associated with any class - they are just statements used to include certain external classes / packages within a file so that they can be used. In fact, you never need to actually import anything, you can always use the full name, i.e.:
java.util.List<String> list = new java.util.ArrayList<String>();
Imports are there for convenience (and only for the compiler - they are lost after the class is compiled), to save you from having to write all that out and instead only make you write List<String> list = new ArrayList<String> (after you make the relevant imports from java.util). Consequently, there is no reason why subclasses should 'inherit' imports.
Imports are syntactic sugar, nothing more. You could write any Java program without ever using an import statement if you really wanted to. For example, the following class compiles all by itself:
class Foo {
java.util.List<String> list = new java.util.ArrayList<String>();
}
Additionally, inheriting imports makes it much, much harder to remove an import from a class. For example, if Bar.java inherits from Foo.java, you might not be able to remove an import from Foo without adding it to Bar. Forcing imports to be explicit makes it significantly easier to change a single file without worrying about the effects on other files, which is pretty much a fundamental principle of Java and object-oriented programming generally.
(This last point is related to issues that were a significant factor in the design of Go, which was specifically attempting to avoid the problems with C and C++ in this area.)
Having each file explicitly specify its imports improves readability. Imagine opening a file and not being able to see the dependencies at a glance, because the imports are inherited from another file.
Why does Eclipse take a fine grained approach when importing types? In C# I'm used to things like "using System.Windows.Controls" and being done with it, but Eclipse prefers to import each widget I reference individually (using the Ctrl+Shift+O shortcut). Is there any harm to importing an entire namespace if I know I'll need multiple types in it?
Eclipse has a great setting called the "Organize Imports" in the Window -> Preferences dialog that lets you say when N classes are used from a package, do a wildcard import. I use it at N=2 or 3 usually.
Somebody can read your code without IDE - in this case non-wildcard imports will help him to figure out which classes are used in your code.
The only harm that wildcard package imports can cause is an increased chance of namespace collisions if there are multiple classes of the same name in multiple packages.
Say for example, I want to program to use the ArrayList class of the Java Collections Framework in an AWT application that uses a List GUI component to display information. For the sake of an example, let's suppose we have the following:
// 'ArrayList' from java.util
ArrayList<String> strings = new ArrayList<String>();
// ...
// 'List' from java.awt
List listComponent = new List()
Now, in order to use the above, there would have to be an import for those two classes, minimally:
import java.awt.List;
import java.util.ArrayList;
Now, if we were to use a wildcard in the package import, we'd have the following.
import java.awt.*;
import java.util.*;
However, now we will have a problem!
There is a java.awt.List class and a java.util.List, so referring to the List class would be ambiguous. One would have to refer to the List with a fully-qualified class name if we want to remove the ambiguity:
import java.awt.*;
import java.util.*;
ArrayList<String> strings = new ArrayList<String>();
// ...
// 'List' from java.awt -- need to use a fully-qualified class name.
java.awt.List listComponent = new java.awt.List()
Therefore, there are cases where using a wildcard package import can lead to problems.
The import directive is a compiler directive, it tells the compiler where to look for a class and allows to not have to always use fully qualified class names, e.g. java.util.HashMap. But the import directives themselves do not get put into the compiled bytecode files, the compiler compiles the fully qualified name into the .class file.
When used wiithout a wildcard, the directive explicitly tells the compiler to look for one specific file in the classpath. With a wildcard, the directive tells the compiler to look for the named package and to search in that package for possible matches every time any name needs to be matched. The latter version is probably going to take (a bit) longer for the compiler than the former.
In other words, the import directive cannot affect runtime code execution in any way. However, the import directive does affect compilation time. Additionally, I find that using import with wildcards makes the code less readable.
Actually, the cost of import statements question of the month on javaperformancetuning.com perfectly summarize this in its conclusion:
There is no runtime cost from using an import statement
The compilation process can take a little more time with an import
statement
The compilation process can take even more time with a wildcard import
statement
For improved readability, wildcard import statements are bad practice for
anything but throwaway classes
The compilation overhead of non-wildcard import statements are
minor, but they give readability
benefits so best practice is to use
them
I don't believe that wildcard imports have any sort of performance implications (and if it does, I think it would only happen at compile time). But as this SO post points out, it's possible that you can have class name overlaps if you use them.
I just use Ctrl+Space to force the import when I'm using a class that hasn't been imported yet, and the import happens automatically. Then I hit Ctrl+Shift+O after I refactor a class to remove any imports that are no longer used.
Up until JDK 1.2 this code would compile fine:
import java.awt.*;
import java.util.*;
public class Foo
{
// List is java.awt.List
private List list;
}
in JDK 1.2 java.util.List was added and the code no longer compiled because the compiler did not know which List was wanted (awt or util). You can fix it by adding "import java.awt.List;" at the end of the imports, but the point is you have to do something to fix it.
I personally use the single import instead of the on-demand import for two reasons:
it is clear where each class comes
from
if you have a huge number of imports
the class is probably doing too much
and should be split up. It is a
"code smell".
From a purist point of view, every import creates a dependency and a potential for conflict. Imports are treated as a necessary evil so they are minimized. Importing another package with a * is like writing a blank check. Importing two packages like that is like giving somebody access to moving money between your accounts.
From a practical point of view, this often makes sense because different projects and libraries use surprisingly similar names for differing concepts. Or, imagine you import everything from package A and then everything from package B, and use some class C from package B. If someone later on adds a class with the name C to package A, your code might break!
That being said, I admit I'm lazy. I'll often pre-import everything in the package, and then let Eclipse organize it for me based on what I actually use.
There's no harm in importing all the classes in a package/namespace, but I think it's better to include each individual class. It makes things clearer to developers who come after you exactly where each class comes from.
It's a non-issue if you're using a capable IDE like IntelliJ. I would imagine that Eclipse and NetBeans can manage imports as well. It will add the code for you and collapse them from view so they don't clutter the window. What could be easier?
Doesn't hurt the code. As a general principle, why import something if you are not going to use?
If you write some java code such as
LinkedList<foo> llist = new LinkedList<foo>()
and you haven't imported LinkedList to your project, Eclipse will ask if you want to import it. Since you are only using LinkedList and nothing else, it will only import LinkedList. If you do something else in the same project such as
ArrayList<foo> alist = new ArrayList<foo>()
Then Eclipse will also say you need to import ArrayList, but nothing else. Eclipse only has you import what you need based on any library calls you have made. If you need multiple types or items from the same library, there isn't harm in using a
import java.namespace.*
to go ahead and bring in the other items you need. Eclipse won't care as long as you are importing the packages and libraries that contain the items you are referencing such as Scanners, LinkedLists, etc.
From a readability perspective, it's a different question. If you want people to explicitly know what exactly you are importing, then calling each widget or package might be in order. This can get rather tedious if you are using lots of different functions from the same package in the standard library and can make your file headers quite long hence the .* wildcard. There's no harm in importing via wildcard, it really boils down to your coding standards and how transparent you want your class headers to be.
Importing each class explicitly gives a hard binding between the short name (e.g. Proxy) and the long name (e.g. java.lang.reflect.Proxy), instead of the loose binding saying that there probably is one in java.lang.reflect.*, java.io.* or java.net.* or somewhere else of the wildcard imports you have.
This may be a problem if for some reason another class named Proxy shows up somewhere in java.io.* or java.net.* or your own code, as the compiler then doesn't know which Proxy class you want as it would have if you explicitly imported java.lang.reflect.Proxy.
The above example is not contrieved. The java.net.Proxy class was introduced in Java 5, and would have broken your code if it was written as hinted above. See the official Sun explanation of how to circumvent wildcard problems at http://java.sun.com/j2se/1.5.0/compatibility.html
(The wildcard import is just a convenience mechanism for those not using an IDE to maintain import statements. If you use an IDE then let it help you :)