Java import vs code performance
Solution 1:
would it affect the performance of my code (for example, program will be slower)?
No, it wouldn't affect performance of your code.
The binaries (the class files) do not increase in size as the import is not implemented with any cut-and-paste mechanism.
It is merely a syntactic sugar for avoiding to have to write for instance
java.util.List<java.math.BigInteger> myList =
new java.util.ArrayList<java.math.BigInteger>();
Here is a little test demonstrating this:
aioobe@e6510:~/tmp$ cat Test.java
import java.util.*;
public class Test {
public static void main(String[] args) {
List<Integer> myInts = new ArrayList<Integer>();
}
}
aioobe@e6510:~/tmp$ javac Test.java
aioobe@e6510:~/tmp$ md5sum Test.class
523036e294b17377b4078ea1cb8e7940 Test.class
(modifying Test.java
)
aioobe@e6510:~/tmp$ cat Test.java
public class Test {
public static void main(String[] args) {
java.util.List<Integer> myInts = new java.util.ArrayList<Integer>();
}
}
aioobe@e6510:~/tmp$ javac Test.java
aioobe@e6510:~/tmp$ md5sum Test.class
523036e294b17377b4078ea1cb8e7940 Test.class
Is the logic behind the import in Java the same as include in C?
No, an #include
is a preprocessor directive and is implemented with a cut-and-paste mechanism.
Solution 2:
... would it affect the performance of my code
Not in the slightest. In fact, the compiled classes (using imports or not) will be identical. An import is merely syntactic sugar that allows you to use a shorter name for an external class or (with a static import) class member in your source code. In other words, it allows you to write:
Map map = new HashMap();
instead of
java.util.Map map = new java.util.HashMap();
That is all.
There is potentially a small (tiny) difference in compilation times. But, AFAIK, something like import java.util.*;
does NOT cause all of the java.util
classes to be loaded by the compiler. Rather it just adds the names of the classes to the symbol table.
Having said that:
- Unnecessary imports are a bad idea, because they clutter up the code and could mislead someone reading the code.
- Wildcard imports (
.*
) can lead to unexpected collisions. - A lot of people (myself included) dislike wildcard imports because they prefer to see a list of the actual classes used.
Is the logic behind the import in Java the same as include in C?
No it is not.
A C / C++ include directive injects arbitrary1 C / C++ "code" into the source stream. This can include declarations and executable statements ... which can affect both performance, execution memory footprint and the size of the executable.
1 - That is, whatever the authors of the include file chose to put into the file. It could be simple method and class "signatures", but it could also be macro's, code and other declarations that are impactful. You have to examine the file to be sure.
Solution 3:
It will have no impact on the ~run~time speed of your program.
It may have an impact on the ~compile~time speed of your program.
If you import java.util.*;
it will load all of the java.util package into the compiler, which may increase the compile time when you .*
an entire package for a single usage (although you should perform some profiling if it's going to be a concern.)
In addition to potential compile time issues, don't forget to consider the readability issues. Generally, I (and people I've talked with) find import pack.age.Class;
to be more readable than import pack.age.*;
- have a talk with your team of course before making a decision about this.
But the logic behind it is very different from #include
and does not bloat the code. You may end up with more than necessary as you include dependency jars, but that's probably not a big issue.
Solution 4:
import
does not slow your program. It is better to have different kinds of classes
in different packages
and import them as needed. Improves code readability.