Within a .java source file, what is the required order of the package statement, imports, and type declarations?
answer
- Order: package → imports → type declarations
- At most one package, it must be first
- Imports are compile-time only (no bytecode)
- No imports after a type declaration
- Package name == directory path on disk
basics
~10 sA source file has up to one package statement first, then any import statements, then the class (and other type) declarations. The package line must come before imports, and imports before any class.
solid answer
~40 sA Java compilation unit has three ordered sections. First, an optional single package declaration (e.g. package com.acme.billing;) that names the package; if present it must be the very first statement, ahead of imports and types (comments and annotations on the package may precede it). Second, zero or more import statements (regular, static, and on-demand wildcard imports) that bring other types or static members into scope. Third, one or more top-level type declarations — classes, interfaces, enums, records — of which at most one is public. Imports cannot appear after a type declaration, and a second package statement is illegal. Getting the order wrong is a compile error. The package also dictates the directory the file lives in on disk.
go deeper
Knows package comes first, then imports, then the class.
States the full fixed order, knows there is at most one package and that imports can't follow a type, and that package maps to directory.
Explains that imports are compile-time-only with no bytecode, the unnamed-package caveat, static vs on-demand imports, and the name-resolution rationale for the order.
Discusses package/module design, import hygiene (avoiding wildcard imports for clarity), and how the order supports deterministic single-pass name resolution.
## The compilation unit A single `.java` file is called a **compilation unit**. Its top-level contents must appear in a fixed order, defined by the Java Language Specification: ``` [package declaration] // optional, at most one [import declarations] // zero or more type declarations // one or more (classes, interfaces, enums, records) ``` ### 1. The package declaration (optional, first) A **package** is a namespace that groups related types and controls access. The declaration looks like: ```java package com.acme.billing; ``` If present, it must be the **first statement** in the file — nothing but comments and the package's own annotations may precede it. There can be at most **one** package statement. If you omit it, the file's types belong to the **unnamed (default) package** — acceptable for tiny experiments but discouraged in real code. The package name also dictates the **directory structure**: `com.acme.billing.Invoice` must live in `com/acme/billing/Invoice.java`. ### 2. Import declarations (optional, middle) **Imports** let you refer to types (or static members) from other packages by their simple name instead of their fully qualified name. They come after the package line and before any type: ```java import java.util.List; // single-type import import java.util.*; // on-demand (wildcard) import of a package import static java.lang.Math.PI; // static import of a member import static java.lang.Math.*; // static on-demand import ``` Imports are purely a compile-time convenience — they generate no bytecode; the compiler still resolves everything to fully qualified names. You may have any number, in any internal order, but **all** imports must come before the first type declaration. An import placed after a class is a compile error. ### 3. Type declarations (required, last) Finally come the **top-level type declarations** — the classes, interfaces, enums, or records. There must be at least one for the file to be meaningful, and (per the one-public-class rule) at most one may be `public`, with the file named after it. ## Why the order is fixed The compiler reads the file top-down and needs the package context and all imports established **before** it processes the types, so that every simple name inside the types can be resolved. Allowing imports after a type would mean a type could reference a name not yet imported, complicating resolution. The rigid order keeps name resolution simple and deterministic. ## A complete example ```java package com.acme.billing; // 1. package first import java.util.List; // 2. imports next import static java.lang.Math.max; public class Invoice { // 3. types last List<String> lines; int cap = max(10, 5); } ``` ## Common errors - Putting `import` before `package` — illegal; package must be first. - A second `package` line — illegal; only one allowed. - An `import` after the class — compile error. - Mismatched package and directory — the build fails to locate the type.
- Do import statements add any runtime overhead?No — imports are a compile-time convenience that let you use simple names; the compiler resolves everything to fully qualified names, and nothing extra is emitted to bytecode.
- What package do types belong to if there is no package statement?The unnamed (default) package. It works for trivial code but is discouraged — such types can't be imported by code in named packages.
saying these in an interview costs you the question
- Allowing imports before the package statement
- Thinking multiple package statements are allowed
- Believing imports generate bytecode or runtime cost
- Placing a type before the imports