What is the disadvantage of using * in an import statement??

There is no affect on runtime performance. 

The import directive is a compiler directive. The Java source to bytecode compiler reads the Java source file (i.e. a something.java file) and converts that source to one or more bytecode files (.class files). 

Most Java source code in the Java source file is converted into Java bytecodes of one sort or another. But the import directive is not. The import directive specifically tells the compiler to do something. The import directive tells the compiler that when it comes across a class or interface name in the source file, e.g. HashMap, then if it cannot find the class file for that name, it should use the import statement to help it look it up. This way, you don't have to always use fully qualified class names, e.g. java.util.HashMap. 

The import directives themselves do not get put into the compiled bytecode files. They are no longer of any use, as the compiler compiles the fully qualified name into the .class file. 

For example, suppose the source file contains 

import java.util.*; 
// 
... 
HashMap map; 
... 

Then the compiler gets to the HashMap map variable declaration, tries to find a class called HashMap in the default package (i.e. no package name), fails, and uses the import statement to see if there is a java.util.HashMap class. This is found, and a reference to java.util.HashMap is inserted into the .class file. After compilation is completed, there is no use for the import directive, so it is not present at all in the compiled bytecode. Consequently, the import directive cannot affect runtime code execution in any way. 

However, it is worth noting that the directive does affect compilation time. Since the directive tells the compiler how to do a second lookup to find classes, obviously this means that more time is spent looking up class and interface names compared to if one lookup sufficed. 

There are two forms of the import directive: with and without the wildcard '*', e.g. 

import java.util.*; 
import java.util.HashMap; 

Without the wildcard, the directive tells the compiler to look for one specific file in the classpath. With the wildcard, the directive is telling the compiler to look for the named package, and to search in that package for possible matches everytime any name needs to be matched. This latter version is probably going to be more costly (i.e. take longer) for the compiler than the former. 

Also, depending on which compiler you use, and which settings, the compiler may re-compile all of the classes in the wildcard package, which could really make things take longer. 

Finally, many people find that using imports with wildcards makes the source much less readable, since the reader also needs to figure out which package a particular class comes from, rather than just looking it up in the import statement. 

So the full answer is 

* 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 

Also, in a scenario where your class ends up having 60-70 imports, its a good practice to break up the class into two (or more) on the basis of functionality. In an Enterprise level application the classes are generally focused on the functional segregation rather than all code in one or two classes.