Say I've code like:
import java.util.Date;
import my.own.Date;
class Test{
public static void main(String [] args){
// I want to choose my.own.Date here. How?
..
// I want to choose util.Date here. How ?
}
}
Should I be using full qualified class names? Can I get rid of the import statements? Is such a scenario common in real world programming?
You can omit the import statements and refer to them using the entire path. Eg:
java.util.Date javaDate = new java.util.Date()
my.own.Date myDate = new my.own.Date();
But I would say that using two classes with the same name and a similiar function is usually not the best idea unless you can make it really clear which is which.
use the fully qualified name instead of importing the class.
e.g.
//import java.util.Date; //delete this
//import my.own.Date;
class Test{
public static void main(String [] args){
// I want to choose my.own.Date here. How?
my.own.Date myDate = new my.own.Date();
// I want to choose util.Date here. How ?
java.util.Date javaDate = new java.util.Date();
}
}
Yes, when you import classes with the same simple names, you must refer to them by their fully qualified class names. I would leave the import statements in, as it gives other developers a sense of what is in the file when they are working with it.
java.util.Data date1 = new java.util.Date();
my.own.Date date2 = new my.own.Date();
Another way to do it is subclass it:
package my.own;
public class FQNDate extends Date {
}
And then import my.own.FQNDate in packages that have java.util.Date.
If you have your own date class you should distinguish it from the built-in Date class. i.e. why did you create your own. Something like ImmutableDate or BetterDate or NanoDate, even MyDate would indicate why you have your own date class. In this case, they will have a unique name.
You can import one of them using import. For all other similar classes, you need to specify fully qualified class names. Otherwise, you will get compilation error.
Example:
import java.util.Date;
class Test{
public static void main(String [] args){
// your own date
my.own.Date myOwndate ;
// util.Date
Date utilDate;
}
}
If you really want or need to use the same class name from two different packages, you have two options:
1-pick one to use in the import and use the other's fully qualified class name:
import my.own.Date;
class Test{
public static void main(String[] args){
// I want to choose my.own.Date here. How?
//Answer:
Date ownDate = new Date();
// I want to choose util.Date here. How ?
//Answer:
java.util.Date utilDate = new java.util.Date();
}
}
2-always use the fully qualified class name:
//no Date import
class Test{
public static void main(String[] args){
// I want to choose my.own.Date here. How?
//Answer:
my.own.Date ownDate = new my.own.Date();
// I want to choose util.Date here. How ?
//Answer:
java.util.Date utilDate = new java.util.Date();
}
}
This scenario is not so common in real-world programming, but not so strange too. It happens sometimes that two classes in different packages have same name and we need both of them.
It is not mandatory that if two classes have same name, then both will contain same functionalities and we should pick only one of them.
If we need both, then there is no harm in using that. And it's not a bad programming idea too.
But we should use fully qualified names of the classes (that have same name) in order to make it clear which class we are referring too.
:)
I hit this issue when, for example, mapping one class to another (such as when switching to a new set of classes to represent person data). At that point, you need both classes because that is the whole point of the code--to map one to the other. And you can't rename the classes in either place (again, the job is to map, not to go change what someone else did).
Fully qualified is one way. It appears you can't actually include both import statements, because Java gets worried about which "Person" is meant, for example.
When you call classes with the same names, you must explicitly specify the package from which the class is called.
You can to do like this:
import first.Foo;
public class Main {
public static void main(String[] args) {
System.out.println(new Foo());
System.out.println(new second.Foo());
}
}
package first;
public class Foo {
public Foo() {
}
@Override
public String toString() {
return "Foo{first class}";
}
}
package second;
public class Foo {
public Foo() {
}
@Override
public String toString() {
return "Foo{second class}";
}
}
Output:
Foo{first class}
Foo{second class}
If you have to use two classes with same name but different packages in the same file, there is no other option than using fully qualified name for at least one of the two classes. I'm more and more wondering if we shouldn't, in such cases, use fully qualified names all the times, so it would be clearer which class is which, but that makes the code harder to parse because of increased verbosity. Unfortunately, more and more programmers make this common by duplicating all data objects: one copy generated by Protoc in case of GRPC, one copy for JSON serialization, one copy for internal logic, one copy for Hibernate, etc., without any automated way of mapping one to another, plain old code duplication all over the place. IDEs are not well-designed for that, showing just com.abc.myproject.... instead of the fully qualified names when trying to use code completion. Unfortunately, Java offers no good solution by itself, IDEs have to jump in with auto-complete or auto-import. Here we would need aliases as offered by C#, Python and Javascript.
I just had the same problem, what I did, I arranged the library order in sequence, for example there were java.lang.NullPointerException and javacard.lang.NullPointerException. I made the first one as default library and if you needed to use the other you can explicitly specify the full qualified class name.
