I'm writing a very basic app, extending the Swing JFrame. What are the differences between making an explicit reference:
public class LineTest extends javax.swing.JFrame {
...
or importing the class beforehand:
import javax.swing.JFrame;
public class LineTest extends JFrame {
...
When (and why) would you use one technique over the other?
There is no real difference; the generated byte code will be exactly the same. An import statement is really just a way to tell the compiler "when I write JFrame, I actually mean javax.swing.JFrame".
You might want to use fully-qualified package names if you have for example two classes with the same name in different packages. One common example from the standard library are the classes java.util.Date and java.sql.Date.
The only difference is in the source code. Using the fully qualified name leads to less readable code, so everyone uses imports pretty much exclusively. The only place where I've ever seen the fully qualified names used consistently is in generated code.
The only reason to use the fully qualified name in regular code is when you have to use two classes with the same simple name (e.g. java.util.List and java.awt.List) - in that case there is no alternative.
For the compiler it doesn't make any difference. The disadvantage of using the full qualified name is that you would have to write it each time you are using the class. I only use the full qualified name if I have two classes with the same name in different packages. This way you can differ between those two classes
Related
In Python you can do a:
from a import b as c
How would you do this in Java, as I have two imports that are clashing.
There is no import aliasing mechanism in Java. You cannot import two classes with the same name and use both of them unqualified.
Import one class and use the fully qualified name for the other one, i.e.
import com.text.Formatter;
private Formatter textFormatter;
private com.json.Formatter jsonFormatter;
As the other answers already stated, Java does not provide this feature.
Implementation of this feature has been requested multiple times, e.g. as JDK-4194542: class name aliasing or JDK-4214789: Extend import to allow renaming of imported type.
From the comments:
This is not an unreasonable request, though hardly essential. The occasional
use of fully qualified names is not an undue burden (unless the library
really reuses the same simple names right and left, which is bad style).
In any event, it doesn't pass the bar of price/performance for a language
change.
So I guess we will not see this feature in Java anytime soon :-P
It's probably worth noting that Groovy has this feature:
import java.util.Calendar
import com.example.Calendar as MyCalendar
MyCalendar myCalendar = new MyCalendar()
Java doesn't allow you to do that. You'll need to refer to one of the classes by its fully qualified name and only import the other one.
Today I filed a JEP draft to OpenJDK about this aliasing feature. I hope they will reconsider it.
If you are interested, you can find a JEP draft here: https://gist.github.com/cardil/b29a81efd64a09585076fe00e3d34de7
It's ridiculous that java doesn't have this yet. Scala has it
import com.text.Formatter
import com.json.{Formatter => JsonFormatter}
val Formatter textFormatter;
val JsonFormatter jsonFormatter;
Unless there are problems with non-default constructors you can always do this (while we all wait for the Java language specification to catch up):
public class YaddaYadda
{
private static class ZU extends eu.zrbj.util.ZrbjUtil_3_0 { }
public void foo (String s)
{
if (ZU.isNullOrEmpty(s))
{
// ...
For project-wide use the 'import' class can go into a separate class file, giving a single point of definition for the import.
This is a lifesaver especially with regard to 'library' classes, meaning collections of static utility functions. For one thing it gives you the ability to version these beasts - as shown in the example - without major inconvenience for the user.
Actually it is possible to create a shortcut so you can use shorter names in your code by doing something like this:
package com.mycompany.installer;
public abstract class ConfigurationReader {
private static class Implementation extends com.mycompany.installer.implementation.ConfigurationReader {}
public abstract String getLoaderVirtualClassPath();
public static QueryServiceConfigurationReader getInstance() {
return new Implementation();
}
}
In that way you only need to specify the long name once, and you can have as many specially named classes you want.
Another thing I like about this pattern is that you can name the implementing class the same as the abstract base class, and just place it in a different namespace. That is unrelated to the import/renaming pattern though.
If I want to use an ArrayList in my code, I need to import java.util.ArrayList. If I also want to use a List, I have to import java.util.List. Why is this needed? ArrayList inherits from List, and thus uses code from it. Why does that not carry over to my class? Surely if ArrayList imports List, and my class in turn imports ArrayList, then List should be defined in my class?
import is just a syntactic feature that lets you avoid writing out the full package every time you use a classname.
You do not need to import dependencies at all.
Some classes depend on a lot of classes and those classes depend on a lot of classes, and you would end up importing a good portion on the JDK. It can't assume which classes/interface you might want to import as well.
If you use an IDE, it can add the imports for you so you don't have to worry about which ones are needed most of the time.
The import keyword does not actually "import" anything: it just tells the compiler that you would like to refer to something by its short name. This is why the "import List" in the ArrayList class has no effect on your class.
You can import everything from a particular package like so: java.util.*;
Keep in mind though, that there is a particular annoyance when doing so, as you need to fully qualify other objects that may share the same class name with the imported package. Check this for reference:
Why is using a wild card with a Java import statement bad?
This is a clear instance of "declare what is being used". You might consider is a distant variant of "need to know".
Using an "ArrayList" does not require you to use "List" also.
If, however, you want to use a "java.util.List" (e,g, as the type of a variable being initialized with an instance of "ArrayList"),
then you clearly should state that you are using both types.
(Or actually , just disambiguate what is intended to be referred to by the simple names used, like "List".)
Why clutter your import section with any possible parent type and interface from any class you are using (even if done implicitly)?
Would likely not provide too much benefit, while at the same time
it would make live harder in case you reall want to use a different class with the same name (other package).
Of course you might remember that you are not required to use "imports" at all. You will need to use full names of classes then,
but it is completely valid to do so.
Furthermore, most modern IDEs will suggest a proper import when using a simple name based on what is also used in the expression context. (So e.g. if you use "List" as a variable type when assigning from an "ArrayList" might suggest "java.util.List" as resulution for "List" with higher priority than other clases named "List".
I completely agree with your question. It would be a lot easier to write code if we do not have to worry about keeping track of long list of import statements.
But, the way java (compiler and runtime) works, I think it is necessary to do so because of the following.
The import statements in Java are only for a compiler. The runtime doesn't know anything about import statements.
When you compile your code, all the class names that you use gets converted into fully qualified classnames by the compiler. If we explicitly do not mention which class we are referring to, compiler might get confused if there are multiple classes matching with the same class name that you provided.
You could say that, java should atleast import non-duplicate classes automatically. But the problem is you never know which classes are non duplicate.
Anyone can create a class with any name (I can even create a class in my own package with name ArrayList or List). For that reason, compiler need to know beforehand if it has to resolve List to java.util.List or some other List.
Yes and no. An ArrayList object will indeed have access to any property (method, object...) defined in the class it extends/implements. But, the class you are working in doesn't know about such super classes. You have to import them explicitly to reference them. You could of course import java.util.* and that will give your class access to all classes in that package.
In python, the import statement can be placed everywhere in the file, even inside a class, or an if.
Is there a way to accomplish the same thing in Java? I understand that it could be a bad practice not to put all the imports at the top of the file, I'm just wondering if it is possible in some way or not.
The very first statement in a Java file must be (if there is one) the package statement, followed by the import statements. They can not be placed in another location.
However, it is possible to skip the import altogether by using fully qualified class names (which I personally don't recommend). You need to use them everywhere you would have used the short, unqualified name.
import my.package.MyClass;
public class Test{
private MyClass instance = new MyClass();
}
can be rewritten as:
public class Test{
private my.package.MyClass instance = new my.package.MyClass();
}
According to the documentation here:
To import a specific member into the current file, put an import statement at the beginning of the file before any type definitions but after the package statement, if there is one.
So it seems that it is not possible.
Short answer : No it's impossible !
The import statement must be in the top of the file after the package statement (if exist).
You must know : You can use your imported class/interface or static method in all classes/interfaces in the same file including inner/nested classes.
There isn't a way, except maybe messing with bytecode if you count that. I suppose the best equivalent would be writing the fully qualified name of what you're looking to use.
Not sure why you would want to though.
No. They need to be at the top, after the package declaration.
An ordinary compilation unit consists of three parts, each of which is
optional:
A package declaration (§7.4), giving the fully qualified name (§6.7) of the package to which the compilation unit belongs.A compilation unit that has no package declaration is part of an
unnamed package (§7.4.2).
import declarations (§7.5) that allow classes and interface from other packages, and static members of classes and interfaces, to be
referred to using their simple names.
Top level declarations of classes and interfaces (§7.6).
This doesn't do a great job at conveying that the ordering of each part is strictly enforced, but the formal grammar does make this clear:
OrdinaryCompilationUnit:
[PackageDeclaration] {ImportDeclaration} {TopLevelClassOrInterfaceDeclaration}
I have two imports that I need to use:
import net.robotmedia.billing.model.Transaction;
import com.google.analytics.tracking.android.Transaction;
and I receive the following error:
The import com.google.analytics.tracking.android.Transaction collides with another import statement
But I need to use both of these items. How do I resolve this?
One of the classes must be used by typing its fully qualified name. For example:
net.robotmedia.billing.model.Transaction tx = new net.robotmedia.billing.model.Transaction();
Remember that imports are just used to let you use a class by its simple name rather than using it with its fully qualified name. If you wanted, you could code all your classes without any import, and always use the fully qualified class names. It would just be much less readable and more cumbersome to write. But if two classes with the same simple name are used inside the same class, then you can only import one of them.
If I access a class within a package using fully qualified name, without importing it, whether it saves any memory?
Using fully qualified class name :
java.lang.Math.sqrt(x);
Import package :
import java.lang.Math;
Math.sqrt(x);
which is the better way : import the package or access using fully qualified name?
Thanking you..
There is no performance difference between importing the package or using the fully qualified class name. The import directive is not converted to Java byte code, consequently there is no effect on runtime performance. The only difference is that it saves you time in case you are using the imported class multiple times. This is a good read here
No, it doesn't save you memory.
Also note that you don't have to import Math at all. Everything in java.lang is imported automatically.
A better example would be something like an ArrayList
import java.util.ArrayList;
....
ArrayList<String> i = new ArrayList<String>();
Note I'm importing the ArrayList specifically. I could have done
import java.util.*;
But you generally want to avoid large wildcard imports to avoid the problem of collisions between packages.
They're equivalent. The access is the same.
The import is just a convention to save you from having to type the fully-resolved class name each time. You can write all your Java without using import, as long as you're a fast touch typer.
But there's no difference in efficiency or class loading.
As already said, on runtime there is no difference (in the class file it is always fully qualified, and after loading and linking the class there are direct pointers to the referred method), and everything in the java.lang package is automatically imported, as is everything in the current package.
The compiler might have to search some microseconds longer, but this should not be a reason - decide for legibility for human readers.
By the way, if you are using lots of static methods (from Math, for example), you could also write
import static java.lang.Math.*;
and then use
sqrt(x)
directly. But only do this if your class is math heavy and it really helps legibility of bigger formulas, since the reader (as the compiler) first would search in the same class and maybe in superclasses, too. (This applies analogously for other static methods and static variables (or constants), too.)
Import package is for better readability;
Fully qualified class has to be used in special scenarios. For example, same class name in different package, or use reflect such as Class.forName().