What is the default (unnamed) package in Java, and why should you avoid putting code in it?
answer
- No `package` line ⇒ unnamed/default package
- Sits in the source root directly
- Named packages can't import from it (decisive)
- JDK: only for small/temporary apps
- JPMS named modules forbid it
basics
~20 sIf a Java file has no package line, its class lands in the default (unnamed) package. It works for tiny experiments, but you should avoid it: classes there can't be imported by classes in named packages, and it doesn't scale or organize anything.
solid answer
~40 sThe default (unnamed) package is where a type goes when its source file declares no `package`. It exists mainly so trivial single-file programs and quick experiments compile without ceremony. You should avoid it in real code for several reasons: a type in a named package cannot `import` a type from the unnamed package, so unnamed-package classes are effectively unusable from organized code; the JDK documentation explicitly limits its use to small or temporary applications; it offers no namespacing, so collisions are likely as the project grows; and the Java Platform Module System (JPMS) does not allow a named module to contain types in the unnamed package. In short, the unnamed package is a convenience for throwaway code only — production code always declares an explicit package.
go deeper
Knows that omitting package puts a class in the default package and that real code should declare a package.
Explains concrete drawbacks: can't be imported from named packages, no namespacing, JDK restricts it to small apps.
Adds the JPMS constraint (named modules exclude the unnamed package) and how it blocks modularization, plus tooling impact.
Enforces a no-default-package policy in standards/linters and accounts for it in module/classpath architecture and migration plans.
## What the unnamed package is Every Java type belongs to some package. If a source file has **no** `package` declaration at the top, its types are placed in the **default package**, also called the **unnamed package**. It has no name and corresponds to the source root directory itself (files sitting directly in `src/`, not in any subfolder). ```java // File: Hello.java (no package line) public class Hello { public static void main(String[] args) { System.out.println("Hi"); } } ``` This compiles and runs fine. The unnamed package exists deliberately, so that beginners and quick scripts don't need to set up directory structure and naming just to print one line. ## Why it must be avoided in real code ### 1. You cannot import from the unnamed package This is the decisive technical reason. A type that lives in a **named** package cannot reference a type in the unnamed package, because there is no name to put in an `import` statement. There is no syntax to import "the class with no package". So the moment your project has even one named package (which it must, to be organized), any class stuck in the unnamed package becomes unreachable from the rest of the code. The unnamed package can use named-package types, but not the reverse. ### 2. The JDK explicitly restricts it The Java Language Specification and JDK docs state the unnamed package is provided for the convenience of developing **small or temporary applications** or when just beginning. It is not intended for anything beyond that. ### 3. No namespacing — collisions and chaos The whole value of packages is grouping and uniqueness. The unnamed package gives neither. As the codebase grows you lose name-collision protection and any logical structure. ### 4. The module system forbids it Under the **Java Platform Module System (JPMS)**, introduced in Java 9, a *named module* (declared via `module-info.java`) **cannot** contain any type in the unnamed package. So code in the unnamed package can never be modularized; it can only run on the classpath as part of the *unnamed module*. This blocks a major architectural path. ### 5. Tooling and conventions assume named packages Build tools, static analysis, IDE refactorings, and team conventions all assume real packages. Code in the default package fights the ecosystem. ## When is it acceptable? - A single-file learning exercise or a script you'll delete. - A `jshell`-style snippet or a tiny demo with one class. Even then, many teams forbid it outright so habits stay clean. ## How to fix code in the unnamed package Add a `package` declaration and move the file into the matching directory: declare `package com.example.app;` and move `Hello.java` to `com/example/app/Hello.java` under the source root. IDEs do this in one refactoring ("Move to package"). ## Summary The unnamed package is the no-`package` fallback meant only for trivial, throwaway code. Avoid it in real projects because named-package classes can't import from it, the JDK restricts it to tiny apps, it gives no namespacing, and named JPMS modules can't contain it.
- Can a class in `com.example` use a class that's in the unnamed package?No. There is no import syntax to name an unnamed-package type, so named-package code cannot reference it. The reverse works: unnamed-package code can use named-package types via import or FQN.
- How does the unnamed package interact with JPMS?A named module (with module-info.java) cannot contain types in the unnamed package. Such code can only run as part of the unnamed module on the classpath, so it can't be modularized.
saying these in an interview costs you the question
- Claiming you can `import` a class from the unnamed package into a named package
- Thinking the default package is fine for production as long as it compiles
- Believing the default package can live inside a named JPMS module
- Confusing the unnamed package with the unnamed module