The only "easy" way to support hot reload in JVM is using java agent. But it can only reload method body, so it's extremely limited tool. That's how IDE usually work. You can sell your house and buy JRebel license, but if you don't have house to sell, you're out of luck. You can try some experimental alternative JVM implementations (DCEVM) which might or might not work.
May be your framework is just restarting automatically very fast. That's not a hot reload, though.
Five years ago I was coding Java EE (JSF, EJB, JPA) on NetBeans, which comes bundled with GlassFish. The hot reload development experience back then was extremely fast (sub-second for what I was doing) and a lot more reliable than JRebel. It didn't need any special configuration. The whole thing worked right out of the box. I got the feeling back then that JRebel's days were numbered if developers caught on. Sadly, the trend was more towards a build-your-own stack approach, typically using Spring, and so JRebel continued to have a market. It's a pity, because Java EE 6 onwards seemed to be quite well thought out with numerous open source implementations and a good reference implementation.
> framework is just restarting automatically very fast. That's not a hot reload, though.
If you can't tell the difference, then what's the difference?
There are plenty of ways to reload classes in the JVM as well - OSGi is the most well known and popular. If an agent is the only way you've seen reloading done, then you mustn't have much experience with the full range of libraries and frameworks available on the JVM.
The difference is that your runtime state is reset and you must architect your application to keep fast startup time which is not always a good thing. OSGI does not reload classes, it loads new classes, you can't reload class for an existing object. It's the same restart, you just leak memory.
> The difference is that your runtime state is reset and you must architect your application to keep fast startup time which is not always a good thing.
These are good things for serverless, which is what the article is about -- runtime state in a serverless application is bad, and fast startup is good.
Serverless instances are intended to be interchangeable and ephemeral. You should be able to start new instances and they should be able to do the same work as the existing instances -- that only works well if they are stateless. Any necessary state should be stored in a database or blob store or some other external state management system.
> The difference is that your runtime state is reset and you must architect your application to keep fast startup time which is not always a good thing.
Seems like slow startup time would be just as bad, if not worse, for a workflow that involves killing the server and bringing it back up again from scratch to test changes. So I think that either way it's a good idea to architect your application, at least in "development mode", to have a fast startup time.
May be your framework is just restarting automatically very fast. That's not a hot reload, though.