Changes
This build switches Hot Reload from using 'continuous builds' to the 'explicit reload' model.
Previously, a daemon would have picked this up, recompiled the code, and sent a 'reload' request to the application whenever source code changed and was saved to disk. With the 'explicit reload' model, reloading requires explicit consent from the user.
CLI usage:
Starting the application (unchanged)
kmp: ./gradlew jvmRunHot --mainClass myMain
jvm: ./gradlew runHot --mainClass my.Main
Requesting a recompile & reload
./gradlew reload
The continuous mode can be re-enabled on CLI using the --autoReload or --auto option, e.g.:
./gradlew jvmRunHot --mainClass my.Main --auto
Note: IDE
The continuous mode is still enabled when Hot Reload is launched from the IDE.
Later implementations of an IDE plugin will take care of explicitly requesting reloads.
Breaking Changes (Tooling Integration: IDE, Amper)
- Orchestration: Orchestration Messages serialVersionUID changed and is now pinned to be stable
Breaking Changes (Properties)
- The
compose.reload.devToolsEnabledproperty was previously used to disable the tooling window. The recompiler would have been unaffected. Since the 'devTools' now is also managing the 'recompiler' process, it is recommended to use thecompose.reload.devToolsHeadlessproperty instead
Misc Changes
- devtools: Dark theme
- Fixes in devtools: Window management, fixed reload animation
- Fixed deadlock in orchestration
- Always show the reload counter in devtools (even when minimized)
- Process Management: Recompiler is now bound to the 'devtools' process
- Fixed: Building a runtime classpath with opaque dependencies
- Fixed: Changing source code before the 'recompiler warmed up' lead to inconsistent states