Hot Code Replacement
The traditional Oracle JVM enables hot code replace to a certain extent since version 1.4 when it was still from Sun.
If you were connected in debug mode (debug ) through a suitable tool such as Eclipse a>, then changes in recompiled classes would be injected into the JVM while it was still running.
However, there are several limitations: you can not add or remove methods and attributes, change signatures, and so on.
On the other hand, it is quite possible to create new classes, change the contents of methods, inject values into variables while execution is paused, etc.
Web applications
But speaking specifically about web applications, that's not all that matters. Often the container is configured to reload when it recognizes some changes to certain files, such as web.xml , for example. Some IDEs plugins trigger this process automatically when you change the code to ensure application update.
In addition, application servers such as Tomcat cache static content, including JSPs, images, and CSS. Tomcat 6, for example, was configured to literally make a copy of your entire application into a temporary folder. This is good for production, but for development it is a nightmare.
To see details about these Tomcat issues, go to, I article Avoid restarting Tomcat 6 and leave the startup faster . It's probably not much different from Tomcat 7.
Java vs. Dynamic Languages
In a way, comparing " deploy " of PHP files with Java, is to compare bananas with oranges.
In PHP, simply copying files is sufficient because in most cases it does not store state and interpreted the files for each request. But think about the cost of that in relation to system performance.
The great benefit of Java in scalability is precisely an architecture that persists objects in memory and reuses them efficiently. The state of the system remains the same with each request, so the overall performance is much greater.
Regarding the availability issue for the user, although it is often necessary to do the redeploy of the application, this can be remedied by using clusters and the partial update of them until all nodes receive the updates.
The architecture of your application matters
Some frameworks work better than others. Depending on the type of change you are making, it can help or hinder the test changes.
A very common detail in large applications is to load% internationalization% (I18n) files. The problem is that bundles are not reloaded if changed, at least not by default. But some frameworks like struts2 or Spring allow you to configure them to reload the files with the translated texts without restarting the application.
In fact, many frameworks have a mode of development. For example, PrimeFaces in "dev" mode displays many details about the errors and context of the facelet at the time of the exception, including the variables that were in the request and session scopes.
Take advantage of this to avoid fixing "trial and error" issues and get straight to the problem. It's important to understand the mechanisms of your framework for the best productivity.
Productivity in practice
With knowledge of the IDE, the application server, and the framework you use, you can fine-tune your development environment and achieve much higher productivity, even though you still have to reboot the server when you do structural changes in their classes.
While the tools can help, and many people agree that JRebel helps, the best way to improve productivity is through changing the approach of developers. From my own experience I say that sometimes we are testing various possible solutions like trying to solve a maze by brute force. Instead of focusing on the upgradeability to be testing various possibilities, first think more carefully about how the problem should be solved. This will greatly decrease the number of times you need to "fix and test" the application.
