skip to content

Two types you need share the same simple name (e.g. java.util.Date and java.sql.Date). How do you use both in one source file?

level: middleimportance: should knowfreq 55%

answer

  1. At most one single-type import per simple name
  2. Import the common one, FQN the rare one at every use
  3. Java has NO import aliasing (unlike Kotlin/C#/Python)
  4. Canonical pair: java.util.Date vs java.sql.Date
  5. FQN at use site overrides the imported simple name

basics

~20 s

You can only import one of them by name. Import one (say import java.util.Date;) and refer to the other by its full name, java.sql.Date, everywhere you use it. There's no syntax to rename an import in Java.

solid answer

~40 s

When two types share a simple name, you can have at most one single-type import for that simple name in the file. The standard pattern is: import the type you use more often, and write the other one with its **fully qualified name** at every use site. For example, `import java.util.Date;` then declare the SQL one as `java.sql.Date sqlDate = ...`. Java deliberately has **no import-aliasing/renaming** syntax (unlike Kotlin's `import ... as`, or C#'s `using X = ...`), so FQNs are the only mechanism. If you find a file needs both names heavily, that's often a design smell suggesting you split responsibilities or wrap one type. The classic real-world example is `java.util.Date` vs `java.sql.Date` (the latter extends the former), and `java.util.List` vs `java.awt.List`.

go deeper

for a junior

Knows you can import only one and must use the full name for the other; recognizes the Date/Date example.

for a middle

Explains the one-single-import-per-name rule, the FQN workaround, and that Java lacks import aliasing.

for a senior

Adds design-level tactics (import the dominant type, wrap at a boundary, treat heavy collisions as a smell) and contrasts Java with aliasing languages.

for a principal

Discusses minimizing such collisions through API/package design, boundary mappers, and code conventions, and reasons about readability/maintainability trade-offs across a large codebase.

## The collision Java identifies types in code by **simple name** after imports are resolved. But the standard library (and large codebases) contain distinct types that share a simple name living in different packages — the canonical pair is **`java.util.Date`** (a general date/time value) and **`java.sql.Date`** (a JDBC type representing a SQL DATE; it actually *extends* `java.util.Date`). You sometimes legitimately need both in the same file, e.g. converting between them. ## Rule: one single-type import per simple name A file may contain **at most one** single-type import for a given simple name. `import java.util.Date; import java.sql.Date;` is a **compile error** (two single-type imports of the same simple name — illegal even if unused). ## The only built-in solution: fully qualified names Import whichever you use most, and spell the other out in full **everywhere**: ```java import java.util.Date; Date utilDate = new Date(); // java.util.Date (imported) java.sql.Date sqlDate = // fully qualified — no import new java.sql.Date(utilDate.getTime()); ``` The FQN at the use site overrides whatever the simple name would resolve to, so the two coexist cleanly. ## Why no `import ... as Alias`? Many languages let you rename on import — Kotlin (`import java.sql.Date as SqlDate`), Python (`import x as y`), C# (`using SqlDate = System.Data...`). **Java has never had this.** The design intent was to keep type identity tied to its real name; the workaround is FQNs. There is genuine community demand for aliasing, but as of current Java it does not exist, so do not claim otherwise in an interview. ## Practical tactics 1. **Import the dominant type, FQN the rare one** — least noise. 2. **Wrap or convert at a boundary** — e.g. a small mapper class so most code only sees one of the types. 3. **Reconsider the design** — a class juggling two same-named types is often doing too much; splitting it removes the collision. ## Shadowing vs. ambiguity recap - A **single-type import shadows** a wildcard import of the same simple name (no error). - **Two single-type imports** of the same simple name = error. - **Two wildcards** supplying the same simple name = error only when you use it; fix by adding one single-type import or using an FQN.

  • Can you write `import java.sql.Date as SqlDate;` in Java?
    No. Java has no import-aliasing syntax. You must either import one and use the fully qualified name for the other, or fully qualify both.
  • What's the relationship between java.util.Date and java.sql.Date?
    `java.sql.Date` extends `java.util.Date`; it represents a SQL DATE (no time component conceptually). Their shared simple name `Date` is the source of the import collision.

saying these in an interview costs you the question

  • Claiming Java supports `import ... as Alias`
  • Trying `import java.util.Date; import java.sql.Date;` and expecting it to compile
  • Thinking you must fully qualify BOTH types
  • Believing you can't use two same-named types in one file at all

context

resolving links…