Fantastic Frameworks and How to Avoid Them
summary
Argues that classpath scanning and runtime proxies (reflection, annotation processing, thread‑locals) create long‑term coupling, dependency hell and bigger startup/memory costs; recommends constructor‑based injection, Java config, shading small libs and ArcUnit checks. Shows concrete rescue: months spent attempting an Axon→Kafka module, then a custom lightweight router + Kafka listener replaces framework magic and runs alongside the old stack after six hours of work. Cites alternatives: JDBC Template, jOOQ, Kotlin Exposed, Quarkus, Ratpack, and Hazelcast shading.
AI-written summary · about
chapters (16)
- 0:00Introduction and welcome
- 1:05Why avoid invasive frameworks
- 6:29Defining invasive frameworks
- 11:05Minimizing dependencies in projects
- 15:04Frameworks vs libraries
- 16:53Frameworks beyond software
- 18:41Learning and maintaining frameworks
- 23:36Trade-offs of framework abstractions
- 25:07JPA and Hibernate pitfalls
- 30:10Keeping frameworks at a distance
- 32:19Improving Spring framework usage
- 37:39Non-invasive framework strategies
- 40:53Case study: Axon and Kafka migration
- 47:34Balancing frameworks and tools
- 50:23Common sense in framework choice
- 51:28Q&A session
related talks
44mKeep Spring at Arm's Length!
49mSpring, Jakarta EE, CDI and Other Pathologies
46mThe Case Against Frameworks
41mJava Beyond Frameworks: Avoiding Lock-In with Agnostic Design
56mBuilding a Framework on top of Spring Boot
38mKeynote
13mTo Framework or Not to Framework? That is the Question
56mDI Frameworks – some hidden pearls