Package Naming and Folder Structure
Two companies might both write a class called Account. When your program uses libraries from both, Java needs a way to tell them apart. The convention is simple and global: start the package name with your organization's internet domain, reversed. Domain names are already unique worldwide, so package names built from them are unique too. The name then maps directly onto folders on disk.
Naming Rules and Conventions
| Rule | Example | Why |
|---|---|---|
| Reverse domain first | com.poolstring, in.gov.uidai, org.apache | Globally unique |
| Then the project, then the layer or feature | com.poolstring.bank.model | Groups related code |
| All lowercase | com.poolstring.bank, not com.PoolString.Bank | Avoids clashes with class names, and with case-insensitive file systems |
| Only letters, digits and underscores per part | com.my_site.app, not com.my-site.app | Each part must be a valid identifier |
| No Java keywords as parts | com.poolstring.newapi, not com.poolstring.new | new is a keyword |
Don't start with java. or javax. | Reserved for the platform |
Breaking the identifier rules is a compile error:
package com.my-site.app;
class Hy {}Hy.java:1: error: ';' expected
package com.my-site.app;
^
1 errorpackage com.poolstring.new.util;
class Kw {}Kw.java:1: error: <identifier> expected
package com.poolstring.new.util;
^
1 errorNames Map to Folders
Each dot-separated part is one folder. The source folder (src) is the root, and the output folder (out) mirrors the same tree:
bank/
├── src/
│ └── com/poolstring/bank/
│ ├── app/BankApp.java package com.poolstring.bank.app;
│ ├── model/Account.java package com.poolstring.bank.model;
│ └── service/TransferService.java package com.poolstring.bank.service;
└── out/
└── com/poolstring/bank/
├── app/BankApp.class
├── model/Account.class
└── service/TransferService.classBuild tools use a slightly longer standard layout: src/main/java for code, src/test/java for tests, and src/main/resources for other files. The package folders start inside those.
When the Folder Doesn't Match
If Account.java declares package com.poolstring.bank.model; but sits directly in src/, the compiler can't find it when another class imports it, because it looks in the folder the package name points to:
javac -d out -sourcepath src src/com/poolstring/bank/app/BankApp.javasrc/com/poolstring/bank/app/BankApp.java:3: error: package com.poolstring.bank.model does not exist
import com.poolstring.bank.model.Account;
^-sourcepath src tells javac to look up other source files by package. Moving Account.java into src/com/poolstring/bank/model/ fixes it. IDEs flag the mismatch as soon as you open the file.
Common Mistakes
Uppercase letters in package names. It compiles, but it breaks convention and can confuse case-insensitive file systems.
Hyphens from a domain name. Replace them with underscores: my-site.com becomes com.my_site.
Moving a file without changing its package line (or the other way round). Keep them in sync; IDE refactoring does both together.
Practice
- Easy: Write package names for a project called "library" at the domain
navika-books.in, with packages for books, members and loans. - Harder: Deliberately put
TransferService.javain the wrong folder, compileBankAppwith-sourcepath src, read the error, then fix it.
Key Takeaways
Was this tutorial helpful?