2

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.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
ktm5124
  • 11,861
  • 21
  • 74
  • 119
  • 6
    If you haven’t imported the java.time package, you won’t be using its classes. – Jakg Nov 30 '18 at 22:16
  • 2
    I personally think that the reason they use the same class names, is that it makes migration to the Java 8 Date and Time API really easy. It is a backport after all, and not only a library. I would not use the fully qualified class names, as it defeats the whole advantage if the classes having the same name. I would instead use the simple class names, and when migrating to Java 8, you just replace the imports. – MC Emperor Nov 30 '18 at 22:26
  • 3
    Also, in addition to @Jakg's comment, only all classes from the `java.lang` package are automatically imported. `java.time` ≠ `java.lang`, you don't have to worry about import conflicts or something. – MC Emperor Nov 30 '18 at 22:34
  • 3
    Your use of imports is wise. No need to fully qualify the classes. *ThreeTen-Backport* purposely uses nearly identical API. To migrate away from the back-port and to *java.time* you will need do little more than search-and-replace those `import` statements. The main thing you will have to replace manually is calls to the utility class used for converting to/from the legacy classes and the the modern (*java.time*/*ThreeTen-Backport*). – Basil Bourque Nov 30 '18 at 23:40

1 Answers1

5

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 = ...

Ousmane D.
  • 54,915
  • 8
  • 91
  • 126