Future-Proofing Java: The Art of Crafting Resilient APIs
summary
Maven Central analysis shows version numbers rarely predict breakage so rely on tests not tags; IntelliJ warnings and generics help but type erasure and unchecked runtime casts still break consumers; use Maven classpath setups with dependency excludes to run V1 vs V2 tests locally; beware static final inlining of String/primitive constants, checked exceptions are compile-time only, and changing visibility or return types breaks at runtime; prefer sealed classes, records and Builder patterns (Java 15+), streams, enums and immutable collections instead of primitives/arrays to make Java APIs evolvable and safer.
AI-written summary · about
chapters (10)
- 0:00Resilient Java APIs intro
- 4:20Semantic versioning failures
- 7:12IDEs misleading API design
- 11:35Refactoring without version testing
- 13:22Compile vs runtime API pitfalls
- 23:22Modern API design with sealed classes
- 30:21Avoid primitive and array misuse
- 33:54Enums and records for safer APIs
- 36:28API evolution best practices
- 37:55Future-proof Java APIs summary
related talks
44mMastering Resilient Java API Design: From Principles to Practice
27mModern Java API Design
41mModern Java for the Masses! Is Java Still Relevant
59mMove Deliberately and Don’t Break Anything: Lessons from...Java
46mStrengthening Java Apps: Best Practices in Secure Coding for Java Developers
51mLife Beyond Java 8
43mEngineering a Modern Java Platform
46mGoing Java::Current in Production