Mastering Resilient Java API Design: From Principles to Practice
summary
Claims that Maven Central shows semantic versioning often fails because bugfix, minor and major bumps break consumers at the same rate, demonstrates that semantic versioning breaks in practice. Shows concrete Java gotchas: generics erase at runtime, compiler inlines string constants, and checked exceptions are a compile time concern not a runtime contract. Proposes a concrete design: use sealed classes + builders with inner classes, records and lambdas to produce policy objects and return streams not collections, a DSL-style API that prevents accidental subclassing and reduces binary breakage.
AI-written summary · about
chapters (15)
- 0:00Introduction and speaker background
- 1:27Legacy Java API design pitfalls
- 3:16API versioning challenges
- 5:06IDE time vs runtime misconceptions
- 10:06Compile time vs runtime failures
- 14:47Constant inlining dangers
- 17:15Policy process configuration separation
- 22:37Sealed classes for API control
- 27:17Builder pattern for resilient APIs
- 30:50Final methods and API boundaries
- 32:41Fluent DSLs with inner classes
- 33:24Avoiding primitives in APIs
- 34:49Modern Java API design principles
- 38:23Takeaways and future-proofing APIs
- 40:35Q&A and closing remarks
related talks
40mFuture-Proofing Java: The Art of Crafting Resilient APIs
27mModern Java API Design
59mMove Deliberately and Don’t Break Anything: Lessons from...Java
34mDesigning a Compatible API — Genius Without Villainy
49mLet's make a contract: the art of designing a Java API
51mLet's make a contract: the art of designing a Java API
01h 08mJava APIs - the Missing Manual
51mRevisiting Effective Java in 2020