{"title":"import Statement","description":"","content":"The previous lesson covered packages, which group related classes into namespaces with names like `com.shop.checkout` or `java.util`. Putting classes into packages solves the naming-collision problem at the cost of long, ceremonial names everywhere they're used. The `import` statement is what lets you write `ArrayList` instead of `java.util.ArrayList` in every line of your file. This lesson covers single-type imports, on-demand (wildcard) imports, how `java.lang` is special, name conflicts and how to resolve them, and what `import` does and doesn't do internally.\n\n---\n\n# The Problem Imports Solve\n\nSuppose a shopping cart class uses `ArrayList`, `HashMap`, and `List` from the `java.util` package. Without any imports, every reference to those types has to spell out the full package path. The result reads like a paperwork form.\n\n\n```java\npublic class ShoppingCart {\n private java.util.List items = new java.util.ArrayList<>();\n private java.util.Map quantities = new java.util.HashMap<>();\n\n public void addItem(String item, int quantity) {\n items.add(item);\n quantities.put(item, quantity);\n }\n\n public static void main(String[] args) {\n ShoppingCart cart = new ShoppingCart();\n cart.addItem(\"Wireless Mouse\", 1);\n cart.addItem(\"USB Cable\", 2);\n\n System.out.println(\"Items: \" + cart.items);\n System.out.println(\"Quantities: \" + cart.quantities);\n }\n}\n```\n\n\nThe code compiles and runs. It's also hard to read. The fully-qualified names take up so much horizontal space that the actual logic gets lost in the prefix. Every time the class needs another `java.util` type, the same `java.util.` is glued to the front. In a 200-line file, that prefix shows up dozens of times for no real benefit; the meaning of `ArrayList` is already clear from context.\n\nThe `import` statement is Java's answer. Declare which types to use by their short names at the top of the file, and the compiler treats every short-name reference in the rest of the file as if it were fully qualified.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.HashMap;\nimport java.util.List;\nimport java.util.Map;\n\npublic class ShoppingCart {\n private List items = new ArrayList<>();\n private Map quantities = new HashMap<>();\n\n public void addItem(String item, int quantity) {\n items.add(item);\n quantities.put(item, quantity);\n }\n\n public static void main(String[] args) {\n ShoppingCart cart = new ShoppingCart();\n cart.addItem(\"Wireless Mouse\", 1);\n cart.addItem(\"USB Cable\", 2);\n\n System.out.println(\"Items: \" + cart.items);\n System.out.println(\"Quantities: \" + cart.quantities);\n }\n}\n```\n\n\nThe behavior is identical. The class body got shorter and clearer. The four `import` lines at the top tell the compiler, \"when this file says `ArrayList`, that means `java.util.ArrayList`.\" Everywhere below, the short name works.\n\nThis is the central trade. Fully-qualified names are explicit but heavy. Short names with imports are clean but require a small declaration up top to disambiguate them. In practice, Java code uses imports almost everywhere and reserves fully-qualified names for a few specific situations covered later in the lesson.\n\n---\n\n# Single-Type Imports\n\nThe most common form of `import` brings in one class or interface by name. The shape is `import` followed by the fully-qualified type name followed by a semicolon.\n\n\n```java\nimport java.util.ArrayList;\nimport java.time.LocalDate;\nimport java.math.BigDecimal;\n```\n\n\nEach line imports exactly one type. After those three lines, `ArrayList`, `LocalDate`, and `BigDecimal` can be used as short names anywhere in the file. Other types in the same packages (like `HashMap` from `java.util` or `LocalTime` from `java.time`) are not affected; if the file needs them, it needs separate import lines for them too.\n\n\n```java\nimport java.util.ArrayList;\nimport java.math.BigDecimal;\n\npublic class CartTotal {\n public static void main(String[] args) {\n ArrayList itemPrices = new ArrayList<>();\n itemPrices.add(new BigDecimal(\"19.99\"));\n itemPrices.add(new BigDecimal(\"4.50\"));\n itemPrices.add(new BigDecimal(\"12.00\"));\n\n BigDecimal total = BigDecimal.ZERO;\n for (BigDecimal price : itemPrices) {\n total = total.add(price);\n }\n\n System.out.println(\"Item prices: \" + itemPrices);\n System.out.println(\"Total: $\" + total);\n }\n}\n```\n\n\nThe file imports exactly two types and uses both throughout the class. Single-type imports are the default style most teams prefer, because each import line documents one external dependency the file pulls in. Reading the imports tells a future maintainer which classes the file relies on without scanning every method body.\n\nA single-type import is a compile-time instruction only. The Java runtime doesn't see imports at all; we return to that point below.\n\n---\n\n# On-Demand (Wildcard) Imports\n\nJava also supports a wildcard form that imports every public type from a package in one line. The wildcard character is `*`.\n\n\n```java\nimport java.util.*;\n```\n\n\nThat single line makes `ArrayList`, `HashMap`, `LinkedList`, `List`, `Map`, `Set`, `Queue`, and every other public type directly inside `java.util` available by short name. It does the same job as listing each one individually with `import java.util.ArrayList; import java.util.HashMap;` and so on.\n\n\n```java\nimport java.util.*;\n\npublic class CartSummary {\n public static void main(String[] args) {\n List items = new ArrayList<>();\n items.add(\"Wireless Mouse\");\n items.add(\"USB Cable\");\n items.add(\"Wireless Mouse\");\n\n Map counts = new HashMap<>();\n for (String item : items) {\n counts.merge(item, 1, Integer::sum);\n }\n\n Set uniqueItems = new HashSet<>(items);\n\n System.out.println(\"Items: \" + items);\n System.out.println(\"Counts: \" + counts);\n System.out.println(\"Unique: \" + uniqueItems);\n }\n}\n```\n\n\nOne wildcard line covers `List`, `ArrayList`, `Map`, `HashMap`, `Set`, and `HashSet`. The file would otherwise need six separate import lines.\n\nWildcards come with two restrictions. The first is that `import java.util.*;` does **not** import sub-packages. A wildcard reaches exactly one level deep. Types directly inside `java.util` become available; types inside `java.util.concurrent` or `java.util.regex` do not.\n\n\n```java\nimport java.util.*;\n\npublic class WildcardLimit {\n public static void main(String[] args) {\n // java.util.concurrent.ConcurrentHashMap is NOT covered by java.util.*\n // This line fails to compile without a separate import:\n // ConcurrentHashMap stock = new ConcurrentHashMap<>();\n\n // The fully-qualified form works:\n java.util.concurrent.ConcurrentHashMap stock =\n new java.util.concurrent.ConcurrentHashMap<>();\n stock.put(\"Mouse\", 12);\n System.out.println(\"Stock: \" + stock);\n }\n}\n```\n\n\nTo use `ConcurrentHashMap` by its short name requires a separate `import java.util.concurrent.ConcurrentHashMap;` or a separate wildcard `import java.util.concurrent.*;`. The single wildcard `java.util.*` is not transitive.\n\nThe second restriction is more of a style point than a compiler rule. Wildcard imports can hide which types a file actually uses, and they can cause name conflicts when two wildcarded packages both define a type with the same simple name. The conflicts section covers that case below. Most teams prefer single-type imports for this reason, and most IDEs default to expanding wildcards automatically.\n\n---\n\n# `java.lang` Is Auto-Imported\n\nEvery Java file behaves as if it begins with an invisible `import java.lang.*;` line. The `java.lang` package contains the types so fundamental that every program needs them, like `String`, `System`, `Math`, `Object`, `Integer`, `Double`, `Boolean`, `Throwable`, and `Exception`.\n\n\n```java\npublic class LangDemo {\n public static void main(String[] args) {\n String customerName = \"Priya\";\n int orders = 7;\n double averageRating = 4.7;\n\n System.out.println(\"Customer: \" + customerName);\n System.out.println(\"Orders: \" + orders);\n System.out.println(\"Rating: \" + Math.round(averageRating));\n }\n}\n```\n\n\n`String`, `System`, and `Math` all live in `java.lang`, and the file uses them with no `import` line for any of them. They're already available by short name from the moment the file starts. The language builds this in because typing `java.lang.String` everywhere would be tedious.\n\nThe auto-import only applies to `java.lang` itself, not its sub-packages. `java.lang.reflect.Method` and `java.lang.annotation.Retention` are not auto-imported. If a file needs them, it imports them explicitly.\n\n---\n\n# Fully-Qualified Names Without Imports\n\nImports are a convenience, not a requirement. Any public type can be referred to by its fully-qualified name without importing it. The two forms are interchangeable for the compiler; the only difference is how the file reads.\n\n\n```java\npublic class FullyQualifiedDemo {\n public static void main(String[] args) {\n java.util.ArrayList cart = new java.util.ArrayList<>();\n cart.add(\"Wireless Mouse\");\n cart.add(\"USB Cable\");\n\n java.time.LocalDate today = java.time.LocalDate.of(2025, 11, 14);\n\n System.out.println(\"Cart: \" + cart);\n System.out.println(\"Order date: \" + today);\n }\n}\n```\n\n\nThe file uses `ArrayList` and `LocalDate` without importing either. It works because each reference spells out the full package path. The output is identical to a version that imports both types and uses the short names.\n\nTwo situations make fully-qualified names useful, not just a style choice. The first is when a type is used exactly once in a file and adding an import to the top would be more visual noise than the single short-name reference would save. The second, more important one, is name conflicts.\n\n---\n\n# Name Conflicts and How to Resolve Them\n\nThe classic conflict in the JDK is `Date`. Two different packages both define a class with that simple name: `java.util.Date` (the older, general-purpose date type) and `java.sql.Date` (a date type designed for SQL columns that store calendar dates without a time component). They are not the same class. They live in different packages, have different APIs, and represent different concepts. A program that talks to both an SQL database and a non-SQL part of the system often needs both.\n\nThe compiler doesn't allow importing both with single-type imports:\n\n\n```java\nimport java.util.Date;\nimport java.sql.Date; // compile error: Date is already defined\n\npublic class DateConflict {\n public static void main(String[] args) {\n Date now = new Date();\n System.out.println(now);\n }\n}\n```\n\n\nThe compiler error is straightforward:\n\n\n```shell\nerror: Date is already defined in a single-type-import\nimport java.sql.Date;\n ^\n```\n\n\nTwo short names called `Date` can't refer to two different classes in the same file. There are three standard ways to resolve the conflict.\n\nThe first option is to import one of them by short name and refer to the other by its fully-qualified name everywhere it appears.\n\n\n```java\nimport java.util.Date;\n\npublic class DateBothWays {\n public static void main(String[] args) {\n Date eventTimestamp = new Date();\n java.sql.Date orderDate = java.sql.Date.valueOf(\"2025-11-14\");\n\n System.out.println(\"Event timestamp: \" + eventTimestamp);\n System.out.println(\"Order date: \" + orderDate);\n }\n}\n```\n\n\n**Output (the timestamp portion varies):**\n\n\n```shell\nEvent timestamp: Fri Nov 14 10:23:11 UTC 2025\nOrder date: 2025-11-14\n```\n\n\n`Date` (the short name) means `java.util.Date` because that's the one that's imported. Any reference to the SQL version has to write `java.sql.Date` in full. This works well when one of the two types is used heavily and the other appears in only a couple of spots.\n\nThe second option is to refuse to import either of them and use fully-qualified names for both. This is the most explicit approach, and it removes any doubt about which `Date` a given line refers to.\n\n\n```java\npublic class DateExplicit {\n public static void main(String[] args) {\n java.util.Date eventTimestamp = new java.util.Date();\n java.sql.Date orderDate = java.sql.Date.valueOf(\"2025-11-14\");\n\n System.out.println(\"Event timestamp: \" + eventTimestamp);\n System.out.println(\"Order date: \" + orderDate);\n }\n}\n```\n\n\n**Output (the timestamp portion varies):**\n\n\n```shell\nEvent timestamp: Fri Nov 14 10:23:11 UTC 2025\nOrder date: 2025-11-14\n```\n\n\nThe file is slightly heavier to read, but every reference is self-describing. This is the preferred approach when both types are used roughly equally, or when the file is part of a larger codebase where mixing the two has historically caused confusion.\n\nThe third option, available since Java does not allow aliasing an import to a new name, is to make a deliberate choice about which form goes through a wildcard. The conflict resolution rules say that a single-type import wins over a conflicting type that would come in through a wildcard, which is captured in the diagram below.\n\n\n```mermaid\nflowchart TD\n Code[\"Source uses Date\"]:::cyan\n Single[\"Single-type import:
import java.sql.Date;\"]:::orange\n Wild[\"Wildcard import:
import java.util.*;\"]:::teal\n Result[\"Date resolves to
java.sql.Date\"]:::green\n Lang[\"java.lang.*
auto-imported\"]:::orange\n\n Code --> Single\n Code --> Wild\n Code --> Lang\n Single --> Result\n Wild -. lower priority .-> Result\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram shows the resolution order. When a short name like `Date` is used in a file, the compiler looks at single-type imports first, then at wildcards, with `java.lang.*` always implicitly present. A single-type import for `java.sql.Date` will take priority over a wildcard `import java.util.*;` that would otherwise pull in `java.util.Date`. This is the practical reason wildcard imports get a bad reputation in larger codebases: adding a new class to a wildcarded package could change which `Date` the file resolves to.\n\n---\n\n# Where Imports Go in the File\n\nThe placement of `import` statements is fixed by the language. Each Java source file has the same overall shape:\n\n\n```java\npackage com.shop.checkout;\n\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class Cart {\n // class body\n}\n```\n\n\nThe `package` declaration, if present, comes first. After that come zero or more `import` statements. After the imports comes the class, interface, or enum declaration. Comments and blank lines are allowed anywhere, but the three sections must appear in that order.\n\nA file with no `package` statement (a class in the unnamed default package) still places imports between an implicit \"no package\" line and the class body:\n\n\n```java\nimport java.util.ArrayList;\n\npublic class Receipt {\n public static void main(String[] args) {\n ArrayList lineItems = new ArrayList<>();\n lineItems.add(\"Wireless Mouse $19.99\");\n lineItems.add(\"USB Cable $4.50\");\n\n System.out.println(\"Receipt:\");\n for (String line : lineItems) {\n System.out.println(\" \" + line);\n }\n }\n}\n```\n\n\nImports must not appear inside the class body, between methods, or anywhere else. Placing an `import` line inside the class produces a compile error along the lines of `class, interface, or enum expected`.\n\nThe number of imports doesn't matter; one or fifty is fine. The order between them is unrestricted as far as the compiler is concerned. Most teams follow a convention.\n\n---\n\n# Conventional Import Order\n\nThe Java Language Specification doesn't dictate the order of imports, but a strong convention exists across the ecosystem. Projects, IDEs, and code-style tools group imports in this order, with a blank line between groups:\n\n1. `java.*` (the standard Java APIs)\n2. `javax.*` (the extended Java APIs, things like `javax.sql`, `javax.crypto`)\n3. Third-party libraries (anything from external dependencies, like `com.fasterxml.jackson.*` or `org.springframework.*`)\n4. Project-local packages (your own application code, like `com.shop.checkout.*`)\n\nWithin each group, imports are alphabetized.\n\n\n```java\npackage com.shop.checkout;\n\nimport java.math.BigDecimal;\nimport java.util.ArrayList;\nimport java.util.List;\n\nimport javax.sql.DataSource;\n\nimport com.fasterxml.jackson.databind.ObjectMapper;\n\nimport com.shop.inventory.Product;\nimport com.shop.inventory.StockLevel;\n\npublic class OrderSummary {\n // class body\n}\n```\n\n\nThe grouping is a readability convention, not a language rule. The compiler treats all the imports identically. But scanning the imports of a well-organized file tells a reader at a glance which external dependencies are in play, separated by source.\n\nMost IDEs (IntelliJ IDEA, Eclipse, VS Code with Java extensions) ship with an \"organize imports\" or \"optimize imports\" command that sorts the imports into the convention's order, removes any that aren't actually used, and (depending on settings) collapses several imports from the same package into a wildcard or expands a wildcard into single-type imports. Running the command before committing keeps the import list tidy without manual work.\n\n---\n\n# What `import` Does NOT Do\n\nThis is the easiest part of `import` to misunderstand, and it's a common interview question.\n\nThe `import` statement is a compile-time instruction. Its job is to allow short type names in the source file. That is the whole job. After the compiler resolves the short names to their fully-qualified forms, the imports themselves are gone. They're not stored in the `.class` file, the JVM never sees them, and they have no runtime cost.\n\nThree specific misconceptions matter here, because each one shows up in real bug reports.\n\n**Imports do not copy code.** Importing `java.util.ArrayList` does not pull a copy of the `ArrayList` class into the file or the `.class` file. The compiled bytecode contains a reference to `java.util.ArrayList` by its fully-qualified name, exactly as if the fully-qualified form had been written directly. The class itself lives in the JDK's `java.base` module and is loaded by the JVM the first time any code touches it.\n\n**Imports do not change runtime behavior.** Two files, one with `import java.util.ArrayList;` and one that uses `java.util.ArrayList` fully qualified everywhere, compile to byte-for-byte equivalent bytecode for the `ArrayList` references. There's no faster or slower version, no \"imported is cached\" effect, nothing. The choice is purely about source-code readability.\n\n**Imports do not \"alias\" or rename types.** Many other languages allow something like `import foo.Bar as Baz` so that `Baz` becomes a local name for `foo.Bar`. Java does not. Every import brings in the type by its original simple name. The only way to give a Java type a different local name is to wrap it in a new class or to refer to it by its fully-qualified name. This is why a conflict like `java.util.Date` versus `java.sql.Date` has to be solved with fully-qualified names or by importing only one of them, rather than with an alias.\n\nImports have zero runtime cost. They are not loaded, not parsed, not evaluated at runtime. Adding 200 imports to a file affects compile time slightly and source readability significantly, but the running program is identical to one with two well-chosen imports.\n\nThe shorthand is that `import` is a substitution rule that runs once, at compile time, on the source text. Everything else follows from that.\n\n---\n\n# Unused Imports and IDE Behavior\n\nA file can have imports for types it doesn't actually use. The compiler accepts them, but they're noise. Most IDEs flag unused imports as warnings and can remove them automatically.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.HashMap; // unused\nimport java.util.List; // unused\n\npublic class WasteImports {\n public static void main(String[] args) {\n ArrayList wishlist = new ArrayList<>();\n wishlist.add(\"Wireless Keyboard\");\n wishlist.add(\"Monitor\");\n System.out.println(\"Wishlist: \" + wishlist);\n }\n}\n```\n\n\nThe class only uses `ArrayList`. The two unused imports compile cleanly, but they suggest to a reader that the file might use `HashMap` and `List` somewhere, which is misleading. IntelliJ IDEA, Eclipse, and VS Code all highlight unused imports and provide a one-click \"remove unused imports\" action. Many teams treat a clean import list as basic code hygiene, and some configure commit hooks or CI to fail the build if unused imports are present.\n\nCommon IDE behaviors around imports shape what most Java code looks like:\n\n\n| Behavior | What It Does |\n| --- | --- |\n| Auto-add import | When you type a short name the file doesn't import, the IDE suggests adding the matching `import` line. |\n| Organize imports | Sorts, groups, and alphabetizes existing imports following the project's style settings. |\n| Remove unused imports | Deletes import lines for types the file doesn't reference. |\n| Expand wildcard | Replaces a `java.util.*` line with individual single-type imports for each type the file actually uses. |\n| Collapse to wildcard | The reverse: if a file uses many types from one package, replaces the individual imports with one wildcard. |\n\n\nThese features explain the typical Java codebase layout: a tidy block of single-type imports in conventional order at the top of every file. The mechanics are simple, but the IDEs do most of the bookkeeping.\n\n---\n\n# A Common Mistake: Wildcard Imports Causing Surprise\n\nA bug shows up when two wildcarded packages both define a type with the same simple name. The compiler flags it, but the error message can be confusing.\n\n**What's wrong with this code?**\n\n\n```java\nimport java.util.*;\nimport java.sql.*;\n\npublic class DateWildcardConflict {\n public static void main(String[] args) {\n Date now = new Date(); // compile error: reference to Date is ambiguous\n System.out.println(now);\n }\n}\n```\n\n\nThe compiler error:\n\n\n```shell\nerror: reference to Date is ambiguous\n Date now = new Date();\n ^\n both class java.sql.Date in java.sql and class java.util.Date in java.util match\n```\n\n\nBoth `java.util.Date` and `java.sql.Date` exist, and both are pulled in by their wildcards. The compiler can't decide which one `Date` should mean, so it refuses to guess.\n\n**Fix:** import one of them explicitly, which then takes priority, and leave the other to fall back to its fully-qualified form when needed.\n\n\n```java\nimport java.util.*;\nimport java.sql.*;\nimport java.util.Date; // explicit single-type import wins\n\npublic class DateWildcardConflict {\n public static void main(String[] args) {\n Date eventTimestamp = new Date();\n java.sql.Date orderDate = java.sql.Date.valueOf(\"2025-11-14\");\n\n System.out.println(\"Event timestamp: \" + eventTimestamp);\n System.out.println(\"Order date: \" + orderDate);\n }\n}\n```\n\n\n**Output (the timestamp portion varies):**\n\n\n```shell\nEvent timestamp: Fri Nov 14 10:23:11 UTC 2025\nOrder date: 2025-11-14\n```\n\n\nThe single-type import for `java.util.Date` takes priority over the wildcard, so `Date` resolves to `java.util.Date`. The SQL variant still has to be written fully qualified, but the file compiles and the intent is now explicit. This is one of the strongest reasons many teams discourage wildcard imports outside of small, throwaway files: they make resolution depend on package contents that can change.\n\n---\n\n# How Resolution Works\n\n`import` works like a lookup table the compiler builds for one file. When the file says `ArrayList`, the compiler walks through this table:\n\n\n```mermaid\nflowchart TD\n Start[\"Short name used:
ArrayList\"]:::cyan\n InFile[\"Defined in this file
or same package?\"]:::orange\n Single[\"Matches a single-type
import?\"]:::orange\n Lang[\"Matches a type in
java.lang?\"]:::teal\n Wild[\"Matches a wildcard
import?\"]:::teal\n Fail[\"Compile error:
cannot find symbol\"]:::red\n Found[\"Resolved to
java.util.ArrayList\"]:::green\n\n Start --> InFile\n InFile -- no --> Single\n Single -- no --> Lang\n Lang -- no --> Wild\n Wild -- no --> Fail\n Single -- yes --> Found\n Wild -- yes --> Found\n Lang -- yes --> Found\n InFile -- yes --> Found\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe diagram captures the resolution order. The compiler first checks types defined in the same file or the same package (those don't need an import at all). Then it checks single-type imports, which are the highest-priority external source. Then it checks `java.lang`, which is always implicitly available. Finally it checks wildcard imports. If none of those match, the short name is unresolvable and the compiler reports `cannot find symbol`.\n\nThis ordering is what makes \"single-type import wins over wildcard\" a stable rule. The single-type imports are checked first; the wildcards only matter for names the single-type imports don't cover.","pageType":"java"}

import Statement

Get Premium