Workaround problem with hot development in Java?

3

Problem situation:

You are developing a web site and doing debugging on it. For example a users CRUD. For this you are using JavaEE 1.7, Eclipse Kepler and Apache Tomcat 7. However, to the development delongo, and already with the application in debug mode, you might find an error and decide to change the code. But for this, by changing the code, Eclipse rebuilds (rebuild) the code to make it available again. However, at this point Tomcat restarts. By doing this over and over, a good development time is spent.

How to work around this problem? Is there any way to develop so that new changes come in, but the server stays the way it was?

For example, in PHP, if an error or some exception occurs, the server logs the error but does not restart. Just change the file and re-run the code that everything will be ok (which I called hot development as well as we have hot backup).

Is there any way to solve this problem?

    
asked by anonymous 31.05.2014 / 00:43

2 answers

4

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.

    
02.06.2014 / 17:47
2

There is a product called JRebel that enables Tomcat to work in continuous deployment mode:

  

link

It is proprietary but has a trial version. The support is quite attentive. When I tested the product, they called me and asked me for product feedback.

    
31.05.2014 / 00:48