@Groovy Duke - I don't disagree with anything there. My understanding (and I could be wrong!) is that the hotswap issue has more to do with the reflective nature of Groovy and Spring Loaded and not Java itself. It has been decades since I last worked on a non Spring Java application but I remember hot swapping not being an issue with the tooling back then. Again, my memory could be wrong. What is definitely true though is that my prior research has found other more current hotwswap tooling options for Java 11 like https://dcevm.github.io/ and https://github.com/dcevm/dcevm/issues/198 for 17, that don't work with Groovy. By real database I mean not a local H2. H2 has been great when starting out but apps quickly outgrow it. In my experience the slowness with full or partial app restarts is often due in large part to Hibernate, compounded by most of us working remotely with local app instances connecting to real databases either in the cloud or very far away from our physical location. I realize perhaps the Grails team hands are tied but we've seen the hotswap issues coming for years now. I've posted here about it and remember chatting with you about it previously. I don't think it's completely unrealistic to expect OCI to devote some resources to the issue, either by forking Spring Loaded or finding an alternative approach. I looked at the David Estes approach and was unsuccessful but thought it was a positive step forward. He's on the technical advisory board after all. Other than the occasional posts and discussions here I have not heard anything about a solution for this. It looks like some prior posts with some steps to get hot swapping partially working have been deleted - or they fell off the back of Slack. These did not work for me either. Regardless if the industry is moving more toward microservcies style architectures, I bet most of us have the legacy of monoliths to deal with (or have use cases where a monolith is a better choice!) -- that will never be approved for full rewrites. These still require maintenance, patching and bug fixing, and if that means needing to move to Grails 6 and Java 11 and losing hot swapping, than that's a pretty big benefit of the framework that gets lost along the way. JRebel does mostly work well for us (as fast as Spring Loaded hotswapping), though there are occasional hickups with IntelliJ and the JRebel plugin versions getting out of sync with one another. Explaining this all to management when also faced with the JRebel bill and the age of our Grails portfolio, it makes alternative paths look appealing. I think Grails is superior to Django in many ways and I much prefer working with it as well as Groovy. Overall, getting clarity on the future of Grails has been difficult. The meeting notes were last updated in 2022! https://grails.org/foundation/minutes/index.html