![]() Technologies like aspect-oriented programming or byte-code manipulation might be the dealbreaker.īe that as it may, I wrote a small application to test it, containing a REST service and a bean that's injected to it. Or there's a certain level of complexity that broke it. Either I'm entirely wrong, and hot code replacement was broken by another framework. There's a reason why they buy expensive tools like JRebel. However, I know for sure it was broken in almost every Spring project I've seen at the customers'. Hot code replacement in complex Spring applicationsĪs things go, hot code replacement worked fine when I prepared this article. They manage to save your application state even if you're adding or removing method parameters. That's where tools like JRebel and HotswapAgent shine. Adding a parameter to a method signature forces you to restart the application. However, if you're changing the signature of a method, hot code replacement fails. The original Java implementation works if the body of a method is modified. You can't modify every aspect of your code without destroying your data. In 2003 IDE vendors had a nice name for this feature: "fix and continue debugging." Limits of hot code replacement The new implementation works on the data you've input before editing and compiling the method. The nice thing is that hot code replacement retains the data. You correct a typo, and after hitting the F5 key in the browser, you see the result of your correction. Adding insult to injury, every input we'd made is lost. After that, we have to navigate to the functionality we're implementing. By definition, developing means modifying the code of the functionality all the time.īefore hot code replacement, we had to restart the server. As a developer, you've started an application, navigating several menus until you've reached the functionality you want to implement. Hot code replacement replaces code that's already running. Hot code replacement was attractive enough to start one or two fights. By the way, if you're interested in how it works, I've found a thesis covering the invention of hot code replacement (chapter 7.2).Īs you can imagine, I fought hard to update to JDK 1.4.1. It was an experimental feature that was later added to the mainstream JDK 1.4.1. As far as I remember, I first saw hot code replacement in a Java 1.3 running an IBM Websphere. I remember an application server that took five to ten minutes to start. Hot code replacement became necessary when application servers were invented. ![]() That's a pity because hot code replacement works a lot better than I expected.īefore continuing with Spring, let me quickly explain what hot code replacement is. Spoiler: instead of fixing hot code replacement, they break it. Interesting enough to write a blog post about it. But I have to admit the developer tools are interesting. They suggested using the Spring Developer Tools to fix the problem. My co-workers contradicted, claiming hot code replacement works fine. The other day I mentioned that hot code replacement is broken in most Spring applications I've seen.
0 Comments
Leave a Reply. |