JoltReload is an experimental Java agent that enables hot-reloading of Java classes at runtime, including the ability to add new methods and fields without restarting the JVM. It's designed to significantly improve developer productivity by eliminating restart cycles during development.
Enable true hot-reload for Java applications during development, allowing developers to:
- Add new methods to existing classes
- Add new fields to existing classes
- Modify existing method implementations
- See changes reflected immediately in running applications
Traditional Java hot-reload solutions (like JVM HotSwap) are limited to modifying method bodies only. They cannot:
- Add and remove methods or fields
- Change method signatures or field types
JoltReload works around these JVM limitations through innovative bytecode manipulation techniques, providing a more complete hot-reload experience.
While there are existing solutions for Java hot-reload, each has significant limitations. JRebel is the most mature and full-featured option, but requires a commercial license, limiting innovation on top of it. Spring-loaded was a promising open-source alternative but is no longer maintained and doesn't support modern Java versions. DCEVM + Hotswap Agent (Dynamic Code Evolution VM) offers powerful capabilities but requires using a specially patched JVM, which isn't always feasible in development environments and is only available as Jetbrains Runtime.
JoltReload aims to fill this gap by providing a free, open-source solution that works on any standard JVM 11 or higher without requiring patches or modifications. It uses pure Java agent technology and bytecode manipulation to achieve hot-reload capabilities that go beyond the JVM's built-in HotSwap.
🚧 This project is under active development and is NOT ready for production use.
- ✅ Adding new instance and static methods
- ✅ Adding new instance and static fields
- ✅ Method modifications take effect on existing instances
- ✅ Full reflection support for dynamically added members
- ✅ Comprehensive test coverage for core functionality
- 🔄 Currently only calls in the same class are rewritten. Cross-class calls in arbitrary order need to be handled
- 🔄 The field mechansim only works with a fixed number of additions. Resizing of the underlying datastructure is not yet implemented
- 🔄 The file-watching mechanism to detect changed class/jar files on disk is missing
- 🔄 Support for annotation addition / changes
- 🔄 We need a plugin SPI to hook into reloads to clear/reload framework caches and recreate proxies
- Cannot change class hierarchy (interfaces, superclasses)
- Limited to a fixed number of new fields (currently 10 instance, 5 static)
- Requires specific JVM flags for JDK 11+
- May not work with all frameworks or libraries
- Performance impact has not been fully evaluated
JoltReload uses a "delta class pattern" to work around JVM restrictions:
- During initial class loading, it adds infrastructure for future modifications
- When methods are added, it generates synthetic "delta" classes containing the new methods
- It rewrites bytecode to transparently redirect calls to the delta classes
- Field additions use pre-allocated backing arrays with synthetic accessors
For detailed architecture information, see docs/architecture.md.
- Java 11 or higher
- Gradle
./gradlew build
./gradlew :agent:shadowJarjava -javaagent:agent/build/libs/agent-all.jar \
--add-opens=java.base/jdk.internal.misc=ALL-UNNAMED \
--add-opens=java.base/java.lang.reflect=ALL-UNNAMED \
-jar your-application.jar./gradlew test- Architecture Overview - Detailed technical documentation
- Coding Guidelines - Development practices and patterns
- CLAUDE.md - AI assistant guidance for the codebase
As this is an experimental project, we welcome contributions, feedback, and ideas. However, please note:
- The API and implementation may change significantly
- Focus is currently on core functionality rather than production readiness
- Extensive testing is required before considering any production use
This project is licensed under the Apache License 2.0 - see the LICENSE file for details.
- Modifies JVM internals using Unsafe operations
- May cause application instability
- Has not been tested for security implications
- Could have memory leaks with excessive reloads
- May conflict with other agents or JVM features
This project is intended for development environments only where application restart is acceptable if issues occur.
This project explores the boundaries of what's possible with Java bytecode manipulation and the JVM's instrumentation API. It's inspired by the developer experience provided by hot-reload in other languages and aims to bring similar capabilities to Java development.