What is the reverse-domain-name convention for Java packages, and why is it used?
answer
- Reverse the org's domain: example.com → com.example
- Borrows DNS's global uniqueness
- All lowercase, legal identifiers, no hyphens
- Convention, not compiler-enforced
- Maven groupId mirrors it
basics
~20 sYou name packages by reversing your organization's internet domain. If your domain is example.com, your packages start with com.example. This makes names globally unique, since domains are unique, so your classes won't clash with anyone else's.
solid answer
~40 sThe convention is to prefix package names with your organization's internet domain name reversed: a company owning `example.com` uses `com.example` as its package root, then appends project and module segments like `com.example.billing.invoice`. The reason is global uniqueness: internet domains are already registered to be unique worldwide, so reversing one guarantees no two organizations produce colliding fully qualified names, even when their JARs end up on the same classpath. By convention the segments are all lowercase, and you avoid Java reserved words and hyphens (which aren't valid identifiers). If a domain segment is a keyword or starts with a digit, you adapt it (e.g. prefix an underscore). It's a strong convention, not enforced by the compiler, but following it keeps libraries from clashing and signals professional structure.
go deeper
Can reverse a simple domain to a package prefix and knows segments are lowercase.
Explains the uniqueness rationale and handles edge cases like hyphens, digits, and keywords in domains.
Relates the convention to classpath collisions across third-party JARs and to Maven groupId/publishing.
Defines org-wide package taxonomy and ownership, aligns groupId/module names, and weighs naming in monorepo vs multi-repo and JPMS module strategies.
## The collision problem A package name is a *namespace*. Its whole job is to keep one organization's class names from colliding with another's. But for that to work globally, two unrelated teams must never independently pick the same package name. How do you coordinate uniqueness across the entire world of Java developers without a central registry? You reuse one that already exists: the **internet domain name system (DNS)**. ## The convention Domain names are globally unique by design — only one organization owns `example.com`. So Java's convention is: take your organization's domain and **reverse the order of its dot-separated parts** to form your package prefix. - Domain `example.com` → package prefix `com.example` - Domain `oracle.com` → `com.oracle` - Domain `bbc.co.uk` → `uk.co.bbc` Why reversed? DNS reads from most-specific to least-specific (left to right: `mail.example.com` narrows down), while a package hierarchy reads from least-specific to most-specific (the broad `com` first, then `example`, then your projects). Reversing aligns the two so the most general grouping comes first, mirroring how the directory tree nests. After the domain prefix you append project and feature segments: ``` com.example.billing com.example.billing.invoice com.example.billing.payment ``` ## Style rules that go with it - **All lowercase.** Package names are conventionally lowercase to avoid clashes with class names (which are capitalized) and to dodge case-sensitivity differences between filesystems. - **No hyphens or other illegal identifier characters.** Each package segment must be a legal Java identifier. A domain like `my-startup.com` cannot become `com.my-startup` because `-` is illegal; replace it (e.g. `com.mystartup` or `com.my_startup`). - **Avoid reserved words.** If a domain segment is a Java keyword (e.g. a hypothetical `int.example.com`), you cannot use `int` as a package segment; the official guidance is to append an underscore (`int_`). - **Don't start a segment with a digit.** Identifiers can't begin with a digit; prefix an underscore if a domain part does (`com._3dgraphics`). ## Why it matters in practice When you depend on third-party libraries, their JARs are merged onto your classpath. If everyone used short names like `util` or `app`, two libraries with a `util.StringHelper` would collide and one would shadow the other unpredictably. Reverse-domain naming makes such collisions essentially impossible: `org.apache.commons.lang3` and `com.google.common` never overlap. ## Is it enforced? No — the compiler accepts any legal package name. Reverse-domain naming is a **strong convention**, not a language rule. But it is universally followed by published libraries, and build/publishing systems (like Maven Central) effectively require a reverse-domain *groupId* you control, reinforcing it. ## Summary Reverse the organization's unique internet domain to form a globally unique, collision-free package prefix; keep segments lowercase and legal-identifier-safe; append project/feature segments below it. The point is worldwide uniqueness borrowed from DNS.
- Your domain is `cool-app.io`. What's a valid package prefix?`io.coolapp` (drop the hyphen) or `io.cool_app` (replace with underscore). `io.cool-app` is invalid because `-` isn't a legal Java identifier character.
- Is reverse-domain naming required by the Java compiler?No. It's a strong, near-universal convention for uniqueness, but the compiler accepts any legal package name. Maven Central publishing, however, effectively requires a reverse-domain groupId you own.
saying these in an interview costs you the question
- Saying the compiler enforces reverse-domain naming
- Using hyphens or uppercase in package segments
- Thinking any short name like `util` or `app` is fine for shared libraries
- Forgetting why it's reversed (to put the broad grouping first, matching the directory nesting)