You can't do that with Java. There are some workarounds, but generally people restart application to check changes.
May be your 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.
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.
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.
Granted, there are advantages to things like JRebel that can also preserve state, but I feel like that is really orthogonal to the whole discussion.
tomcat using exploded wars hot reloads out of the box. run it inside intellij and it is even easier.
The Play framework uses classloaders to keep library classes (which are stateless) loaded, while reloading app code.
The JVM has build in hot swapping for cases where signatures don't change.
And then JRebel uses proprietary rocket science to do really good hot reloading.
java has had hot reloading of recompiled classes for years.
and if you use dcevm, the number of things that can be hot-reloaded is even higher: http://dcevm.github.io/