What happens when static imports introduce a naming collision? Walk through the rules for ambiguity and shadowing.

## The problem A static import lets you use a static member by its **simple name** (no `ClassName.` prefix). But simple names aren't unique across classes — two classes can both have a static method `of` or a constant `EMPTY`. When more than one thing claims the same bare name in a file, Java needs rules to decide what an unqualified use means. ## The precedence chain (highest priority first) When the compiler sees an unqualified name `foo`, it resolves in this order: 1. **A member declared in the current class, or inherited from a supertype.** These always win over imports. 2. **An explicit single-member static import** (`import static X.foo;`). 3. **A wildcard static import** (`import static X.*;`). Lowest priority. A higher source **shadows** (hides) a lower one for that name — and crucially, this can happen **silently**, with no warning. ### Example of silent shadowing ```java import static java.lang.Integer.MAX_VALUE; // wildcard-or-explicit import class C { static final int MAX_VALUE = 5; // member of this class void m() { System.out.println(MAX_VALUE); // prints 5, NOT Integer.MAX_VALUE } } ``` The local field wins per rule 1; the import is hidden. No error — just possibly-surprising behavior. ### Explicit beats wildcard ```java import static java.util.Collections.emptyList; // explicit import static some.other.Util.*; // wildcard also has emptyList // unqualified emptyList() -> the explicit import wins, unambiguously ``` ## The genuine error: equal-precedence ambiguity If two sources at the **same** precedence level both supply the bare name, the compiler can't choose and **fails to compile**. The classic case is two **wildcard** static imports: ```java import static a.A.*; // A has static of(...) import static b.B.*; // B also has static of(...) of(...); // COMPILE ERROR: reference to 'of' is ambiguous ``` Fixes: (a) **qualify** it — `A.of(...)`; or (b) replace one wildcard with an **explicit** import, which raises that name's precedence and breaks the tie. ## Static import vs. a regular-imported type A static import can also collide with a **type** name brought in by a normal import, or with the simple name of the enclosing class. Java's spec resolves these via the name-resolution rules (a member name vs a type name are looked up in different contexts), but the practical lesson is the same: collisions are confusing, and the silent winner may surprise you. ## Overloads are *not* a clash Importing a name that has several overloads (e.g. `Math.max(int,int)` and `Math.max(double,double)`) is **not** an ambiguity — all overloads come in under one name and normal overload resolution picks the right signature at each call. Ambiguity is about the same simple name coming from **different declaring classes** at equal precedence. ## Why this matters / how to avoid it - **Prefer explicit single-member imports** — they're unambiguous and raise precedence, so they win cleanly over wildcards. - **Avoid statically importing generic names** (`of`, `get`, `valueOf`, `create`, `EMPTY`) that many classes share — these are clash magnets. - When a clash does occur, the safe, always-available fix is to **drop the static import for that name and qualify it** with the class. - Be aware of **silent shadowing** by local/inherited members: a static import can be quietly overridden, so don't assume a bare name resolves to the import.