A package in Java is a way of grouping related classes, interfaces, and sub-packages together. It serves the same purpose as a folder on your computer: it organizes files so you can find them, prevents naming conflicts, and controls who can access what.
Real-world analogy: Imagine a large hospital. The hospital has departments – Cardiology, Neurology, Emergency, Radiology. Each department has its own staff, equipment, and procedures. A nurse named “Sarah” might work in Cardiology, and another nurse named “Sarah” might work in Neurology. There is no confusion because the department acts as a namespace. You say “Sarah from Cardiology” or “Sarah from Neurology.” Java packages work the same way. You can have a User class in com.myapp.model and another User class in com.thirdparty.auth without any conflict.
Packages solve three fundamental problems:
Organization – As projects grow from 10 classes to 10,000 classes, packages keep the codebase navigable. Without them, you would have thousands of files in a single directory.
Namespace management – Two classes can have the same name as long as they live in different packages. The fully qualified name (java.util.Date vs java.sql.Date) eliminates ambiguity.
Access control – Java’s default (package-private) access modifier restricts visibility to classes within the same package. This lets you hide implementation details from the rest of the application.
Package Naming Convention
Java uses a reverse domain name convention for package names. If your company’s domain is example.com, your packages start with com.example. This guarantees global uniqueness – no two organizations will accidentally create the same package name.
// Reverse domain naming examples:
// Company domain: google.com -> com.google.gson, com.google.common.collect
// Company domain: apache.org -> org.apache.commons.lang3
// Company domain: springframework -> org.springframework.boot
// Personal project: myapp -> com.myapp.model, com.myapp.service
// A class inside a package
package com.myapp.model;
public class User {
private String name;
private String email;
public User(String name, String email) {
this.name = name;
this.email = email;
}
public String getName() { return name; }
public String getEmail() { return email; }
}
The package statement tells the compiler: “This class belongs to com.myapp.model.” Every other class in the project can now refer to it by its fully qualified name: com.myapp.model.User.
2. Built-in Java Packages
Java ships with hundreds of packages in the standard library (the Java API). You do not need to download or install anything extra – they are available the moment you install the JDK. Understanding the most common packages will make you significantly more productive.
java.lang – The Foundation (Auto-Imported)
The java.lang package is so fundamental that Java imports it automatically into every class. You never write import java.lang.String; – it is already there. This package contains the building blocks of every Java program:
String – Text representation
System – Standard I/O, environment, garbage collection
Math – Mathematical operations (abs, sqrt, pow, random)
Object – The root superclass of every Java class
Integer, Double, Boolean – Wrapper classes for primitives
// Examples of using built-in packages
// java.lang -- no import needed
String greeting = "Hello, Java!";
int absolute = Math.abs(-42); // 42
double squareRoot = Math.sqrt(144); // 12.0
System.out.println(greeting);
// java.util -- must import
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Scanner;
ArrayList names = new ArrayList<>();
names.add("Alice");
names.add("Bob");
HashMap scores = new HashMap<>();
scores.put("Alice", 95);
scores.put("Bob", 87);
Scanner scanner = new Scanner(System.in);
// java.io -- must import
import java.io.File;
import java.io.BufferedReader;
import java.io.FileReader;
File file = new File("data.txt");
boolean exists = file.exists();
// java.time -- must import (Java 8+)
import java.time.LocalDate;
import java.time.LocalDateTime;
LocalDate today = LocalDate.now();
LocalDateTime now = LocalDateTime.now();
A key takeaway: every class in Java belongs to a package. When you write a class without a package statement, it goes into the default package (unnamed package). This is acceptable for quick experiments but should never be used in production code because classes in the default package cannot be imported by classes in named packages.
3. Creating Packages
Creating your own package involves two steps: declaring the package in your source file and organizing the file into the correct directory structure. These two must match exactly – if they do not, the compiler will refuse to compile your code.
The package Statement
The package statement must be the very first line of your Java source file (before any imports, class declarations, or comments, with the exception of regular comments). There can be only one package statement per file.
// File: com/myapp/models/User.java
package com.myapp.models; // MUST be the first statement
import java.time.LocalDate; // imports come after the package statement
public class User {
private String name;
private String email;
private LocalDate createdAt;
public User(String name, String email) {
this.name = name;
this.email = email;
this.createdAt = LocalDate.now();
}
public String getName() { return name; }
public String getEmail() { return email; }
public LocalDate getCreatedAt() { return createdAt; }
@Override
public String toString() {
return "User{name='" + name + "', email='" + email + "', createdAt=" + createdAt + "}";
}
}
Directory Structure Must Match
This is the most critical rule about packages: the directory structure on disk must exactly mirror the package declaration. Each dot in the package name represents a directory separator.
If your package is com.myapp.models, the file must be located at:
When you compile and run classes that belong to packages, you need to be aware of the source root. The compiler and JVM use the package name to locate files.
// Compiling from the project root (src/ directory):
// Step 1: Compile the User class
// Command: javac com/myapp/models/User.java
// Step 2: Compile Main that uses User
// Command: javac com/myapp/app/Main.java
// Step 3: Run the Main class using its fully qualified name
// Command: java com.myapp.app.Main
// NOTE: Use dots (not slashes) and do NOT include .class extension
// Compile all files at once:
// Command: javac com/myapp/models/*.java com/myapp/services/*.java com/myapp/app/Main.java
// Or compile everything recursively (Java 9+):
// Command: javac $(find . -name "*.java")
Note: Modern IDEs like IntelliJ IDEA and Eclipse handle directory creation and compilation automatically. When you declare a package in a new file, the IDE creates the matching folder structure for you. However, understanding the underlying mechanism is essential for debugging classpath issues and working with build tools like Maven and Gradle.
4. Importing Packages
When you want to use a class from another package, you have two options: use the fully qualified name every time, or import it once and use the short name everywhere. Import statements appear after the package declaration and before the class declaration.
Single Class Import
The most common and recommended approach is importing the exact class you need:
package com.myapp.app;
// Single class imports -- explicit and clear
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Map;
import com.myapp.models.User;
import com.myapp.services.UserService;
public class Main {
public static void main(String[] args) {
// No need to write java.util.ArrayList -- just ArrayList
ArrayList users = new ArrayList<>();
Map userMap = new HashMap<>();
UserService service = new UserService();
}
}
Wildcard Import
The wildcard * imports all classes from a package. It does not import sub-packages – only classes directly in that package.
package com.myapp.app;
// Wildcard import -- imports ALL classes from java.util
import java.util.*;
import com.myapp.models.*;
public class Main {
public static void main(String[] args) {
// All of these work because we imported java.util.*
ArrayList list = new ArrayList<>();
HashMap map = new HashMap<>();
HashSet set = new HashSet<>();
Scanner scanner = new Scanner(System.in);
// This works because we imported com.myapp.models.*
User user = new User("Alice", "alice@example.com");
}
}
// IMPORTANT: Wildcard does NOT import sub-packages!
import java.util.*; // imports ArrayList, HashMap, etc.
// does NOT import java.util.stream.Stream
// does NOT import java.util.concurrent.ExecutorService
// You would need separate imports for sub-packages:
import java.util.stream.*;
import java.util.concurrent.*;
Why Wildcard Imports Are Discouraged in Production
While wildcard imports save typing, they are generally discouraged in professional codebases for several reasons:
Ambiguity – If you import java.util.* and java.sql.*, and then use Date, the compiler cannot tell whether you mean java.util.Date or java.sql.Date. You get a compilation error.
Readability – Explicit imports tell the reader exactly which classes are used. A new developer can glance at the imports and immediately understand the dependencies.
Future conflicts – A new version of a library might add a class whose name conflicts with one of your other imports.
// Ambiguity problem with wildcard imports:
import java.util.*; // contains java.util.Date
import java.sql.*; // contains java.sql.Date
public class DateProblem {
public static void main(String[] args) {
// COMPILE ERROR: reference to Date is ambiguous
// Date date = new Date();
// Solution 1: Use fully qualified name
java.util.Date utilDate = new java.util.Date();
java.sql.Date sqlDate = new java.sql.Date(System.currentTimeMillis());
// Solution 2: Import one explicitly, qualify the other
// At top of file: import java.util.Date;
// Then: Date utilDate = new Date();
// And: java.sql.Date sqlDate = new java.sql.Date(...);
}
}
Static Imports
Static imports let you use static methods and constants from another class without qualifying them with the class name. This is useful for utility methods you call frequently, but overuse can make code confusing.
// Without static import
public class CircleCalc {
public double area(double radius) {
return Math.PI * Math.pow(radius, 2);
}
public double hypotenuse(double a, double b) {
return Math.sqrt(Math.pow(a, 2) + Math.pow(b, 2));
}
}
// With static import -- cleaner for math-heavy code
import static java.lang.Math.PI;
import static java.lang.Math.pow;
import static java.lang.Math.sqrt;
public class CircleCalc {
public double area(double radius) {
return PI * pow(radius, 2);
}
public double hypotenuse(double a, double b) {
return sqrt(pow(a, 2) + pow(b, 2));
}
}
// Static wildcard import -- imports ALL static members
import static java.lang.Math.*;
public class MathDemo {
public static void main(String[] args) {
System.out.println("PI = " + PI); // 3.141592653589793
System.out.println("sqrt(16) = " + sqrt(16)); // 4.0
System.out.println("abs(-7) = " + abs(-7)); // 7
System.out.println("max(10, 20) = " + max(10, 20)); // 20
System.out.println("random() = " + random()); // e.g., 0.7234...
}
}
// Common static imports in testing (JUnit 5)
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;
Fully Qualified Name (No Import)
You can always skip the import and use the full package + class name. This is common when you have a naming conflict or use a class only once:
public class FullyQualifiedExample {
public static void main(String[] args) {
// Using fully qualified names -- no import statement needed
java.util.ArrayList names = new java.util.ArrayList<>();
names.add("Alice");
java.time.LocalDate today = java.time.LocalDate.now();
System.out.println("Today: " + today);
// This is verbose, but sometimes necessary to resolve conflicts
java.util.Date utilDate = new java.util.Date();
java.sql.Date sqlDate = new java.sql.Date(utilDate.getTime());
}
}
Import Summary
Import Style
Syntax
Use When
Single class
import java.util.ArrayList;
Default choice. Explicit and clear.
Wildcard
import java.util.*;
Quick prototyping. Avoid in production code.
Static single
import static java.lang.Math.PI;
Frequently used constants or assertions.
Static wildcard
import static java.lang.Math.*;
Math-heavy code. Use sparingly.
Fully qualified
java.util.Date d = new java.util.Date();
Resolving name conflicts. One-time use.
5. Access Control with Packages
Packages are deeply connected to Java’s access control system. The default access modifier (also called package-private) relies entirely on packages to determine visibility. When you declare a field, method, or class without any access modifier, it is visible only to other classes in the same package.
This is an intentional design decision. It lets you create helper classes and internal APIs that are visible within a module (package) but hidden from the rest of the application. Think of it as the “internal affairs” of a department – other departments do not see your internal memos.
Visibility Table
Modifier
Same Class
Same Package
Subclass (Different Package)
Any Class (Different Package)
public
Yes
Yes
Yes
Yes
protected
Yes
Yes
Yes
No
default (no modifier)
Yes
Yes
No
No
private
Yes
No
No
No
// === File: com/myapp/models/User.java ===
package com.myapp.models;
public class User {
public String name; // visible everywhere
protected String email; // visible in same package + subclasses
String nickname; // package-private: visible ONLY in com.myapp.models
private String passwordHash; // visible ONLY within this User class
public User(String name, String email, String nickname, String passwordHash) {
this.name = name;
this.email = email;
this.nickname = nickname;
this.passwordHash = passwordHash;
}
// Package-private method -- only classes in com.myapp.models can call this
String getPasswordHash() {
return passwordHash;
}
// Public method -- anyone can call this
public String getDisplayName() {
return name + " (" + nickname + ")";
}
}
// === File: com/myapp/models/UserValidator.java ===
package com.myapp.models; // SAME package
public class UserValidator {
public boolean isValid(User user) {
// CAN access public field
System.out.println(user.name); // OK
// CAN access protected field (same package)
System.out.println(user.email); // OK
// CAN access package-private field (same package)
System.out.println(user.nickname); // OK
// CANNOT access private field
// System.out.println(user.passwordHash); // COMPILE ERROR
// CAN access package-private method (same package)
String hash = user.getPasswordHash(); // OK
return hash != null && !hash.isEmpty();
}
}
// === File: com/myapp/services/UserService.java ===
package com.myapp.services; // DIFFERENT package
import com.myapp.models.User;
public class UserService {
public void processUser(User user) {
// CAN access public field
System.out.println(user.name); // OK
// CANNOT access protected field (different package, not a subclass)
// System.out.println(user.email); // COMPILE ERROR
// CANNOT access package-private field (different package)
// System.out.println(user.nickname); // COMPILE ERROR
// CANNOT access private field
// System.out.println(user.passwordHash); // COMPILE ERROR
// CANNOT access package-private method (different package)
// user.getPasswordHash(); // COMPILE ERROR
// CAN access public method
System.out.println(user.getDisplayName()); // OK
}
}
Protected Access and Inheritance Across Packages
The protected modifier has a nuanced behavior. Within the same package, it behaves like package-private (any class can access it). Across packages, only subclasses can access it, and only through inheritance (not through an instance reference).
// === File: com/myapp/models/User.java ===
package com.myapp.models;
public class User {
protected String email;
public User(String email) {
this.email = email;
}
}
// === File: com/myapp/services/AdminUser.java ===
package com.myapp.services; // different package
import com.myapp.models.User;
public class AdminUser extends User {
public AdminUser(String email) {
super(email);
}
public void showEmail() {
// CAN access protected field through inheritance
System.out.println(this.email); // OK -- accessing through 'this'
}
public void showOtherEmail(User other) {
// CANNOT access protected field through an instance of the parent class
// System.out.println(other.email); // COMPILE ERROR
}
}
// Output:
// The protected field 'email' is accessible via this.email (inheritance),
// but NOT via other.email (instance reference from a different package).
Package-Private Classes
Even entire classes can be package-private. This is common for internal helper classes that should not be used outside the package:
// === File: com/myapp/models/PasswordEncoder.java ===
package com.myapp.models;
// No 'public' keyword -- this class is package-private
class PasswordEncoder {
static String encode(String rawPassword) {
// Simple hash for demonstration (use BCrypt in production!)
return Integer.toHexString(rawPassword.hashCode());
}
static boolean matches(String rawPassword, String encodedPassword) {
return encode(rawPassword).equals(encodedPassword);
}
}
// === File: com/myapp/models/User.java ===
package com.myapp.models;
public class User {
private String name;
private String passwordHash;
public User(String name, String rawPassword) {
this.name = name;
// Can use PasswordEncoder because it is in the same package
this.passwordHash = PasswordEncoder.encode(rawPassword);
}
public boolean checkPassword(String rawPassword) {
return PasswordEncoder.matches(rawPassword, this.passwordHash);
}
}
// === File: com/myapp/services/UserService.java ===
package com.myapp.services;
import com.myapp.models.User;
// import com.myapp.models.PasswordEncoder; // COMPILE ERROR -- not visible!
public class UserService {
public void createUser(String name, String password) {
User user = new User(name, password); // OK -- User is public
// PasswordEncoder.encode(password); // COMPILE ERROR -- not accessible
}
}
This pattern is powerful. The User class uses PasswordEncoder internally, but no class outside the com.myapp.models package can even see that PasswordEncoder exists. The implementation detail is completely hidden.
6. Package Naming Conventions
Java has well-established conventions for naming packages. Following them is not optional in professional projects – it is expected. Consistent naming makes code predictable and avoids collisions with third-party libraries.
Rules
All lowercase – Package names are always written in lowercase letters. No camelCase, no UPPER_CASE.
Reverse domain name – Start with your organization’s reversed internet domain name: com.google, org.apache, io.github.username.
No hyphens – Use underscores if your domain contains hyphens: my-company.com becomes com.my_company.
No starting with digits – If a domain component starts with a digit (e.g., 123data.com), prefix it with an underscore: com._123data.
No Java keywords – If a domain component is a Java keyword (e.g., switch.io), prefix it with an underscore: io._switch.
Singular nouns preferred – Use com.myapp.model rather than com.myapp.models (though both are seen in practice).
// GOOD -- follows conventions
package com.lovemesomecoding.tutorial;
package com.myapp.user.service;
package org.opensource.util;
package io.github.myusername.calculator;
// BAD -- violates conventions
package Com.MyApp.Models; // uppercase letters
package my-app.models; // hyphens not allowed
package 123data.processor; // starts with digit
package com.myapp.Class; // uppercase, and 'Class' is ambiguous
package stuff; // vague name, no domain prefix
7. Sub-packages
A sub-package is a package that lives inside another package in the directory hierarchy. For example, java.util.stream is a sub-package of java.util, and java.util.concurrent.locks is a sub-package of java.util.concurrent.
However, there is a crucial concept to understand: sub-packages have NO special relationship with their parent package in terms of access control. A sub-package is treated as a completely independent package. Classes in java.util cannot see package-private members of classes in java.util.stream, and vice versa.
This is a common misconception. Many beginners assume that because com.myapp.model.dto is “inside” com.myapp.model, it inherits the package-private access of com.myapp.model. It does not. They are separate packages.
// === File: com/myapp/model/User.java ===
package com.myapp.model;
public class User {
String internalId; // package-private -- only visible in com.myapp.model
public String name;
public User(String name) {
this.internalId = "USR-" + System.nanoTime();
this.name = name;
}
}
// === File: com/myapp/model/UserRepository.java ===
package com.myapp.model; // SAME package as User
public class UserRepository {
public void save(User user) {
// CAN access package-private field -- same package
System.out.println("Saving user with internal ID: " + user.internalId); // OK
}
}
// === File: com/myapp/model/dto/UserDTO.java ===
package com.myapp.model.dto; // SUB-PACKAGE -- treated as a DIFFERENT package
import com.myapp.model.User;
public class UserDTO {
public String name;
public static UserDTO fromUser(User user) {
UserDTO dto = new UserDTO();
dto.name = user.name; // OK -- public field
// CANNOT access package-private field from sub-package!
// dto.id = user.internalId; // COMPILE ERROR
return dto;
}
}
Importing Sub-packages
Importing a parent package does not automatically import its sub-packages. Each must be imported individually:
// Importing parent does NOT import sub-packages
import java.util.*; // imports ArrayList, HashMap, etc.
// does NOT import Stream, Collectors, etc.
// You must import sub-packages separately
import java.util.stream.*; // Stream, Collectors
import java.util.concurrent.*; // ExecutorService, Future
import java.util.concurrent.locks.*; // Lock, ReentrantLock
// Similarly for your own packages:
import com.myapp.model.*; // imports User, Order
// does NOT import UserDTO from com.myapp.model.dto
import com.myapp.model.dto.*; // imports UserDTO, OrderDTO
8. Creating a Multi-Package Project
Now let us build a complete multi-package project from scratch. This is a Student Management System with four packages, each with a clear responsibility. This example demonstrates how classes interact across packages, when to use public vs. package-private, and how imports work in practice.
Project Structure
// Project directory structure:
//
// src/
// com/
// school/
// model/
// Student.java -- data class
// Course.java -- data class
// Enrollment.java -- package-private helper
// service/
// StudentService.java -- business logic
// CourseService.java -- business logic
// util/
// Validator.java -- validation utilities
// IdGenerator.java -- package-private utility
// app/
// Main.java -- entry point
Package 1: com.school.model
The model package contains the data classes. Notice that Enrollment is package-private – it is an implementation detail of the model package.
// === File: com/school/model/Student.java ===
package com.school.model;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
public class Student {
private final String id;
private String name;
private String email;
private final List enrollments; // uses package-private Enrollment
public Student(String id, String name, String email) {
this.id = id;
this.name = name;
this.email = email;
this.enrollments = new ArrayList<>();
}
public String getId() { return id; }
public String getName() { return name; }
public String getEmail() { return email; }
public void setName(String name) { this.name = name; }
public void setEmail(String email) { this.email = email; }
// Package-private -- only model classes can call this
void addEnrollment(Enrollment enrollment) {
this.enrollments.add(enrollment);
}
// Public -- returns an unmodifiable view of course names
public List getEnrolledCourseNames() {
List names = new ArrayList<>();
for (Enrollment e : enrollments) {
names.add(e.getCourseName());
}
return Collections.unmodifiableList(names);
}
public int getEnrollmentCount() {
return enrollments.size();
}
@Override
public String toString() {
return "Student{id='" + id + "', name='" + name + "', courses=" + getEnrolledCourseNames() + "}";
}
}
// === File: com/school/model/Course.java ===
package com.school.model;
public class Course {
private final String code;
private String title;
private int maxCapacity;
private int currentEnrollment;
public Course(String code, String title, int maxCapacity) {
this.code = code;
this.title = title;
this.maxCapacity = maxCapacity;
this.currentEnrollment = 0;
}
public String getCode() { return code; }
public String getTitle() { return title; }
public int getMaxCapacity() { return maxCapacity; }
public int getCurrentEnrollment() { return currentEnrollment; }
public boolean hasAvailableSeats() {
return currentEnrollment < maxCapacity;
}
// Package-private -- only model classes can increment enrollment
void incrementEnrollment() {
currentEnrollment++;
}
@Override
public String toString() {
return "Course{code='" + code + "', title='" + title +
"', enrolled=" + currentEnrollment + "/" + maxCapacity + "}";
}
}
// === File: com/school/model/Enrollment.java ===
package com.school.model;
import java.time.LocalDate;
// Package-private class -- NOT visible outside com.school.model
// This is an implementation detail. Other packages interact with
// Student and Course directly, never with Enrollment.
class Enrollment {
private final String studentId;
private final String courseCode;
private final String courseName;
private final LocalDate enrollDate;
Enrollment(String studentId, String courseCode, String courseName) {
this.studentId = studentId;
this.courseCode = courseCode;
this.courseName = courseName;
this.enrollDate = LocalDate.now();
}
String getStudentId() { return studentId; }
String getCourseCode() { return courseCode; }
String getCourseName() { return courseName; }
LocalDate getEnrollDate() { return enrollDate; }
// Static factory method used by Student and Course within this package
static void enroll(Student student, Course course) {
if (!course.hasAvailableSeats()) {
throw new IllegalStateException("Course " + course.getCode() + " is full");
}
Enrollment enrollment = new Enrollment(student.getId(), course.getCode(), course.getTitle());
student.addEnrollment(enrollment);
course.incrementEnrollment();
}
}
Package 2: com.school.util
The utility package contains shared helper classes. IdGenerator is package-private because only Validator uses it internally.
// === File: com/school/util/Validator.java ===
package com.school.util;
public class Validator {
public static boolean isValidEmail(String email) {
if (email == null || email.isBlank()) return false;
return email.matches("^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+$");
}
public static boolean isValidName(String name) {
if (name == null || name.isBlank()) return false;
return name.length() >= 2 && name.length() <= 100;
}
public static boolean isValidCourseCode(String code) {
if (code == null || code.isBlank()) return false;
// Course codes must be like "CS101", "MATH200"
return code.matches("^[A-Z]{2,5}\\d{3}$");
}
public static String generateStudentId() {
return IdGenerator.generate("STU");
}
public static String generateCourseId() {
return IdGenerator.generate("CRS");
}
}
// === File: com/school/util/IdGenerator.java ===
package com.school.util;
import java.util.concurrent.atomic.AtomicLong;
// Package-private -- only Validator exposes the ID generation functionality
class IdGenerator {
private static final AtomicLong counter = new AtomicLong(1000);
static String generate(String prefix) {
return prefix + "-" + counter.incrementAndGet();
}
}
Package 3: com.school.service
The service package contains business logic. It depends on the model and util packages but not the other way around. This is a clean, one-way dependency.
// === File: com/school/service/StudentService.java ===
package com.school.service;
import com.school.model.Student;
import com.school.model.Course;
import com.school.util.Validator;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class StudentService {
private final Map students = new HashMap<>();
public Student createStudent(String name, String email) {
// Use Validator from the util package
if (!Validator.isValidName(name)) {
throw new IllegalArgumentException("Invalid name: " + name);
}
if (!Validator.isValidEmail(email)) {
throw new IllegalArgumentException("Invalid email: " + email);
}
String id = Validator.generateStudentId();
Student student = new Student(id, name, email);
students.put(id, student);
return student;
}
public Student findById(String id) {
Student student = students.get(id);
if (student == null) {
throw new IllegalArgumentException("Student not found: " + id);
}
return student;
}
public List findAll() {
return new ArrayList<>(students.values());
}
// Notice: we cannot access Enrollment directly because it is package-private
// in com.school.model. We cannot do "new Enrollment(...)" here.
// We must use public methods on Student and Course instead.
}
// === File: com/school/service/CourseService.java ===
package com.school.service;
import com.school.model.Course;
import com.school.model.Student;
import com.school.util.Validator;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class CourseService {
private final Map courses = new HashMap<>();
public Course createCourse(String code, String title, int capacity) {
if (!Validator.isValidCourseCode(code)) {
throw new IllegalArgumentException("Invalid course code: " + code +
". Must be 2-5 uppercase letters followed by 3 digits (e.g., CS101).");
}
if (courses.containsKey(code)) {
throw new IllegalArgumentException("Course already exists: " + code);
}
Course course = new Course(code, title, capacity);
courses.put(code, course);
return course;
}
public Course findByCode(String code) {
Course course = courses.get(code);
if (course == null) {
throw new IllegalArgumentException("Course not found: " + code);
}
return course;
}
public List findAll() {
return new ArrayList<>(courses.values());
}
public List findAvailable() {
List available = new ArrayList<>();
for (Course course : courses.values()) {
if (course.hasAvailableSeats()) {
available.add(course);
}
}
return available;
}
}
Package 4: com.school.app
The application package contains the entry point. It depends on service and model packages. It orchestrates the entire application.
// === File: com/school/app/Main.java ===
package com.school.app;
import com.school.model.Student;
import com.school.model.Course;
import com.school.service.StudentService;
import com.school.service.CourseService;
// import com.school.model.Enrollment; // COMPILE ERROR -- Enrollment is package-private!
// import com.school.util.IdGenerator; // COMPILE ERROR -- IdGenerator is package-private!
public class Main {
public static void main(String[] args) {
StudentService studentService = new StudentService();
CourseService courseService = new CourseService();
// Create courses
Course java = courseService.createCourse("CS101", "Introduction to Java", 30);
Course python = courseService.createCourse("CS102", "Python Programming", 25);
Course database = courseService.createCourse("CS201", "Database Design", 20);
System.out.println("--- Courses Created ---");
for (Course course : courseService.findAll()) {
System.out.println(" " + course);
}
// Create students
Student alice = studentService.createStudent("Alice Johnson", "alice@university.edu");
Student bob = studentService.createStudent("Bob Smith", "bob@university.edu");
System.out.println("\n--- Students Created ---");
for (Student student : studentService.findAll()) {
System.out.println(" " + student);
}
// Show available courses
System.out.println("\n--- Available Courses ---");
for (Course course : courseService.findAvailable()) {
System.out.println(" " + course.getCode() + ": " + course.getTitle() +
" (" + (course.getMaxCapacity() - course.getCurrentEnrollment()) + " seats left)");
}
System.out.println("\n--- Package Visibility Demo ---");
System.out.println("We can access Student.getName(): " + alice.getName());
System.out.println("We can access Course.getTitle(): " + java.getTitle());
System.out.println("We CANNOT access Enrollment -- it is package-private in com.school.model");
System.out.println("We CANNOT access IdGenerator -- it is package-private in com.school.util");
}
}
// Output:
// --- Courses Created ---
// Course{code='CS101', title='Introduction to Java', enrolled=0/30}
// Course{code='CS102', title='Python Programming', enrolled=0/25}
// Course{code='CS201', title='Database Design', enrolled=0/20}
//
// --- Students Created ---
// Student{id='STU-1001', name='Alice Johnson', courses=[]}
// Student{id='STU-1002', name='Bob Smith', courses=[]}
//
// --- Available Courses ---
// CS101: Introduction to Java (30 seats left)
// CS102: Python Programming (25 seats left)
// CS201: Database Design (20 seats left)
//
// --- Package Visibility Demo ---
// We can access Student.getName(): Alice Johnson
// We can access Course.getTitle(): Introduction to Java
// We CANNOT access Enrollment -- it is package-private in com.school.model
// We CANNOT access IdGenerator -- it is package-private in com.school.util
Dependency Flow
Notice how the dependencies flow in one direction:
com.school.app depends on com.school.service and com.school.model
com.school.service depends on com.school.model and com.school.util
com.school.model depends on nothing (it is self-contained)
com.school.util depends on nothing (it is self-contained)
This is the hallmark of a well-designed package structure: dependencies flow from higher-level packages (app, service) to lower-level packages (model, util), never in reverse. The model and util packages know nothing about services or the application layer.
9. Common Mistakes
These are mistakes that every Java developer makes at least once. Understanding them saves hours of debugging.
Mistake 1: Package Name Does Not Match Directory Structure
The package declaration and the directory path must be identical. If they are not, the compiler will reject the file or you will get ClassNotFoundException at runtime.
// File is located at: src/com/myapp/model/User.java
// WRONG -- package does not match directory
package com.myapp.models; // says "models" but directory is "model"
// Compiler error: package com.myapp.models does not match directory structure
// CORRECT
package com.myapp.model; // matches the directory exactly
// WRONG -- using wrong separator
package com/myapp/model; // slashes instead of dots -- syntax error
package com.myapp.Model; // capital M does not match lowercase directory
// CORRECT
package com.myapp.model;
Mistake 2: Forgetting the Package Statement
// File: src/com/myapp/model/User.java
// WRONG -- missing package statement
// The file is in com/myapp/model/ but has no package declaration
public class User {
// This class is in the DEFAULT (unnamed) package
// Other packaged classes CANNOT import it!
}
// CORRECT
package com.myapp.model;
public class User {
// Now properly belongs to com.myapp.model
}
Mistake 3: Circular Dependencies
Circular dependencies occur when package A depends on package B and package B depends on package A. While Java does not prevent this, it creates tightly coupled, hard-to-maintain code.
// BAD -- Circular dependency between service and model
// === File: com/myapp/model/User.java ===
package com.myapp.model;
import com.myapp.service.UserService; // model depends on service
public class User {
private String name;
public void save() {
UserService service = new UserService();
service.save(this); // model calling service -- BAD design
}
}
// === File: com/myapp/service/UserService.java ===
package com.myapp.service;
import com.myapp.model.User; // service depends on model
public class UserService {
public void save(User user) {
System.out.println("Saving " + user);
}
}
// The dependency is circular: model -> service -> model
// This is a design smell. The model should NOT know about the service.
// GOOD -- One-way dependency: service depends on model, model depends on nothing
// === File: com/myapp/model/User.java ===
package com.myapp.model;
public class User {
private String name;
public User(String name) { this.name = name; }
public String getName() { return name; }
}
// === File: com/myapp/service/UserService.java ===
package com.myapp.service;
import com.myapp.model.User; // one-way dependency
public class UserService {
public void save(User user) {
System.out.println("Saving " + user.getName());
}
}
Mistake 4: Wildcard Import Conflicts
// Problem: Both packages have a class named "List"
import java.util.*; // contains java.util.List
import java.awt.*; // contains java.awt.List
public class ImportConflict {
public static void main(String[] args) {
// COMPILE ERROR: reference to List is ambiguous
// List myList = new ArrayList();
// Fix: Use explicit import for the one you want
// Or use fully qualified name:
java.util.List myList = new java.util.ArrayList<>();
}
}
Mistake 5: Assuming Sub-package Access
// === File: com/myapp/model/User.java ===
package com.myapp.model;
public class User {
String internalCode = "ABC"; // package-private
}
// === File: com/myapp/model/dto/UserDTO.java ===
package com.myapp.model.dto; // this is a DIFFERENT package
import com.myapp.model.User;
public class UserDTO {
public static void main(String[] args) {
User user = new User();
// COMPILE ERROR: internalCode is not visible
// Many developers expect this to work because dto is "inside" model
// System.out.println(user.internalCode);
// Sub-packages are completely separate packages in Java!
}
}
Mistake 6: Using the Default Package in Production
// File: User.java (no package declaration -- sits in default package)
// No package statement -- this class is in the unnamed "default" package
public class User {
private String name;
}
// Problem 1: Classes in named packages CANNOT import from the default package
// === File: com/myapp/service/UserService.java ===
package com.myapp.service;
// import User; // COMPILE ERROR -- cannot import from default package
// Problem 2: Default package classes cannot be referenced by fully qualified name
// because they have no package name
// Rule: ALWAYS use a package statement in every class. The default package
// should only be used for throwaway experiments or learning exercises.
10. Best Practices
Here are the practices that experienced Java developers follow for package organization. These are not just rules from a textbook – they come from years of maintaining large-scale applications.
1. Prefer Feature-Based Over Layer-Based Organization
As projects grow, organizing by feature is usually more maintainable than organizing by layer. With feature-based packages, all related classes are together, making it easy to find, modify, and delete features without hunting across multiple package trees.
// LAYER-BASED (common but can become unwieldy at scale)
com.myapp.controller/
UserController.java
OrderController.java
ProductController.java
com.myapp.service/
UserService.java
OrderService.java
ProductService.java
com.myapp.repository/
UserRepository.java
OrderRepository.java
ProductRepository.java
// Adding a new feature (e.g., "Notification") requires changes to 3+ packages.
// Deleting a feature means removing files from multiple packages.
// FEATURE-BASED (better for larger projects)
com.myapp.user/
UserController.java
UserService.java
UserRepository.java
User.java
com.myapp.order/
OrderController.java
OrderService.java
OrderRepository.java
Order.java
com.myapp.product/
ProductController.java
ProductService.java
ProductRepository.java
Product.java
// Adding or removing a feature = adding or removing one package.
// Everything related to "user" is in one place.
2. Use Package-Private as the Default
Make everything package-private by default, and only promote to public when another package actually needs it. This minimizes your public API surface and gives you freedom to change internal implementation without breaking other packages.
3. Avoid Circular Dependencies
If package A imports from package B and package B imports from package A, you have a circular dependency. Resolve it by introducing a third package for shared types, or by using interfaces to break the cycle.
4. Keep Package Count Manageable
Having 50 packages with 1-2 classes each is just as bad as having 1 package with 200 classes. Aim for a sweet spot where each package contains 5-15 related classes. If a package grows larger than 20 classes, consider splitting it. If it has fewer than 3 classes, consider merging it with a related package.
5. Follow the Naming Conventions Strictly
Always use lowercase, always use reverse domain, and never use special characters. Consistency across the team and across the industry makes code universally readable.
6. Summary Table
Practice
Do
Do Not
Package naming
com.mycompany.project.feature
MyPackage, stuff, misc
Default access
Make classes/methods package-private by default
Make everything public "just in case"
Import style
Single class imports: import java.util.ArrayList;
Wildcard imports in production: import java.util.*;
Dependencies
One-way: app -> service -> model
Circular: model -> service -> model
Package size
5-15 closely related classes per package
1 class per package or 100+ classes per package
Organization
Feature-based for large projects, layer-based for small
Random grouping with no logical structure
Default package
Always declare a package
Leave classes in the unnamed default package
Sub-packages
Use when logical hierarchy exists
Assume sub-packages inherit parent access
11. Complete Practical Example: Online Bookstore
Let us build a complete, multi-package Online Bookstore application that demonstrates every concept covered in this tutorial. This example has four packages with deliberate access control decisions, proper imports, and clean one-way dependencies.
Project Structure
// Project structure:
//
// src/
// com/
// bookstore/
// model/
// Book.java -- public data class
// Customer.java -- public data class
// Order.java -- public data class
// OrderItem.java -- package-private (internal to model)
// PriceCalculator.java -- package-private (internal to model)
// service/
// BookService.java -- public service
// OrderService.java -- public service
// util/
// Formatter.java -- public utility
// app/
// BookstoreApp.java -- main entry point
com.bookstore.model - Data Classes
// === File: com/bookstore/model/Book.java ===
package com.bookstore.model;
public class Book {
private final String isbn;
private String title;
private String author;
private double price;
private int stock;
public Book(String isbn, String title, String author, double price, int stock) {
this.isbn = isbn;
this.title = title;
this.author = author;
this.price = price;
this.stock = stock;
}
public String getIsbn() { return isbn; }
public String getTitle() { return title; }
public String getAuthor() { return author; }
public double getPrice() { return price; }
public int getStock() { return stock; }
// Package-private -- only model classes can modify stock
void decreaseStock(int quantity) {
if (quantity > stock) {
throw new IllegalStateException("Insufficient stock for '" + title +
"'. Available: " + stock + ", Requested: " + quantity);
}
this.stock -= quantity;
}
public boolean isInStock() {
return stock > 0;
}
@Override
public String toString() {
return "Book{isbn='" + isbn + "', title='" + title + "', author='" + author +
"', price=$" + String.format("%.2f", price) + ", stock=" + stock + "}";
}
}
// === File: com/bookstore/model/Customer.java ===
package com.bookstore.model;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
public class Customer {
private final String id;
private String name;
private String email;
private final List orderHistory;
public Customer(String id, String name, String email) {
this.id = id;
this.name = name;
this.email = email;
this.orderHistory = new ArrayList<>();
}
public String getId() { return id; }
public String getName() { return name; }
public String getEmail() { return email; }
public List getOrderHistory() {
return Collections.unmodifiableList(orderHistory);
}
// Package-private -- only model classes (Order) can add to history
void addOrder(Order order) {
orderHistory.add(order);
}
public int getTotalOrders() {
return orderHistory.size();
}
@Override
public String toString() {
return "Customer{id='" + id + "', name='" + name + "', orders=" + orderHistory.size() + "}";
}
}
// === File: com/bookstore/model/OrderItem.java ===
package com.bookstore.model;
// Package-private class -- an implementation detail of Order
// The service layer works with Order, never with OrderItem directly
class OrderItem {
private final Book book;
private final int quantity;
private final double unitPrice;
OrderItem(Book book, int quantity) {
this.book = book;
this.quantity = quantity;
this.unitPrice = book.getPrice();
}
Book getBook() { return book; }
int getQuantity() { return quantity; }
double getUnitPrice() { return unitPrice; }
double getSubtotal() {
return unitPrice * quantity;
}
@Override
public String toString() {
return quantity + "x " + book.getTitle() + " @ $" + String.format("%.2f", unitPrice);
}
}
// === File: com/bookstore/model/Order.java ===
package com.bookstore.model;
import java.time.LocalDateTime;
import java.util.ArrayList;
import java.util.List;
public class Order {
private static int orderCounter = 0;
private final String orderId;
private final Customer customer;
private final List items; // uses package-private OrderItem
private final LocalDateTime orderDate;
private final double subtotal;
private final double discount;
private final double tax;
private final double total;
// Package-private constructor -- only OrderBuilder or service can create orders
Order(Customer customer, List items) {
this.orderId = "ORD-" + (++orderCounter);
this.customer = customer;
this.items = new ArrayList<>(items);
this.orderDate = LocalDateTime.now();
// Use package-private PriceCalculator
this.subtotal = PriceCalculator.calculateSubtotal(items);
this.discount = PriceCalculator.calculateDiscount(items);
double afterDiscount = subtotal - discount;
this.tax = PriceCalculator.calculateTax(afterDiscount);
this.total = PriceCalculator.calculateTotal(items);
// Decrease stock for each book
for (OrderItem item : items) {
item.getBook().decreaseStock(item.getQuantity());
}
// Add this order to the customer's history
customer.addOrder(this);
}
public String getOrderId() { return orderId; }
public String getCustomerName() { return customer.getName(); }
public LocalDateTime getOrderDate() { return orderDate; }
public double getSubtotal() { return subtotal; }
public double getDiscount() { return discount; }
public double getTax() { return tax; }
public double getTotal() { return total; }
public int getItemCount() { return items.size(); }
// Public method that exposes item info without exposing OrderItem class
public List getItemDescriptions() {
List descriptions = new ArrayList<>();
for (OrderItem item : items) {
descriptions.add(item.toString());
}
return descriptions;
}
@Override
public String toString() {
StringBuilder sb = new StringBuilder();
sb.append("Order ").append(orderId).append(" for ").append(customer.getName()).append("\n");
sb.append(" Date: ").append(orderDate.toLocalDate()).append("\n");
for (OrderItem item : items) {
sb.append(" - ").append(item).append(" = $")
.append(String.format("%.2f", item.getSubtotal())).append("\n");
}
sb.append(" Subtotal: $").append(String.format("%.2f", subtotal)).append("\n");
if (discount > 0) {
sb.append(" Discount: -$").append(String.format("%.2f", discount)).append(" (10% bulk)\n");
}
sb.append(" Tax: $").append(String.format("%.2f", tax)).append("\n");
sb.append(" Total: $").append(String.format("%.2f", total));
return sb.toString();
}
}
com.bookstore.util - Utility Classes
// === File: com/bookstore/util/Formatter.java ===
package com.bookstore.util;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
public class Formatter {
private static final DateTimeFormatter DATE_FORMAT =
DateTimeFormatter.ofPattern("MMM dd, yyyy");
private static final DateTimeFormatter DATE_TIME_FORMAT =
DateTimeFormatter.ofPattern("MMM dd, yyyy hh:mm a");
public static String formatPrice(double price) {
return String.format("$%.2f", price);
}
public static String formatDate(LocalDateTime dateTime) {
return dateTime.format(DATE_FORMAT);
}
public static String formatDateTime(LocalDateTime dateTime) {
return dateTime.format(DATE_TIME_FORMAT);
}
public static String padRight(String text, int width) {
return String.format("%-" + width + "s", text);
}
public static String padLeft(String text, int width) {
return String.format("%" + width + "s", text);
}
public static String repeat(String str, int times) {
StringBuilder sb = new StringBuilder();
for (int i = 0; i < times; i++) {
sb.append(str);
}
return sb.toString();
}
}
com.bookstore.service - Business Logic
// === File: com/bookstore/service/BookService.java ===
package com.bookstore.service;
import com.bookstore.model.Book;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class BookService {
private final Map catalog = new HashMap<>();
public void addBook(String isbn, String title, String author, double price, int stock) {
if (catalog.containsKey(isbn)) {
throw new IllegalArgumentException("Book with ISBN " + isbn + " already exists");
}
catalog.put(isbn, new Book(isbn, title, author, price, stock));
}
public Book findByIsbn(String isbn) {
Book book = catalog.get(isbn);
if (book == null) {
throw new IllegalArgumentException("Book not found: " + isbn);
}
return book;
}
public List findByAuthor(String author) {
List result = new ArrayList<>();
for (Book book : catalog.values()) {
if (book.getAuthor().equalsIgnoreCase(author)) {
result.add(book);
}
}
return result;
}
public List findInStock() {
List result = new ArrayList<>();
for (Book book : catalog.values()) {
if (book.isInStock()) {
result.add(book);
}
}
return result;
}
public List getAllBooks() {
return new ArrayList<>(catalog.values());
}
// Notice: BookService CANNOT call book.decreaseStock() because
// that method is package-private in com.bookstore.model.
// Stock management happens only through Order creation.
}
// === File: com/bookstore/service/OrderService.java ===
package com.bookstore.service;
import com.bookstore.model.Book;
import com.bookstore.model.Customer;
import com.bookstore.model.Order;
// import com.bookstore.model.OrderItem; // CANNOT import -- package-private
// import com.bookstore.model.PriceCalculator; // CANNOT import -- package-private
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class OrderService {
private final List orders = new ArrayList<>();
private final Map customers = new HashMap<>();
public Customer createCustomer(String name, String email) {
String id = "CUST-" + (customers.size() + 1);
Customer customer = new Customer(id, name, email);
customers.put(id, customer);
return customer;
}
public Customer findCustomer(String id) {
Customer customer = customers.get(id);
if (customer == null) {
throw new IllegalArgumentException("Customer not found: " + id);
}
return customer;
}
// The OrderService creates orders through the model's public API.
// It passes Book objects and quantities to the model layer,
// which handles OrderItem creation internally.
public Order placeOrder(Customer customer, Map bookQuantities) {
if (bookQuantities.isEmpty()) {
throw new IllegalArgumentException("Order must contain at least one book");
}
// Validate stock before creating the order
for (Map.Entry entry : bookQuantities.entrySet()) {
Book book = entry.getKey();
int quantity = entry.getValue();
if (quantity <= 0) {
throw new IllegalArgumentException("Quantity must be positive for: " + book.getTitle());
}
if (book.getStock() < quantity) {
throw new IllegalStateException("Insufficient stock for '" + book.getTitle() +
"'. Available: " + book.getStock() + ", Requested: " + quantity);
}
}
// Delegate to model layer -- Order constructor handles OrderItem creation,
// price calculation, stock decrements, and customer history updates
Order order = createOrder(customer, bookQuantities);
orders.add(order);
return order;
}
// Package-private helper that builds the order through the model's internal API
private Order createOrder(Customer customer, Map bookQuantities) {
// We use reflection or a factory in real apps. For this tutorial,
// Order has a package-private constructor accessible within its own package.
// Since OrderService is in a different package, we would typically use
// a public factory method on Order. Let us add one:
return Order.create(customer, bookQuantities);
}
public List getAllOrders() {
return new ArrayList<>(orders);
}
}
Notice that OrderService calls Order.create() – a public factory method. Let us add that to the Order class:
// Add this public factory method to Order.java:
public static Order create(Customer customer, Map bookQuantities) {
List items = new ArrayList<>();
for (Map.Entry entry : bookQuantities.entrySet()) {
items.add(new OrderItem(entry.getKey(), entry.getValue()));
}
return new Order(customer, items);
}
// This is the PUBLIC API for creating orders.
// The OrderItem and PriceCalculator classes remain package-private.
// External packages only see: Order.create(customer, bookQuantities)
com.bookstore.app - Entry Point
// === File: com/bookstore/app/BookstoreApp.java ===
package com.bookstore.app;
import com.bookstore.model.Book;
import com.bookstore.model.Customer;
import com.bookstore.model.Order;
import com.bookstore.service.BookService;
import com.bookstore.service.OrderService;
import com.bookstore.util.Formatter;
// These imports would FAIL -- the classes are package-private:
// import com.bookstore.model.OrderItem; // COMPILE ERROR
// import com.bookstore.model.PriceCalculator; // COMPILE ERROR
import java.util.HashMap;
import java.util.Map;
public class BookstoreApp {
public static void main(String[] args) {
// --- Set up services ---
BookService bookService = new BookService();
OrderService orderService = new OrderService();
// --- Add books to catalog ---
bookService.addBook("978-0134685991", "Effective Java", "Joshua Bloch", 45.99, 10);
bookService.addBook("978-0596009205", "Head First Design Patterns", "Eric Freeman", 39.99, 8);
bookService.addBook("978-0132350884", "Clean Code", "Robert C. Martin", 34.99, 15);
bookService.addBook("978-0201633610", "Design Patterns", "Gang of Four", 49.99, 5);
// --- Display catalog ---
System.out.println("========== BOOKSTORE CATALOG ==========");
System.out.println(Formatter.padRight("Title", 30)
+ Formatter.padRight("Author", 20)
+ Formatter.padLeft("Price", 10)
+ Formatter.padLeft("Stock", 8));
System.out.println(Formatter.repeat("-", 68));
for (Book book : bookService.getAllBooks()) {
System.out.println(Formatter.padRight(book.getTitle(), 30)
+ Formatter.padRight(book.getAuthor(), 20)
+ Formatter.padLeft(Formatter.formatPrice(book.getPrice()), 10)
+ Formatter.padLeft(String.valueOf(book.getStock()), 8));
}
// --- Create customers ---
Customer alice = orderService.createCustomer("Alice Johnson", "alice@email.com");
Customer bob = orderService.createCustomer("Bob Williams", "bob@email.com");
System.out.println("\n========== CUSTOMERS ==========");
System.out.println(alice);
System.out.println(bob);
// --- Place Order 1: Alice buys 2 books (no bulk discount) ---
Map aliceBooks = new HashMap<>();
aliceBooks.put(bookService.findByIsbn("978-0134685991"), 1); // Effective Java
aliceBooks.put(bookService.findByIsbn("978-0132350884"), 1); // Clean Code
Order order1 = orderService.placeOrder(alice, aliceBooks);
System.out.println("\n========== ORDER 1 ==========");
System.out.println(order1);
// --- Place Order 2: Bob buys 4 books (gets 10% bulk discount) ---
Map bobBooks = new HashMap<>();
bobBooks.put(bookService.findByIsbn("978-0596009205"), 2); // Head First x2
bobBooks.put(bookService.findByIsbn("978-0201633610"), 2); // Design Patterns x2
Order order2 = orderService.placeOrder(bob, bobBooks);
System.out.println("\n========== ORDER 2 (BULK DISCOUNT) ==========");
System.out.println(order2);
// --- Check updated stock ---
System.out.println("\n========== UPDATED STOCK ==========");
for (Book book : bookService.getAllBooks()) {
System.out.println(" " + book.getTitle() + ": " + book.getStock() + " remaining");
}
// --- Customer order history ---
System.out.println("\n========== CUSTOMER HISTORY ==========");
System.out.println(alice.getName() + " has " + alice.getTotalOrders() + " order(s)");
System.out.println(bob.getName() + " has " + bob.getTotalOrders() + " order(s)");
// --- What we CANNOT do from this package ---
System.out.println("\n========== ACCESS CONTROL DEMO ==========");
System.out.println("From com.bookstore.app, we CAN:");
System.out.println(" - Access Book, Customer, Order (public classes)");
System.out.println(" - Call public methods: book.getTitle(), order.getTotal()");
System.out.println(" - Use Formatter utility methods");
System.out.println("From com.bookstore.app, we CANNOT:");
System.out.println(" - Access OrderItem (package-private in model)");
System.out.println(" - Access PriceCalculator (package-private in model)");
System.out.println(" - Call book.decreaseStock() (package-private method)");
System.out.println(" - Call customer.addOrder() (package-private method)");
}
}
// Output:
// ========== BOOKSTORE CATALOG ==========
// Title Author Price Stock
// --------------------------------------------------------------------
// Effective Java Joshua Bloch $45.99 10
// Head First Design Patterns Eric Freeman $39.99 8
// Clean Code Robert C. Martin $34.99 15
// Design Patterns Gang of Four $49.99 5
//
// ========== CUSTOMERS ==========
// Customer{id='CUST-1', name='Alice Johnson', orders=0}
// Customer{id='CUST-2', name='Bob Williams', orders=0}
//
// ========== ORDER 1 ==========
// Order ORD-1 for Alice Johnson
// Date: 2026-02-28
// - 1x Effective Java @ $45.99 = $45.99
// - 1x Clean Code @ $34.99 = $34.99
// Subtotal: $80.98
// Tax: $6.48
// Total: $87.46
//
// ========== ORDER 2 (BULK DISCOUNT) ==========
// Order ORD-2 for Bob Williams
// Date: 2026-02-28
// - 2x Head First Design Patterns @ $39.99 = $79.98
// - 2x Design Patterns @ $49.99 = $99.98
// Subtotal: $179.96
// Discount: -$18.00 (10% bulk)
// Tax: $12.96
// Total: $174.92
//
// ========== UPDATED STOCK ==========
// Effective Java: 9 remaining
// Head First Design Patterns: 6 remaining
// Clean Code: 14 remaining
// Design Patterns: 3 remaining
//
// ========== CUSTOMER HISTORY ==========
// Alice Johnson has 1 order(s)
// Bob Williams has 1 order(s)
//
// ========== ACCESS CONTROL DEMO ==========
// From com.bookstore.app, we CAN:
// - Access Book, Customer, Order (public classes)
// - Call public methods: book.getTitle(), order.getTotal()
// - Use Formatter utility methods
// From com.bookstore.app, we CANNOT:
// - Access OrderItem (package-private in model)
// - Access PriceCalculator (package-private in model)
// - Call book.decreaseStock() (package-private method)
// - Call customer.addOrder() (package-private method)
12. Quick Reference
Concept
Key Point
Package
A namespace for grouping related classes. Maps to directory structure.
package statement
Must be the first statement in a Java file. Only one per file.
import statement
Lets you use classes from other packages by their short name.
Wildcard import *
Imports all classes from a package. Does NOT import sub-packages.
Static import
Imports static members (methods, constants) for direct use.
java.lang
The only auto-imported package. Contains String, Math, System, Object.
Default (package-private)
Visible only within the same package. Sub-packages do NOT count.
Naming convention
Reverse domain, all lowercase: com.company.project.module
Sub-packages
Logically nested but treated as completely separate packages by Java.
Default package
Unnamed package for classes without a package statement. Avoid in production.
Feature-based packages
Group all classes for a feature together. Preferred for larger projects.
Circular dependencies
Package A imports from B and B imports from A. Always avoid.
March 8, 2019
Generics
1. What are Generics?
Generics allow you to write classes, interfaces, and methods that operate on types specified by the caller, rather than hardcoded into the implementation. Introduced in Java 5 (JDK 1.5), generics bring type safety at compile time — the compiler catches type mismatches before your code ever runs, eliminating an entire category of runtime errors.
Before generics, collections stored everything as Object. You could put a String into a List, then accidentally retrieve it as an Integer, and the compiler would not complain. The error would only surface at runtime as a ClassCastException — often in production, often at the worst possible time.
The Problem Generics Solve
Consider this pre-generics code (Java 1.4 and earlier):
import java.util.ArrayList;
import java.util.List;
public class WithoutGenerics {
public static void main(String[] args) {
// Raw List -- no type information. Anything goes.
List names = new ArrayList();
names.add("Alice");
names.add("Bob");
names.add(42); // No compiler error! An Integer slipped into a "names" list.
// Later, when we retrieve elements...
for (int i = 0; i < names.size(); i++) {
String name = (String) names.get(i); // Manual cast required every time
System.out.println(name.toUpperCase());
}
// Output:
// ALICE
// BOB
// Exception in thread "main" java.lang.ClassCastException:
// java.lang.Integer cannot be cast to java.lang.String
}
}
There are three problems with the raw type approach:
No compile-time type checking -- the Integer 42 was silently added to a list that should only contain strings
Manual casting -- every retrieval requires (String) cast, which is tedious and error-prone
Runtime failure -- the ClassCastException only appears when the code runs, not when it compiles
Now here is the same code with generics:
import java.util.ArrayList;
import java.util.List;
public class WithGenerics {
public static void main(String[] args) {
// Parameterized List -- only String elements allowed
List names = new ArrayList<>();
names.add("Alice");
names.add("Bob");
// names.add(42); // COMPILE ERROR: incompatible types: int cannot be converted to String
// No casting needed -- the compiler knows every element is a String
for (String name : names) {
System.out.println(name.toUpperCase());
}
// Output:
// ALICE
// BOB
}
}
Before vs After Generics
Aspect
Without Generics (Raw Types)
With Generics
Declaration
List names = new ArrayList();
List<String> names = new ArrayList<>();
Type safety
None -- any Object can be added
Enforced at compile time
Retrieval
Manual cast: (String) list.get(0)
No cast needed: list.get(0)
Error detection
Runtime (ClassCastException)
Compile time (compiler error)
Readability
Type intent is hidden
Type intent is self-documenting
The golden rule: Generics move type errors from runtime to compile time. A bug caught by the compiler costs you 30 seconds. A bug caught in production costs you hours -- or worse.
2. Generic Classes
A generic class is a class that declares one or more type parameters in angle brackets after its name. These type parameters act as placeholders -- they are replaced with actual types when the class is instantiated. This allows you to write a single class that works with any type while maintaining full type safety.
Basic Syntax
The general form of a generic class declaration is:
// T is a type parameter -- a placeholder for a real type
public class Box {
private T content;
public Box(T content) {
this.content = content;
}
public T getContent() {
return content;
}
public void setContent(T content) {
this.content = content;
}
@Override
public String toString() {
return "Box[" + content + "]";
}
}
// Usage -- T is replaced with actual types at instantiation
public class BoxDemo {
public static void main(String[] args) {
// Box of String
Box nameBox = new Box<>("Alice");
String name = nameBox.getContent(); // No cast needed
System.out.println(name); // Output: Alice
// Box of Integer
Box ageBox = new Box<>(30);
int age = ageBox.getContent(); // Autoboxing/unboxing works seamlessly
System.out.println(age); // Output: 30
// Box of a custom type
Box> listBox = new Box<>(List.of("A", "B", "C"));
List items = listBox.getContent();
System.out.println(items); // Output: [A, B, C]
}
}
Type Parameter Naming Conventions
By convention, type parameters use single uppercase letters. This distinguishes them from class names at a glance. Here are the standard conventions used throughout the Java ecosystem:
Letter
Convention
Example Usage
T
Type (general purpose)
Box<T>, Optional<T>
E
Element (used in collections)
List<E>, Set<E>, Queue<E>
K
Key (used in maps)
Map<K, V>
V
Value (used in maps)
Map<K, V>
N
Number
Calculator<N extends Number>
S, U, V
Second, third, fourth types
Function<T, R>, BiFunction<T, U, R>
R
Return type
Function<T, R>, Callable<R>
Multiple Type Parameters
A generic class can declare multiple type parameters, separated by commas. A classic example is a Pair class that holds two values of potentially different types:
public class Pair {
private final K key;
private final V value;
public Pair(K key, V value) {
this.key = key;
this.value = value;
}
public K getKey() {
return key;
}
public V getValue() {
return value;
}
@Override
public String toString() {
return "(" + key + ", " + value + ")";
}
// Static factory method -- type inference handles the type parameters
public static Pair of(K key, V value) {
return new Pair<>(key, value);
}
}
public class PairDemo {
public static void main(String[] args) {
// Explicit type arguments
Pair entry = new Pair<>("age", 30);
System.out.println(entry.getKey()); // Output: age
System.out.println(entry.getValue()); // Output: 30
// Using the factory method -- types are inferred
Pair> config = Pair.of("roles", List.of("ADMIN", "USER"));
System.out.println(config); // Output: (roles, [ADMIN, USER])
// Pair of Pairs -- generics compose naturally
Pair> location = Pair.of("Office", Pair.of(37.7749, -122.4194));
System.out.println(location); // Output: (Office, (37.7749, -122.4194))
}
}
Generic Class with Bounded Type
You can constrain a type parameter so that it only accepts types that extend a particular class or implement a particular interface. This lets you call methods of the bound type inside your generic class:
// Only accepts types that are Numbers (Integer, Double, Long, etc.)
public class NumberBox {
private T number;
public NumberBox(T number) {
this.number = number;
}
public double doubleValue() {
// Because T extends Number, we can call Number's methods
return number.doubleValue();
}
public boolean isPositive() {
return number.doubleValue() > 0;
}
public T getNumber() {
return number;
}
}
public class NumberBoxDemo {
public static void main(String[] args) {
NumberBox intBox = new NumberBox<>(42);
System.out.println(intBox.doubleValue()); // Output: 42.0
System.out.println(intBox.isPositive()); // Output: true
NumberBox doubleBox = new NumberBox<>(-3.14);
System.out.println(doubleBox.isPositive()); // Output: false
// NumberBox stringBox = new NumberBox<>("hello");
// COMPILE ERROR: String does not extend Number
}
}
3. Generic Methods
A generic method is a method that declares its own type parameters, independent of any type parameters on the enclosing class. The type parameter list appears in angle brackets before the return type. Generic methods can appear in generic classes, non-generic classes, or even as static methods.
The compiler infers the type argument from the arguments you pass, so you rarely need to specify it explicitly.
public class GenericMethodDemo {
// Generic method -- is declared before the return type
public static void printArray(T[] array) {
for (T element : array) {
System.out.print(element + " ");
}
System.out.println();
}
// Generic method that returns a value
public static T getFirst(List list) {
if (list == null || list.isEmpty()) {
return null;
}
return list.get(0);
}
// Generic method with two type parameters
public static Map mapOf(K key, V value) {
Map map = new HashMap<>();
map.put(key, value);
return map;
}
// Generic swap method
public static void swap(T[] array, int i, int j) {
T temp = array[i];
array[i] = array[j];
array[j] = temp;
}
// Generic max method -- requires Comparable bound
public static > T max(T a, T b) {
return a.compareTo(b) >= 0 ? a : b;
}
public static void main(String[] args) {
// printArray -- type inferred from arguments
Integer[] intArr = {1, 2, 3, 4, 5};
String[] strArr = {"Hello", "World"};
printArray(intArr); // Output: 1 2 3 4 5
printArray(strArr); // Output: Hello World
// getFirst -- type inferred from list
List names = List.of("Alice", "Bob", "Charlie");
String first = getFirst(names); // No cast needed
System.out.println("First: " + first); // Output: First: Alice
// swap
String[] colors = {"Red", "Blue", "Green"};
swap(colors, 0, 2);
printArray(colors); // Output: Green Blue Red
// max -- works with any Comparable type
System.out.println(max(10, 20)); // Output: 20
System.out.println(max("apple", "banana")); // Output: banana
System.out.println(max(3.14, 2.71)); // Output: 3.14
}
}
Generic Methods in Non-Generic Classes
A key insight is that a method can be generic even if its enclosing class is not. This is common for utility classes:
// This is NOT a generic class -- no type parameter on the class itself
public class ArrayUtils {
// But these are generic methods
public static boolean contains(T[] array, T target) {
for (T element : array) {
if (element.equals(target)) {
return true;
}
}
return false;
}
public static int indexOf(T[] array, T target) {
for (int i = 0; i < array.length; i++) {
if (array[i].equals(target)) {
return i;
}
}
return -1;
}
public static T[] reverse(T[] array) {
@SuppressWarnings("unchecked")
T[] reversed = (T[]) java.lang.reflect.Array.newInstance(
array.getClass().getComponentType(), array.length);
for (int i = 0; i < array.length; i++) {
reversed[i] = array[array.length - 1 - i];
}
return reversed;
}
public static void main(String[] args) {
String[] fruits = {"Apple", "Banana", "Cherry"};
System.out.println(contains(fruits, "Banana")); // Output: true
System.out.println(contains(fruits, "Grape")); // Output: false
System.out.println(indexOf(fruits, "Cherry")); // Output: 2
String[] reversed = reverse(fruits);
System.out.println(Arrays.toString(reversed)); // Output: [Cherry, Banana, Apple]
}
}
4. Bounded Type Parameters
Sometimes you need a type parameter that is not completely open-ended. You want to restrict it to a family of types so that you can call specific methods on it. This is where bounded type parameters come in.
Upper Bounds with extends
The extends keyword in a type parameter bound means "is a subtype of" -- this works for both classes and interfaces. When you write <T extends Number>, T can be Integer, Double, Long, or any other subclass of Number.
Why is this useful? Because inside the method or class, you can call any method defined on the bound type. Without the bound, T is effectively Object, and you can only call toString(), equals(), and hashCode().
public class BoundedTypeDemo {
// Without bound: T is Object -- we can't call .doubleValue()
// public static double sum(List numbers) {
// double total = 0;
// for (T n : numbers) {
// total += n.doubleValue(); // COMPILE ERROR: Object has no doubleValue()
// }
// return total;
// }
// With upper bound: T must be a Number -- now we can call doubleValue()
public static double sum(List numbers) {
double total = 0;
for (T n : numbers) {
total += n.doubleValue(); // OK: Number has doubleValue()
}
return total;
}
// Finding the maximum in a list -- T must be Comparable
public static > T findMax(List list) {
if (list == null || list.isEmpty()) {
throw new IllegalArgumentException("List must not be null or empty");
}
T max = list.get(0);
for (int i = 1; i < list.size(); i++) {
if (list.get(i).compareTo(max) > 0) {
max = list.get(i);
}
}
return max;
}
public static void main(String[] args) {
List integers = List.of(10, 20, 30);
List doubles = List.of(1.5, 2.5, 3.5);
System.out.println("Sum of integers: " + sum(integers)); // Output: Sum of integers: 60.0
System.out.println("Sum of doubles: " + sum(doubles)); // Output: Sum of doubles: 7.5
// sum(List.of("a", "b")); // COMPILE ERROR: String does not extend Number
List words = List.of("banana", "apple", "cherry");
System.out.println("Max word: " + findMax(words)); // Output: Max word: cherry
System.out.println("Max integer: " + findMax(integers)); // Output: Max integer: 30
}
}
Multiple Bounds
A type parameter can have multiple bounds, separated by &. The syntax is <T extends ClassA & InterfaceB & InterfaceC>. If one of the bounds is a class (not an interface), it must be listed first.
import java.io.Serializable;
public class MultipleBoundsDemo {
// T must be Comparable AND Serializable
public static & Serializable> T clampedMax(T a, T b, T ceiling) {
T larger = a.compareTo(b) >= 0 ? a : b;
return larger.compareTo(ceiling) > 0 ? ceiling : larger;
}
// A practical example: a method that requires both Number and Comparable
public static > T clamp(T value, T min, T max) {
if (value.compareTo(min) < 0) return min;
if (value.compareTo(max) > 0) return max;
return value;
}
public static void main(String[] args) {
// Integer implements both Comparable and Serializable
System.out.println(clampedMax(10, 20, 15)); // Output: 15
// clamp example
System.out.println(clamp(5, 1, 10)); // Output: 5 (within range)
System.out.println(clamp(-3, 1, 10)); // Output: 1 (below min, clamped up)
System.out.println(clamp(15, 1, 10)); // Output: 10 (above max, clamped down)
System.out.println(clamp(3.7, 1.0, 5.0)); // Output: 3.7
}
}
5. Wildcards
Wildcards (?) represent an unknown type. They are used in type arguments (not type parameters) -- that is, you use them when using a generic type, not when declaring one. Wildcards are essential for writing flexible APIs that can accept a range of parameterized types.
There are three kinds of wildcards:
Wildcard
Syntax
Meaning
Use Case
Upper bounded
? extends Type
Any subtype of Type
Reading from a structure (producer)
Lower bounded
? super Type
Any supertype of Type
Writing to a structure (consumer)
Unbounded
?
Any type at all
When the type does not matter
Upper Bounded Wildcards (? extends Type)
Use upper bounded wildcards when you want to read from a generic structure. You know the elements are at least the bound type, so you can safely read them as that type. However, you cannot write to such a structure (except null), because the compiler does not know the exact type.
public class UpperBoundedWildcardDemo {
// This method accepts List, List, List, etc.
public static double sumOfList(List list) {
double total = 0;
for (Number n : list) { // Safe to read as Number
total += n.doubleValue();
}
return total;
}
// Without the wildcard, this would ONLY accept List -- not List!
// Remember: List is NOT a subtype of List, even though Integer IS a subtype of Number.
// This is called "invariance" and it's a critical concept to understand.
public static void main(String[] args) {
List integers = List.of(1, 2, 3);
List doubles = List.of(1.5, 2.5, 3.5);
List numbers = List.of(1, 2.5, 3L);
System.out.println(sumOfList(integers)); // Output: 6.0
System.out.println(sumOfList(doubles)); // Output: 7.5
System.out.println(sumOfList(numbers)); // Output: 6.5
// Why can't we add to a List?
List unknown = integers;
// unknown.add(42); // COMPILE ERROR!
// unknown.add(3.14); // COMPILE ERROR!
// The compiler doesn't know if the list is List, List, etc.
// Adding a Double to a List would break type safety.
Number first = unknown.get(0); // But READING is fine
System.out.println("First: " + first); // Output: First: 1
}
}
Lower Bounded Wildcards (? super Type)
Use lower bounded wildcards when you want to write to a generic structure. You know the structure accepts at least the bound type and all its subtypes, so you can safely add elements of that type. However, when you read from it, you can only guarantee the element is an Object.
public class LowerBoundedWildcardDemo {
// This method accepts List, List, List
The PECS Principle (Producer Extends, Consumer Super)
Joshua Bloch coined this mnemonic in Effective Java, and it is the single most important rule for using wildcards correctly:
Producer Extends: If a parameterized type produces (provides) elements of type T, use ? extends T. You are reading from it.
Consumer Super: If a parameterized type consumes (accepts) elements of type T, use ? super T. You are writing to it.
If a parameter both produces and consumes, do not use wildcards -- use an exact type.
import java.util.*;
import java.util.function.Predicate;
public class PECSDemo {
// 'src' is a PRODUCER (we read from it) -- use extends
// 'dest' is a CONSUMER (we write to it) -- use super
public static void transferFiltered(
List src, // Producer: extends
List dest, // Consumer: super
Predicate filter) // Consumer: super (it "consumes" T to test it)
{
for (T item : src) {
if (filter.test(item)) {
dest.add(item);
}
}
}
public static void main(String[] args) {
List source = List.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
List evens = new ArrayList<>();
// Transfer even numbers from List to List
transferFiltered(source, evens, n -> n % 2 == 0);
System.out.println("Evens: " + evens); // Output: Evens: [2, 4, 6, 8, 10]
}
}
Unbounded Wildcards (?)
Use an unbounded wildcard when the actual type does not matter. This is appropriate when you are working with methods from Object (like toString() or size()) or when the method's logic is type-independent.
public class UnboundedWildcardDemo {
// We don't care what type the list contains -- we just want its size
public static int countElements(List list) {
return list.size();
}
// Print any list -- we only call toString() on elements
public static void printList(List list) {
for (Object element : list) {
System.out.print(element + " ");
}
System.out.println();
}
// Check if two lists have the same size
public static boolean sameSize(List a, List b) {
return a.size() == b.size();
}
public static void main(String[] args) {
List names = List.of("Alice", "Bob");
List ages = List.of(30, 25);
List scores = List.of(95.5, 87.3, 91.0);
printList(names); // Output: Alice Bob
printList(ages); // Output: 30 25
printList(scores); // Output: 95.5 87.3 91.0
System.out.println(countElements(scores)); // Output: 3
System.out.println(sameSize(names, ages)); // Output: true
}
}
Wildcard Summary
Scenario
Wildcard to Use
Can Read As
Can Write
Read elements as T
? extends T
T
Only null
Write elements of type T
? super T
Object
T and subtypes
Read and write
No wildcard (use T)
T
T
Type does not matter
?
Object
Only null
6. Type Erasure
Here is the part that trips up many Java developers: generics exist only at compile time. At runtime, the JVM has no concept of generic types. The compiler removes (erases) all type parameter information and replaces it with their bounds (or Object if unbounded). This process is called type erasure.
Type erasure was a deliberate design choice to maintain backward compatibility with pre-generics Java code. It means that List<String> and List<Integer> are the same class at runtime -- they are both just List.
What Happens During Erasure
Generic Code (Compile Time)
After Erasure (Runtime)
List<String>
List
Box<Integer>
Box
<T> T getFirst(List<T>)
Object getFirst(List)
<T extends Number> T sum(T a, T b)
Number sum(Number a, Number b)
Pair<String, Integer>
Pair (fields become Object)
Consequences of Type Erasure
Type erasure imposes several limitations that every Java developer must understand. These are not bugs -- they are inherent trade-offs of the erasure-based generics design:
public class TypeErasureDemo {
// 1. You CANNOT create instances of type parameters
public static T createInstance() {
// return new T(); // COMPILE ERROR: Type parameter T cannot be instantiated directly
// Workaround: pass a Supplier or Class
return null;
}
// Workaround using Class
public static T createInstance(Class clazz) throws Exception {
return clazz.getDeclaredConstructor().newInstance();
}
// 2. You CANNOT use instanceof with generic types
public static void checkType(List list) {
// if (list instanceof List) {} // COMPILE ERROR
// At runtime, list is just a List -- the is gone
if (list instanceof List) { } // This is OK -- unbounded wildcard is fine
}
// 3. You CANNOT create generic arrays
public static void cannotCreateGenericArray() {
// T[] array = new T[10]; // COMPILE ERROR
// List[] arrayOfLists = new List[10]; // COMPILE ERROR
// Workaround: use Array.newInstance or collections
@SuppressWarnings("unchecked")
T[] workaround = (T[]) new Object[10]; // Works but produces unchecked warning
}
// 4. You CANNOT overload methods that differ only by type parameter
// public static void process(List list) { }
// public static void process(List list) { } // COMPILE ERROR
// After erasure, both signatures become process(List list) -- they clash
// 5. You CANNOT catch or throw generic types
// class MyException extends Exception { } // COMPILE ERROR
// The JVM needs to know the exact exception type at runtime
public static void main(String[] args) throws Exception {
// Demonstrating that generic types are the same at runtime
List strings = new ArrayList<>();
List integers = new ArrayList<>();
System.out.println(strings.getClass() == integers.getClass()); // Output: true
System.out.println(strings.getClass().getName()); // Output: java.util.ArrayList
// Both are just ArrayList at runtime -- the and are gone
// Creating instances via Class
String s = createInstance(String.class);
System.out.println("Created: " + s); // Output: Created:
}
}
Bridge Methods
When a generic class is extended with a concrete type, the compiler sometimes generates bridge methods to maintain polymorphism after type erasure. You will rarely interact with bridge methods directly, but understanding them explains some unexpected behaviors:
// Generic interface
public interface Transformer {
T transform(T input);
}
// Concrete implementation
public class UpperCaseTransformer implements Transformer {
@Override
public String transform(String input) {
return input.toUpperCase();
}
}
// After type erasure, the interface becomes:
// Object transform(Object input)
//
// But UpperCaseTransformer has:
// String transform(String input)
//
// These are different signatures! The compiler generates a "bridge method":
// public Object transform(Object input) {
// return transform((String) input); // delegates to the real method
// }
//
// This bridge method ensures that calling transformer.transform(obj)
// via the interface still dispatches to the correct implementation.
public class BridgeMethodDemo {
public static void main(String[] args) {
Transformer transformer = new UpperCaseTransformer();
System.out.println(transformer.transform("hello")); // Output: HELLO
// The bridge method is visible via reflection
for (java.lang.reflect.Method m : UpperCaseTransformer.class.getDeclaredMethods()) {
System.out.println(m.getName() + " - bridge: " + m.isBridge()
+ " - params: " + java.util.Arrays.toString(m.getParameterTypes()));
}
// Output:
// transform - bridge: false - params: [class java.lang.String]
// transform - bridge: true - params: [class java.lang.Object]
}
}
7. Generic Interfaces
Just as classes can be generic, interfaces can declare type parameters. In fact, some of the most important interfaces in the Java standard library are generic: Comparable<T>, Iterable<T>, Comparator<T>, Function<T, R>, and more.
When a class implements a generic interface, it has three choices:
Approach
Example
When to Use
Concrete type
class Name implements Comparable<Name>
The type is fixed and known
Keep generic
class Box<T> implements Container<T>
The implementing class is also generic
Raw type
class Legacy implements Comparable
Never do this -- legacy only
// Defining a generic interface
public interface Repository {
T findById(ID id);
List findAll();
T save(T entity);
void deleteById(ID id);
boolean existsById(ID id);
}
// Approach 1: Implement with concrete types
public class UserRepository implements Repository {
private final Map store = new HashMap<>();
@Override
public User findById(Long id) {
return store.get(id);
}
@Override
public List findAll() {
return new ArrayList<>(store.values());
}
@Override
public User save(User user) {
store.put(user.getId(), user);
return user;
}
@Override
public void deleteById(Long id) {
store.remove(id);
}
@Override
public boolean existsById(Long id) {
return store.containsKey(id);
}
}
// Approach 2: Keep the type parameters -- create a reusable base class
public class InMemoryRepository implements Repository {
private final Map store = new HashMap<>();
private final Function idExtractor;
public InMemoryRepository(Function idExtractor) {
this.idExtractor = idExtractor;
}
@Override
public T findById(ID id) {
return store.get(id);
}
@Override
public List findAll() {
return new ArrayList<>(store.values());
}
@Override
public T save(T entity) {
store.put(idExtractor.apply(entity), entity);
return entity;
}
@Override
public void deleteById(ID id) {
store.remove(id);
}
@Override
public boolean existsById(ID id) {
return store.containsKey(id);
}
}
Implementing Comparable<T>
Comparable<T> is arguably the most frequently implemented generic interface. It defines a natural ordering for a class. Here is a proper implementation:
public class Employee implements Comparable {
private final String name;
private final double salary;
public Employee(String name, double salary) {
this.name = name;
this.salary = salary;
}
public String getName() { return name; }
public double getSalary() { return salary; }
// Natural ordering: by salary (ascending)
@Override
public int compareTo(Employee other) {
return Double.compare(this.salary, other.salary);
}
@Override
public String toString() {
return name + "($" + salary + ")";
}
}
public class ComparableDemo {
public static void main(String[] args) {
List team = new ArrayList<>(List.of(
new Employee("Alice", 95000),
new Employee("Bob", 72000),
new Employee("Charlie", 110000),
new Employee("Diana", 88000)
));
// Sort uses Comparable.compareTo()
Collections.sort(team);
System.out.println("By salary: " + team);
// Output: By salary: [Bob($72000.0), Diana($88000.0), Alice($95000.0), Charlie($110000.0)]
// Collections.min() and max() also use Comparable
System.out.println("Lowest paid: " + Collections.min(team)); // Output: Lowest paid: Bob($72000.0)
System.out.println("Highest paid: " + Collections.max(team)); // Output: Highest paid: Charlie($110000.0)
}
}
8. Generic Collections
Generics and the Collections Framework are inseparable. When generics were introduced in Java 5, the entire Collections API was retrofitted to use them. This is why you write List<String> instead of the raw List. Understanding how generics power collections is essential for everyday Java development.
The Diamond Operator (Java 7+)
Before Java 7, you had to repeat the type arguments on both sides of the assignment:
import java.util.*;
public class GenericCollectionsDemo {
public static void main(String[] args) {
// Java 5/6 -- type arguments repeated on both sides (verbose)
Map> scores1 = new HashMap>();
// Java 7+ -- diamond operator infers the type arguments
Map> scores2 = new HashMap<>(); // Much cleaner
// Java 9+ -- factory methods with implicit typing
List names = List.of("Alice", "Bob", "Charlie");
Set primes = Set.of(2, 3, 5, 7, 11);
Map ages = Map.of("Alice", 30, "Bob", 25);
// -------------------------------------------------------
// List -- ordered, allows duplicates
// -------------------------------------------------------
List languages = new ArrayList<>();
languages.add("Java");
languages.add("Python");
languages.add("Java"); // Duplicates OK
String first = languages.get(0); // No cast needed -- type safe
System.out.println("Languages: " + languages); // Output: Languages: [Java, Python, Java]
// -------------------------------------------------------
// Set -- no duplicates
// -------------------------------------------------------
Set uniqueLanguages = new LinkedHashSet<>(languages);
System.out.println("Unique: " + uniqueLanguages); // Output: Unique: [Java, Python]
// -------------------------------------------------------
// Map -- key-value pairs
// -------------------------------------------------------
Map> courseStudents = new HashMap<>();
courseStudents.put("CS101", List.of("Alice", "Bob"));
courseStudents.put("CS201", List.of("Charlie", "Diana"));
// Type safety carries through nested generics
List cs101Students = courseStudents.get("CS101"); // returns List, not Object
System.out.println("CS101: " + cs101Students); // Output: CS101: [Alice, Bob]
// -------------------------------------------------------
// Queue -- FIFO ordering
// -------------------------------------------------------
Queue taskQueue = new LinkedList<>();
taskQueue.offer("Build feature");
taskQueue.offer("Write tests");
taskQueue.offer("Deploy");
System.out.println("Next task: " + taskQueue.poll()); // Output: Next task: Build feature
// -------------------------------------------------------
// Deque -- double-ended queue (also used as a stack)
// -------------------------------------------------------
Deque stack = new ArrayDeque<>();
stack.push("First");
stack.push("Second");
stack.push("Third");
System.out.println("Stack pop: " + stack.pop()); // Output: Stack pop: Third
// -------------------------------------------------------
// PriorityQueue -- elements ordered by natural ordering or Comparator
// -------------------------------------------------------
PriorityQueue minHeap = new PriorityQueue<>();
minHeap.addAll(List.of(30, 10, 50, 20, 40));
System.out.print("Priority order: ");
while (!minHeap.isEmpty()) {
System.out.print(minHeap.poll() + " ");
}
// Output: Priority order: 10 20 30 40 50
System.out.println();
}
}
Type Safety Benefits in Practice
The real power of generic collections becomes apparent when you chain operations. Every step preserves type information, and the compiler verifies correctness throughout:
import java.util.*;
import java.util.stream.*;
public class TypeSafetyBenefitDemo {
record Student(String name, int grade, String major) {}
public static void main(String[] args) {
List students = List.of(
new Student("Alice", 92, "CS"),
new Student("Bob", 85, "Math"),
new Student("Charlie", 97, "CS"),
new Student("Diana", 88, "CS"),
new Student("Eve", 91, "Math")
);
// Every step is type-safe -- the compiler tracks types through the entire pipeline
Map> byMajor = students.stream()
.collect(Collectors.groupingBy(Student::major)); // Map>
Map avgGradeByMajor = students.stream()
.collect(Collectors.groupingBy(
Student::major, // K = String
Collectors.averagingInt(Student::grade) // V = Double
));
System.out.println("CS students: " + byMajor.get("CS"));
// Output: CS students: [Student[name=Alice, grade=92, major=CS], ...]
System.out.println("Average grades: " + avgGradeByMajor);
// Output: Average grades: {CS=92.33333333333333, Math=88.0}
// Optional -- not Optional
9. Recursive Type Bounds
A recursive type bound is a type parameter that is bounded by an expression involving the type parameter itself. The most common form is <T extends Comparable<T>>, which reads: "T is a type that can compare itself to other instances of T."
This pattern appears throughout the Java standard library and is essential for writing type-safe APIs that deal with ordering, self-referential structures, or fluent builders.
The Classic: <T extends Comparable<T>>
public class RecursiveTypeBoundDemo {
// Without recursive bound -- less type safe
// public static T findMax(List list) {
// // Can't call compareTo() because T is just Object
// }
// With recursive bound -- T must be comparable to itself
public static > T findMax(List list) {
if (list.isEmpty()) throw new IllegalArgumentException("Empty list");
T max = list.get(0);
for (T item : list) {
if (item.compareTo(max) > 0) {
max = item;
}
}
return max;
}
// Sorting with recursive bounds
public static > List sorted(List list) {
List copy = new ArrayList<>(list);
Collections.sort(copy); // Works because T is Comparable
return copy;
}
// Range check with recursive bounds
public static > boolean isBetween(T value, T low, T high) {
return value.compareTo(low) >= 0 && value.compareTo(high) <= 0;
}
public static void main(String[] args) {
System.out.println(findMax(List.of(3, 1, 4, 1, 5, 9))); // Output: 9
System.out.println(findMax(List.of("banana", "apple", "cherry"))); // Output: cherry
System.out.println(sorted(List.of(5, 2, 8, 1, 9))); // Output: [1, 2, 5, 8, 9]
System.out.println(isBetween(5, 1, 10)); // Output: true
System.out.println(isBetween(15, 1, 10)); // Output: false
System.out.println(isBetween("dog", "cat", "fox")); // Output: true
}
}
Fluent Builder with Recursive Generics
Recursive type bounds enable the curiously recurring template pattern (CRTP), which is particularly useful for builder hierarchies. Without it, a subclass builder's methods would return the parent builder type, breaking method chaining.
// Base class with a self-referential builder
public abstract class Pizza {
private final String size;
private final boolean cheese;
private final boolean pepperoni;
private final boolean mushrooms;
// T extends Builder -- the recursive bound
protected abstract static class Builder> {
private String size;
private boolean cheese;
private boolean pepperoni;
private boolean mushrooms;
// Each method returns T (the concrete builder type), not Builder
@SuppressWarnings("unchecked")
protected T self() {
return (T) this;
}
public T size(String size) {
this.size = size;
return self();
}
public T cheese(boolean cheese) {
this.cheese = cheese;
return self();
}
public T pepperoni(boolean pepperoni) {
this.pepperoni = pepperoni;
return self();
}
public T mushrooms(boolean mushrooms) {
this.mushrooms = mushrooms;
return self();
}
public abstract Pizza build();
}
protected Pizza(Builder builder) {
this.size = builder.size;
this.cheese = builder.cheese;
this.pepperoni = builder.pepperoni;
this.mushrooms = builder.mushrooms;
}
@Override
public String toString() {
return size + " pizza [cheese=" + cheese + ", pepperoni=" + pepperoni
+ ", mushrooms=" + mushrooms + "]";
}
}
// Subclass with its own builder that adds extra options
public class CalzonePizza extends Pizza {
private final boolean sauceInside;
public static class Builder extends Pizza.Builder {
private boolean sauceInside;
public Builder sauceInside(boolean sauceInside) {
this.sauceInside = sauceInside;
return self();
}
@Override
public CalzonePizza build() {
return new CalzonePizza(this);
}
@Override
protected Builder self() {
return this;
}
}
private CalzonePizza(Builder builder) {
super(builder);
this.sauceInside = builder.sauceInside;
}
}
// Usage -- method chaining works correctly across the class hierarchy
public class BuilderDemo {
public static void main(String[] args) {
CalzonePizza pizza = new CalzonePizza.Builder()
.size("Large") // returns CalzonePizza.Builder, not Pizza.Builder
.cheese(true) // still CalzonePizza.Builder
.pepperoni(true) // still CalzonePizza.Builder
.sauceInside(true) // CalzonePizza.Builder-specific method
.build();
System.out.println(pizza);
// Output: Large pizza [cheese=true, pepperoni=true, mushrooms=false]
}
}
Understanding Enum<E extends Enum<E>>
The Java Enum class uses the most famous recursive type bound in the language: Enum<E extends Enum<E>>. This ensures that enum methods like compareTo() and valueOf() work with the correct enum type, not just Enum in general.
When you write enum Color { RED, GREEN, BLUE }, the compiler generates class Color extends Enum<Color>. This means:
Color.RED.compareTo(Color.BLUE) works because Comparable<Color> is inherited
You cannot accidentally compare Color.RED to Size.LARGE -- the type system prevents it
Enum.valueOf(Color.class, "RED") returns Color, not Enum
10. Generic Utility Methods
One of the greatest strengths of generics is the ability to write reusable utility methods that work across all types while maintaining compile-time type safety. The Java standard library is full of these (see Collections, Arrays, Objects), and writing your own is a hallmark of senior-level Java development.
The java.util.Collections class is a masterclass in generic utility methods. Here are some of the most useful ones and how they leverage generics:
import java.util.*;
public class CollectionsUtilityDemo {
public static void main(String[] args) {
// -------------------------------------------------------
// Collections.sort() -- >
// -------------------------------------------------------
List names = new ArrayList<>(List.of("Charlie", "Alice", "Bob"));
Collections.sort(names);
System.out.println("Sorted: " + names); // Output: Sorted: [Alice, Bob, Charlie]
// -------------------------------------------------------
// Collections.unmodifiableList() -- List unmodifiableList(List)
// -------------------------------------------------------
List readOnly = Collections.unmodifiableList(names);
// readOnly.add("Diana"); // Throws UnsupportedOperationException
System.out.println("Unmodifiable: " + readOnly); // Output: Unmodifiable: [Alice, Bob, Charlie]
// -------------------------------------------------------
// Collections.singletonList() -- List singletonList(T o)
// -------------------------------------------------------
List single = Collections.singletonList("OnlyOne");
System.out.println("Singleton: " + single); // Output: Singleton: [OnlyOne]
// -------------------------------------------------------
// Collections.emptyList/Map/Set -- List emptyList()
// -------------------------------------------------------
List empty = Collections.emptyList();
System.out.println("Empty: " + empty); // Output: Empty: []
// -------------------------------------------------------
// Collections.synchronizedList() -- List synchronizedList(List)
// -------------------------------------------------------
List threadSafe = Collections.synchronizedList(new ArrayList<>(names));
System.out.println("Thread-safe: " + threadSafe);
// -------------------------------------------------------
// Collections.frequency() -- int frequency(Collection, Object)
// -------------------------------------------------------
List items = List.of("a", "b", "a", "c", "a");
System.out.println("Frequency of 'a': " + Collections.frequency(items, "a"));
// Output: Frequency of 'a': 3
// -------------------------------------------------------
// Collections.min/max with Comparator
// -------------------------------------------------------
String longest = Collections.max(names, Comparator.comparingInt(String::length));
System.out.println("Longest name: " + longest); // Output: Longest name: Charlie
}
}
11. Common Mistakes
Even experienced developers fall into these traps. Understanding these mistakes will save you hours of debugging and help you write cleaner generic code.
Mistake 1: Using Raw Types
A raw type is a generic type used without any type arguments. Raw types exist only for backward compatibility with pre-Java 5 code. There is never a valid reason to use them in new code.
public class RawTypeMistake {
public static void main(String[] args) {
// BAD -- raw type. The compiler cannot help you.
List names = new ArrayList();
names.add("Alice");
names.add(42); // No error -- but this is a bug
String first = (String) names.get(0); // Manual cast -- tedious
// String second = (String) names.get(1); // ClassCastException at runtime!
// GOOD -- parameterized type. The compiler has your back.
List safeNames = new ArrayList<>();
safeNames.add("Alice");
// safeNames.add(42); // COMPILE ERROR -- bug caught immediately
String safeFirst = safeNames.get(0); // No cast needed
}
}
Mistake 2: Trying to Instantiate Type Parameters
public class InstantiationMistake {
// BAD -- cannot instantiate T directly
// public static T createBad() {
// return new T(); // COMPILE ERROR
// }
// GOOD -- use a Supplier
public static T create(java.util.function.Supplier supplier) {
return supplier.get();
}
// GOOD -- use Class with reflection
public static T create(Class clazz) throws Exception {
return clazz.getDeclaredConstructor().newInstance();
}
public static void main(String[] args) throws Exception {
// Using Supplier (preferred -- no reflection, no exceptions)
String s = create(String::new);
ArrayList list = create(ArrayList::new);
// Using Class
String s2 = create(String.class);
System.out.println("Created: '" + s2 + "'"); // Output: Created: ''
}
}
Mistake 3: Generic Array Creation
public class GenericArrayMistake {
public static void main(String[] args) {
// BAD -- cannot create generic arrays directly
// List[] arrayOfLists = new List[10]; // COMPILE ERROR
// Why? Because arrays are "reified" -- they know their component type at runtime.
// But generics are erased -- List becomes just List at runtime.
// If Java allowed this, you could break type safety:
// Hypothetically, if it were allowed:
// Object[] objArray = arrayOfLists; // Arrays are covariant, so this would compile
// objArray[0] = List.of(42); // This is a List, stored in a List[] slot
// String s = arrayOfLists[0].get(0); // ClassCastException! Integer is not String
// GOOD -- use a List of Lists instead
List> listOfLists = new ArrayList<>();
listOfLists.add(List.of("Alice", "Bob"));
listOfLists.add(List.of("Charlie"));
// GOOD -- if you truly need an array, use a workaround with unchecked cast
@SuppressWarnings("unchecked")
List[] array = (List[]) new List[10];
array[0] = List.of("Hello");
System.out.println(array[0]); // Output: [Hello]
}
}
Mistake 4: Confusing extends in Generics vs Class Hierarchy
public class ExtendsConfusion {
public static void main(String[] args) {
// In class hierarchy: Integer IS-A Number (subtype relationship)
Number n = Integer.valueOf(42); // This works -- Integer extends Number
// But in generics: List IS NOT a List
// List numbers = new ArrayList(); // COMPILE ERROR!
// Why? Because if this were allowed:
// numbers.add(3.14); // This would be legal (Double is a Number)
// But the actual list is ArrayList -- a Double would corrupt it!
// This is called INVARIANCE: Generic types are invariant.
// List and List are NOT related, even though Integer extends Number.
// Solution 1: Use wildcards
List readOnly = new ArrayList(); // OK for reading
// Solution 2: Use the exact type
List numbers = new ArrayList<>(); // Both Integer and Double can go in
numbers.add(42);
numbers.add(3.14);
}
}
Mistake 5: Overloading with Type Erasure Conflicts
public class ErasureConflict {
// These two methods look different at the source level...
// public void process(List strings) { }
// public void process(List integers) { }
// ...but after erasure, both become:
// public void process(List strings) { }
// public void process(List integers) { }
// COMPILE ERROR: both methods have same erasure
// Solution: use different method names
public void processStrings(List strings) {
strings.forEach(s -> System.out.println("String: " + s));
}
public void processIntegers(List integers) {
integers.forEach(i -> System.out.println("Integer: " + i));
}
// Or use a single generic method
public void process(List items, String label) {
items.forEach(item -> System.out.println(label + ": " + item));
}
}
Mistake 6: Using Generics with Primitives
public class PrimitiveMistake {
public static void main(String[] args) {
// BAD -- generics do not support primitive types
// List numbers = new ArrayList<>(); // COMPILE ERROR
// GOOD -- use wrapper classes (autoboxing handles conversion)
List numbers = new ArrayList<>();
numbers.add(42); // autoboxing: int -> Integer
int value = numbers.get(0); // auto-unboxing: Integer -> int
// Be aware of boxing overhead in performance-critical code
// For large datasets, consider specialized collections:
// - IntStream, LongStream, DoubleStream (java.util.stream)
// - int[], double[] (plain arrays)
// - Third-party: Eclipse Collections IntList, Trove TIntArrayList
// Null danger with auto-unboxing
List data = new ArrayList<>();
data.add(null); // Allowed for Integer (it's an object)
// int bad = data.get(0); // NullPointerException! null cannot unbox to int
}
}
12. Best Practices
These best practices come from years of experience in the Java ecosystem and are distilled from Effective Java by Joshua Bloch, Java language specifications, and real-world codebase reviews. Following them will make your generic code safer, cleaner, and more maintainable.
Practice 1: Always Use Parameterized Types
Never use raw types. If you do not know the type, use <?> (unbounded wildcard) rather than leaving the type argument off entirely.
// BAD
List names = new ArrayList();
Map config = new HashMap();
// GOOD
List names = new ArrayList<>();
Map config = new HashMap<>();
// If you truly don't know the type, use unbounded wildcard
List unknownList = getListFromSomewhere();
// You can read from it (as Object), check size, iterate, etc.
Practice 2: Use Bounded Wildcards for API Flexibility
Public API methods should use wildcards in their parameters to be as flexible as possible for callers. This follows the PECS principle.
public class WildcardAPIBestPractice {
// LESS FLEXIBLE -- only accepts List, not List or List
public static double sumRigid(List numbers) {
return numbers.stream().mapToDouble(Number::doubleValue).sum();
}
// MORE FLEXIBLE -- accepts List, List, List, etc.
public static double sumFlexible(List numbers) {
return numbers.stream().mapToDouble(Number::doubleValue).sum();
}
// LESS FLEXIBLE -- only accepts Comparator
public static String maxRigid(List list, Comparator comparator) {
return list.stream().max(comparator).orElseThrow();
}
// MORE FLEXIBLE -- accepts Comparator
Practice 3: Prefer Generic Methods Over Wildcard Types in Return Values
Use wildcards in parameters (inputs) but avoid them in return types. A method that returns List<?> forces the caller to deal with an unknown type. Instead, use a type parameter so the caller gets a concrete type.
public class ReturnTypeBestPractice {
// BAD -- caller gets List, which is almost useless
public static List filterBad(List list) {
return list; // Caller can't do much with List
}
// GOOD -- caller gets List, preserving the type information
public static List filterGood(List list, Predicate predicate) {
return list.stream().filter(predicate).collect(Collectors.toList());
}
public static void main(String[] args) {
List names = List.of("Alice", "Bob", "Charlie", "Anna");
// filterGood returns List -- full type safety preserved
List aNames = filterGood(names, n -> n.startsWith("A"));
String first = aNames.get(0); // No cast needed
System.out.println(first); // Output: Alice
}
}
Practice 4: Use @SuppressWarnings("unchecked") Sparingly
Unchecked warnings exist for a reason -- they indicate a potential type safety hole. Only suppress them when you have carefully verified that the cast is safe, and always document why it is safe.
public class SuppressWarningsBestPractice {
// BAD -- suppressing at class or method level hides all warnings
// @SuppressWarnings("unchecked")
// public T[] toArray(List list) { ... }
// GOOD -- suppress at the narrowest possible scope with a comment
public static T[] toArray(List list, Class componentType) {
// Safe because we create the array with the correct component type
@SuppressWarnings("unchecked")
T[] array = (T[]) java.lang.reflect.Array.newInstance(componentType, list.size());
return list.toArray(array);
}
public static void main(String[] args) {
List names = List.of("Alice", "Bob", "Charlie");
String[] nameArray = toArray(names, String.class);
System.out.println(java.util.Arrays.toString(nameArray));
// Output: [Alice, Bob, Charlie]
}
}
Practice 5: Favor Generic Methods Over Raw Types for Interoperability
When you need to work with legacy code that uses raw types, wrap the interaction in a generic method that performs a checked cast, rather than spreading raw type usage throughout your code.
public class LegacyInteropBestPractice {
// Legacy code returns raw List
@SuppressWarnings("rawtypes")
public static List getLegacyData() {
List data = new java.util.ArrayList();
data.add("Alice");
data.add("Bob");
return data;
}
// Wrapper method: isolates the raw type and unchecked cast
@SuppressWarnings("unchecked") // Safe: we know getLegacyData() returns strings
public static List getLegacyNames() {
return (List) getLegacyData();
}
// Safer alternative: validate each element
public static List checkedCast(List raw, Class type) {
List result = new ArrayList<>();
for (Object item : raw) {
result.add(type.cast(item)); // Throws ClassCastException if wrong type
}
return result;
}
public static void main(String[] args) {
// All downstream code uses proper generics
List names = getLegacyNames();
names.forEach(name -> System.out.println(name.toUpperCase()));
// Output: ALICE
// BOB
// Extra-safe approach
List verified = checkedCast(getLegacyData(), String.class);
System.out.println("Verified: " + verified); // Output: Verified: [Alice, Bob]
}
}
Best Practices Summary
#
Practice
Rationale
1
Always use parameterized types -- never raw types
Raw types bypass compile-time type checking entirely
2
Use bounded wildcards in method parameters (PECS)
Makes APIs more flexible for callers without sacrificing type safety
3
Avoid wildcards in return types
Callers should receive concrete types, not unknowns
Let us bring everything together with a real-world example that demonstrates generic classes, generic methods, bounded type parameters, wildcards, and generic interfaces working in concert. We will build a type-safe in-memory repository -- a pattern you will encounter in Spring Boot, JPA, and virtually every data-driven Java application.
This example is designed to show how generics enable you to write a single piece of infrastructure code that works with any entity type, while the compiler ensures that you never accidentally mix up your User operations with your Product operations.
import java.util.*;
import java.util.concurrent.atomic.AtomicLong;
import java.util.function.Function;
import java.util.function.Predicate;
import java.util.stream.Collectors;
// ============================================================
// Step 1: Define a generic Identifiable interface
// ============================================================
// Any entity stored in our repository must have an ID
public interface Identifiable {
ID getId();
void setId(ID id);
}
// ============================================================
// Step 2: Define a generic Repository interface
// ============================================================
// T is the entity type, ID is the primary key type
// T must be Identifiable -- bounded type parameter
public interface CrudRepository, ID> {
T save(T entity);
Optional findById(ID id);
List findAll();
List findAll(Predicate filter); // Wildcard: consumer of T
List findAllMapped(Function mapper); // Generic method with wildcards
boolean existsById(ID id);
long count();
void deleteById(ID id);
void deleteAll();
}
// ============================================================
// Step 3: Implement a generic in-memory repository
// ============================================================
public class InMemoryCrudRepository>
implements CrudRepository {
private final Map store = new LinkedHashMap<>();
private final AtomicLong sequence = new AtomicLong(1);
@Override
public T save(T entity) {
if (entity.getId() == null) {
entity.setId(sequence.getAndIncrement());
}
store.put(entity.getId(), entity);
return entity;
}
@Override
public Optional findById(Long id) {
return Optional.ofNullable(store.get(id));
}
@Override
public List findAll() {
return new ArrayList<>(store.values());
}
// Wildcard in Predicate: accepts Predicate, Predicate
What This Example Demonstrates
Generic Feature
Where It Appears
Generic interface
Identifiable<ID>, CrudRepository<T, ID>
Bounded type parameter
T extends Identifiable<ID> in CrudRepository
Generic class
InMemoryCrudRepository<T>, EntityService<T>
Generic method
<R> List<R> findAllMapped(...)
Upper bounded wildcard
Function<? super T, ? extends R>
Lower bounded wildcard
Predicate<? super T>
Diamond operator
new InMemoryCrudRepository<>()
PECS principle
Predicate consumes T (super), Function produces R (extends)
Type safety
Cannot mix User and Product repositories
This is the power of generics: you write the repository logic once, and it works correctly and type-safely with User, Product, Order, or any entity you create in the future. The compiler guarantees that you cannot store a Product in a User repository, retrieve a User when you expected a Product, or pass the wrong type to a service method. All of these checks happen at compile time, with zero runtime overhead.
14. Quick Reference Cheat Sheet
Syntax
Name
Example
class Box<T>
Generic class
Box<String> box = new Box<>("hello");
<T> T method(T arg)
Generic method
String s = identity("hello");
<T extends Number>
Upper bounded type parameter
<T extends Comparable<T>> T max(T a, T b)
<T extends A & B>
Multiple bounds
<T extends Number & Comparable<T>>
? extends T
Upper bounded wildcard
List<? extends Number> -- read-only
? super T
Lower bounded wildcard
List<? super Integer> -- write-only
?
Unbounded wildcard
List<?> -- any type
<>
Diamond operator
new ArrayList<>() -- type inferred
PECS
Producer Extends, Consumer Super
Read = extends, Write = super
March 8, 2019
Static and Final keywords
1. What is the static Keyword?
The static keyword in Java means “belonging to the class itself, not to any particular instance.” When you declare a variable, method, block, or inner class as static, it is associated with the class as a whole rather than with individual objects created from that class.
Real-world analogy: Think of a school classroom. Every student (instance) has their own notebook (instance variable), but the whiteboard on the wall (static variable) is shared by everyone in the class. There is only one whiteboard, and if the teacher writes something on it, every student can see it. You do not need a specific student to access the whiteboard — you just walk into the classroom and look at it.
This is exactly how static works in Java. A static member belongs to the classroom (the class), not to any individual student (object). It exists in memory once, it is loaded when the class is first loaded by the JVM, and it can be accessed without creating any object.
Here are the key characteristics of the static keyword:
Shared across all instances — there is only one copy in memory, regardless of how many objects you create
Loaded when the class is loaded — static members exist before any object is created
Accessed via the class name — you do not need an object reference (though Java allows it, it is bad practice)
Cannot access instance members directly — static context has no this reference
The static keyword can be applied to four things in Java:
Applied To
What It Creates
Example
Variable
Class variable (shared by all instances)
static int count;
Method
Class method (callable without an object)
static void printInfo()
Block
Static initializer (runs once at class loading)
static { ... }
Inner Class
Static nested class (no outer instance needed)
static class Entry { }
2. Static Variables (Class Variables)
A static variable (also called a class variable) is a variable declared with the static keyword inside a class but outside any method or constructor. Unlike instance variables, which get their own copy for each object, a static variable has exactly one copy shared across all instances of the class.
Static variables are stored in the method area (or metaspace in modern JVMs), not on the heap with individual objects. They are initialized when the class is first loaded, and they persist for the entire lifetime of the application.
When to use static variables:
Counting how many instances have been created
Storing configuration values shared by all instances
Defining constants (combined with final)
Caching data that all objects should share
Let us start with a simple example that demonstrates the difference between static and instance variables:
public class Employee {
// Instance variable -- each Employee gets its own copy
private String name;
// Static variable -- shared across ALL Employee objects
private static int employeeCount = 0;
// Static variable -- company name is the same for all employees
private static String companyName = "TechCorp";
public Employee(String name) {
this.name = name;
employeeCount++; // Increment the shared counter
}
public String getName() {
return name;
}
public static int getEmployeeCount() {
return employeeCount;
}
public static String getCompanyName() {
return companyName;
}
public static void main(String[] args) {
System.out.println("Employees before: " + Employee.getEmployeeCount());
// Output: Employees before: 0
Employee emp1 = new Employee("Alice");
Employee emp2 = new Employee("Bob");
Employee emp3 = new Employee("Charlie");
System.out.println("Employees after: " + Employee.getEmployeeCount());
// Output: Employees after: 3
// All employees share the same company name
System.out.println(emp1.getName() + " works at " + Employee.getCompanyName());
// Output: Alice works at TechCorp
System.out.println(emp2.getName() + " works at " + Employee.getCompanyName());
// Output: Bob works at TechCorp
}
}
In the example above, employeeCount is incremented every time a new Employee is created. Because it is static, all three objects share the same counter. If it were an instance variable, each object would have its own counter stuck at 1.
Here is a memory visualization to make this concrete:
Memory Area
Variable
Value
Method Area (shared)
Employee.employeeCount
3
Method Area (shared)
Employee.companyName
“TechCorp”
Heap (emp1 object)
name
“Alice”
Heap (emp2 object)
name
“Bob”
Heap (emp3 object)
name
“Charlie”
A common real-world use of static variables is generating unique IDs:
public class Order {
private static int nextOrderId = 1000; // Shared counter for ID generation
private final int orderId;
private final String product;
private final double amount;
public Order(String product, double amount) {
this.orderId = nextOrderId++; // Assign and increment atomically
this.product = product;
this.amount = amount;
}
@Override
public String toString() {
return "Order{id=" + orderId + ", product='" + product + "', amount=$" + amount + "}";
}
public static void main(String[] args) {
Order order1 = new Order("Laptop", 999.99);
Order order2 = new Order("Mouse", 29.99);
Order order3 = new Order("Keyboard", 79.99);
System.out.println(order1); // Order{id=1000, product='Laptop', amount=$999.99}
System.out.println(order2); // Order{id=1001, product='Mouse', amount=$29.99}
System.out.println(order3); // Order{id=1002, product='Keyboard', amount=$79.99}
}
}
Important caveat: In a multi-threaded application, the nextOrderId++ pattern above is not thread-safe because the increment operation is not atomic. In production code, you would use AtomicInteger instead:
import java.util.concurrent.atomic.AtomicInteger;
public class ThreadSafeOrder {
// Thread-safe static counter
private static final AtomicInteger nextOrderId = new AtomicInteger(1000);
private final int orderId;
public ThreadSafeOrder() {
this.orderId = nextOrderId.getAndIncrement();
}
public int getOrderId() {
return orderId;
}
}
3. Static Methods
A static method belongs to the class, not to any instance. You call it using the class name, and it does not have access to this or any instance variables/methods. Static methods can only directly access other static members.
Rules for static methods:
Can be called without creating an object: ClassName.methodName()
Cannot use this or super keywords
Cannot access instance variables or instance methods directly
Can access other static variables and static methods
Cannot be overridden (they can be hidden, but that is different from polymorphic overriding)
You use static methods every day in Java without realizing it. Math.sqrt(), Integer.parseInt(), Collections.sort(), Arrays.asList() — these are all static methods. You never create a Math object to calculate a square root.
Utility Class Pattern
One of the most common uses of static methods is the utility class — a class that contains only static methods and has no state. Utility classes are never instantiated.
public final class StringUtils {
// Private constructor prevents instantiation
private StringUtils() {
throw new UnsupportedOperationException("Utility class cannot be instantiated");
}
/**
* Checks if a string is null or empty (after trimming whitespace).
*/
public static boolean isBlank(String str) {
return str == null || str.trim().isEmpty();
}
/**
* Capitalizes the first letter of a string.
*/
public static String capitalize(String str) {
if (isBlank(str)) {
return str;
}
return str.substring(0, 1).toUpperCase() + str.substring(1).toLowerCase();
}
/**
* Reverses a string.
*/
public static String reverse(String str) {
if (str == null) {
return null;
}
return new StringBuilder(str).reverse().toString();
}
/**
* Truncates a string to the specified length, adding "..." if truncated.
*/
public static String truncate(String str, int maxLength) {
if (str == null || str.length() <= maxLength) {
return str;
}
return str.substring(0, maxLength) + "...";
}
public static void main(String[] args) {
System.out.println(StringUtils.isBlank("")); // true
System.out.println(StringUtils.isBlank(" ")); // true
System.out.println(StringUtils.isBlank("hello")); // false
System.out.println(StringUtils.capitalize("hello")); // Hello
System.out.println(StringUtils.reverse("Java")); // avaJ
System.out.println(StringUtils.truncate("Hello, World!", 5)); // Hello...
}
}
Notice the key patterns in the utility class above: the class is final (cannot be extended), the constructor is private (cannot be instantiated), and all methods are static.
Static Factory Methods
Another important use of static methods is the factory method pattern. Instead of calling new directly, you call a static method that creates and returns an object. This has several advantages over constructors: you can give the method a descriptive name, you can return a cached instance, and you can return a subclass.
public class DatabaseConnection {
private final String host;
private final int port;
private final String database;
private final boolean ssl;
// Private constructor -- clients cannot call new DatabaseConnection()
private DatabaseConnection(String host, int port, String database, boolean ssl) {
this.host = host;
this.port = port;
this.database = database;
this.ssl = ssl;
}
// Static factory method -- descriptive name tells you what it creates
public static DatabaseConnection forProduction(String database) {
return new DatabaseConnection("prod-db.company.com", 5432, database, true);
}
// Another static factory method
public static DatabaseConnection forDevelopment(String database) {
return new DatabaseConnection("localhost", 5432, database, false);
}
// Another static factory method
public static DatabaseConnection forTesting() {
return new DatabaseConnection("localhost", 5432, "test_db", false);
}
@Override
public String toString() {
return String.format("Connection{host='%s', port=%d, db='%s', ssl=%s}",
host, port, database, ssl);
}
public static void main(String[] args) {
DatabaseConnection prod = DatabaseConnection.forProduction("users_db");
DatabaseConnection dev = DatabaseConnection.forDevelopment("users_db");
DatabaseConnection test = DatabaseConnection.forTesting();
System.out.println(prod);
// Connection{host='prod-db.company.com', port=5432, db='users_db', ssl=true}
System.out.println(dev);
// Connection{host='localhost', port=5432, db='users_db', ssl=false}
System.out.println(test);
// Connection{host='localhost', port=5432, db='test_db', ssl=false}
}
}
Why Static Methods Cannot Access Instance Members
This is one of the most common compiler errors beginners encounter. A static method exists without any object, so there is no this -- and therefore no way to know which object's instance variables to access.
public class StaticAccessDemo {
private String instanceVar = "I belong to an instance";
private static String staticVar = "I belong to the class";
// STATIC method
public static void staticMethod() {
System.out.println(staticVar); // OK -- accessing static from static
// System.out.println(instanceVar); // COMPILE ERROR: non-static variable
// // cannot be referenced from a static context
// System.out.println(this); // COMPILE ERROR: 'this' cannot be
// // referenced from a static context
}
// INSTANCE method -- can access everything
public void instanceMethod() {
System.out.println(instanceVar); // OK -- accessing instance from instance
System.out.println(staticVar); // OK -- accessing static from instance
staticMethod(); // OK -- calling static from instance
}
public static void main(String[] args) {
// Static method -- called on the class
StaticAccessDemo.staticMethod();
// Instance method -- requires an object
StaticAccessDemo obj = new StaticAccessDemo();
obj.instanceMethod();
}
}
4. Static Blocks (Static Initializers)
A static block (also called a static initializer) is a block of code enclosed in static { } that runs exactly once when the class is first loaded by the JVM. It runs before any constructor, before any static method is called, and before any object is created.
Static blocks are used for complex initialization of static variables -- things that cannot be done in a single line, such as loading configuration files, registering database drivers, populating lookup tables, or handling exceptions during initialization.
Key facts about static blocks:
Execute exactly once, when the class is loaded
Execute in the order they appear in the source code
Run before any constructor or instance initializer
Cannot throw checked exceptions (must handle them internally)
A class can have multiple static blocks -- they run in order
import java.util.*;
public class CountryLookup {
// Static map that will be populated in the static block
private static final Map COUNTRY_CODES;
private static final Map COUNTRY_NAMES;
// Static block -- runs once when CountryLookup class is loaded
static {
System.out.println("Static block 1: Initializing country codes...");
Map codes = new HashMap<>();
codes.put("US", "United States");
codes.put("GB", "United Kingdom");
codes.put("DE", "Germany");
codes.put("FR", "France");
codes.put("JP", "Japan");
codes.put("AU", "Australia");
codes.put("BR", "Brazil");
codes.put("IN", "India");
COUNTRY_CODES = Collections.unmodifiableMap(codes);
}
// Second static block -- runs after the first one
static {
System.out.println("Static block 2: Building reverse lookup...");
Map names = new HashMap<>();
for (Map.Entry entry : COUNTRY_CODES.entrySet()) {
names.put(entry.getValue().toLowerCase(), entry.getKey());
}
COUNTRY_NAMES = Collections.unmodifiableMap(names);
}
public static String getCountryName(String code) {
return COUNTRY_CODES.getOrDefault(code.toUpperCase(), "Unknown");
}
public static String getCountryCode(String name) {
return COUNTRY_NAMES.getOrDefault(name.toLowerCase(), "Unknown");
}
public static void main(String[] args) {
// The static blocks run BEFORE main executes
System.out.println("--- main() starts ---");
System.out.println(getCountryName("US")); // United States
System.out.println(getCountryName("JP")); // Japan
System.out.println(getCountryCode("Germany")); // DE
System.out.println(getCountryCode("Brazil")); // BR
}
}
// Output:
// Static block 1: Initializing country codes...
// Static block 2: Building reverse lookup...
// --- main() starts ---
// United States
// Japan
// DE
// BR
Notice in the output above that both static blocks ran before main() started executing. This is because main() is a static method of the class, and the class must be loaded before any of its methods can be called.
Here is a practical example showing a common real-world use case -- loading a JDBC driver and reading a configuration file:
import java.io.*;
import java.util.Properties;
public class AppConfig {
private static final Properties CONFIG = new Properties();
private static final String APP_VERSION;
static {
// Load configuration file
try (InputStream input = AppConfig.class
.getClassLoader()
.getResourceAsStream("application.properties")) {
if (input == null) {
System.err.println("Warning: application.properties not found, using defaults");
CONFIG.setProperty("db.host", "localhost");
CONFIG.setProperty("db.port", "5432");
CONFIG.setProperty("db.name", "myapp");
CONFIG.setProperty("app.version", "1.0.0-default");
} else {
CONFIG.load(input);
}
} catch (IOException e) {
throw new ExceptionInInitializerError("Failed to load configuration: " + e.getMessage());
}
APP_VERSION = CONFIG.getProperty("app.version", "unknown");
}
public static String get(String key) {
return CONFIG.getProperty(key);
}
public static String get(String key, String defaultValue) {
return CONFIG.getProperty(key, defaultValue);
}
public static String getVersion() {
return APP_VERSION;
}
}
Execution Order: Static Blocks, Instance Blocks, and Constructors
Understanding the execution order is critical for debugging initialization issues:
Notice that the static members (steps 1 and 2) run only once, while the instance members (steps 4, 5, and 6) run every time a new object is created.
5. Static Inner Classes (Static Nested Classes)
A static inner class (formally called a static nested class) is a class defined inside another class with the static modifier. Unlike a regular inner class, it does not need an instance of the outer class to be created. It is essentially a top-level class that is logically grouped inside another class for organizational purposes.
Key differences between static and non-static inner classes:
Feature
Static Nested Class
Inner Class (Non-Static)
Outer instance required?
No
Yes
Can access outer instance members?
No (only static members)
Yes (all members)
Creation syntax
new Outer.Inner()
outer.new Inner()
Has reference to outer class?
No
Yes (hidden reference)
Memory leak risk?
Low
Higher (holds outer reference)
The most famous example in the Java standard library is Map.Entry. You do not need a Map instance to create an Entry -- it is a static nested interface inside Map.
One of the most common uses in application code is the Builder pattern:
public class HttpRequest {
private final String url;
private final String method;
private final Map headers;
private final String body;
private final int timeoutMs;
// Private constructor -- only the Builder can create HttpRequest objects
private HttpRequest(Builder builder) {
this.url = builder.url;
this.method = builder.method;
this.headers = Collections.unmodifiableMap(builder.headers);
this.body = builder.body;
this.timeoutMs = builder.timeoutMs;
}
// Static nested class -- does NOT need an HttpRequest instance to exist
public static class Builder {
// Required
private final String url;
// Optional with defaults
private String method = "GET";
private Map headers = new HashMap<>();
private String body = null;
private int timeoutMs = 30000;
public Builder(String url) {
this.url = url;
}
public Builder method(String method) {
this.method = method;
return this;
}
public Builder header(String key, String value) {
this.headers.put(key, value);
return this;
}
public Builder body(String body) {
this.body = body;
return this;
}
public Builder timeout(int ms) {
this.timeoutMs = ms;
return this;
}
public HttpRequest build() {
return new HttpRequest(this);
}
}
@Override
public String toString() {
return method + " " + url + " (timeout=" + timeoutMs + "ms, headers=" + headers + ")";
}
public static void main(String[] args) {
// Builder is created without an HttpRequest instance
HttpRequest request = new HttpRequest.Builder("https://api.example.com/users")
.method("POST")
.header("Content-Type", "application/json")
.header("Authorization", "Bearer token123")
.body("{\"name\": \"Alice\"}")
.timeout(5000)
.build();
System.out.println(request);
// POST https://api.example.com/users (timeout=5000ms, headers={Authorization=Bearer token123, Content-Type=application/json})
}
}
Here is another practical example -- a linked list node as a static nested class:
public class LinkedList {
private Node head;
private int size;
// Static nested class -- Node does not need access to LinkedList's instance members
// The type parameter is independent of LinkedList's type parameter
private static class Node {
E data;
Node next;
Node(E data) {
this.data = data;
this.next = null;
}
}
public void addFirst(T element) {
Node newNode = new Node<>(element);
newNode.next = head;
head = newNode;
size++;
}
public T getFirst() {
if (head == null) {
throw new NoSuchElementException("List is empty");
}
return head.data;
}
public int size() {
return size;
}
public static void main(String[] args) {
LinkedList list = new LinkedList<>();
list.addFirst("Charlie");
list.addFirst("Bob");
list.addFirst("Alice");
System.out.println("First: " + list.getFirst()); // First: Alice
System.out.println("Size: " + list.size()); // Size: 3
}
}
6. Static Import
A static import allows you to use static members (fields and methods) of a class without qualifying them with the class name. Instead of writing Math.PI and Math.sqrt(), you can write PI and sqrt() directly.
Static imports were introduced in Java 5. They are useful for reducing verbosity when you frequently use static constants or utility methods from a specific class.
Syntax:
import static java.lang.Math.PI; -- imports a single static member
import static java.lang.Math.*; -- imports all static members from the class
// Without static import
public class CircleCalcVerbose {
public static void main(String[] args) {
double radius = 5.0;
double area = Math.PI * Math.pow(radius, 2);
double circumference = 2 * Math.PI * radius;
double diagonal = Math.sqrt(Math.pow(radius, 2) + Math.pow(radius, 2));
System.out.println("Area: " + area);
System.out.println("Circumference: " + circumference);
System.out.println("Diagonal: " + diagonal);
}
}
// With static import -- much cleaner for math-heavy code
import static java.lang.Math.PI;
import static java.lang.Math.pow;
import static java.lang.Math.sqrt;
public class CircleCalcClean {
public static void main(String[] args) {
double radius = 5.0;
double area = PI * pow(radius, 2);
double circumference = 2 * PI * radius;
double diagonal = sqrt(pow(radius, 2) + pow(radius, 2));
System.out.println("Area: " + area);
System.out.println("Circumference: " + circumference);
System.out.println("Diagonal: " + diagonal);
}
}
Static imports are also very common in unit tests with frameworks like JUnit and AssertJ:
Readability trade-offs: Static imports improve readability when the origin of the method is obvious (like PI, assertEquals), but they hurt readability when it is unclear where a method comes from. Use them sparingly and avoid wildcard imports (*) in production code.
Good Use
Bad Use
import static java.lang.Math.PI
import static com.utils.StringHelper.*
import static org.junit.Assert.* (in tests)
import static java.util.stream.Collectors.*
Constants everyone recognizes
Methods that could come from multiple places
7. What is the final Keyword?
The final keyword in Java means "this cannot be changed." It is a restriction that prevents modification, and it can be applied to three things: variables, methods, and classes. Each application has a different meaning, but they all share the same core idea -- once something is declared final, it is locked down.
Real-world analogy: Think of writing in permanent marker versus pencil. A pencil (non-final) lets you erase and rewrite. A permanent marker (final) means once you write something, it stays. You cannot change the text -- you can only read it.
Applied To
What It Prevents
Example
Variable
Reassignment (value cannot change)
final int MAX = 100;
Method
Overriding (subclasses cannot override)
final void process()
Class
Inheritance (cannot be extended)
final class String
The final keyword is one of the most important tools for writing robust, predictable, and thread-safe Java code. Experienced developers use it liberally because it communicates intent, catches bugs at compile time, and enables compiler optimizations.
8. Final Variables
A final variable can only be assigned once. After the assignment, any attempt to reassign it results in a compile-time error. There are several forms of final variables, each with its own rules.
8.1 Final Local Variables
A local variable declared final must be assigned exactly once before it is used. It does not need to be assigned at declaration -- it just cannot be reassigned.
public class FinalLocalVariables {
public static void main(String[] args) {
// Assigned at declaration -- cannot be changed
final int maxRetries = 3;
// maxRetries = 5; // COMPILE ERROR: cannot assign a value to final variable
// Blank final -- assigned later, but only once
final String greeting;
boolean isMorning = true;
if (isMorning) {
greeting = "Good morning!";
} else {
greeting = "Good afternoon!";
}
System.out.println(greeting); // Good morning!
// greeting = "Hello!"; // COMPILE ERROR: variable greeting might already have been assigned
// Final in a loop -- a new variable is created each iteration
for (int i = 0; i < 3; i++) {
final int value = i * 10; // This is fine -- each iteration creates a new scope
System.out.println(value); // 0, 10, 20
}
}
}
8.2 Final Instance Variables (Blank Finals)
A final instance variable must be assigned by the time the constructor finishes. It can be assigned in the declaration, in an instance initializer block, or in the constructor -- but exactly once.
public class ImmutableUser {
// Final instance variables -- set once, never changed
private final String username;
private final String email;
private final long createdAt;
// Assigned at declaration
private final String role = "USER";
public ImmutableUser(String username, String email) {
this.username = username;
this.email = email;
this.createdAt = System.currentTimeMillis();
// After the constructor finishes, these can NEVER be reassigned
}
// Only getters -- no setters for final fields
public String getUsername() { return username; }
public String getEmail() { return email; }
public long getCreatedAt() { return createdAt; }
public String getRole() { return role; }
public static void main(String[] args) {
ImmutableUser user = new ImmutableUser("alice", "alice@example.com");
System.out.println(user.getUsername()); // alice
System.out.println(user.getEmail()); // alice@example.com
System.out.println(user.getRole()); // USER
}
}
8.3 Final Parameters
Method parameters can be declared final to prevent reassignment inside the method body. This is considered good practice by many developers because it avoids accidental modification of input values.
public class FinalParameters {
// The 'final' keyword prevents reassigning the parameter
public static double calculateDiscount(final double price, final double discountRate) {
// price = price * 0.9; // COMPILE ERROR: final parameter cannot be assigned
// You must create a new variable instead
double discountedPrice = price * (1 - discountRate);
return discountedPrice;
}
// Common in constructors -- ensures you do not accidentally swap or modify parameters
public static class Product {
private final String name;
private final double price;
public Product(final String name, final double price) {
// These assignments are fine -- we are assigning TO the fields, not reassigning params
this.name = name;
this.price = price;
}
}
public static void main(String[] args) {
double result = calculateDiscount(100.0, 0.20);
System.out.println("Discounted price: $" + result); // Discounted price: $80.0
}
}
8.4 Constants (static final) and Naming Conventions
The combination of static and final creates a constant -- a value that belongs to the class and can never be changed. Java convention is to name constants using UPPER_SNAKE_CASE.
public class HttpStatus {
// Constants -- public static final with UPPER_SNAKE_CASE
public static final int OK = 200;
public static final int CREATED = 201;
public static final int NO_CONTENT = 204;
public static final int BAD_REQUEST = 400;
public static final int UNAUTHORIZED = 401;
public static final int FORBIDDEN = 403;
public static final int NOT_FOUND = 404;
public static final int INTERNAL_SERVER_ERROR = 500;
public static final String DEFAULT_CONTENT_TYPE = "application/json";
public static final long REQUEST_TIMEOUT_MS = 30_000L;
public static String getStatusMessage(int code) {
switch (code) {
case OK: return "OK";
case CREATED: return "Created";
case BAD_REQUEST: return "Bad Request";
case UNAUTHORIZED: return "Unauthorized";
case NOT_FOUND: return "Not Found";
case INTERNAL_SERVER_ERROR: return "Internal Server Error";
default: return "Unknown";
}
}
public static void main(String[] args) {
System.out.println(HttpStatus.OK + " " + getStatusMessage(OK));
// 200 OK
System.out.println(HttpStatus.NOT_FOUND + " " + getStatusMessage(NOT_FOUND));
// 404 Not Found
// HttpStatus.OK = 201; // COMPILE ERROR: cannot assign a value to final variable
}
}
9. Final Methods
A final method cannot be overridden by subclasses. When you declare a method as final, you are saying: "This is the definitive implementation. No subclass is allowed to change this behavior."
When to use final methods:
Template Method Pattern -- the parent class defines the algorithm structure, and subclasses override specific steps, but the overall template is final
Critical algorithms -- security-sensitive methods like authentication or encryption that must not be altered
Framework code -- methods that enforce invariants or contracts that subclasses must not break
Performance note: In older Java versions, declaring a method as final allowed the JVM to inline the method for better performance. Modern JVMs (HotSpot) are smart enough to do this optimization automatically, so performance is no longer a reason to use final methods. Use them for design correctness, not performance.
public abstract class DataProcessor {
// FINAL method -- defines the algorithm template. Subclasses CANNOT override this.
public final void process(String data) {
System.out.println("=== Starting data processing ===");
String validated = validate(data);
String transformed = transform(validated);
save(transformed);
System.out.println("=== Processing complete ===\n");
}
// These are the "hooks" that subclasses MUST implement
protected abstract String validate(String data);
protected abstract String transform(String data);
protected abstract void save(String data);
}
public class CsvProcessor extends DataProcessor {
// Cannot override process() -- it is final
// public void process(String data) { } // COMPILE ERROR
@Override
protected String validate(String data) {
System.out.println("Validating CSV format...");
if (!data.contains(",")) {
throw new IllegalArgumentException("Not valid CSV: " + data);
}
return data;
}
@Override
protected String transform(String data) {
System.out.println("Transforming CSV to uppercase...");
return data.toUpperCase();
}
@Override
protected void save(String data) {
System.out.println("Saving CSV: " + data);
}
}
public class JsonProcessor extends DataProcessor {
@Override
protected String validate(String data) {
System.out.println("Validating JSON format...");
if (!data.startsWith("{")) {
throw new IllegalArgumentException("Not valid JSON: " + data);
}
return data;
}
@Override
protected String transform(String data) {
System.out.println("Transforming JSON -- adding timestamp...");
return data.replace("}", ", \"processed\": true}");
}
@Override
protected void save(String data) {
System.out.println("Saving JSON: " + data);
}
}
public class Main {
public static void main(String[] args) {
DataProcessor csv = new CsvProcessor();
csv.process("name,age,city");
DataProcessor json = new JsonProcessor();
json.process("{\"name\": \"Alice\"}");
}
}
// Output:
// === Starting data processing ===
// Validating CSV format...
// Transforming CSV to uppercase...
// Saving CSV: NAME,AGE,CITY
// === Processing complete ===
//
// === Starting data processing ===
// Validating JSON format...
// Transforming JSON -- adding timestamp...
// Saving JSON: {"name": "Alice", "processed": true}
// === Processing complete ===
In the example above, the process() method is final. This guarantees that every subclass follows the same three-step algorithm: validate, transform, save. A subclass can customize each step, but it cannot skip a step, reorder them, or bypass the logging. This is the Template Method Pattern, and the final keyword is what makes it work.
10. Final Classes
A final class cannot be extended (subclassed). When you declare a class as final, no other class can inherit from it. This is the strongest form of the final keyword -- it locks down the entire class hierarchy.
Why would you make a class final?
Immutability -- If a class is designed to be immutable, making it final prevents subclasses from adding mutable state. This is why String, Integer, Double, and all wrapper classes are final.
Security -- Prevents malicious subclasses from overriding methods to bypass security checks.
Correctness -- If a class relies on specific invariants, subclasses might break those invariants.
Design intent -- The class is not designed for extension and would not work correctly as a base class.
Many well-known Java classes are final:
Final Class
Reason
java.lang.String
Immutability and security (used in class loading, security managers)
java.lang.Integer, Double, Boolean, etc.
Wrapper classes must be immutable
java.lang.Math
Utility class with only static methods
java.lang.System
Core system operations must not be overridden
// This class is final -- nobody can extend it
public final class Money {
private final long cents; // Store as cents to avoid floating-point issues
private final String currency;
public Money(long cents, String currency) {
if (cents < 0) {
throw new IllegalArgumentException("Amount cannot be negative");
}
if (currency == null || currency.length() != 3) {
throw new IllegalArgumentException("Currency must be a 3-letter ISO code");
}
this.cents = cents;
this.currency = currency.toUpperCase();
}
// Factory methods for convenience
public static Money dollars(double amount) {
return new Money(Math.round(amount * 100), "USD");
}
public static Money euros(double amount) {
return new Money(Math.round(amount * 100), "EUR");
}
public Money add(Money other) {
if (!this.currency.equals(other.currency)) {
throw new IllegalArgumentException("Cannot add different currencies: "
+ this.currency + " and " + other.currency);
}
return new Money(this.cents + other.cents, this.currency);
}
public Money multiply(int factor) {
return new Money(this.cents * factor, this.currency);
}
public double toDouble() {
return cents / 100.0;
}
@Override
public String toString() {
return String.format("%s %.2f", currency, toDouble());
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Money money = (Money) o;
return cents == money.cents && currency.equals(money.currency);
}
@Override
public int hashCode() {
return Objects.hash(cents, currency);
}
public static void main(String[] args) {
Money price = Money.dollars(29.99);
Money tax = Money.dollars(2.40);
Money total = price.add(tax);
System.out.println("Price: " + price); // Price: USD 29.99
System.out.println("Tax: " + tax); // Tax: USD 2.40
System.out.println("Total: " + total); // Total: USD 32.39
Money bulk = Money.euros(9.99).multiply(5);
System.out.println("Bulk: " + bulk); // Bulk: EUR 49.95
}
}
// This would cause a COMPILE ERROR:
// class ExtendedMoney extends Money { } // Cannot inherit from final 'Money'
11. Effectively Final (Java 8+)
Starting in Java 8, a local variable is considered effectively final if it is never reassigned after initialization, even if it is not explicitly declared with the final keyword. This matters because lambda expressions and anonymous inner classes can only capture local variables that are final or effectively final.
Before Java 8, you had to explicitly write final on every variable you wanted to use inside an anonymous class. Java 8 relaxed this rule -- if you never reassign the variable, the compiler treats it as final automatically.
import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;
public class EffectivelyFinalDemo {
public static void main(String[] args) {
// This variable is "effectively final" -- never reassigned
String prefix = "Hello, ";
List names = Arrays.asList("Alice", "Bob", "Charlie");
// Lambda can use 'prefix' because it is effectively final
List greetings = names.stream()
.map(name -> prefix + name) // 'prefix' captured here
.collect(Collectors.toList());
System.out.println(greetings);
// [Hello, Alice, Hello, Bob, Hello, Charlie]
// ------------------------------------
// This variable is NOT effectively final -- it is reassigned
String suffix = "!";
suffix = "!!"; // Reassignment makes it NOT effectively final
// This would cause a COMPILE ERROR:
// names.stream().map(name -> name + suffix);
// Error: local variables referenced from a lambda expression
// must be final or effectively final
}
}
Why does Java enforce this rule? When a lambda captures a local variable, it creates a copy of that variable's value. If the original variable could change after the lambda captured it, the lambda would have a stale copy, leading to confusing bugs. By requiring final or effectively final, Java guarantees consistency.
Here is a more practical example showing effectively final variables in event handling and callbacks:
import java.util.*;
import java.util.concurrent.*;
public class EffectivelyFinalPractical {
public static void main(String[] args) throws Exception {
// All of these are effectively final (never reassigned)
String apiUrl = "https://api.example.com/data";
int maxRetries = 3;
long timeoutMs = 5000L;
// They can all be used inside the lambda
ExecutorService executor = Executors.newSingleThreadExecutor();
Future future = executor.submit(() -> {
// All three variables are captured as effectively final
System.out.println("Fetching from: " + apiUrl);
System.out.println("Max retries: " + maxRetries);
System.out.println("Timeout: " + timeoutMs + "ms");
return "data from " + apiUrl;
});
System.out.println("Result: " + future.get());
executor.shutdown();
// ------------------------------------
// Workaround when you need to modify a "captured" variable:
// Use an array or AtomicInteger
List names = Arrays.asList("Alice", "Bob", "Charlie", "Diana");
// WRONG -- this would not compile:
// int count = 0;
// names.forEach(name -> count++);
// RIGHT -- use an array (the array reference is effectively final,
// even though its contents change)
int[] count = {0};
names.forEach(name -> {
if (name.length() > 3) {
count[0]++;
}
});
System.out.println("Names longer than 3 chars: " + count[0]);
// Names longer than 3 chars: 3
}
}
The table below summarizes the differences between final, effectively final, and non-final variables:
Type
Explicitly declared final?
Reassigned?
Usable in lambdas?
final int x = 10;
Yes
No (compile error)
Yes
int x = 10; (never reassigned)
No
No
Yes (effectively final)
int x = 10; x = 20;
No
Yes
No (compile error)
12. Static Final Constants
The combination of static and final is the standard way to define constants in Java. A static final variable belongs to the class (not any instance) and cannot be reassigned. It is the Java equivalent of const in other languages.
The Java compiler performs constant folding for static final primitive values and String literals -- it replaces references to the constant with the actual value at compile time. This means changing a constant requires recompiling all classes that reference it.
static final vs. enum
Before Java 5 introduced enums, developers used static final int constants to represent fixed sets of values (like days of the week, status codes, etc.). This pattern, known as the int enum pattern, has significant drawbacks that enums solve. Here is a comparison:
// OLD WAY: static final int constants (fragile, not type-safe)
public class PaymentStatusOld {
public static final int PENDING = 0;
public static final int COMPLETED = 1;
public static final int FAILED = 2;
public static final int REFUNDED = 3;
// Problem 1: Any int is accepted -- no type safety
public static void processPayment(int status) {
if (status == COMPLETED) {
System.out.println("Payment completed");
}
}
public static void main(String[] args) {
processPayment(COMPLETED); // OK
processPayment(42); // Compiles fine! No error. Bug hiding in plain sight.
processPayment(-1); // Also compiles fine.
}
}
// BETTER WAY: enum (type-safe, readable, extensible)
public enum PaymentStatus {
PENDING("Awaiting processing"),
COMPLETED("Payment successful"),
FAILED("Payment declined"),
REFUNDED("Payment refunded");
private final String description;
PaymentStatus(String description) {
this.description = description;
}
public String getDescription() {
return description;
}
}
public class PaymentProcessor {
// Problem solved: Only valid PaymentStatus values are accepted
public static void processPayment(PaymentStatus status) {
System.out.println("Status: " + status + " - " + status.getDescription());
}
public static void main(String[] args) {
processPayment(PaymentStatus.COMPLETED); // OK
// processPayment(42); // COMPILE ERROR -- not a PaymentStatus
}
}
When to use static final constants vs. enums:
Use static final
Use enum
Mathematical constants (PI, E)
Fixed set of related values (status, type, direction)
Configuration values (timeout, max retries)
Values that need methods or behavior
String constants (API keys, URLs, messages)
Values used in switch statements
Numeric limits (MAX_SIZE, MIN_AGE)
Values that benefit from type safety
13. Common Mistakes and Pitfalls
Even experienced developers fall into these traps. Understanding these pitfalls will save you hours of debugging.
Mistake 1: Accessing Instance Members from Static Context
This is the single most common static-related error for beginners. A static method has no this reference, so it cannot access instance variables or methods.
public class StaticMistake1 {
private String name = "Alice"; // Instance variable
private static String company = "TechCorp"; // Static variable
public static void main(String[] args) {
// COMPILE ERROR: non-static variable 'name' cannot be referenced from a static context
// System.out.println(name);
// This works -- 'company' is static
System.out.println(company);
// Fix: Create an instance first
StaticMistake1 obj = new StaticMistake1();
System.out.println(obj.name); // Now we can access 'name' through the object
}
}
Mistake 2: final Does NOT Mean Immutable
This is the most dangerous misconception about final. When you declare a reference variable as final, it means the reference cannot point to a different object. But the object itself can still be modified.
import java.util.*;
public class FinalNotImmutable {
public static void main(String[] args) {
// final reference -- cannot reassign the variable
final List names = new ArrayList<>();
// But we CAN modify the contents of the list!
names.add("Alice");
names.add("Bob");
names.add("Charlie");
System.out.println(names); // [Alice, Bob, Charlie]
names.remove("Bob");
System.out.println(names); // [Alice, Charlie]
names.clear();
System.out.println(names); // []
// This is what final prevents -- reassigning the reference
// names = new ArrayList<>(); // COMPILE ERROR: cannot assign a value to final variable
// To make truly immutable, use Collections.unmodifiableList or List.of()
final List immutableNames = List.of("Alice", "Bob", "Charlie");
// immutableNames.add("Diana"); // RUNTIME ERROR: UnsupportedOperationException
// immutableNames.remove("Alice"); // RUNTIME ERROR: UnsupportedOperationException
System.out.println(immutableNames); // [Alice, Bob, Charlie]
// Same applies to final maps, sets, arrays...
final int[] numbers = {1, 2, 3};
numbers[0] = 99; // This is allowed! Array contents can change.
System.out.println(Arrays.toString(numbers)); // [99, 2, 3]
// numbers = new int[5]; // COMPILE ERROR: cannot reassign final array reference
}
}
Mistake 3: Mutable Static Variables in Multi-Threaded Environments
Mutable static variables are shared across all threads. Without proper synchronization, concurrent modifications can cause data corruption, race conditions, and bugs that are extremely hard to reproduce.
import java.util.concurrent.atomic.AtomicInteger;
public class StaticThreadSafety {
// DANGEROUS: Mutable static variable without synchronization
private static int unsafeCounter = 0;
// SAFE: Using AtomicInteger for thread-safe operations
private static final AtomicInteger safeCounter = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
// Simulate 1000 threads incrementing the counter
Thread[] threads = new Thread[1000];
for (int i = 0; i < 1000; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < 100; j++) {
unsafeCounter++; // NOT thread-safe (race condition)
safeCounter.incrementAndGet(); // Thread-safe
}
});
threads[i].start();
}
// Wait for all threads to finish
for (Thread t : threads) {
t.join();
}
System.out.println("Expected: 100000");
System.out.println("Unsafe counter: " + unsafeCounter); // Often LESS than 100000
System.out.println("Safe counter: " + safeCounter.get()); // Always exactly 100000
}
}
Mistake 4: Static Blocks Run in Declaration Order
If your static blocks depend on each other, order matters. A static variable or block cannot reference another static member that is declared later in the file.
public class StaticOrderMistake {
// These run in order: first staticA, then static block, then staticB
static int staticA = 10;
static {
// staticA is 10 here -- already initialized
System.out.println("Static block: staticA = " + staticA);
// staticB is 0 here -- default value, not yet initialized to 20
// This is a subtle bug if you expect staticB to be 20
System.out.println("Static block: staticB = " + staticB); // Prints 0, not 20!
}
static int staticB = 20; // This assignment happens AFTER the static block
public static void main(String[] args) {
System.out.println("main: staticA = " + staticA); // 10
System.out.println("main: staticB = " + staticB); // 20
}
}
// Output:
// Static block: staticA = 10
// Static block: staticB = 0 <-- Surprise! Not 20!
// main: staticA = 10
// main: staticB = 20
14. Best Practices
Here are the guidelines that experienced Java developers follow when working with static and final:
Best Practices for static
Practice
Reason
Use static for utility methods that do not depend on object state
Clearer intent, no unnecessary object creation
Prefer static factory methods over constructors for complex creation logic
Descriptive names, can return cached instances or subclasses
Minimize mutable static state
Shared mutable state causes threading bugs and makes testing harder
Make utility classes final with a private constructor
Prevents instantiation and subclassing
Access static members via the class name, not an object reference
Math.PI instead of mathObj.PI -- clearer and less misleading
Use static inner classes instead of inner classes when the inner class does not need the outer instance
Avoids hidden reference to outer class, prevents memory leaks
Best Practices for final
Practice
Reason
Use final for all fields that should not change after construction
Enforces immutability, enables safe sharing between threads
Use static final for constants with UPPER_SNAKE_CASE
Standard Java naming convention, recognized by all developers
Prefer enum over static final int for type-safe sets of values
Compile-time type safety, readable in debugger and logs
Mark classes as final if they are not designed for inheritance
Prevents accidental subclassing that could break invariants
Use final on method parameters in complex methods
Prevents accidental reassignment, especially in long methods
Use effectively final variables in lambdas instead of adding final everywhere
Reduces noise; the compiler checks for you
Combined Best Practices
Immutable objects are thread-safe by definition. Using final fields and no setters means you never need synchronization for reads.
Static factory methods + private constructor + final class = the gold standard for value classes (like Money, Color, Point).
Avoid static mutable collections. If you must have a static collection, make it static final and wrap it with Collections.unmodifiableList() or use List.of().
Use final liberally. Many coding standards (including Google Java Style Guide) recommend making every variable final unless there is a reason not to.
15. Complete Practical Example: Application Configuration System
Let us bring everything together with a real-world example. This AppSettings class demonstrates static final constants, static utility methods, static blocks for initialization, final parameters, effectively final variables in lambdas, a static nested class, and immutable design -- all in one cohesive example.
This is the kind of code you would see in a production Spring Boot or enterprise Java application:
import java.util.*;
import java.util.stream.Collectors;
/**
* Application settings manager demonstrating static, final, and combined patterns.
* This class is final (cannot be subclassed) and uses static members extensively.
*/
public final class AppSettings {
// ========== STATIC FINAL CONSTANTS ==========
// These are true constants -- known at compile time, never change
public static final String APP_NAME = "MyApplication";
public static final String APP_VERSION = "2.5.1";
public static final int DEFAULT_PORT = 8080;
public static final int MAX_CONNECTIONS = 100;
public static final long SESSION_TIMEOUT_MS = 30 * 60 * 1000L; // 30 minutes
public static final String DATE_FORMAT = "yyyy-MM-dd HH:mm:ss";
// ========== STATIC FINAL COLLECTIONS (immutable) ==========
public static final List SUPPORTED_LANGUAGES;
public static final Map DEFAULT_HEADERS;
// ========== MUTABLE STATIC STATE (minimized, thread-safe) ==========
private static final Map settings = new HashMap<>();
private static boolean initialized = false;
// ========== STATIC BLOCKS ==========
// Complex initialization that cannot be done in a single line
static {
// Initialize supported languages
SUPPORTED_LANGUAGES = List.of("en", "es", "fr", "de", "ja", "pt", "zh");
}
static {
// Initialize default HTTP headers
Map headers = new LinkedHashMap<>();
headers.put("Content-Type", "application/json");
headers.put("Accept", "application/json");
headers.put("X-App-Name", APP_NAME);
headers.put("X-App-Version", APP_VERSION);
DEFAULT_HEADERS = Collections.unmodifiableMap(headers);
}
static {
// Load default settings
settings.put("db.host", "localhost");
settings.put("db.port", "5432");
settings.put("db.name", "myapp");
settings.put("log.level", "INFO");
settings.put("cache.enabled", "true");
settings.put("cache.ttl.seconds", "300");
initialized = true;
System.out.println("[AppSettings] Initialized with " + settings.size() + " default settings");
}
// ========== PRIVATE CONSTRUCTOR ==========
// Prevents instantiation -- this is a utility/configuration class
private AppSettings() {
throw new UnsupportedOperationException("AppSettings cannot be instantiated");
}
// ========== STATIC METHODS ==========
/**
* Gets a setting value by key.
*
* @param key the setting key (final -- cannot be reassigned in the method)
* @return the value, or null if not found
*/
public static String get(final String key) {
Objects.requireNonNull(key, "Setting key cannot be null");
return settings.get(key);
}
/**
* Gets a setting value with a default fallback.
*/
public static String get(final String key, final String defaultValue) {
String value = settings.get(key);
return value != null ? value : defaultValue;
}
/**
* Gets a setting as an integer.
*/
public static int getInt(final String key, final int defaultValue) {
String value = settings.get(key);
if (value == null) {
return defaultValue;
}
try {
return Integer.parseInt(value);
} catch (NumberFormatException e) {
System.err.println("[AppSettings] Warning: '" + key + "' is not a valid integer: " + value);
return defaultValue;
}
}
/**
* Gets a setting as a boolean.
*/
public static boolean getBoolean(final String key, final boolean defaultValue) {
String value = settings.get(key);
return value != null ? Boolean.parseBoolean(value) : defaultValue;
}
/**
* Sets a configuration value.
*/
public static void set(final String key, final String value) {
Objects.requireNonNull(key, "Setting key cannot be null");
Objects.requireNonNull(value, "Setting value cannot be null");
settings.put(key, value);
}
/**
* Returns all settings whose keys start with the given prefix.
* Demonstrates effectively final variables in lambda expressions.
*/
public static Map getByPrefix(final String prefix) {
// 'prefix' is effectively final (also explicitly final here)
// so it can be used inside the lambda
return settings.entrySet().stream()
.filter(entry -> entry.getKey().startsWith(prefix))
.collect(Collectors.toMap(
Map.Entry::getKey,
Map.Entry::getValue,
(v1, v2) -> v1,
LinkedHashMap::new
));
}
/**
* Prints a formatted summary of all settings.
*/
public static void printSummary() {
// 'separator' is effectively final -- used in lambda below
String separator = "=".repeat(50);
System.out.println(separator);
System.out.println(APP_NAME + " v" + APP_VERSION + " Configuration");
System.out.println(separator);
settings.entrySet().stream()
.sorted(Map.Entry.comparingByKey())
.forEach(entry -> System.out.printf(" %-25s = %s%n",
entry.getKey(), entry.getValue()));
System.out.println(separator);
System.out.println("Supported languages: " + SUPPORTED_LANGUAGES);
System.out.println("Default headers: " + DEFAULT_HEADERS);
System.out.println(separator);
}
/**
* Creates a snapshot of current settings.
* Returns a SettingsSnapshot (static nested class).
*/
public static SettingsSnapshot snapshot() {
return new SettingsSnapshot(new HashMap<>(settings));
}
// ========== STATIC NESTED CLASS ==========
// Does not need an AppSettings instance (which cannot be created anyway)
/**
* An immutable snapshot of settings at a point in time.
* This is a static nested class -- it does not hold a reference to AppSettings.
*/
public static final class SettingsSnapshot {
private final Map data;
private final long timestamp;
private SettingsSnapshot(final Map data) {
this.data = Collections.unmodifiableMap(data);
this.timestamp = System.currentTimeMillis();
}
public String get(final String key) {
return data.get(key);
}
public int size() {
return data.size();
}
public long getTimestamp() {
return timestamp;
}
@Override
public String toString() {
return "SettingsSnapshot{size=" + data.size() + ", timestamp=" + timestamp + "}";
}
}
// ========== MAIN METHOD -- Demonstrates everything ==========
public static void main(String[] args) {
// Static final constants -- accessed via class name
System.out.println("App: " + AppSettings.APP_NAME + " v" + AppSettings.APP_VERSION);
System.out.println("Default port: " + AppSettings.DEFAULT_PORT);
System.out.println("Session timeout: " + AppSettings.SESSION_TIMEOUT_MS + "ms");
System.out.println();
// Static methods -- called without creating an object
System.out.println("DB Host: " + AppSettings.get("db.host"));
System.out.println("DB Port: " + AppSettings.getInt("db.port", 3306));
System.out.println("Cache enabled: " + AppSettings.getBoolean("cache.enabled", false));
System.out.println();
// Modify settings at runtime
AppSettings.set("db.host", "prod-db.company.com");
AppSettings.set("log.level", "DEBUG");
AppSettings.set("feature.dark-mode", "true");
// Get settings by prefix (uses lambda with effectively final variable)
Map dbSettings = AppSettings.getByPrefix("db.");
System.out.println("Database settings: " + dbSettings);
System.out.println();
// Static nested class -- created without AppSettings instance
AppSettings.SettingsSnapshot snap = AppSettings.snapshot();
System.out.println("Snapshot: " + snap);
System.out.println("Snapshot db.host: " + snap.get("db.host"));
// The snapshot is immutable -- changes to AppSettings do not affect it
AppSettings.set("db.host", "new-host.example.com");
System.out.println("Live db.host: " + AppSettings.get("db.host"));
System.out.println("Snapshot db.host: " + snap.get("db.host")); // Still old value
System.out.println();
// Print full summary
AppSettings.printSummary();
}
}
// Output:
// [AppSettings] Initialized with 6 default settings
// App: MyApplication v2.5.1
// Default port: 8080
// Session timeout: 1800000ms
//
// DB Host: localhost
// DB Port: 5432
// Cache enabled: true
//
// Database settings: {db.host=prod-db.company.com, db.port=5432, db.name=myapp}
//
// Snapshot: SettingsSnapshot{size=7, timestamp=1709136000000}
// Snapshot db.host: prod-db.company.com
// Live db.host: new-host.example.com
// Snapshot db.host: prod-db.company.com
//
// ==================================================
// MyApplication v2.5.1 Configuration
// ==================================================
// cache.enabled = true
// cache.ttl.seconds = 300
// db.host = new-host.example.com
// db.name = myapp
// db.port = 5432
// feature.dark-mode = true
// log.level = DEBUG
// ==================================================
// Supported languages: [en, es, fr, de, ja, pt, zh]
// Default headers: {Content-Type=application/json, Accept=application/json, X-App-Name=MyApplication, X-App-Version=2.5.1}
// ==================================================
Summary
Here is a quick reference of everything covered in this tutorial:
Keyword
Applied To
Effect
static
Variable
One copy shared by all instances (class variable)
static
Method
Belongs to the class; callable without an object
static
Block
Runs once when the class is loaded (static initializer)
static
Inner Class
Nested class that does not require an outer instance
static import
Import
Allows using static members without class name qualification
Never reassigned; usable in lambdas without final keyword
Key takeaways for your career:
Use static for things that belong to the class, not to instances -- utility methods, constants, counters, factory methods
Use final to prevent change -- immutable fields, constants, template methods, sealed classes
Remember that final prevents reassignment, not mutation -- a final List can still have elements added to it
Prefer enum over static final int for type-safe sets of values
Minimize mutable static state -- it causes concurrency bugs and makes testing difficult
Use static final with UPPER_SNAKE_CASE for constants -- this is the universal Java convention
Embrace effectively final variables in lambdas -- they keep your code clean without verbose final declarations
March 8, 2019
Exception Handling
1. What is Exception Handling?
An exception is an unexpected event that occurs during the execution of a program and disrupts the normal flow of instructions. Exception handling is the mechanism Java provides to detect these events and respond to them gracefully, so your program does not crash.
Think of it like a safety net under a tightrope walker. The walker (your program) is crossing a bridge (executing code). If the bridge breaks (an error occurs), instead of falling to the ground (crashing), the walker lands safely in the net (the exception handler) and can decide what to do next – try again, take a different path, or alert someone for help.
Without exception handling, any unexpected situation – a missing file, a network timeout, dividing by zero, accessing a null reference – causes your program to terminate immediately with an ugly stack trace. In a production application serving thousands of users, that is unacceptable.
Here is what happens when you do not handle an exception:
public class NoHandling {
public static void main(String[] args) {
int numerator = 10;
int denominator = 0;
// This line throws ArithmeticException -- program crashes here
int result = numerator / denominator;
// This line NEVER executes
System.out.println("Result: " + result);
System.out.println("Program finished.");
}
}
// Output:
// Exception in thread "main" java.lang.ArithmeticException: / by zero
// at NoHandling.main(NoHandling.java:7)
Notice two important things: the program crashed immediately at line 7, and the remaining lines never executed. Now compare that with proper exception handling:
public class WithHandling {
public static void main(String[] args) {
int numerator = 10;
int denominator = 0;
try {
int result = numerator / denominator;
System.out.println("Result: " + result);
} catch (ArithmeticException e) {
System.out.println("Error: Cannot divide by zero.");
}
// This line DOES execute because the exception was handled
System.out.println("Program finished.");
}
}
// Output:
// Error: Cannot divide by zero.
// Program finished.
With exception handling, the program catches the error, handles it gracefully, and continues running. This is the fundamental purpose of exception handling: keeping your program alive and responsive, even when things go wrong.
Common situations that cause exceptions:
Trying to read a file that does not exist (FileNotFoundException)
Accessing an array element beyond its bounds (ArrayIndexOutOfBoundsException)
Calling a method on a null reference (NullPointerException)
Connecting to a database that is down (SQLException)
Parsing a non-numeric string as a number (NumberFormatException)
Running out of memory (OutOfMemoryError)
2. Exception Hierarchy
Java organizes all exceptions and errors in a class hierarchy rooted at the Throwable class. Understanding this hierarchy is essential because it determines which exceptions you can catch, which you must declare, and which you should never try to handle.
Throwable is the root class of Java’s exception hierarchy. Only objects that are instances of Throwable (or its subclasses) can be thrown with the throw keyword or caught with a catch block. It has two direct subclasses: Error and Exception.
Error (Do Not Catch)
Error represents serious problems that a reasonable application should not try to catch or recover from. These are typically conditions where the JVM itself is in trouble:
OutOfMemoryError – The JVM ran out of heap memory. You cannot meaningfully recover from this.
StackOverflowError – A method called itself recursively too many times, exhausting the call stack.
VirtualMachineError – The JVM is broken or has run out of resources to operate.
If you see an Error, the correct response is usually to fix the root cause in your code (e.g., fix the infinite recursion) or increase JVM resources (e.g., increase heap size with -Xmx), not to catch it at runtime.
Exception (The Ones You Handle)
Exception represents conditions that a program might reasonably want to catch and recover from. This class branches into two categories based on whether the compiler forces you to handle them:
Checked Exceptions – Direct subclasses of Exception (but not RuntimeException). The compiler requires you to handle or declare them.
Unchecked Exceptions – Subclasses of RuntimeException. The compiler does not force you to handle them.
3. Checked vs Unchecked Exceptions
This is one of the most important distinctions in Java and a common interview question. The difference comes down to one question: does the compiler force you to handle it?
Checked Exceptions
Checked exceptions are exceptions that the compiler checks at compile time. If a method can throw a checked exception, you must either catch it with a try-catch block or declare it in the method signature with the throws keyword. If you do neither, your code will not compile.
Checked exceptions represent recoverable conditions that are outside your program’s control – things like a file not existing, a network connection failing, or a database being unavailable. The compiler forces you to think about these scenarios.
Common checked exceptions:
IOException – Input/output operation failed
FileNotFoundException – File does not exist at the specified path
SQLException – Database access error
ClassNotFoundException – A class could not be found at runtime
InterruptedException – A thread was interrupted while waiting
ParseException – Error while parsing a date or other formatted text
import java.io.FileReader;
import java.io.IOException;
public class CheckedExample {
public static void main(String[] args) {
// This will NOT compile without handling IOException
// FileReader constructor throws FileNotFoundException (a checked exception)
// Option 1: Handle with try-catch
try {
FileReader reader = new FileReader("data.txt");
int character = reader.read(); // read() throws IOException
System.out.println((char) character);
reader.close();
} catch (IOException e) {
System.out.println("Could not read file: " + e.getMessage());
}
}
// Option 2: Declare with throws
public static void readFile() throws IOException {
FileReader reader = new FileReader("data.txt");
int character = reader.read();
System.out.println((char) character);
reader.close();
}
}
Unchecked Exceptions (Runtime Exceptions)
Unchecked exceptions are subclasses of RuntimeException. The compiler does not require you to handle or declare them. They typically represent programming bugs – mistakes in your logic that should be fixed in the code itself, not caught at runtime.
Common unchecked exceptions:
NullPointerException – Called a method on a null reference
ArrayIndexOutOfBoundsException – Accessed an invalid array index
IllegalArgumentException – Passed an invalid argument to a method
ArithmeticException – Illegal arithmetic operation (e.g., divide by zero)
NumberFormatException – Tried to parse a non-numeric string
ClassCastException – Invalid type cast
IllegalStateException – Method called at an inappropriate time
UnsupportedOperationException – Requested operation is not supported
public class UncheckedExample {
public static void main(String[] args) {
// NullPointerException -- calling method on null
String name = null;
// name.length(); // Throws NullPointerException
// ArrayIndexOutOfBoundsException -- invalid index
int[] numbers = {1, 2, 3};
// int value = numbers[5]; // Throws ArrayIndexOutOfBoundsException
// NumberFormatException -- invalid number format
// int num = Integer.parseInt("abc"); // Throws NumberFormatException
// ArithmeticException -- divide by zero
// int result = 10 / 0; // Throws ArithmeticException
// IllegalArgumentException -- invalid argument
// Thread.sleep(-1); // Throws IllegalArgumentException
// You CAN catch unchecked exceptions, but often it is better
// to prevent them with proper validation
String input = "abc";
try {
int parsed = Integer.parseInt(input);
System.out.println("Parsed: " + parsed);
} catch (NumberFormatException e) {
System.out.println("'" + input + "' is not a valid number");
}
}
}
// Output:
// 'abc' is not a valid number
Comparison Table
Feature
Checked Exception
Unchecked Exception
Superclass
Exception (excluding RuntimeException)
RuntimeException
Compile-time check
Yes – must handle or declare
No – compiler does not enforce
Typical cause
External conditions (file, network, database)
Programming bugs (null, bad index, bad cast)
Recovery
Often recoverable (retry, fallback, user prompt)
Usually indicates a bug to fix in code
Examples
IOException, SQLException, FileNotFoundException
NullPointerException, IllegalArgumentException
Best approach
Catch and handle, or propagate with throws
Prevent with validation and null checks
4. The try-catch Block
The try-catch block is the fundamental mechanism for handling exceptions in Java. You place risky code inside the try block, and the code that handles the error goes in the catch block.
Basic Syntax
try {
// Code that might throw an exception
// If an exception occurs, execution jumps to the matching catch block
} catch (ExceptionType variableName) {
// Code to handle the exception
// Only runs if the exception type matches
}
Here is how it works step by step:
Java executes the code inside the try block line by line.
If no exception occurs, the entire try block runs, the catch block is skipped, and execution continues after the catch.
If an exception occurs on any line, execution immediately jumps to the first matching catch block. The remaining lines in the try block are skipped.
After the catch block finishes, execution continues normally after the entire try-catch structure.
public class TryCatchFlow {
public static void main(String[] args) {
System.out.println("1. Before try block");
try {
System.out.println("2. Inside try -- before risky code");
int result = 10 / 0; // ArithmeticException thrown here
System.out.println("3. Inside try -- after risky code"); // SKIPPED
} catch (ArithmeticException e) {
System.out.println("4. Inside catch -- handling error");
}
System.out.println("5. After try-catch -- program continues");
}
}
// Output:
// 1. Before try block
// 2. Inside try -- before risky code
// 4. Inside catch -- handling error
// 5. After try-catch -- program continues
Multiple catch Blocks
A single try block can have multiple catch blocks to handle different types of exceptions differently. Java checks them from top to bottom and executes the first matching block. Because of this, you must order catch blocks from most specific to most general. If you put a parent exception class before a child, the child catch will be unreachable, and the compiler will report an error.
public class MultipleCatch {
public static void main(String[] args) {
String[] data = {"10", "abc", null};
for (String item : data) {
try {
// Could throw NullPointerException if item is null
int length = item.length();
// Could throw NumberFormatException if item is not numeric
int number = Integer.parseInt(item);
// Could throw ArithmeticException
int result = 100 / number;
System.out.println("100 / " + number + " = " + result);
} catch (NullPointerException e) {
System.out.println("Error: input is null");
} catch (NumberFormatException e) {
System.out.println("Error: '" + item + "' is not a number");
} catch (ArithmeticException e) {
System.out.println("Error: division by zero");
}
}
}
}
// Output:
// 100 / 10 = 10
// Error: 'abc' is not a number
// Error: input is null
Exception Object Methods
When you catch an exception, you receive an exception object that contains useful information for debugging. Here are the most commonly used methods:
Method
Returns
Purpose
getMessage()
String
A human-readable description of the error
printStackTrace()
void
Prints the full stack trace to standard error (useful for debugging)
getCause()
Throwable
Returns the underlying exception that caused this one (may be null)
getClass().getName()
String
Returns the fully qualified class name of the exception
getStackTrace()
StackTraceElement[]
Returns the stack trace as an array (for programmatic access)
public class ExceptionMethods {
public static void main(String[] args) {
try {
int[] arr = new int[3];
arr[10] = 42; // Invalid index
} catch (ArrayIndexOutOfBoundsException e) {
// getMessage() -- short description
System.out.println("Message: " + e.getMessage());
// getClass().getName() -- exception type
System.out.println("Type: " + e.getClass().getName());
// getCause() -- underlying cause (null if none)
System.out.println("Cause: " + e.getCause());
// printStackTrace() -- full stack trace (printed to System.err)
System.out.println("\nFull stack trace:");
e.printStackTrace();
}
}
}
// Output:
// Message: Index 10 out of bounds for length 3
// Type: java.lang.ArrayIndexOutOfBoundsException
// Cause: null
//
// Full stack trace:
// java.lang.ArrayIndexOutOfBoundsException: Index 10 out of bounds for length 3
// at ExceptionMethods.main(ExceptionMethods.java:5)
5. The finally Block
The finally block is an optional block that comes after try and catch. Its purpose is to execute cleanup code that should always run, regardless of whether an exception occurred or not. This makes it perfect for releasing resources like file handles, database connections, or network sockets.
The finally block runs in all of these scenarios:
The try block completes normally (no exception)
An exception is thrown and caught by a catch block
An exception is thrown but not caught (finally still runs before the exception propagates)
The try or catch block contains a return statement (finally runs before the return)
The only situation where finally does not run is if the JVM itself shuts down (via System.exit()) or the JVM crashes.
public class FinallyDemo {
public static void main(String[] args) {
// Scenario 1: No exception
System.out.println("--- Scenario 1: No exception ---");
try {
System.out.println("Try: doing work...");
} catch (Exception e) {
System.out.println("Catch: handling error");
} finally {
System.out.println("Finally: cleanup runs");
}
// Scenario 2: Exception caught
System.out.println("\n--- Scenario 2: Exception caught ---");
try {
int result = 10 / 0;
} catch (ArithmeticException e) {
System.out.println("Catch: " + e.getMessage());
} finally {
System.out.println("Finally: cleanup runs");
}
// Scenario 3: finally runs even with return
System.out.println("\n--- Scenario 3: Return in try ---");
System.out.println("getValue() returned: " + getValue());
}
public static String getValue() {
try {
System.out.println("Try: about to return");
return "from try";
} finally {
System.out.println("Finally: runs BEFORE the return");
}
}
}
// Output:
// --- Scenario 1: No exception ---
// Try: doing work...
// Finally: cleanup runs
//
// --- Scenario 2: Exception caught ---
// Catch: / by zero
// Finally: cleanup runs
//
// --- Scenario 3: Return in try ---
// Try: about to return
// Finally: runs BEFORE the return
// getValue() returned: from try
Classic Pattern: Resource Cleanup with finally
Before Java 7, the standard pattern for working with resources was to open them in the try block and close them in finally. This ensured resources were always released, even if an exception occurred:
import java.io.FileReader;
import java.io.BufferedReader;
import java.io.IOException;
public class FinallyResourceCleanup {
public static void main(String[] args) {
BufferedReader reader = null;
try {
reader = new BufferedReader(new FileReader("data.txt"));
String line = reader.readLine();
System.out.println("First line: " + line);
} catch (IOException e) {
System.out.println("Error reading file: " + e.getMessage());
} finally {
// Always close the resource, even if an exception occurred
if (reader != null) {
try {
reader.close();
} catch (IOException e) {
System.out.println("Error closing reader: " + e.getMessage());
}
}
}
}
}
Notice how ugly this code is. The finally block needs its own try-catch because close() can also throw an IOException. You also need a null check because the reader might not have been created if the constructor threw an exception. This boilerplate is exactly why Java 7 introduced try-with-resources.
6. try-with-resources (Java 7+)
The try-with-resources statement, introduced in Java 7, automatically closes resources when the try block finishes. A resource is any object that implements the AutoCloseable interface (which has a single close() method). This eliminates the need for verbose finally blocks when working with I/O, database connections, or any closeable resource.
Syntax
// Resource is declared inside parentheses after 'try'
// It is automatically closed when the try block ends
try (ResourceType resource = new ResourceType()) {
// Use the resource
// resource.close() is called automatically when this block ends
} catch (ExceptionType e) {
// Handle exceptions
}
// No finally block needed for closing!
Compare the same file-reading code from the previous section, now using try-with-resources:
import java.io.FileReader;
import java.io.BufferedReader;
import java.io.IOException;
public class TryWithResourcesDemo {
public static void main(String[] args) {
// BufferedReader is AutoCloseable -- it will be closed automatically
try (BufferedReader reader = new BufferedReader(new FileReader("data.txt"))) {
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
} catch (IOException e) {
System.out.println("Error: " + e.getMessage());
}
// reader.close() is called automatically -- no finally needed!
}
}
Multiple Resources
You can declare multiple resources separated by semicolons. They are closed in reverse order of declaration (last opened, first closed):
import java.io.*;
public class MultipleResources {
public static void main(String[] args) {
// Both reader and writer are auto-closed when the block ends
// writer is closed first, then reader (reverse order)
try (
BufferedReader reader = new BufferedReader(new FileReader("input.txt"));
BufferedWriter writer = new BufferedWriter(new FileWriter("output.txt"))
) {
String line;
while ((line = reader.readLine()) != null) {
writer.write(line.toUpperCase());
writer.newLine();
}
System.out.println("File copied and converted to uppercase.");
} catch (IOException e) {
System.out.println("Error: " + e.getMessage());
}
}
}
Creating Your Own AutoCloseable Resource
Any class can be used with try-with-resources by implementing the AutoCloseable interface:
public class DatabaseConnection implements AutoCloseable {
private String connectionId;
public DatabaseConnection(String url) {
this.connectionId = "conn-" + System.currentTimeMillis();
System.out.println("Opening connection " + connectionId + " to " + url);
}
public void executeQuery(String sql) {
System.out.println("[" + connectionId + "] Executing: " + sql);
}
@Override
public void close() {
System.out.println("Closing connection " + connectionId);
}
public static void main(String[] args) {
try (DatabaseConnection db = new DatabaseConnection("jdbc:mysql://localhost/mydb")) {
db.executeQuery("SELECT * FROM users");
db.executeQuery("UPDATE users SET active = true WHERE id = 1");
}
// close() is called automatically
}
}
// Output:
// Opening connection conn-1709123456789 to jdbc:mysql://localhost/mydb
// [conn-1709123456789] Executing: SELECT * FROM users
// [conn-1709123456789] Executing: UPDATE users SET active = true WHERE id = 1
// Closing connection conn-1709123456789
7. Throwing Exceptions
So far we have been catching exceptions that Java throws for us. But you can also throw exceptions yourself using the throw keyword. This is how you signal that something has gone wrong in your own code – for example, when a method receives an invalid argument or a business rule is violated.
The throw Keyword
The throw keyword is followed by an exception object (created with new). When Java encounters a throw statement, it immediately stops executing the current method and looks for a matching catch block in the call stack.
public class ThrowExample {
public static void setAge(int age) {
if (age < 0) {
throw new IllegalArgumentException("Age cannot be negative: " + age);
}
if (age > 150) {
throw new IllegalArgumentException("Age is unrealistic: " + age);
}
System.out.println("Age set to: " + age);
}
public static void main(String[] args) {
setAge(25); // Works fine
try {
setAge(-5); // Throws IllegalArgumentException
} catch (IllegalArgumentException e) {
System.out.println("Error: " + e.getMessage());
}
try {
setAge(200); // Throws IllegalArgumentException
} catch (IllegalArgumentException e) {
System.out.println("Error: " + e.getMessage());
}
}
}
// Output:
// Age set to: 25
// Error: Age cannot be negative: -5
// Error: Age is unrealistic: 200
Re-throwing Exceptions
Sometimes you want to catch an exception, do something with it (like logging), and then re-throw it so the caller can handle it too. You can re-throw the same exception or wrap it in a different one:
import java.io.IOException;
public class RethrowExample {
public static void processFile(String path) throws IOException {
try {
// Simulate file processing
if (path == null) {
throw new IOException("File path is null");
}
System.out.println("Processing: " + path);
} catch (IOException e) {
System.out.println("LOG: Error processing file - " + e.getMessage());
throw e; // Re-throw the same exception to the caller
}
}
public static void main(String[] args) {
try {
processFile(null);
} catch (IOException e) {
System.out.println("MAIN: Caught re-thrown exception - " + e.getMessage());
}
}
}
// Output:
// LOG: Error processing file - File path is null
// MAIN: Caught re-thrown exception - File path is null
throw vs throws
These two keywords are related but serve different purposes. Do not confuse them:
Feature
throw
throws
Purpose
Actually throws an exception object
Declares that a method might throw an exception
Used with
An exception instance (throw new IOException())
Exception class names in method signature
Location
Inside a method body
In the method declaration (after parameter list)
Count
Throws one exception at a time
Can declare multiple exceptions
Example
throw new IOException("fail");
void read() throws IOException, SQLException
8. The throws Clause
When a method can throw a checked exception but does not want to handle it internally, it must declare the exception using the throws clause in its method signature. This tells the caller: “I might throw this exception, so you need to deal with it.”
This mechanism allows exceptions to propagate up the call stack until some method catches them. If no method catches the exception, the JVM terminates the program and prints the stack trace.
import java.io.*;
public class ThrowsDemo {
// Level 3: This method throws IOException -- does not handle it
public static String readFirstLine(String path) throws IOException {
BufferedReader reader = new BufferedReader(new FileReader(path));
String line = reader.readLine();
reader.close();
return line;
}
// Level 2: This method also throws IOException -- passes it up
public static void processConfig(String path) throws IOException {
String firstLine = readFirstLine(path);
System.out.println("Config: " + firstLine);
}
// Level 1: This method catches the exception -- the buck stops here
public static void main(String[] args) {
try {
processConfig("config.properties");
} catch (IOException e) {
System.out.println("Could not load config: " + e.getMessage());
System.out.println("Using default settings instead.");
}
}
}
// If config.properties does not exist:
// Could not load config: config.properties (No such file or directory)
// Using default settings instead.
Declaring Multiple Exceptions
A method can declare multiple checked exceptions, separated by commas:
import java.io.IOException;
import java.sql.SQLException;
import java.text.ParseException;
public class MultipleThrows {
// Declares three different checked exceptions
public static void importData(String filePath, String dbUrl)
throws IOException, SQLException, ParseException {
// Could throw IOException
// readFile(filePath);
// Could throw ParseException
// parseData(rawData);
// Could throw SQLException
// saveToDatabase(dbUrl, parsedData);
System.out.println("Data imported successfully.");
}
public static void main(String[] args) {
try {
importData("data.csv", "jdbc:mysql://localhost/mydb");
} catch (IOException e) {
System.out.println("File error: " + e.getMessage());
} catch (SQLException e) {
System.out.println("Database error: " + e.getMessage());
} catch (ParseException e) {
System.out.println("Parse error at position: " + e.getErrorOffset());
}
}
}
When to Handle vs When to Declare
A common question is: “Should I catch the exception here, or declare it with throws and let the caller handle it?” Here is a practical guide:
Handle it here (catch) when…
Propagate it (throws) when…
You can meaningfully recover (retry, use default, prompt user)
You do not know how the caller wants to handle it
You are at the top-level entry point (main, controller, servlet)
You are writing a library or utility method
You want to translate it to a different exception type
The caller has more context to make a recovery decision
Logging and continuing is the right behavior
The exception represents a condition the caller should know about
Rule of thumb: Handle the exception at the level that has enough context to decide what to do about it. Utility methods usually propagate; application-level code usually catches.
9. Creating Custom Exceptions
Java provides many built-in exception classes, but real-world applications often need their own custom exceptions to represent domain-specific error conditions. For example, a banking application might need InsufficientFundsException, and a user management system might need UserNotFoundException.
Why Create Custom Exceptions?
Clarity – InsufficientFundsException is far more meaningful than a generic Exception("Not enough money")
Catch specificity – Callers can catch your specific exception type separately from other exceptions
Additional data – Custom exceptions can carry domain-specific fields (account number, requested amount, available balance)
Separation of concerns – Business logic errors are distinct from I/O errors, parsing errors, etc.
How to Create a Custom Exception
Extend Exception for a checked custom exception (caller must handle)
Extend RuntimeException for an unchecked custom exception (caller does not have to handle)
Provide standard constructors: no-arg, message, message + cause, cause
// Checked custom exception -- caller MUST handle or declare
public class InsufficientFundsException extends Exception {
private double currentBalance;
private double withdrawAmount;
// Constructor with message only
public InsufficientFundsException(String message) {
super(message);
}
// Constructor with all details
public InsufficientFundsException(String message, double currentBalance, double withdrawAmount) {
super(message);
this.currentBalance = currentBalance;
this.withdrawAmount = withdrawAmount;
}
// Constructor with message and cause (for exception chaining)
public InsufficientFundsException(String message, Throwable cause) {
super(message, cause);
}
public double getCurrentBalance() {
return currentBalance;
}
public double getWithdrawAmount() {
return withdrawAmount;
}
public double getDeficit() {
return withdrawAmount - currentBalance;
}
}
Now let us use this custom exception in a practical banking example:
public class BankAccount {
private String accountNumber;
private double balance;
public BankAccount(String accountNumber, double initialBalance) {
this.accountNumber = accountNumber;
this.balance = initialBalance;
}
// This method throws our custom checked exception
public void withdraw(double amount) throws InsufficientFundsException {
if (amount <= 0) {
throw new IllegalArgumentException("Withdrawal amount must be positive: " + amount);
}
if (amount > balance) {
throw new InsufficientFundsException(
"Account " + accountNumber + ": Cannot withdraw $" + amount
+ " (balance: $" + balance + ")",
balance,
amount
);
}
balance -= amount;
System.out.println("Withdrew $" + amount + ". New balance: $" + balance);
}
public static void main(String[] args) {
BankAccount account = new BankAccount("ACC-1001", 500.00);
try {
account.withdraw(200.00); // Success
account.withdraw(400.00); // Fails -- only $300 left
} catch (InsufficientFundsException e) {
System.out.println("Transaction failed: " + e.getMessage());
System.out.println("You are short by: $" + e.getDeficit());
}
}
}
// Output:
// Withdrew $200.0. New balance: $300.0
// Transaction failed: Account ACC-1001: Cannot withdraw $400.0 (balance: $300.0)
// You are short by: $100.0
Unchecked Custom Exception
If your exception represents a programming error (misuse of an API) rather than a recoverable condition, extend RuntimeException:
// Unchecked custom exception -- caller does NOT have to handle
public class UserNotFoundException extends RuntimeException {
private String userId;
public UserNotFoundException(String userId) {
super("User not found with ID: " + userId);
this.userId = userId;
}
public UserNotFoundException(String userId, Throwable cause) {
super("User not found with ID: " + userId, cause);
this.userId = userId;
}
public String getUserId() {
return userId;
}
}
// Usage
public class UserService {
public User findById(String userId) {
User user = database.lookup(userId); // returns null if not found
if (user == null) {
throw new UserNotFoundException(userId);
}
return user;
}
}
10. Multi-catch (Java 7+)
Before Java 7, if you wanted to handle multiple exception types the same way, you had to write separate catch blocks with duplicated code. Java 7 introduced multi-catch, which lets you catch multiple exception types in a single catch block using the pipe (|) operator.
import java.io.IOException;
import java.sql.SQLException;
import java.text.ParseException;
public class MultiCatchDemo {
// Before Java 7 -- duplicated catch blocks
public static void beforeJava7(String input) {
try {
processInput(input);
} catch (IOException e) {
System.out.println("Error: " + e.getMessage());
logError(e);
} catch (SQLException e) {
System.out.println("Error: " + e.getMessage()); // Same code!
logError(e);
} catch (ParseException e) {
System.out.println("Error: " + e.getMessage()); // Same code!
logError(e);
}
}
// Java 7+ -- single multi-catch block
public static void withMultiCatch(String input) {
try {
processInput(input);
} catch (IOException | SQLException | ParseException e) {
// One block handles all three exception types
System.out.println("Error: " + e.getMessage());
logError(e);
}
}
private static void processInput(String input)
throws IOException, SQLException, ParseException {
// Processing logic that could throw any of these
}
private static void logError(Exception e) {
// Log the error
}
}
Multi-catch Rules and Restrictions
No parent-child relationships – You cannot put both a parent and child exception in the same multi-catch. For example, IOException | FileNotFoundException is a compile error because FileNotFoundException extends IOException. The parent already covers the child.
The exception variable is effectively final – Inside a multi-catch block, you cannot reassign the exception variable (e = new IOException() will not compile). This is because the type is a union type.
You can combine multi-catch with separate catches – Handle some exceptions the same way and others differently:
public class MultiCatchCombined {
public static void process(String data) {
try {
int number = Integer.parseInt(data);
int[] arr = new int[number];
arr[number] = 42; // Out of bounds if number > 0
} catch (NumberFormatException | ArrayIndexOutOfBoundsException e) {
// Handle these two the same way
System.out.println("Input error: " + e.getMessage());
} catch (NegativeArraySizeException e) {
// Handle this one differently
System.out.println("Cannot create array with negative size");
}
}
public static void main(String[] args) {
process("abc"); // NumberFormatException
process("5"); // ArrayIndexOutOfBoundsException
process("-3"); // NegativeArraySizeException
}
}
// Output:
// Input error: For input string: "abc"
// Input error: Index 5 out of bounds for length 5
// Cannot create array with negative size
11. Exception Chaining
Exception chaining (also called wrapping or nesting) is the practice of catching one exception and throwing a new, higher-level exception while preserving the original exception as the cause. This is critical in layered applications where low-level details (like SQL errors) should be translated into meaningful business-level exceptions without losing debugging information.
For example, a UserService catches a SQLException from the database layer but throws a UserNotFoundException to the controller layer. The original SQLException is preserved as the cause so developers can still see the root problem in logs.
import java.sql.SQLException;
public class ExceptionChaining {
// Low-level method -- throws SQLException
public static String queryDatabase(String userId) throws SQLException {
// Simulating a database error
throw new SQLException("Connection refused: database server is down");
}
// Mid-level method -- translates to a business exception
public static String findUserName(String userId) {
try {
return queryDatabase(userId);
} catch (SQLException e) {
// Wrap the low-level exception in a business-level exception
// The original SQLException is preserved as the cause
throw new RuntimeException("Failed to find user: " + userId, e);
}
}
public static void main(String[] args) {
try {
String name = findUserName("user-42");
} catch (RuntimeException e) {
System.out.println("Error: " + e.getMessage());
System.out.println("Root cause: " + e.getCause().getMessage());
System.out.println("Root cause type: " + e.getCause().getClass().getName());
}
}
}
// Output:
// Error: Failed to find user: user-42
// Root cause: Connection refused: database server is down
// Root cause type: java.sql.SQLException
Two Ways to Set the Cause
You can attach a cause exception in two ways:
public class ChainingMethods {
public static void main(String[] args) {
// Method 1: Via constructor (preferred -- cleaner and more common)
try {
throw new Exception("original problem");
} catch (Exception original) {
RuntimeException wrapper = new RuntimeException("Higher-level error", original);
// wrapper.getCause() returns the original exception
System.out.println("Wrapper message: " + wrapper.getMessage());
System.out.println("Cause message: " + wrapper.getCause().getMessage());
}
// Method 2: Via initCause() (useful when constructor does not accept cause)
try {
throw new Exception("original problem");
} catch (Exception original) {
RuntimeException wrapper = new RuntimeException("Higher-level error");
wrapper.initCause(original); // Set cause after construction
System.out.println("Wrapper message: " + wrapper.getMessage());
System.out.println("Cause message: " + wrapper.getCause().getMessage());
}
}
}
// Output:
// Wrapper message: Higher-level error
// Cause message: original problem
// Wrapper message: Higher-level error
// Cause message: original problem
Why Exception Chaining Matters
Without exception chaining, you lose the original error information:
// BAD: Original exception is lost -- debugging becomes very difficult
try {
riskyOperation();
} catch (SQLException e) {
throw new RuntimeException("Operation failed"); // WHERE did it fail? WHY?
}
// GOOD: Original exception is preserved -- full debugging context available
try {
riskyOperation();
} catch (SQLException e) {
throw new RuntimeException("Operation failed", e); // Full cause chain preserved
}
// When you print the stack trace of the GOOD version, you see:
// RuntimeException: Operation failed
// at MyClass.myMethod(MyClass.java:15)
// Caused by: SQLException: Connection refused
// at Database.query(Database.java:42)
// ... 3 more
12. Best Practices
Proper exception handling separates professional, production-quality code from code that breaks in unexpected ways. Here are the practices that experienced Java developers follow:
1. Catch Specific Exceptions
Never catch Exception or Throwable unless you have a very good reason (like a top-level error handler in a web framework). Catching too broadly hides bugs and makes debugging nearly impossible.
// BAD: Catches everything, including bugs you should fix
try {
processOrder(order);
} catch (Exception e) {
System.out.println("Something went wrong"); // What went wrong? No idea.
}
// GOOD: Catch only what you expect and can handle
try {
processOrder(order);
} catch (InsufficientFundsException e) {
notifyUser("Not enough funds. Balance: $" + e.getCurrentBalance());
} catch (ProductOutOfStockException e) {
notifyUser("Sorry, " + e.getProductName() + " is out of stock.");
}
2. Never Use Empty Catch Blocks
An empty catch block silently swallows the exception. The error still happened, but now you have no idea it did. At minimum, log the exception.
// TERRIBLE: Exception is completely swallowed -- silent failure
try {
saveToDatabase(data);
} catch (SQLException e) {
// Nothing here -- the data was NOT saved, but nobody knows!
}
// ACCEPTABLE: At minimum, log it
try {
saveToDatabase(data);
} catch (SQLException e) {
logger.error("Failed to save data: {}", e.getMessage(), e);
}
// BEST: Log and take appropriate action
try {
saveToDatabase(data);
} catch (SQLException e) {
logger.error("Failed to save to primary DB, trying backup", e);
saveToBackupDatabase(data); // Fallback strategy
}
3. Do Not Use Exceptions for Flow Control
Exceptions should represent exceptional conditions, not normal program logic. They are significantly slower than regular control flow because the JVM has to build a stack trace object.
// BAD: Using exception as a loop terminator
try {
int i = 0;
while (true) {
System.out.println(array[i++]); // Eventually throws ArrayIndexOutOfBoundsException
}
} catch (ArrayIndexOutOfBoundsException e) {
// Loop "finished"
}
// GOOD: Use normal loop bounds
for (int i = 0; i < array.length; i++) {
System.out.println(array[i]);
}
// BAD: Using exception to check if a string is a number
public static boolean isNumber(String s) {
try {
Integer.parseInt(s);
return true;
} catch (NumberFormatException e) {
return false;
}
}
// GOOD: Use validation instead (for performance-critical code)
public static boolean isNumber(String s) {
if (s == null || s.isEmpty()) return false;
for (char c : s.toCharArray()) {
if (!Character.isDigit(c)) return false;
}
return true;
}
4. Fail Fast
Validate inputs at the beginning of a method and throw immediately if something is wrong. This prevents the method from doing partial work that is hard to undo.
// GOOD: Validate early, fail fast
public void transferMoney(BankAccount from, BankAccount to, double amount) {
// Validate all inputs FIRST, before doing any work
if (from == null) throw new IllegalArgumentException("Source account cannot be null");
if (to == null) throw new IllegalArgumentException("Target account cannot be null");
if (amount <= 0) throw new IllegalArgumentException("Amount must be positive: " + amount);
if (from.equals(to)) throw new IllegalArgumentException("Cannot transfer to the same account");
// Now proceed with the actual transfer
from.withdraw(amount);
to.deposit(amount);
}
5. Use Custom Exceptions for Business Logic
Do not use generic exception types like Exception or RuntimeException for your business rules. Create specific exception classes that make your code self-documenting.
6. Always Clean Up Resources
Use try-with-resources for anything that implements AutoCloseable. This applies to file handles, database connections, network sockets, and streams.
7. Write Meaningful Error Messages
Exception messages should include the context needed for debugging: what was expected, what actually happened, and any relevant variable values.
// BAD: Vague messages that do not help debugging
throw new IllegalArgumentException("Invalid input");
throw new RuntimeException("Error occurred");
throw new IOException("Failed");
// GOOD: Specific messages with context
throw new IllegalArgumentException("Age must be between 0 and 150, but was: " + age);
throw new RuntimeException("Failed to send email to " + recipient + " via SMTP server " + host);
throw new IOException("Cannot read config file: " + path + " (file does not exist)");
8. Prefer Unchecked Exceptions for Programming Errors
Use checked exceptions for recoverable conditions that the caller must handle (file not found, network timeout). Use unchecked exceptions for programming bugs that should be fixed in the code (null arguments, invalid state).
Summary of Best Practices
Practice
Do
Do Not
Catch specificity
Catch the most specific exception type
Catch Exception or Throwable
Empty catch
Log the error or take action
Leave catch block empty
Flow control
Use normal control flow (if/else, loops)
Use try-catch as if/else replacement
Validation
Fail fast with descriptive messages
Let errors propagate silently
Resources
Use try-with-resources
Rely on manual close in finally
Messages
Include context (values, identifiers)
Write vague messages ("Error occurred")
Chaining
Preserve the original cause
Throw new exception without cause
13. Common Mistakes
Even experienced developers make exception handling mistakes. Here are the most common anti-patterns and how to avoid them.
Mistake 1: Swallowing Exceptions
This is the single most dangerous mistake. Catching an exception and doing nothing with it means errors happen silently, and you will spend hours debugging something that the exception message would have told you in two seconds.
// MISTAKE: Silent failure -- data is NOT saved, but the program acts like it was
public void saveUser(User user) {
try {
database.insert(user);
} catch (SQLException e) {
// Silently swallowed -- the user thinks their data was saved
}
}
// FIX: Always handle the error meaningfully
public void saveUser(User user) {
try {
database.insert(user);
} catch (SQLException e) {
logger.error("Failed to save user {}: {}", user.getId(), e.getMessage(), e);
throw new DataAccessException("Could not save user " + user.getId(), e);
}
}
Mistake 2: Catching Exception Too Broadly
Catching Exception catches everything, including NullPointerException, ClassCastException, and other bugs you should find and fix, not catch and ignore.
// MISTAKE: Catches bugs along with expected exceptions
try {
String name = null;
processUser(name.toUpperCase()); // NullPointerException -- this is a bug!
} catch (Exception e) {
System.out.println("User processing failed"); // Hides the NPE bug
}
// FIX: Catch only specific expected exceptions
try {
processUser(name);
} catch (UserNotFoundException e) {
System.out.println("User not found: " + e.getMessage());
}
// Let NullPointerException propagate -- it is a bug that needs fixing!
Mistake 3: Losing the Original Stack Trace
When you catch one exception and throw another, always pass the original as the cause. Without it, you lose the information about where the problem actually started.
// MISTAKE: Original exception is lost
try {
readConfigFile();
} catch (IOException e) {
throw new RuntimeException("Config loading failed");
// The IOException and its stack trace are gone forever
}
// FIX: Preserve the original exception as the cause
try {
readConfigFile();
} catch (IOException e) {
throw new RuntimeException("Config loading failed", e);
// Now the full chain is available: RuntimeException -> IOException
}
Mistake 4: Not Closing Resources
Forgetting to close resources leads to resource leaks – file handles, database connections, or network sockets that stay open and are never released, eventually causing the application to run out of resources.
// MISTAKE: Resource leak -- if readLine() throws, the reader is never closed
public String readFile(String path) throws IOException {
BufferedReader reader = new BufferedReader(new FileReader(path));
String content = reader.readLine();
reader.close(); // Never reached if readLine() throws
return content;
}
// FIX: Use try-with-resources -- close is guaranteed
public String readFile(String path) throws IOException {
try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
return reader.readLine(); // reader is closed automatically
}
}
Mistake 5: Throwing Generic Exception Types
Declaring throws Exception on a method forces every caller to catch Exception, which defeats the purpose of Java's exception type system.
// MISTAKE: Forces callers to catch the vague "Exception" type
public void doWork() throws Exception {
// ...
}
// FIX: Declare specific exceptions
public void doWork() throws IOException, SQLException {
// Now callers know exactly what can go wrong
}
Mistake 6: Using return in finally
Returning from a finally block silently swallows any exception thrown in the try or catch block. The exception is discarded, and the return value from finally is used instead. This is extremely confusing and should be avoided.
// MISTAKE: return in finally swallows the exception
public static int badMethod() {
try {
throw new RuntimeException("Something went wrong!");
} finally {
return 42; // The RuntimeException is silently discarded!
}
}
// The caller gets 42 and has no idea an exception occurred
System.out.println(badMethod()); // Prints: 42 (no exception!)
// FIX: Never return from a finally block
public static int goodMethod() {
try {
// do work
return 42;
} finally {
// cleanup only -- no return statement here
System.out.println("Cleanup completed");
}
}
14. Complete Practical Example: Banking Transaction System
Let us build a complete banking transaction system that demonstrates everything we have learned. This example includes custom exceptions, exception chaining, try-with-resources, proper error handling, and best practices. Study this code carefully – it shows how exception handling works in a real application.
Step 1: Custom Exception Classes
First, we define three custom exceptions for our banking domain. Each carries relevant context for debugging and user-facing messages.
// Checked exception -- caller must handle
public class InsufficientFundsException extends Exception {
private final String accountId;
private final double requestedAmount;
private final double availableBalance;
public InsufficientFundsException(String accountId, double requested, double available) {
super(String.format("Account %s: requested $%.2f but only $%.2f available",
accountId, requested, available));
this.accountId = accountId;
this.requestedAmount = requested;
this.availableBalance = available;
}
public String getAccountId() { return accountId; }
public double getRequestedAmount() { return requestedAmount; }
public double getAvailableBalance() { return availableBalance; }
public double getDeficit() { return requestedAmount - availableBalance; }
}
// Unchecked exception -- programming error (account does not exist)
public class AccountNotFoundException extends RuntimeException {
private final String accountId;
public AccountNotFoundException(String accountId) {
super("Account not found: " + accountId);
this.accountId = accountId;
}
public AccountNotFoundException(String accountId, Throwable cause) {
super("Account not found: " + accountId, cause);
this.accountId = accountId;
}
public String getAccountId() { return accountId; }
}
// Checked exception -- represents a transaction failure
public class TransactionException extends Exception {
private final String transactionId;
public TransactionException(String transactionId, String message) {
super(message);
this.transactionId = transactionId;
}
public TransactionException(String transactionId, String message, Throwable cause) {
super(message, cause);
this.transactionId = transactionId;
}
public String getTransactionId() { return transactionId; }
}
Step 2: BankAccount Class
The account class uses fail-fast validation and throws meaningful exceptions:
public class BankAccount {
private final String accountId;
private final String ownerName;
private double balance;
public BankAccount(String accountId, String ownerName, double initialBalance) {
// Fail fast -- validate all inputs immediately
if (accountId == null || accountId.isBlank()) {
throw new IllegalArgumentException("Account ID cannot be null or blank");
}
if (ownerName == null || ownerName.isBlank()) {
throw new IllegalArgumentException("Owner name cannot be null or blank");
}
if (initialBalance < 0) {
throw new IllegalArgumentException(
"Initial balance cannot be negative: " + initialBalance);
}
this.accountId = accountId;
this.ownerName = ownerName;
this.balance = initialBalance;
}
public void deposit(double amount) {
if (amount <= 0) {
throw new IllegalArgumentException("Deposit amount must be positive: " + amount);
}
balance += amount;
}
public void withdraw(double amount) throws InsufficientFundsException {
if (amount <= 0) {
throw new IllegalArgumentException("Withdrawal amount must be positive: " + amount);
}
if (amount > balance) {
throw new InsufficientFundsException(accountId, amount, balance);
}
balance -= amount;
}
public String getAccountId() { return accountId; }
public String getOwnerName() { return ownerName; }
public double getBalance() { return balance; }
@Override
public String toString() {
return String.format("Account[%s, %s, $%.2f]", accountId, ownerName, balance);
}
}
Step 3: TransactionService with Exception Chaining
The service layer coordinates transfers and demonstrates exception chaining – it catches low-level exceptions and wraps them in business-level TransactionException:
import java.util.HashMap;
import java.util.Map;
import java.util.UUID;
public class TransactionService {
private final Map accounts = new HashMap<>();
public void addAccount(BankAccount account) {
accounts.put(account.getAccountId(), account);
}
public BankAccount getAccount(String accountId) {
BankAccount account = accounts.get(accountId);
if (account == null) {
throw new AccountNotFoundException(accountId);
}
return account;
}
public String transfer(String fromId, String toId, double amount)
throws TransactionException {
String txId = "TX-" + UUID.randomUUID().toString().substring(0, 8);
// Fail fast -- validate inputs before doing any work
if (fromId == null || toId == null) {
throw new TransactionException(txId, "Account IDs cannot be null");
}
if (fromId.equals(toId)) {
throw new TransactionException(txId, "Cannot transfer to the same account");
}
if (amount <= 0) {
throw new TransactionException(txId,
"Transfer amount must be positive: " + amount);
}
try {
// These throw AccountNotFoundException (unchecked) if not found
BankAccount fromAccount = getAccount(fromId);
BankAccount toAccount = getAccount(toId);
System.out.println("[" + txId + "] Transferring $" + amount
+ " from " + fromId + " to " + toId);
// withdraw() throws InsufficientFundsException (checked)
fromAccount.withdraw(amount);
toAccount.deposit(amount);
System.out.println("[" + txId + "] Transfer successful");
System.out.println(" " + fromAccount);
System.out.println(" " + toAccount);
return txId;
} catch (InsufficientFundsException e) {
// Exception chaining: wrap business exception in transaction exception
throw new TransactionException(txId,
"Transfer failed: insufficient funds", e);
} catch (AccountNotFoundException e) {
// Exception chaining: wrap runtime exception in transaction exception
throw new TransactionException(txId,
"Transfer failed: " + e.getMessage(), e);
}
}
}
Step 4: Transaction Logger with try-with-resources
The logger demonstrates try-with-resources with a custom AutoCloseable:
import java.io.FileWriter;
import java.io.IOException;
import java.io.PrintWriter;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
public class TransactionLogger implements AutoCloseable {
private final PrintWriter writer;
private final DateTimeFormatter formatter =
DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
public TransactionLogger(String logFile) throws IOException {
// true = append mode
this.writer = new PrintWriter(new FileWriter(logFile, true));
log("INFO", "Transaction logger started");
}
public void log(String level, String message) {
String timestamp = LocalDateTime.now().format(formatter);
String entry = String.format("[%s] [%s] %s", timestamp, level, message);
writer.println(entry);
writer.flush();
System.out.println(entry); // Also print to console
}
public void logSuccess(String txId, String fromId, String toId, double amount) {
log("SUCCESS", String.format("%s: $%.2f transferred from %s to %s",
txId, amount, fromId, toId));
}
public void logFailure(String txId, String reason, Throwable cause) {
log("FAILURE", txId + ": " + reason);
if (cause != null) {
log("DETAIL", "Cause: " + cause.getClass().getSimpleName()
+ " - " + cause.getMessage());
}
}
@Override
public void close() {
log("INFO", "Transaction logger shutting down");
writer.close(); // Release the file handle
}
}
Step 5: Main Application Bringing It All Together
The main class ties everything together and demonstrates proper exception handling at every level:
import java.io.IOException;
public class BankingApp {
public static void main(String[] args) {
// Set up accounts
TransactionService service = new TransactionService();
service.addAccount(new BankAccount("ACC-001", "Alice Johnson", 1000.00));
service.addAccount(new BankAccount("ACC-002", "Bob Smith", 500.00));
service.addAccount(new BankAccount("ACC-003", "Charlie Brown", 250.00));
// try-with-resources: logger is automatically closed when block ends
try (TransactionLogger logger = new TransactionLogger("transactions.log")) {
// Transaction 1: Successful transfer
try {
String txId = service.transfer("ACC-001", "ACC-002", 200.00);
logger.logSuccess(txId, "ACC-001", "ACC-002", 200.00);
} catch (TransactionException e) {
logger.logFailure("N/A", e.getMessage(), e.getCause());
}
// Transaction 2: Insufficient funds
try {
String txId = service.transfer("ACC-003", "ACC-001", 999.99);
logger.logSuccess(txId, "ACC-003", "ACC-001", 999.99);
} catch (TransactionException e) {
logger.logFailure(e.getTransactionId(), e.getMessage(), e.getCause());
}
// Transaction 3: Account not found
try {
String txId = service.transfer("ACC-001", "ACC-999", 50.00);
logger.logSuccess(txId, "ACC-001", "ACC-999", 50.00);
} catch (TransactionException e) {
logger.logFailure(e.getTransactionId(), e.getMessage(), e.getCause());
}
// Transaction 4: Invalid amount
try {
String txId = service.transfer("ACC-001", "ACC-002", -100.00);
logger.logSuccess(txId, "ACC-001", "ACC-002", -100.00);
} catch (TransactionException e) {
logger.logFailure(e.getTransactionId(), e.getMessage(), e.getCause());
}
// Transaction 5: Same account transfer
try {
String txId = service.transfer("ACC-001", "ACC-001", 50.00);
logger.logSuccess(txId, "ACC-001", "ACC-001", 50.00);
} catch (TransactionException e) {
logger.logFailure(e.getTransactionId(), e.getMessage(), e.getCause());
}
// Print final balances
logger.log("INFO", "=== Final Balances ===");
for (String id : new String[]{"ACC-001", "ACC-002", "ACC-003"}) {
BankAccount acc = service.getAccount(id);
logger.log("INFO", acc.toString());
}
} catch (IOException e) {
// This only catches the logger's IOException
System.err.println("FATAL: Could not initialize transaction logger: "
+ e.getMessage());
}
// TransactionLogger.close() is called automatically here
}
}
// Output:
// [2026-02-28 10:30:00] [INFO] Transaction logger started
// [TX-a1b2c3d4] Transferring $200.0 from ACC-001 to ACC-002
// [TX-a1b2c3d4] Transfer successful
// Account[ACC-001, Alice Johnson, $800.00]
// Account[ACC-002, Bob Smith, $700.00]
// [2026-02-28 10:30:00] [SUCCESS] TX-a1b2c3d4: $200.00 transferred from ACC-001 to ACC-002
// [2026-02-28 10:30:00] [FAILURE] TX-e5f6g7h8: Transfer failed: insufficient funds
// [2026-02-28 10:30:00] [DETAIL] Cause: InsufficientFundsException - Account ACC-003: requested $999.99 but only $250.00 available
// [2026-02-28 10:30:00] [FAILURE] TX-i9j0k1l2: Transfer failed: Account not found: ACC-999
// [2026-02-28 10:30:00] [DETAIL] Cause: AccountNotFoundException - Account not found: ACC-999
// [2026-02-28 10:30:00] [FAILURE] TX-m3n4o5p6: Transfer amount must be positive: -100.0
// [2026-02-28 10:30:00] [DETAIL] Cause: null
// [2026-02-28 10:30:00] [FAILURE] TX-q7r8s9t0: Cannot transfer to the same account
// [2026-02-28 10:30:00] [DETAIL] Cause: null
// [2026-02-28 10:30:00] [INFO] === Final Balances ===
// [2026-02-28 10:30:00] [INFO] Account[ACC-001, Alice Johnson, $800.00]
// [2026-02-28 10:30:00] [INFO] Account[ACC-002, Bob Smith, $700.00]
// [2026-02-28 10:30:00] [INFO] Account[ACC-003, Charlie Brown, $250.00]
// [2026-02-28 10:30:00] [INFO] Transaction logger shutting down
What This Example Demonstrates
Concept
Where It Appears
Custom checked exception
InsufficientFundsException, TransactionException
Custom unchecked exception
AccountNotFoundException
Exception chaining
TransactionService.transfer() wraps caught exceptions in TransactionException
try-with-resources
TransactionLogger implements AutoCloseable, used with try-with-resources in main()
Fail fast validation
BankAccount constructor, transfer() method
Specific exception catching
Separate catch blocks for InsufficientFundsException and AccountNotFoundException
Meaningful error messages
Every exception includes account IDs, amounts, and context
throw vs throws
throw new in method bodies; throws in method signatures
Extra data in exceptions
Custom getters for account ID, amounts, deficit
Resource cleanup
Logger file handle closed automatically via AutoCloseable
Quick Reference
Keyword / Concept
Purpose
Example
try
Wraps code that might throw an exception
try { riskyCode(); }
catch
Handles a specific exception type
catch (IOException e) { ... }
finally
Runs always, for cleanup
finally { resource.close(); }
throw
Throws an exception object
throw new IllegalArgumentException("msg");
throws
Declares exceptions a method may throw
void read() throws IOException
try-with-resources
Auto-closes AutoCloseable resources
try (var r = new FileReader("f")) { ... }
Multi-catch
Catches multiple types in one block
catch (IOException | SQLException e)
Exception chaining
Wraps an exception as the cause of another
throw new AppException("msg", originalException);
Checked exception
Must be caught or declared; extends Exception
IOException, SQLException
Unchecked exception
Not required to catch; extends RuntimeException
NullPointerException, IllegalArgumentException
March 8, 2019
Java OOP
What is Object-Oriented Programming (OOP)?
Object-Oriented Programming (OOP) is a programming paradigm that organizes software around objects rather than functions and logic. An object is a self-contained unit that bundles together data (fields) and the operations (methods) that work on that data. Java is an object-oriented language from the ground up — every piece of code you write lives inside a class, and almost everything you interact with is an object.
Think of it this way: in the real world, you interact with objects every day — a car, a bank account, a phone. Each object has state (a car has a color, speed, and fuel level) and behavior (a car can accelerate, brake, and turn). OOP lets you model software the same way, making code more intuitive, organized, and maintainable.
Why Does OOP Matter?
Before OOP, most programming was procedural — a list of instructions executed from top to bottom. This works fine for small programs, but as software grows to thousands of lines, procedural code becomes tangled, hard to debug, and nearly impossible to extend without breaking something else. OOP solves this by:
Modeling real-world concepts — Objects map naturally to business concepts (Customer, Order, Product), making code easier to understand.
Organizing code into manageable units — Each class has a single responsibility, so you know exactly where to look when something breaks.
Enabling code reuse — Inheritance and composition let you build on existing code instead of rewriting it.
Making code extensible — You can add new behavior without modifying existing, tested code.
Supporting team development — Different developers can work on different classes independently.
Procedural vs. Object-Oriented: A Quick Comparison
// === Procedural Approach ===
// Data and functions are separate. Any function can access and modify the data.
// As the program grows, tracking who changes what becomes a nightmare.
String employeeName = "Alice";
double employeeSalary = 75000;
static double calculateBonus(double salary) {
return salary * 0.10;
}
static void printEmployee(String name, double salary) {
System.out.println(name + " earns $" + salary);
}
// Nothing stops you from doing this anywhere in the code:
employeeSalary = -50000; // Invalid! But no guard against it.
// === Object-Oriented Approach ===
// Data and behavior live together. The object protects its own state.
public class Employee {
private String name;
private double salary;
public Employee(String name, double salary) {
this.name = name;
setSalary(salary);
}
public void setSalary(double salary) {
if (salary < 0) {
throw new IllegalArgumentException("Salary cannot be negative");
}
this.salary = salary;
}
public double calculateBonus() {
return this.salary * 0.10;
}
public void printInfo() {
System.out.println(name + " earns $" + salary);
}
}
// Now invalid data is impossible:
Employee alice = new Employee("Alice", 75000);
// alice.setSalary(-50000); // Throws IllegalArgumentException
Notice the difference: in the OOP version, the Employee object owns its data and controls how that data is accessed. No outside code can set the salary to a negative number. This is the essence of OOP — objects are responsible for their own state.
The Four Pillars of OOP
Java's OOP model rests on four fundamental principles, often called the four pillars. Every design decision you make in Java connects back to one or more of these:
Pillar
What It Does
Key Benefit
Java Mechanism
Encapsulation
Bundles data and methods together; hides internal state
Data protection and controlled access
private fields, getters/setters
Inheritance
Creates parent-child relationships between classes
Code reuse and hierarchical modeling
extends, super
Polymorphism
Allows one interface to represent multiple forms
Flexibility and extensibility
Overloading, overriding, upcasting
Abstraction
Hides complex implementation, exposes only essentials
Simplified interfaces and reduced complexity
abstract classes, interface
We will explore each pillar in depth with practical, compilable examples. Let us start with Encapsulation, since it is the foundation that the other three pillars build on.
1. Encapsulation
Encapsulation means bundling the data (fields) and the methods that operate on that data into a single unit (a class), and then restricting direct access to the data from outside the class. The class controls how its data is read and modified through public methods, typically getters and setters.
Think of encapsulation like an ATM machine. You do not reach into the machine and grab cash directly. Instead, you interact through a controlled interface — you insert your card, enter your PIN, and request an amount. The ATM validates your request, checks your balance, and dispenses the cash. The internal mechanics are hidden from you.
The Core Idea: Private Fields, Public Methods
The most important rule of encapsulation is: make fields private and provide public methods to access them. This gives the class full control over its own data.
public class Person {
// Fields are private -- no outside code can access them directly
private String name;
private int age;
// Constructor
public Person(String name, int age) {
this.name = name;
setAge(age); // Use the setter to enforce validation from day one
}
// Getter -- read access
public String getName() {
return name;
}
// Setter -- write access with validation
public void setName(String name) {
if (name == null || name.isBlank()) {
throw new IllegalArgumentException("Name cannot be null or blank");
}
this.name = name;
}
// Getter
public int getAge() {
return age;
}
// Setter with validation -- age must be between 0 and 150
public void setAge(int age) {
if (age < 0 || age > 150) {
throw new IllegalArgumentException("Age must be between 0 and 150, got: " + age);
}
this.age = age;
}
@Override
public String toString() {
return name + " (age " + age + ")";
}
}
// Usage:
Person person = new Person("Alice", 30);
System.out.println(person.getName()); // Alice
System.out.println(person.getAge()); // 30
person.setAge(31); // Works fine
// person.setAge(-5); // Throws IllegalArgumentException
// person.age = -5; // Compile error -- age is private
Data Validation in Setters
One of the biggest advantages of encapsulation is the ability to validate data before accepting it. Without encapsulation, anyone can set a field to an invalid value. With it, the object protects its own invariants.
public class EmailAccount {
private String email;
private String password;
public void setEmail(String email) {
if (email == null || !email.contains("@") || !email.contains(".")) {
throw new IllegalArgumentException("Invalid email format: " + email);
}
this.email = email.toLowerCase().trim();
}
public void setPassword(String password) {
if (password == null || password.length() < 8) {
throw new IllegalArgumentException("Password must be at least 8 characters");
}
if (password.equals(password.toLowerCase())) {
throw new IllegalArgumentException("Password must contain at least one uppercase letter");
}
this.password = password; // In real code, you would hash this
}
public String getEmail() {
return email;
}
// Notice: no getPassword() method -- we intentionally
// prevent anyone from reading the password back out.
}
Real-World Example: BankAccount
A bank account is the classic encapsulation example. You cannot set the balance directly — you must use deposit() and withdraw() methods, which enforce business rules like minimum balance and overdraft protection.
public class BankAccount {
private final String accountNumber; // final -- never changes after creation
private final String ownerName;
private double balance;
public BankAccount(String accountNumber, String ownerName, double initialDeposit) {
if (initialDeposit < 0) {
throw new IllegalArgumentException("Initial deposit cannot be negative");
}
this.accountNumber = accountNumber;
this.ownerName = ownerName;
this.balance = initialDeposit;
}
// Read-only access to balance -- no setBalance() method exists
public double getBalance() {
return balance;
}
public String getAccountNumber() {
return accountNumber;
}
public String getOwnerName() {
return ownerName;
}
public void deposit(double amount) {
if (amount <= 0) {
throw new IllegalArgumentException("Deposit amount must be positive");
}
balance += amount;
System.out.println("Deposited $" + amount + ". New balance: $" + balance);
}
public void withdraw(double amount) {
if (amount <= 0) {
throw new IllegalArgumentException("Withdrawal amount must be positive");
}
if (amount > balance) {
throw new IllegalArgumentException("Insufficient funds. Balance: $" + balance);
}
balance -= amount;
System.out.println("Withdrew $" + amount + ". New balance: $" + balance);
}
@Override
public String toString() {
return "Account " + accountNumber + " (" + ownerName + "): $" + balance;
}
}
// Usage:
BankAccount account = new BankAccount("ACC-001", "Alice", 1000.00);
account.deposit(500.00); // Deposited $500.0. New balance: $1500.0
account.withdraw(200.00); // Withdrew $200.0. New balance: $1300.0
System.out.println(account.getBalance()); // 1300.0
// account.balance = 1000000; // Compile error -- balance is private
// account.withdraw(5000); // Throws IllegalArgumentException: Insufficient funds
Immutable Objects
The strongest form of encapsulation is an immutable object — an object whose state cannot change after creation. All fields are final, there are no setters, and if any field holds a mutable object (like a List), the class returns a defensive copy.
Immutable objects are inherently thread-safe, simple to reason about, and safe to use as keys in HashMap or elements in HashSet.
import java.util.Collections;
import java.util.List;
public final class Address {
private final String street;
private final String city;
private final String state;
private final String zipCode;
public Address(String street, String city, String state, String zipCode) {
this.street = street;
this.city = city;
this.state = state;
this.zipCode = zipCode;
}
public String getStreet() { return street; }
public String getCity() { return city; }
public String getState() { return state; }
public String getZipCode() { return zipCode; }
// No setters -- the object cannot be changed after creation
@Override
public String toString() {
return street + ", " + city + ", " + state + " " + zipCode;
}
}
// Since Java 16, you can use records for simple immutable data carriers:
public record AddressRecord(String street, String city, String state, String zipCode) {
// This generates the constructor, getters, equals(), hashCode(),
// and toString() automatically -- all fields are final and private.
}
Access Modifiers Summary
Java provides four access levels that control visibility. Encapsulation relies on choosing the right level for each field and method:
Modifier
Class
Package
Subclass
World
When to Use
private
Yes
No
No
No
Fields (almost always), helper methods
(default/package)
Yes
Yes
No
No
Package-internal utilities
protected
Yes
Yes
Yes
No
Methods subclasses need to override
public
Yes
Yes
Yes
Yes
API methods, constants
Rule of thumb: Start with private for everything. Only widen access when you have a specific reason. You can always make something more visible later, but making a public field private is a breaking change.
2. Inheritance
Inheritance allows a new class (the subclass or child) to inherit fields and methods from an existing class (the superclass or parent). This creates an IS-A relationship: a Dog IS-A Animal, a Car IS-A Vehicle, a Manager IS-A Employee.
Inheritance serves two purposes:
Code reuse — Common fields and methods live in the parent class. Subclasses inherit them without duplicating code.
Hierarchical modeling — You can model real-world "kind-of" relationships naturally.
The extends Keyword
In Java, a class uses the extends keyword to inherit from another class. Java supports single inheritance only — a class can extend exactly one parent class. (You can implement multiple interfaces, which we will cover in the Abstraction section.)
// Parent class (superclass)
public class Vehicle {
private String make;
private String model;
private int year;
private double fuelLevel; // percentage 0-100
public Vehicle(String make, String model, int year) {
this.make = make;
this.model = model;
this.year = year;
this.fuelLevel = 100.0;
}
public void start() {
System.out.println(year + " " + make + " " + model + " engine started.");
}
public void stop() {
System.out.println(year + " " + make + " " + model + " engine stopped.");
}
public void refuel(double amount) {
fuelLevel = Math.min(100.0, fuelLevel + amount);
System.out.println("Fuel level: " + fuelLevel + "%");
}
// Getters
public String getMake() { return make; }
public String getModel() { return model; }
public int getYear() { return year; }
public double getFuelLevel() { return fuelLevel; }
@Override
public String toString() {
return year + " " + make + " " + model;
}
}
// Child class (subclass) -- Car IS-A Vehicle
public class Car extends Vehicle {
private int numberOfDoors;
private boolean sunroof;
public Car(String make, String model, int year, int numberOfDoors, boolean sunroof) {
super(make, model, year); // Call parent constructor
this.numberOfDoors = numberOfDoors;
this.sunroof = sunroof;
}
// Car-specific method
public void openSunroof() {
if (sunroof) {
System.out.println("Sunroof opened on " + this);
} else {
System.out.println(this + " does not have a sunroof.");
}
}
public int getNumberOfDoors() { return numberOfDoors; }
public boolean hasSunroof() { return sunroof; }
}
// Child class -- Truck IS-A Vehicle
public class Truck extends Vehicle {
private double payloadCapacity; // in tons
private boolean fourWheelDrive;
public Truck(String make, String model, int year, double payloadCapacity, boolean fourWheelDrive) {
super(make, model, year); // Call parent constructor
this.payloadCapacity = payloadCapacity;
this.fourWheelDrive = fourWheelDrive;
}
public void loadCargo(double tons) {
if (tons > payloadCapacity) {
System.out.println("Cannot load " + tons + " tons. Max capacity: " + payloadCapacity + " tons.");
} else {
System.out.println("Loaded " + tons + " tons onto " + this);
}
}
public double getPayloadCapacity() { return payloadCapacity; }
public boolean isFourWheelDrive() { return fourWheelDrive; }
}
// Usage:
Car myCar = new Car("Toyota", "Camry", 2024, 4, true);
myCar.start(); // Inherited from Vehicle: "2024 Toyota Camry engine started."
myCar.openSunroof(); // Car-specific: "Sunroof opened on 2024 Toyota Camry"
myCar.refuel(20); // Inherited from Vehicle: "Fuel level: 100.0%"
Truck myTruck = new Truck("Ford", "F-150", 2024, 1.5, true);
myTruck.start(); // Inherited: "2024 Ford F-150 engine started."
myTruck.loadCargo(1.0); // Truck-specific: "Loaded 1.0 tons onto 2024 Ford F-150"
The super Keyword
The super keyword is used inside a subclass to refer to its parent class. It has two primary uses:
super(args) — Calls the parent class constructor. This must be the first statement in the subclass constructor. If you do not call super() explicitly, Java automatically inserts a call to the parent's no-argument constructor (and this will fail if the parent does not have one).
super.methodName() — Calls the parent class version of an overridden method.
public class ElectricCar extends Car {
private double batteryLevel; // percentage 0-100
public ElectricCar(String make, String model, int year, int numberOfDoors) {
super(make, model, year, numberOfDoors, true); // Call Car's constructor
this.batteryLevel = 100.0;
}
// Override the start method
@Override
public void start() {
// Call parent's start method first
super.start();
System.out.println("Electric motor engaged. Battery: " + batteryLevel + "%");
}
// Override refuel -- electric cars charge, they don't refuel
@Override
public void refuel(double amount) {
batteryLevel = Math.min(100.0, batteryLevel + amount);
System.out.println("Battery charged to " + batteryLevel + "%");
}
}
// Usage:
ElectricCar tesla = new ElectricCar("Tesla", "Model 3", 2024, 4);
tesla.start();
// Output:
// 2024 Tesla Model 3 engine started.
// Electric motor engaged. Battery: 100.0%
Constructor Chaining
When you create an instance of a subclass, Java calls constructors from the top of the inheritance chain downward. This is called constructor chaining. Every object in Java ultimately starts with the Object class constructor.
public class A {
public A() {
System.out.println("A's constructor");
}
}
public class B extends A {
public B() {
super(); // Calls A's constructor (Java inserts this even if you omit it)
System.out.println("B's constructor");
}
}
public class C extends B {
public C() {
super(); // Calls B's constructor
System.out.println("C's constructor");
}
}
// Creating an instance of C:
C obj = new C();
// Output:
// A's constructor
// B's constructor
// C's constructor
Method Overriding with @Override
A subclass can provide its own implementation of a method it inherited from its parent. This is called method overriding. The rules are:
The method must have the same name, return type, and parameter list as the parent method.
The access modifier can be the same or less restrictive (e.g., a protected method can be overridden as public, but not as private).
Always use the @Override annotation. It tells the compiler to verify you are actually overriding a parent method. If you misspell the method name, the compiler catches it.
public class Animal {
public String speak() {
return "...";
}
}
public class Dog extends Animal {
@Override
public String speak() {
return "Woof!";
}
}
public class Cat extends Animal {
@Override
public String speak() {
return "Meow!";
}
}
// Without @Override, this typo would silently create a new method:
public class Bird extends Animal {
@Override
public String spaek() { // Compile error! No method "spaek" in parent.
return "Tweet!";
}
}
The final Keyword in Inheritance
The final keyword can be used to restrict inheritance:
final class — The class cannot be extended. Example: String, Integer, and all wrapper classes are final.
final method — The method cannot be overridden by subclasses. Use this when a method's behavior is critical and should never change.
// final class -- cannot be extended
public final class MathUtils {
public static double circleArea(double radius) {
return Math.PI * radius * radius;
}
}
// This would cause a compile error:
// public class AdvancedMathUtils extends MathUtils { } // Error: cannot extend final class
// final method -- cannot be overridden
public class Transaction {
private double amount;
// No subclass should ever change how the ID is generated
public final String generateId() {
return "TXN-" + System.currentTimeMillis();
}
// Subclasses CAN override this
public void process() {
System.out.println("Processing transaction: " + generateId());
}
}
Single Inheritance Limitation
Java allows a class to extend only one parent class. This avoids the "diamond problem" found in languages like C++ that support multiple inheritance. If you need a class to inherit behavior from multiple sources, use interfaces (covered in the Abstraction section).
// This is NOT allowed in Java:
// public class FlyingCar extends Car, Airplane { } // Compile error
// Instead, use interfaces:
public interface Flyable {
void fly();
}
public interface Drivable {
void drive();
}
public class FlyingCar implements Flyable, Drivable {
@Override
public void fly() {
System.out.println("Flying through the air");
}
@Override
public void drive() {
System.out.println("Driving on the road");
}
}
3. Polymorphism
Polymorphism means "many forms." In Java, it allows you to use a single interface or parent type to represent objects of different classes, and each object responds to the same method call in its own way. This is one of the most powerful concepts in OOP because it lets you write flexible, extensible code.
There are two types of polymorphism in Java:
Compile-time polymorphism (Method Overloading) — Resolved by the compiler based on the method signature.
Runtime polymorphism (Method Overriding) — Resolved at runtime based on the actual object type.
Compile-Time Polymorphism: Method Overloading
Method overloading means defining multiple methods with the same name but different parameter lists (different number, types, or order of parameters). The compiler decides which version to call based on the arguments you pass.
public class Calculator {
// Overloaded add() methods -- same name, different parameters
public int add(int a, int b) {
return a + b;
}
public int add(int a, int b, int c) {
return a + b + c;
}
public double add(double a, double b) {
return a + b;
}
public String add(String a, String b) {
return a + b; // String concatenation
}
}
// Usage:
Calculator calc = new Calculator();
System.out.println(calc.add(5, 3)); // 8 (int version)
System.out.println(calc.add(5, 3, 2)); // 10 (three-int version)
System.out.println(calc.add(5.5, 3.2)); // 8.7 (double version)
System.out.println(calc.add("Hello, ", "World")); // "Hello, World" (String version)
Important: You cannot overload a method by changing only the return type. The parameter list must differ. The following would cause a compile error:
// This will NOT compile -- same parameters, different return type
public int getValue() { return 42; }
public double getValue() { return 42.0; } // Compile error: duplicate method
Runtime Polymorphism: Method Overriding
Runtime polymorphism is where OOP really shines. When a parent reference variable points to a child object, and you call an overridden method, Java determines at runtime which version of the method to execute based on the actual object type, not the variable type. This is also called dynamic dispatch.
public class Shape {
private String name;
public Shape(String name) {
this.name = name;
}
public double area() {
return 0; // Default: unknown shape has zero area
}
public String getName() {
return name;
}
}
public class Circle extends Shape {
private double radius;
public Circle(double radius) {
super("Circle");
this.radius = radius;
}
@Override
public double area() {
return Math.PI * radius * radius;
}
}
public class Rectangle extends Shape {
private double width;
private double height;
public Rectangle(double width, double height) {
super("Rectangle");
this.width = width;
this.height = height;
}
@Override
public double area() {
return width * height;
}
}
public class Triangle extends Shape {
private double base;
private double height;
public Triangle(double base, double height) {
super("Triangle");
this.base = base;
this.height = height;
}
@Override
public double area() {
return 0.5 * base * height;
}
}
Polymorphism with Collections
The real power of polymorphism is working with a collection of objects through a common parent type. You do not need to know the specific type of each object — you just call the method, and each object does the right thing.
import java.util.List;
public class ShapeDemo {
public static void main(String[] args) {
// A list of Shape references, but each element is a different subclass
List shapes = List.of(
new Circle(5.0),
new Rectangle(4.0, 6.0),
new Triangle(3.0, 8.0),
new Circle(2.5),
new Rectangle(10.0, 3.0)
);
// Polymorphism in action: each shape calculates its own area
double totalArea = 0;
for (Shape shape : shapes) {
double area = shape.area(); // Dynamic dispatch -- calls the correct override
System.out.printf("%s: area = %.2f%n", shape.getName(), area);
totalArea += area;
}
System.out.printf("Total area: %.2f%n", totalArea);
}
}
// Output:
// Circle: area = 78.54
// Rectangle: area = 24.00
// Triangle: area = 12.00
// Circle: area = 19.63
// Rectangle: area = 30.00
// Total area: 164.17
Notice that the loop code does not contain a single if or instanceof check. It does not care whether a shape is a Circle, Rectangle, or Triangle. It simply calls area(), and polymorphism ensures the correct version runs. This is what makes polymorphic code so clean and extensible — to add a new shape (Pentagon, Ellipse, etc.), you only need to create a new subclass. The existing loop works without any changes.
The instanceof Operator and Pattern Matching
Sometimes you need to check the actual type of an object at runtime. The instanceof operator returns true if an object is an instance of a specific class (or any of its subclasses). Since Java 16, pattern matching lets you combine the type check and the cast in one step.
// Traditional instanceof (pre-Java 16)
public static void describeShape(Shape shape) {
if (shape instanceof Circle) {
Circle circle = (Circle) shape; // Manual cast required
System.out.println("Circle with radius: " + circle.getRadius());
} else if (shape instanceof Rectangle) {
Rectangle rect = (Rectangle) shape;
System.out.println("Rectangle " + rect.getWidth() + " x " + rect.getHeight());
} else {
System.out.println("Unknown shape: " + shape.getName());
}
}
// Pattern matching instanceof (Java 16+) -- cleaner syntax
public static void describeShapeModern(Shape shape) {
if (shape instanceof Circle circle) {
// 'circle' is automatically cast -- no explicit cast needed
System.out.println("Circle with radius: " + circle.getRadius());
} else if (shape instanceof Rectangle rect) {
System.out.println("Rectangle " + rect.getWidth() + " x " + rect.getHeight());
} else {
System.out.println("Unknown shape: " + shape.getName());
}
}
A word of caution: Heavy use of instanceof often signals a design problem. If you find yourself writing long instanceof chains, ask whether polymorphism could solve the problem more cleanly. Let each subclass define its own behavior through overriding rather than checking types externally.
4. Abstraction
Abstraction is the process of hiding complex implementation details and exposing only what is necessary. When you use a List in Java, you call add(), get(), and remove() without knowing whether the underlying implementation is an ArrayList (backed by an array) or a LinkedList (backed by nodes). That is abstraction at work.
Think of it like driving a car: you interact with the steering wheel, pedals, and gear shift (the abstraction). You do not need to understand how the engine combustion, transmission gearing, or electronic fuel injection works. The complexity is hidden behind a simple interface.
Java provides two mechanisms for abstraction: abstract classes and interfaces.
Abstract Classes
An abstract class is a class that cannot be instantiated directly. It serves as a blueprint for subclasses. It can contain:
Abstract methods (declared with abstract, no body) — Subclasses must implement these.
Concrete methods (with a body) — Subclasses inherit these and can optionally override them.
Fields, constructors, and static methods — Just like a regular class.
Use an abstract class when subclasses share common state (fields) or behavior (method implementations), but also have behavior that varies from subclass to subclass.
public abstract class PaymentMethod {
private String ownerName;
private double transactionFeePercent;
public PaymentMethod(String ownerName, double transactionFeePercent) {
this.ownerName = ownerName;
this.transactionFeePercent = transactionFeePercent;
}
// Abstract method -- each payment type processes payments differently
public abstract boolean processPayment(double amount);
// Abstract method -- each payment type displays its info differently
public abstract String getPaymentDetails();
// Concrete method -- shared by all payment types
public double calculateFee(double amount) {
return amount * (transactionFeePercent / 100.0);
}
// Concrete method -- shared logic
public void printReceipt(double amount) {
double fee = calculateFee(amount);
System.out.println("=== Payment Receipt ===");
System.out.println("Paid by: " + ownerName);
System.out.println("Method: " + getPaymentDetails());
System.out.printf("Amount: $%.2f%n", amount);
System.out.printf("Fee: $%.2f%n", fee);
System.out.printf("Total: $%.2f%n", amount + fee);
System.out.println("=======================");
}
public String getOwnerName() { return ownerName; }
}
public class CreditCard extends PaymentMethod {
private String cardNumber;
private String expirationDate;
public CreditCard(String ownerName, String cardNumber, String expirationDate) {
super(ownerName, 2.9); // Credit cards typically charge ~2.9% fee
this.cardNumber = cardNumber;
this.expirationDate = expirationDate;
}
@Override
public boolean processPayment(double amount) {
// In a real app, this would call a payment gateway API
System.out.println("Charging $" + amount + " to credit card ending in "
+ cardNumber.substring(cardNumber.length() - 4));
return true;
}
@Override
public String getPaymentDetails() {
return "Credit Card ending in " + cardNumber.substring(cardNumber.length() - 4)
+ " (exp: " + expirationDate + ")";
}
}
public class BankTransfer extends PaymentMethod {
private String bankName;
private String accountNumber;
public BankTransfer(String ownerName, String bankName, String accountNumber) {
super(ownerName, 0.5); // Bank transfers have lower fees
this.bankName = bankName;
this.accountNumber = accountNumber;
}
@Override
public boolean processPayment(double amount) {
System.out.println("Initiating bank transfer of $" + amount
+ " from " + bankName + " account ending in "
+ accountNumber.substring(accountNumber.length() - 4));
return true;
}
@Override
public String getPaymentDetails() {
return bankName + " account ending in "
+ accountNumber.substring(accountNumber.length() - 4);
}
}
public class PayPal extends PaymentMethod {
private String email;
public PayPal(String ownerName, String email) {
super(ownerName, 3.5); // PayPal fees
this.email = email;
}
@Override
public boolean processPayment(double amount) {
System.out.println("Processing PayPal payment of $" + amount
+ " from " + email);
return true;
}
@Override
public String getPaymentDetails() {
return "PayPal (" + email + ")";
}
}
// Usage -- polymorphism + abstraction working together:
public class PaymentDemo {
public static void main(String[] args) {
PaymentMethod creditCard = new CreditCard("Alice", "4111111111111234", "12/26");
PaymentMethod bankTransfer = new BankTransfer("Bob", "Chase", "9876543210");
PaymentMethod paypal = new PayPal("Charlie", "charlie@email.com");
// Process payments polymorphically
List payments = List.of(creditCard, bankTransfer, paypal);
for (PaymentMethod payment : payments) {
payment.processPayment(100.00);
payment.printReceipt(100.00);
System.out.println();
}
// You cannot instantiate an abstract class:
// PaymentMethod pm = new PaymentMethod("Test", 1.0); // Compile error
}
}
// Output:
// Charging $100.0 to credit card ending in 1234
// === Payment Receipt ===
// Paid by: Alice
// Method: Credit Card ending in 1234 (exp: 12/26)
// Amount: $100.00
// Fee: $2.90
// Total: $102.90
// =======================
//
// Initiating bank transfer of $100.0 from Chase account ending in 3210
// === Payment Receipt ===
// Paid by: Bob
// Method: Chase account ending in 3210
// Amount: $100.00
// Fee: $0.50
// Total: $100.50
// =======================
//
// Processing PayPal payment of $100.0 from charlie@email.com
// === Payment Receipt ===
// Paid by: Charlie
// Method: PayPal (charlie@email.com)
// Amount: $100.00
// Fee: $3.50
// Total: $103.50
// =======================
Interfaces
An interface defines a contract — a set of methods that implementing classes must provide. Unlike abstract classes, interfaces:
Cannot have instance fields (only public static final constants).
Cannot have constructors.
Support multiple implementation — a class can implement many interfaces.
Since Java 8, can have default methods (methods with a body) and static methods.
Since Java 9, can have private methods for internal code reuse.
Use an interface when you want to define what a class can do without dictating how it does it or what state it holds.
// Interface defines a contract: any Sortable object can be sorted
public interface Sortable {
int compareTo(Object other);
}
// Interface with default method (Java 8+)
public interface Loggable {
String getLogPrefix();
// Default method -- provides a default implementation
default void log(String message) {
System.out.println("[" + getLogPrefix() + "] " + message);
}
}
// Interface with static method
public interface Identifiable {
String getId();
static boolean isValidId(String id) {
return id != null && id.length() >= 3;
}
}
// A class can implement multiple interfaces
public class Product implements Loggable, Identifiable {
private String id;
private String name;
private double price;
public Product(String id, String name, double price) {
this.id = id;
this.name = name;
this.price = price;
}
@Override
public String getLogPrefix() {
return "Product-" + id;
}
@Override
public String getId() {
return id;
}
public String getName() { return name; }
public double getPrice() { return price; }
}
// Usage:
Product laptop = new Product("P001", "Laptop", 999.99);
laptop.log("Created successfully"); // [Product-P001] Created successfully
System.out.println(Identifiable.isValidId("P001")); // true
System.out.println(Identifiable.isValidId("AB")); // false
Abstract Class vs. Interface: When to Use Which
Feature
Abstract Class
Interface
Instance fields
Yes — can have instance variables
No — only public static final constants
Constructors
Yes
No
Method bodies
Can have both abstract and concrete methods
Abstract by default; default and static methods since Java 8
Multiple inheritance
No — single extends only
Yes — a class can implement many interfaces
Access modifiers
Any (private, protected, public)
public (or private since Java 9 for helper methods)
When to use
Subclasses share common state and behavior
Unrelated classes need to share a capability
Relationship
"IS-A" with shared implementation
"CAN-DO" capability contract
Example
abstract class Animal — Dog, Cat share fields
interface Serializable — any class can be serializable
Rule of thumb: Use an interface to define what an object can do. Use an abstract class when you also want to provide shared state or partial implementation that subclasses can build on.
5. Composition vs. Inheritance
Inheritance represents an IS-A relationship (a Dog IS-A Animal). Composition represents a HAS-A relationship (a Car HAS-A Engine). Both are tools for code reuse, but they serve different purposes and have different trade-offs.
A common mistake among beginners is reaching for inheritance when composition would be more appropriate. The famous advice from the Gang of Four (GoF) design patterns book is: "Favor composition over inheritance."
Why Composition Is Often Preferred
Loose coupling — With composition, you can swap components at runtime. With inheritance, the parent-child relationship is fixed at compile time.
No fragile base class problem — Changing a parent class can break all subclasses. Changing a composed object only affects that object.
More flexible — A class can be composed of many objects (has-a Engine, has-a Transmission, has-a GPS), but can only extend one parent.
// BAD: Using inheritance where composition is more appropriate
// A Car is NOT an Engine -- it HAS an Engine
public class Engine {
public void start() {
System.out.println("Engine started");
}
}
// This is wrong -- a Car is not a kind of Engine
// public class Car extends Engine { }
// GOOD: Using composition -- Car HAS-A Engine
public class Engine {
private int horsepower;
public Engine(int horsepower) {
this.horsepower = horsepower;
}
public void start() {
System.out.println(horsepower + "HP engine started");
}
public void stop() {
System.out.println("Engine stopped");
}
}
public class Transmission {
private String type; // "automatic" or "manual"
public Transmission(String type) {
this.type = type;
}
public void shift(int gear) {
System.out.println(type + " transmission shifted to gear " + gear);
}
}
public class GPS {
public void navigate(String destination) {
System.out.println("Navigating to " + destination);
}
}
public class Car {
// Composition: Car HAS-A Engine, Transmission, and GPS
private final Engine engine;
private final Transmission transmission;
private GPS gps; // Optional -- can be added or removed
public Car(Engine engine, Transmission transmission) {
this.engine = engine;
this.transmission = transmission;
}
public void installGPS(GPS gps) {
this.gps = gps; // Components can be swapped at runtime
}
public void drive(String destination) {
engine.start();
transmission.shift(1);
if (gps != null) {
gps.navigate(destination);
}
}
}
// Usage:
Engine v6 = new Engine(300);
Transmission auto = new Transmission("automatic");
Car myCar = new Car(v6, auto);
myCar.installGPS(new GPS());
myCar.drive("New York");
// Output:
// 300HP engine started
// automatic transmission shifted to gear 1
// Navigating to New York
When to Use Inheritance vs. Composition
Use Inheritance When
Use Composition When
There is a genuine IS-A relationship
There is a HAS-A relationship
Subclass is a specialization of the parent
You want to reuse behavior from multiple sources
You want polymorphic behavior
You want to swap components at runtime
Example: Dog extends Animal
Example: Car has Engine, Wheels, GPS
6. SOLID Principles
The SOLID principles are five design guidelines that help you write OOP code that is maintainable, flexible, and resilient to change. They were popularized by Robert C. Martin (Uncle Bob) and are considered essential knowledge for any professional Java developer.
Letter
Principle
In Plain English
S
Single Responsibility
A class should have only one reason to change.
O
Open/Closed
Classes should be open for extension but closed for modification.
L
Liskov Substitution
Subclasses should be usable wherever their parent class is expected.
I
Interface Segregation
Prefer many small interfaces over one large, general-purpose interface.
D
Dependency Inversion
Depend on abstractions (interfaces), not concrete implementations.
Practical Example: Single Responsibility Principle
The most commonly violated SOLID principle is the Single Responsibility Principle (SRP). Here is what a violation looks like and how to fix it:
// BAD: This class has too many responsibilities
// It handles user data, validation, database operations, AND email sending.
// If any of those concerns change, this class must change.
public class UserService {
public void registerUser(String name, String email, String password) {
// 1. Validation
if (name == null || name.isBlank()) throw new IllegalArgumentException("Invalid name");
if (!email.contains("@")) throw new IllegalArgumentException("Invalid email");
if (password.length() < 8) throw new IllegalArgumentException("Password too short");
// 2. Database operation
String sql = "INSERT INTO users (name, email, password) VALUES (?, ?, ?)";
// ... execute SQL ...
// 3. Email sending
// ... connect to SMTP server, build email, send ...
System.out.println("Welcome email sent to " + email);
// 4. Logging
System.out.println("[LOG] User registered: " + email);
}
}
// GOOD: Each class has a single responsibility
public class UserValidator {
public void validate(String name, String email, String password) {
if (name == null || name.isBlank()) throw new IllegalArgumentException("Invalid name");
if (!email.contains("@")) throw new IllegalArgumentException("Invalid email");
if (password.length() < 8) throw new IllegalArgumentException("Password too short");
}
}
public class UserRepository {
public void save(User user) {
String sql = "INSERT INTO users (name, email, password) VALUES (?, ?, ?)";
// ... execute SQL ...
}
}
public class EmailService {
public void sendWelcomeEmail(String email) {
// ... connect to SMTP server, build email, send ...
System.out.println("Welcome email sent to " + email);
}
}
// The service class now coordinates (orchestrates) -- it does not do the actual work
public class UserService {
private final UserValidator validator;
private final UserRepository repository;
private final EmailService emailService;
public UserService(UserValidator validator, UserRepository repository, EmailService emailService) {
this.validator = validator;
this.repository = repository;
this.emailService = emailService;
}
public void registerUser(String name, String email, String password) {
validator.validate(name, email, password);
User user = new User(name, email, password);
repository.save(user);
emailService.sendWelcomeEmail(email);
}
}
Now each class has exactly one reason to change: UserValidator changes when validation rules change, UserRepository changes when the database schema changes, EmailService changes when the email provider changes. The UserService only changes when the overall registration workflow changes.
Quick Summary of Remaining SOLID Principles
Open/Closed Principle: You should be able to add new behavior (new shapes, new payment methods) by creating new classes, not by modifying existing ones. The Shape and PaymentMethod examples earlier in this tutorial follow this principle — adding a Pentagon class requires no changes to existing code.
Liskov Substitution Principle: If your code works with a Vehicle reference, it should work correctly regardless of whether the actual object is a Car, Truck, or ElectricCar. Subclasses must not violate the expectations set by the parent class.
Interface Segregation Principle: Instead of one large Worker interface with code(), manage(), test(), and design(), create separate Coder, Manager, Tester, and Designer interfaces. A class should not be forced to implement methods it does not use.
Dependency Inversion Principle: High-level modules should depend on abstractions (interfaces), not concrete classes. Notice how the UserService constructor accepts interfaces/abstractions rather than creating concrete instances with new. This makes the code testable and flexible.
7. Common OOP Mistakes
Even experienced developers fall into these traps. Being aware of them will save you hours of debugging and refactoring.
Mistake 1: Overusing Inheritance
Not every code-reuse scenario calls for inheritance. If the relationship is not genuinely IS-A, use composition instead.
// BAD: Stack is NOT an ArrayList -- it just uses one internally
// By extending ArrayList, Stack exposes methods like add(index, element)
// and remove(index) that violate stack behavior (LIFO).
public class Stack extends ArrayList {
public void push(T item) { add(item); }
public T pop() { return remove(size() - 1); }
}
// Users can bypass the stack behavior:
Stack stack = new Stack<>();
stack.push("A");
stack.push("B");
stack.add(0, "WRONG"); // This should not be allowed on a stack!
// GOOD: Use composition -- Stack HAS-A List
public class Stack {
private final List items = new ArrayList<>();
public void push(T item) { items.add(item); }
public T pop() { return items.remove(items.size() - 1); }
public T peek() { return items.get(items.size() - 1); }
public boolean isEmpty() { return items.isEmpty(); }
public int size() { return items.size(); }
// No add(index, element), remove(index), or other List methods exposed
}
Mistake 2: Breaking Encapsulation
Creating a getter and setter for every field defeats the purpose of encapsulation. Only expose what outside code genuinely needs.
// BAD: Every field has a public getter and setter -- this is barely
// better than making the fields public.
public class Order {
private double subtotal;
private double tax;
private double total;
public void setSubtotal(double subtotal) { this.subtotal = subtotal; }
public void setTax(double tax) { this.tax = tax; }
public void setTotal(double total) { this.total = total; }
// Nothing stops someone from setting total to a value that
// does not equal subtotal + tax.
}
// GOOD: The object manages its own derived state.
public class Order {
private double subtotal;
private double taxRate;
public Order(double subtotal, double taxRate) {
this.subtotal = subtotal;
this.taxRate = taxRate;
}
public double getSubtotal() { return subtotal; }
public double getTax() { return subtotal * taxRate; }
public double getTotal() { return subtotal + getTax(); }
// total is always consistent -- it cannot be set to a wrong value
}
Mistake 3: God Classes
A "God class" is a single class that tries to do everything. It violates the Single Responsibility Principle and quickly becomes unmaintainable. If your class has more than 300-500 lines or the word "Manager" or "Utility" in the name with dozens of methods, it is probably doing too much. Break it up into focused classes.
Mistake 4: Violating the Liskov Substitution Principle
// Classic LSP violation: Square extends Rectangle
public class Rectangle {
protected int width;
protected int height;
public void setWidth(int width) { this.width = width; }
public void setHeight(int height) { this.height = height; }
public int getArea() { return width * height; }
}
public class Square extends Rectangle {
// A square must maintain width == height
@Override
public void setWidth(int width) {
this.width = width;
this.height = width; // Unexpected side effect!
}
@Override
public void setHeight(int height) {
this.width = height;
this.height = height; // Unexpected side effect!
}
}
// This code works correctly for Rectangle but breaks for Square:
public void resize(Rectangle rect) {
rect.setWidth(5);
rect.setHeight(10);
// Expected area: 50
System.out.println(rect.getArea());
// For Rectangle: 50 (correct)
// For Square: 100 (WRONG -- setHeight changed width too)
}
// The fix: Square should NOT extend Rectangle.
// Instead, create a Shape interface that both implement independently.
Mistake 5: Exposing Mutable Internal State
// BAD: Returning the internal list directly
public class Team {
private List members = new ArrayList<>();
public List getMembers() {
return members; // Caller can modify the internal list!
}
}
Team team = new Team();
team.getMembers().add("Alice");
team.getMembers().clear(); // Oops -- cleared the team's internal data!
// GOOD: Return a defensive copy or an unmodifiable view
public class Team {
private final List members = new ArrayList<>();
public void addMember(String name) {
members.add(name);
}
public List getMembers() {
return Collections.unmodifiableList(members); // Read-only view
}
}
8. Complete Practical Example: Employee Management System
Let us tie everything together with a complete, compilable example that demonstrates all four pillars of OOP working in concert. We will build a simple employee management system with:
Encapsulation — Private fields with validation
Inheritance — Manager and Developer extend Employee
Polymorphism — Each employee type calculates bonus differently
Abstraction — Abstract Employee class and Reviewable interface
Composition — Department HAS employees
// === Interface: defines a capability contract ===
public interface Reviewable {
String performReview();
int getPerformanceScore(); // 1-10
}
public interface Promotable {
boolean isEligibleForPromotion();
void promote(String newTitle);
}
// === Abstract base class: shared state and behavior ===
public abstract class Employee implements Reviewable, Promotable {
// Encapsulation: all fields are private
private final String employeeId;
private String name;
private String title;
private double baseSalary;
private int yearsOfExperience;
public Employee(String employeeId, String name, String title,
double baseSalary, int yearsOfExperience) {
this.employeeId = employeeId;
this.name = name;
this.title = title;
setBaseSalary(baseSalary);
this.yearsOfExperience = yearsOfExperience;
}
// Abstract methods -- each employee type implements differently
public abstract double calculateBonus();
public abstract String getRole();
// Concrete method -- shared by all employees
public double getTotalCompensation() {
return baseSalary + calculateBonus();
}
// Encapsulation: validation in setter
public void setBaseSalary(double baseSalary) {
if (baseSalary < 30000) {
throw new IllegalArgumentException("Salary must be at least $30,000");
}
this.baseSalary = baseSalary;
}
// Promotable interface implementation
@Override
public boolean isEligibleForPromotion() {
return yearsOfExperience >= 2 && getPerformanceScore() >= 7;
}
@Override
public void promote(String newTitle) {
if (!isEligibleForPromotion()) {
System.out.println(name + " is not eligible for promotion yet.");
return;
}
this.title = newTitle;
this.baseSalary *= 1.15; // 15% raise on promotion
System.out.println(name + " promoted to " + newTitle
+ "! New salary: $" + String.format("%.2f", baseSalary));
}
// Getters
public String getEmployeeId() { return employeeId; }
public String getName() { return name; }
public String getTitle() { return title; }
public double getBaseSalary() { return baseSalary; }
public int getYearsOfExperience() { return yearsOfExperience; }
@Override
public String toString() {
return String.format("[%s] %s - %s (%s) | Salary: $%.2f | Bonus: $%.2f",
employeeId, name, title, getRole(), baseSalary, calculateBonus());
}
}
// === Concrete subclass: Developer ===
public class Developer extends Employee {
private String programmingLanguage;
private int pullRequestsPerMonth;
private int bugFixesPerMonth;
public Developer(String employeeId, String name, String title,
double baseSalary, int yearsOfExperience,
String programmingLanguage) {
super(employeeId, name, title, baseSalary, yearsOfExperience);
this.programmingLanguage = programmingLanguage;
this.pullRequestsPerMonth = 0;
this.bugFixesPerMonth = 0;
}
public void logWork(int pullRequests, int bugFixes) {
this.pullRequestsPerMonth += pullRequests;
this.bugFixesPerMonth += bugFixes;
}
// Polymorphism: Developer's bonus is based on output metrics
@Override
public double calculateBonus() {
double baseBonus = getBaseSalary() * 0.10; // 10% base bonus
double outputBonus = (pullRequestsPerMonth * 200) + (bugFixesPerMonth * 150);
return baseBonus + outputBonus;
}
@Override
public String getRole() {
return "Developer (" + programmingLanguage + ")";
}
// Reviewable interface
@Override
public String performReview() {
return getName() + " review: " + pullRequestsPerMonth + " PRs, "
+ bugFixesPerMonth + " bug fixes this month.";
}
@Override
public int getPerformanceScore() {
if (pullRequestsPerMonth >= 15 && bugFixesPerMonth >= 5) return 10;
if (pullRequestsPerMonth >= 10) return 8;
if (pullRequestsPerMonth >= 5) return 6;
return 4;
}
public String getProgrammingLanguage() { return programmingLanguage; }
}
// === Concrete subclass: Manager ===
public class Manager extends Employee {
private List directReports;
private double teamPerformanceRating; // 1.0 - 5.0
public Manager(String employeeId, String name, String title,
double baseSalary, int yearsOfExperience) {
super(employeeId, name, title, baseSalary, yearsOfExperience);
this.directReports = new ArrayList<>();
this.teamPerformanceRating = 3.0;
}
public void addDirectReport(Employee employee) {
directReports.add(employee);
System.out.println(employee.getName() + " now reports to " + getName());
}
public void setTeamPerformanceRating(double rating) {
if (rating < 1.0 || rating > 5.0) {
throw new IllegalArgumentException("Rating must be between 1.0 and 5.0");
}
this.teamPerformanceRating = rating;
}
// Polymorphism: Manager's bonus depends on team size and performance
@Override
public double calculateBonus() {
double baseBonus = getBaseSalary() * 0.15; // 15% base bonus (higher than developer)
double teamBonus = directReports.size() * 1000 * teamPerformanceRating;
return baseBonus + teamBonus;
}
@Override
public String getRole() {
return "Manager (" + directReports.size() + " reports)";
}
// Reviewable interface
@Override
public String performReview() {
return getName() + " review: Managing " + directReports.size()
+ " employees, team rating: " + teamPerformanceRating;
}
@Override
public int getPerformanceScore() {
if (teamPerformanceRating >= 4.5) return 10;
if (teamPerformanceRating >= 3.5) return 8;
if (teamPerformanceRating >= 2.5) return 6;
return 4;
}
public List getDirectReports() {
return Collections.unmodifiableList(directReports);
}
}
// === Composition: Department HAS employees ===
public class Department {
private final String name;
private final List employees;
public Department(String name) {
this.name = name;
this.employees = new ArrayList<>();
}
public void addEmployee(Employee employee) {
employees.add(employee);
}
// Polymorphism: works with any Employee subclass
public void printDepartmentReport() {
System.out.println("\n=== " + name + " Department Report ===");
System.out.println("Total employees: " + employees.size());
double totalSalary = 0;
double totalBonus = 0;
for (Employee emp : employees) {
System.out.println(emp); // Calls toString() -- polymorphism
System.out.println(" " + emp.performReview()); // Interface method -- polymorphism
totalSalary += emp.getBaseSalary();
totalBonus += emp.calculateBonus(); // Each type calculates differently
}
System.out.printf("%nDepartment totals -- Salaries: $%.2f | Bonuses: $%.2f | Total: $%.2f%n",
totalSalary, totalBonus, totalSalary + totalBonus);
}
// Find highest performer using polymorphism
public Employee getTopPerformer() {
return employees.stream()
.max((a, b) -> Integer.compare(a.getPerformanceScore(), b.getPerformanceScore()))
.orElse(null);
}
public String getName() { return name; }
public List getEmployees() {
return Collections.unmodifiableList(employees);
}
}
// === Putting it all together ===
import java.util.*;
public class EmployeeManagementDemo {
public static void main(String[] args) {
// Create employees (Abstraction: we use Employee references for polymorphism)
Developer dev1 = new Developer("D001", "Alice", "Senior Developer",
95000, 5, "Java");
Developer dev2 = new Developer("D002", "Bob", "Junior Developer",
65000, 1, "Python");
Developer dev3 = new Developer("D003", "Charlie", "Mid Developer",
80000, 3, "Java");
Manager mgr1 = new Manager("M001", "Diana", "Engineering Manager",
120000, 8);
// Log some work for developers
dev1.logWork(18, 7); // 18 PRs, 7 bug fixes
dev2.logWork(6, 2); // 6 PRs, 2 bug fixes
dev3.logWork(12, 4); // 12 PRs, 4 bug fixes
// Set up manager's team
mgr1.addDirectReport(dev1);
mgr1.addDirectReport(dev2);
mgr1.addDirectReport(dev3);
mgr1.setTeamPerformanceRating(4.2);
// Composition: create a department that HAS employees
Department engineering = new Department("Engineering");
engineering.addEmployee(dev1);
engineering.addEmployee(dev2);
engineering.addEmployee(dev3);
engineering.addEmployee(mgr1);
// Polymorphism: the department works with all employee types uniformly
engineering.printDepartmentReport();
// Find and promote top performer
Employee topPerformer = engineering.getTopPerformer();
if (topPerformer != null) {
System.out.println("\nTop performer: " + topPerformer.getName()
+ " (score: " + topPerformer.getPerformanceScore() + ")");
topPerformer.promote("Lead " + topPerformer.getTitle());
}
}
}
// Output:
//
// Alice now reports to Diana
// Bob now reports to Diana
// Charlie now reports to Diana
//
// === Engineering Department Report ===
// Total employees: 4
// [D001] Alice - Senior Developer (Developer (Java)) | Salary: $95000.00 | Bonus: $14150.00
// Alice review: 18 PRs, 7 bug fixes this month.
// [D002] Bob - Junior Developer (Developer (Python)) | Salary: $65000.00 | Bonus: $7700.00
// Bob review: 6 PRs, 2 bug fixes this month.
// [D003] Charlie - Mid Developer (Developer (Java)) | Salary: $80000.00 | Bonus: $10600.00
// Charlie review: 12 PRs, 4 bug fixes this month.
// [M001] Diana - Engineering Manager (Manager (3 reports)) | Salary: $120000.00 | Bonus: $30600.00
// Diana review: Managing 3 employees, team rating: 4.2
//
// Department totals -- Salaries: $360000.00 | Bonuses: $63050.00 | Total: $423050.00
//
// Top performer: Alice (score: 10)
// Alice promoted to Lead Senior Developer! New salary: $109250.00
What This Example Demonstrates
OOP Concept
Where It Appears
Encapsulation
All fields are private; salary has validation in the setter; internal lists are returned as unmodifiable views
Inheritance
Developer and Manager extend Employee; shared fields and methods (name, salary, getTotalCompensation()) live in the parent
Polymorphism
Department.printDepartmentReport() calls calculateBonus() and performReview() on each employee — each type responds differently
Abstraction
Employee is abstract with abstract methods; Reviewable and Promotable interfaces define capability contracts
Composition
Department HAS-A list of employees; Manager HAS-A list of direct reports
SRP
Each class has one responsibility: Employee holds employee data, Department manages a group of employees
9. Summary and Quick Reference
Concept
Definition
Java Keywords
Remember
Encapsulation
Hide internal state; control access through methods
private, getters/setters
Make fields private. Validate in setters. Expose only what is needed.
Inheritance
Create IS-A relationships; reuse parent class code
extends, super, @Override
Only use for genuine IS-A relationships. Prefer composition for HAS-A.
Polymorphism
One type, many forms; same method call, different behavior
Overloading, overriding, upcasting
Parent references can hold child objects. Method calls resolve at runtime.
Abstraction
Hide complexity; expose only essential features
abstract, interface
Abstract class for shared state. Interface for shared capability.
Composition
Build complex objects by combining simpler ones
Instance fields of other class types
"Favor composition over inheritance." Use HAS-A when IS-A does not apply.
SOLID
Five principles for maintainable OOP design
Design principles, not keywords
One responsibility per class. Depend on abstractions, not concrete types.
Key Takeaways
Start with encapsulation. Make every field private. Only add getters and setters that your code actually needs. Validate data in setters.
Use inheritance sparingly. Only extend a class when there is a genuine IS-A relationship. Otherwise, use composition.
Design for polymorphism. Write code that works with parent types and interfaces. This makes your system extensible without modifying existing code.
Abstract the right things. Use abstract classes for shared state and behavior. Use interfaces for shared capabilities across unrelated classes.
Follow SOLID principles. Keep classes small and focused. Depend on abstractions. Make sure subclasses are true substitutes for their parents.
Think before you code. Ask yourself: "What objects exist in this problem? What does each one know (state)? What can each one do (behavior)? How do they relate to each other?" This is the OOP mindset.