An Experiment in Continuous Deployment of JVM applications
summary
Claims a single JVM can receive bytecode updates with no downtime by streaming compiled .class bytes into a running process. Uses Instrumentation API to call redefineClasses and the Attach API to load a dynamic agent that listens to a Hazelcast map populated by Hazelcast Jet from the filesystem or CI. Limitations: only method bodies can change (no adding/removing fields or methods), no built-in version tagging, demo code on GitHub shows the proof of concept.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:26Continuous integration basics
- 3:10Continuous delivery vs deployment
- 4:37Zero-downtime deployment challenges
- 7:06Java agents and instrumentation API
- 9:21Dynamic agent attachment
- 12:11Attach API explained
- 14:20Stream processing engines
- 15:45Jet stream processing overview
- 17:08System architecture design
- 19:56Limitations of approach
- 21:00Future improvements
- 22:24Resources and demo
related talks
45mMaking Java more dynamic
46mThe Hitchhiker’s guide to Java class reloading
30mWriting Java agents for fun and not so much profit
14mHow does code hot swapping work, and what are its pitfalls?
55mMaking Java more dynamic
50mCode Coverage Instrumentation
47mLegal JVM Doping in Your Containers
39mThe Java Agent: Modifying Bytecode at Runtime to Protect Against Log4J