Packages and access modifiers

Why packages?

A real application has hundreds of classes. Packages organise them by area (billing, orders, users) and prevent name clashes: your com.shop.billing.Invoice and a library's org.pdf.Invoice can both exist. The package name usually starts with a reversed domain name the team owns (com.mycompany.app) and matches the folder structure.

// file: src/main/java/com/shop/billing/Invoice.java
package com.shop.billing;            // must be the first statement

import java.time.LocalDate;          // one class
import java.util.*;                  // every class in java.util (not sub-packages)
import com.shop.orders.Order;        // a class from another package of your app

public class Invoice {
    private final Order order;
    private final LocalDate date = LocalDate.now();
    public Invoice(Order order) { this.order = order; }
}

The fully qualified name of a class is its package plus its name: com.shop.billing.Invoice. You can always use that full name instead of importing (java.util.List<String> list). Classes in java.lang (String, Math, System, Integer) are imported automatically.

The four access levels

• Fields: almost always private.
• Methods: public if other packages need them; package-private for helpers used inside the package; private for internal steps.
• Classes: a top-level class is either public or package-private. Only one public top-level class per file.
• protected: for members that subclasses need; use sparingly, because subclasses in other packages then depend on them.

Static imports

import static java.lang.Math.max;
import static java.lang.Math.PI;
double r = max(2.5, 3.0) * PI;      // no Math. prefix

Modules in one sentence

Since Java 9, the Java Platform Module System (module-info.java) can group packages into modules with explicit exports; most application code and frameworks still work at the package level, so you can learn modules later.