skip to content

Show an idiomatic use of static imports for enum constants and library constants, and explain how to keep them readable as a design choice.

level: middleimportance: nice to knowfreq 28%

answer

  1. enum constants are public static final -> importable
  2. SECONDS.toMillis(5), 2*PI*r
  3. explicit, not wildcard
  4. skip generic names (EMPTY/DEFAULT/NONE)
  5. switch case labels need no import

basics

~20 s

You can static-import enum constants or named constants so you write SECONDS instead of TimeUnit.SECONDS, or PI instead of Math.PI. Do it only when the name is well-known and the file uses it a lot; otherwise keep the prefix.

solid answer

~40 s

Enum constants are static members, so you can statically import them: import static java.util.concurrent.TimeUnit.SECONDS; then write SECONDS.toMillis(5). Same for library constants: import static java.lang.Math.PI;. This reads well when the bare name is recognizable and used densely in the file — math code, time/unit code, or constant tables. The risk is that a stripped constant like EMPTY or DEFAULT could come from anywhere, so reserve static-importing constants for unambiguous, well-known names and import them explicitly rather than via wildcard. As a design point: a static import is a per-file readability decision, not a global one; the goal is that a reader who isn't using an IDE can still tell what the bare name means. If they can't, keep the qualifier.

code

java · 10 lines
java
import static java.util.concurrent.TimeUnit.SECONDS;
import static java.lang.Math.PI;

class Demo {
    void run() throws InterruptedException {
        long fiveSecondsMs = SECONDS.toMillis(5); // vs TimeUnit.SECONDS.toMillis(5)
        double circumference = 2 * PI * 3.0;       // vs 2 * Math.PI * 3.0
        System.out.println(fiveSecondsMs + " " + circumference);
    }
}

go deeper

for a junior

Knows you can import enum/library constants to write SECONDS or PI directly, and that it should be used for familiar names.

for a middle

Explains that enum constants are static fields and thus importable, gives idiomatic examples, and prefers explicit over wildcard.

for a senior

Articulates the per-file design call, the generic-name pitfall, enum clash risk, and the switch-label distinction.

for a principal

Frames it as a readability convention with lint enforcement and consistency across constant-heavy modules, balancing domain clarity against origin cues.

## Enum constants are static members An `enum` constant (like `TimeUnit.SECONDS` or `DayOfWeek.MONDAY`) is, under the hood, a **public static final field** of the enum type. Because it's a static member, it is eligible for **static import** just like `Math.PI`. ```java import static java.util.concurrent.TimeUnit.SECONDS; import static java.util.concurrent.TimeUnit.MILLISECONDS; long ms = SECONDS.toMillis(5); // instead of TimeUnit.SECONDS.toMillis(5) executor.awaitTermination(10, SECONDS); // reads naturally ``` Library/numeric constants work the same way: ```java import static java.lang.Math.PI; import static java.lang.Math.E; double circumference = 2 * PI * r; ``` ## When this is a readability *win* - The bare name is **well-known and unambiguous** in context (`PI`, `SECONDS`, `MONDAY`). - The constant is used **densely** in the file, so the removed prefixes add up to real noise reduction. - The surrounding code reads more like the domain (a formula, a duration). ## When it backfires - The constant has a **generic name** (`EMPTY`, `DEFAULT`, `NONE`, `ALL`) — stripped of its enum/class, a reader has no idea which type it belongs to. - You only use it **once or twice** — the brevity gain is tiny and the lost origin cue isn't worth it. - A **wildcard** static import of an enum (`import static SomeEnum.*;`) dumps every constant into the namespace and invites clashes with another enum's constants (e.g. two enums both having `NONE`). ## Design guidance 1. **Import constants explicitly, by name** (one per line), not via wildcard, so the import list documents exactly which constants you borrowed. 2. **Only strip the qualifier for recognizable names.** If `SECONDS` alone is clear, import it; if `LOW` alone is murky, keep `Priority.LOW`. 3. **Watch for clashes** between two enums with overlapping constant names — qualify or import only one (see the ambiguity question). 4. **Treat it as a per-file call.** Static imports are local to the file; deciding to import `MONDAY..SUNDAY` in a calendar-heavy file while qualifying them elsewhere is perfectly fine and often best. ## A note on `switch` Inside a `switch` on an enum, you write the constant labels **unqualified by language rule** (`case MONDAY:`) — that is *not* a static import and requires none. Static import only matters where you reference the constant as a normal expression (`if (day == MONDAY)` needs the import; `case MONDAY:` does not). ## Bottom line Static-importing enum/library constants is a clean way to make domain-heavy code read naturally, provided you keep it explicit, restrict it to unambiguous well-known names, and remember the reader without an IDE.

  • Do you need a static import to write 'case MONDAY:' in a switch over DayOfWeek?
    No. Enum switch case labels are unqualified by language rule and require no import. Static import is only needed to use the constant as a normal expression elsewhere, e.g. if (day == MONDAY).
  • Why is wildcard-importing an entire enum's constants risky?
    It pulls every constant into the file's namespace, increasing the chance of a clash with another enum that shares a constant name (e.g. two enums with NONE), which can cause an ambiguity error. Explicit imports of just the constants you use avoid this.

saying these in an interview costs you the question

  • Thinking enum constants can't be static-imported
  • Static-importing generic constant names like NONE/DEFAULT and losing the type
  • Believing case labels in a switch require a static import
  • Defaulting to wildcard-importing an entire enum

context

resolving links…