Should you fully qualify the package prefix when using ThreeTen-Backport versus java.time?

ktm5124 :

We're using Three Ten Backport in our project, since one of our customers is using Java 7. Three Ten Backport gives us the new date-time functionality (java.time.*) introduced in Java 8.

I'd like to know if the following is a good practice. Since most of our customers are using Java 8, and one day we might upgrade all customers to Java 8, does it really make sense to fully qualify the class names with org.threeten.bp? Eventually we might uprade all customers to Java 8 and remove this dependency, and if we end up doing this then there will be less code changes if we just use the class names without the package prefix. To give a code example, what I mean is this.

import org.threeten.bp.LocalDate Time;

public class Example {

     public void example() {
          LocalDateTime datetime = // ....
     } 
}

You can see in the example that I reference LocalDateTime without the package prefix. In Java 8, will the java.time.LocalDateTime class be loaded, or the org.threeten.bp.LocalDateTime? It's a little unclear since in this code, in Java 8, there are two LocalDateTime's floating around, one from java.time and the other from org.threeten.bp. I assume that the native Java library will be given precedence and loaded, but I could be wrong.

Is doing this good practice? Or could it generate compiler warnings/errors? Even if it doesn't generate any warnings or errors, might it still be a bad practice? I'm tempted to do this because fully qualifying a class by a package is just plain ugly, and if we end up removing the Three Ten dependency then we'll have to change every instance of that code, instead of just deleting import statements. Happy to hear your thoughts.

Ousmane D. :

There will only be a clash when you have both imports:

import org.threeten.bp.LocalDateTime;
import java.time.LocalDateTime;

Having only the import org.threeten.bp.LocalDateTime; shouldn't cause an issue. So, you don't need to fully qualify any statement with LocalDateTime datetime = ...