Lab 02 — API Compatibility Checker
What You'll Build
A diffing engine that compares two API snapshots (sets of MethodSignature)
and classifies each change as REMOVED, ADDED, or MODIFIED — then reports
which changes are binary-breaking.
Concepts
| Change type | Binary-breaking? | Explanation |
|---|---|---|
| REMOVED | Yes | Callers compiled against the old API get NoSuchMethodError at runtime |
| MODIFIED (return type changed) | Yes | The JVM encodes return type in the method descriptor |
| ADDED | No | Callers compiled against the old API still link correctly |
This is exactly what japicmp does — this lab reimplements the core classification logic from scratch.
Running
mvn test
Expected: 9 tests, 0 failures.
Key Classes
| Class | Role |
|---|---|
MethodSignature | className + methodName + returnType + parameterTypes; methodKey() is the identity key |
ChangeType | Enum: REMOVED, ADDED, MODIFIED |
CompatibilityIssue | One change: method + changeType + isBinaryBreaking() |
CompatibilityReport | Aggregated result with helpers for binary-breaking issues vs. compatible additions |
ApiCompatibilityChecker | check(oldApi, newApi) — the diffing algorithm |
Algorithm
- Build
Map<methodKey, MethodSignature>for each snapshot. - Key in old, absent in new → REMOVED.
- Key in both, return type differs → MODIFIED.
- Key in new, absent in old → ADDED.
Interview Angle
Explain why method return type is part of the JVM method descriptor (§4.3.3 of the JVM spec), and why changing it is binary-breaking even though Java source code only cares about the method name and parameter types.