In the previous article "Accelerating Spring/Hibernate application startup during debugging", we mainly used some techniques to increase the startup speed, you still cannot perform hot deployment or hot replacement such as classes. Therefore, write another article on hot deployment/hot replacement. Many people have introduced this knowledge before, but it is scattered. The purpose of this article is to aggregate them. This article takes the HotSpot virtual machine as an example.
First, let's look at two concepts: Hot deployment and hot replacement.
Hot deployment
That is, when the container is running, reload the class or reload the entire project. A common solution is to use a custom ClassLoader;
Partial loading examples: JSP and Play frameworks;
Example of reloading the entire project: for example, Tomcat and Jetty. By default, the system regularly checks whether the class file has been modified. If yes, uninstall the current container and reload the entire project ).
The disadvantage of this situation is obvious: You can only reload the entire class/project, not just replace the part of the class.
Introduction to JSP hot deployment:
Http://www.linuxidc.com/Linux/2013-05/83816.htm
Introduction to Tomcat hot deployment:
Http://www.94it.cn/a/jingxuanboke/2013/0501/4578.html
Play! Framework:
Http://mingj.iteye.com/blog/307238
Hot replacement
The advantage of hot replacement over the previous hot deployment is that it can replace partial replacement within the class, such as the method body, addition, deletion method, and field, rather than the entire class. Common Implementation Methods: HotSwap, HotSwap patch,
HotSwap
You can only hot Replace the method body. You only need to enable the debug mode in eclipse, idea, and other development tools.
HotSwap patch DCEVM
This patch enhances HotSwap and can add or delete class fields, methods, and change the class parent class. It must also be debugged in debug mode. For more information, see the following document.
Hotswap User Manual
DCE Problems and Solutions
I used jdk1.6.0 _ 25 for testing. No problem is found. jdk1.6.0 _ 26 is not supported, and I did not succeed in testing jdk7_13 and jdk7_21. Official website said it is based on JDK7-b102 compiled. I guess these two versions are incorrect.
Java agent + Instrumentation
1. Spring-Loaded
SpringSource is released on the official website. It is used in Grails 2 and allows: Add/modify/delete methods, fields, and constructors. Annotations on the Type/method/field/constructor can also be modified, and values of the enum type can also be added/deleted/modified.
Usage:
For example, you can specify the above configuration in the VM parameter when executing tomcat/jetty. It does not need to be executed in debug mode. If idea is used, press Ctrl + Shift + F9 to compile the current class/Ctrl + F9 to compile all the changed classes.
2. Fakereplace
Similar to Spring-Loaded, refer to its official website for details:
Https://github.com/fakereplace/fakereplace
Https://github.com/fakereplace/fakereplace/wiki/How-It-Works
It supports some frameworks:
- Seam 2
- Weld (basic integration)
- JSF
- Metawidget
- Hibernate (if the entity is modified, restart the entire EMF. It is not very fast)
- Resteasy
The specific usage is also specified in the VM parameter:
You can download the jar package at the following address or compile it yourself.
Http://repo.grails.org/grails/plugins-releases/org/fakereplace/fakereplace-dist/1.0.0.Alpha2/
It provides some configurations, such:
- Packages that require hot replacement
- Log (optional) supports trace, debug, info, and error.
- Index-file fakereplace index path. Fakereplace stores this file after the first run to accelerate startup
- Dump-dir when hot replacement, the Dump class to this directory, only useful when developing Fakereplace
- Port Fakereplace listening port
The two implementations are very similar. Spring-Loaded uses CGLIB to implement proxy, and FakeReplace uses Javassist for implementation.
There is also Agent Smith, but N has not been maintained for a long time. In fact, the Play framework also uses Instrumentation, but it is the whole replacement, so it is not classified.
All of the above have disadvantages: for example, when I write a spring Project, I cannot dynamically load the configuration such as @ RequestMapping or the configuration file. These are supported in powerful JRebel.
JRebel
JRebel is my simplest and most powerful hot replacement/hot deployment tool. However, the disadvantage is that it is charged and not cheap. All the information we introduced earlier is free of charge. First, let's take a look at the comparison between the features it supports and JVM Hot Swap: