HK1166396B - Method and apparatus for updating a java application - Google Patents

Description

Method and device for updating Java application program

Technical Field

The present application relates to the field of computers, and in particular, to a method and an apparatus for updating an application program.

Background

In the development process of Java software, developers need to compile again after modifying codes each time, package the codes into an application program, and then restart the application program to see the final execution effect after modification; some applications require a long time to restart after recompiling, for example, applications that cannot be split into modules for development (e.g., WEB layer development of WEB applications), for which recompiling and packaging of the entire application and shutdown of the restart WEB application server (e.g., Jboss) are required each time even a small amount of code is modified. In enterprise-level development, generally, a common application program is modified, and the process from code modification to closing and restarting of a WEB server requires about 5 minutes, and for a larger application program, the process may require more than 10 minutes; in the process of programming, developers need to check the running result of the current code regularly and modify the current code correspondingly to ensure that the code presents a corresponding effect according to the wishes of the developers, and therefore the WEB server needs to be closed and restarted continuously, so that the time which is meaningless spent on code compiling and restarting the application program is greatly prolonged, and especially when code errors are repaired, the consumption is more obvious, and the efficiency of code research and development is reduced seriously. In addition, for a large service application program, in the process of upgrading, the application program often needs to be restarted, recompiled, deployed and reissued, and in the process of restarting the service, external service often needs to be interrupted, so that the service quality of the system is affected.

To address the above problems, two solutions are provided in the prior art:

the first solution is: the thermal deployment function of a WEB server (e.g., tomcat, Jboss) is directly used. The WEB server monitors the change of the file, and if a certain file is modified, the WEB server reloads the module to which the file belongs; thereby enabling thermal deployment.

However, with this solution, the following disadvantages exist:

A. the WEB server reloads the whole module by monitoring the change of the file, and only can perform hot loading on sevlets (a Java application program at a server end); for an application program using the framework, the content in the framework cannot be loaded, and if the update of the framework code is realized through servlet hot loading, the framework needs to be initialized again, and the speed is very slow.

B. After the file is modified each time, the WEB server can automatically carry out hot deployment, which can increase the memory requirement, and simultaneously, because the corresponding module needs to be reinitialized, a large amount of CPU resources can be occupied; after many hot deployments, system resources are heavily occupied, necessitating hot deployments to be stopped, recompiled applications, and services to be restarted.

The second solution is: the state of the Java virtual machine is changed through an interface (Jpda or Jvmti) provided by the Java virtual machine (Jvm) by adopting a hotspot method, and the modified class file (. class file) is replaced with the original class file in Jvm. By adopting the solution, the regions which can be reached in the running state can be modified, and the adopted mode adjusting tool can be debug and has certain heat deploying capacity.

With this solution, however, there are the following drawbacks:

A. only the regions that can be reached by the operating state can be modified, and new regions cannot be added. For example, only the modification of the method body is supported, and the operations of adding a method, modifying a method name, modifying a method parameter and the like are not supported. For hot deployment, hot deployment of all codes cannot be achieved, especially frequent operations such as adding methods, adding internal classes, modifying method names, and the like; the application range of the heat deployment method is seriously influenced, and the method has certain limitations.

B. The hot deployment provided by hotspot is complicated and results in instability and sometimes breakdown during use.

C. The development amount of the tools adopted when the hot deployment is realized through the solution is extremely large, and the development complexity is increased.

In summary, none of the existing solutions can achieve the ideal hot deployment of Java applications, and a new solution is needed to overcome the drawbacks of the existing solutions.

Disclosure of Invention

The application provides a method and a device for modifying a Java application program, which are used for reducing the complexity of an operation flow and improving the execution efficiency of the Java application program in the process of modifying the Java application program.

The specific technical scheme provided by the application is as follows:

a method for updating a Java application program includes:

determining that at least one compiled target class file exists;

acquiring the at least one target class file at a specified storage position;

establishing a corresponding class loader aiming at the acquired at least one target class file, and loading the at least one target class file into a Java application program in an operating state by adopting the class loader; wherein the class loader inherits the current environment loader.

An apparatus for Java application update, comprising:

the scanning unit is used for determining that at least one compiled object class file exists;

the acquisition unit is used for acquiring the at least one target class file at a specified storage position;

the processing unit is used for establishing a corresponding class loading program for the acquired at least one target class file, and loading the at least one target class file into a Java application program in an operating state by adopting the class loading program; wherein the class loader inherits the current environment loader.

In the embodiment of the application, a new hot deployment tool is developed, and a target class file is loaded at a specified storage position and loaded into a Java application program in a running state through a newly-built easystartClassLoader inheriting a classloader in the current environment, so that the Java application program is updated.

Drawings

FIG. 1 is a schematic diagram illustrating the working principle of a WEB server in an embodiment of the present application;

FIG. 2 is a functional structure diagram of a WEB server in the embodiment of the present application;

fig. 3 is a flowchart illustrating an update of a Java application program in an operating state by a WEB server in an embodiment of the present application.

Detailed Description

Referring to fig. 1, in order to reduce the complexity of the operation flow and improve the execution efficiency in the process of modifying the Java application, in the embodiment of the present application, a new hot deployment tool is developed, and preferably, the WEB server used by the hot deployment tool during running is Jboss, and the code development environment (i.e. code editor) used by the hot deployment tool is: eclipse, but the embodiments of the present application are not limited to the Jboss and eclipse implementations, and are only examples, and only exemplary descriptions are provided here

As shown in fig. 1, in the prior art, when a developer writes a source code, the source code is compiled and encapsulated by using a compiling tool such as antx/maven, and a software product (e.g., an executable Java application) is finally generated; then, the developer deploys the software product to a Jboss, starts Jvm (Java virtual Machine), starts the Jboss by Jvm, and starts the software product by the Jboss (including starting an application framework and starting application codes of the software product by the application framework); at this time, the developer sends an execution command to the Jboss, and can see the corresponding execution effect. If the source code needs to be modified according to the execution effect, the developer needs to close the Jboss, repeat the source code modification and compiling packaging processes, deploy the software product generated according to the modified source code to the Jboss again, and restart the Jboss to run the modified software product. This process takes a long time and reduces the modification efficiency of the Java application, thereby affecting the performance of the entire service system.

Unlike normal programs, Java programs (. class files) are not native executable programs. When the class file needs to be run, Jvm (Java virtual machine) is run first, then the class file is loaded into Jvm to run, the tool responsible for loading the class file is called a class loader, and the interface used by Jvm in the loading process is called Jvmti interface. In the embodiment of the present application, in the redesigned thermal deployment tool, the function of the Jvmti interface is redefined, and the original framework code in Jvm is replaced, so that, when Jvm is started, Jvm automatically creates a classloader (referred to as EasyStartClassLoader) according to the changed framework code, and directly obtains the newly compiled class file in the specified storage location, where,

jvmti interface: as shown in fig. 1, when an original framework (which may also be referred to as an application framework) runs, a Jboss generally obtains an application code included in a local software product through a classLoader in a running environment, and in the embodiment of the present application, a behavior of the original framework is changed by redefining a Jvmti interface, so that the Jboss obtains a newly compiled target at a specified storage location each time the target is called.

In practice, the class file may not be obtained from the code editor, for example, the class file may be compiled directly to generate a target by calling Jvm from the command line, or a new target generated by compiling may be copied from another specified location. In the following embodiments, a class file is described as an example, where a specified storage device in a code editor acquires a target.

EasyStartClassLoader: in the embodiment, when creating the EasyStartClassLoader, the conventional mechanism of the classtallockloader for delegation is reversed (the classtalloader is loaded first and then the child classLoader is loaded), the EasyStartClassLoader is loaded first and then the parent classLoader of the EasyStartClassLoader is loaded, the parent classLoader is set as the environment classLoader, and only the target class file can be loaded by limiting the EasyStartClassLoader, so that other class files related to the target class file or a class file library can be loaded by the environment classLoader. The environment classLoader is a creator of the current environment, the environment refers to a current running state, namely a state in which a set of codes runs, and the classLoader loading the set of codes is the current environment classLoader.

In the loading process, the external environment can normally use the object loaded by the easyStartClassLoader in a Java reflection mechanism or an interface in Java, so that the newly loaded object is automatically called to run in a running state and an instant result is obtained.

Taking the code editor as eclipse as an example, after a developer modifies part of codes, eclipse compiles a code file of the modified part into a new class file, namely a target class file; because a single file is compiled, the speed is very high, and the compiling time can be ignored; then, by using the frame processed by the jvmti interface of the JVM (i.e. the redefined frame), file scanning is periodically performed to determine that a newly compiled target exists in the designated folder in eclipse.

Preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

Referring to fig. 2, in the embodiment of the present application, an apparatus (e.g., a WEB server) for updating a Java application includes a scanning unit 10, an obtaining unit 11, and a processing unit 12, where

A scanning unit 10, configured to scan at a specified storage location, and determine that a recompiled object class file, that is, an object class file, is generated;

in the embodiment of the present invention, since the target class file is obtained in the code editor, the scanning unit 10 needs to be used to scan the file periodically to determine that the target class file exists, in practical applications, if the target class file is generated by directly compiling according to the Jvm command, or the target class file is copied from other positions according to the instruction, the scanning unit 10 may not be used, and details are not described herein;

an obtaining unit 11, configured to obtain at least one object class file, namely an object class file;

in this embodiment, the reason why the class file is acquired by the acquisition unit 11 at the specified storage location is that the framework adopted by Jvm uses the redesigned Jvmti interface, and the framework behavior is changed.

The processing unit 12 is configured to establish a corresponding class loader, namely, an easyStartClassLoader, for the obtained at least one target class file, and load the obtained at least one target class file into the Java application program in the running state by using the class loader; wherein, the class loader inherits the current environment loader, i.e. the easyStartClassLoader inherits the current environment classloder.

In this example, scanner unit 10, fetch unit 11, and processing unit 12 are running in effect, embedded in the original framework logic, without changing the original framework code, through the redesigned Jvmti interface of Jvm.

Jvm should be supported in the WEB server, preferably, the WEB server is a Jboss or tomcat.

Based on the above system architecture, referring to fig. 3, in the embodiment of the present application, taking a class file as an example, a detailed flow for a WEB server to update a Java application in an operating state is described as follows:

step 300: it is determined that there is at least one complied object class file, i.e., object class file, in the code editor (e.g., eclipse).

Step 310: and acquiring the at least one target class file at a specified storage position in the code editor.

In this embodiment, when step 310 is executed, Jvm supported by the WEB server changes the behavior of the original framework running in Jvm through the newly defined Jvmti interface, so that the changed framework can obtain a newly compiled target of a developer at a specified storage location of eclipse (e.g., the eclipse compiles the target.

In the prior art, Jvm is configured to use a Jvmti interface, and Jvm calls each class file through the Jvmti interface when loading each class file, and modifies the byte code of each class file through the Jvmti interface, where the existing Jvmti interface is implemented by the following code:

byte[]

transform(ClassLoader loader，

String className，

Class<？> classBeingRedefined，

ProtectionDomain protectionDomain，

byte[] classfileBuffer)

throws IllegalClassFormatException；

the class file is called through a Jvmti interface in the prior art, the loader is a class loader for loading the called class file, the class name is the name of the called class file, the class BeingRedfined is the type of the called class file, the protectionDomain is the scope of the called class file, and the class file buffer is the byte code read by Jvm. In general, the bytecode read by classfileBuffer may be analyzed, the content of the bytecode is changed and returned to Jvm, Jvm runs the changed bytecode, so as to achieve the purpose of changing the behavior of the framework, and actually the originally used code is not changed, so that the originally running mode of the framework is changed without changing the originally used code, i.e. without intrusion. However, analyzing and changing the bytecode requires developers to have a good understanding of the mechanism of compiling class files by Java and the mechanism of class files, and thus, a considerable amount of work is required even if the purpose of changing Jvm the original manner of calling class files is achieved in the above manner.

In the embodiment of the application, in order to reduce the workload for realizing the purpose, the class file to be changed is imported into a code editor (such as eclipse), the operation mode of the class is changed according to the actual requirement in a self-defined mode, after the class file is stored, the code editor automatically compiles to generate the object class file, accordingly, Jvm directly obtains the byte codes of the compiled object class file through a Jvmti interface only by checking the class name in the code editor and determining that the class file needs to be replaced, and the byte codes in the class file are not required to be analyzed and modified, so that the workload required by the use mode of the original Jvmti interface is greatly reduced.

In the embodiment of the application, the execution code for realizing Jvmti interface calling is as follows:

String targetName＝“targetClass”；

if(className.equals(targetName)){

return Transformer.getBytesFromFile(targetName)；

}

return null；

wherein the method defined by getbytsfromfile (targetName is only a file stream for returning the target class,

step 320: and establishing a corresponding easyStartClassLoader aiming at least one obtained class file, and loading the obtained at least one class file into a Java application program in a running state by adopting the easyStartClassLoader, wherein the easyStartClassLoader inherits the current environment classLoader.

In this embodiment, the above easyStartClassLoader functions to load a specified object generated by coding in the code editor, a class file, preferably, at least one easyStartClassLoader may be created for the object generated by recompilation, for example, one easyStartClassLoader may be created for each class file, or one easyStartClassLoader may be created for a plurality of objects, and the loaded object is returned to the Java application in the running state in Jvm, so that the Java application may operate using the newly loaded object.

In the embodiment of the present application, to implement the above functions, the following difficulties exist:

firstly, after a class file is loaded by one class loader, the class file cannot be reloaded, and the class file cannot be reloaded until one class loader is reestablished;

the class files cannot be used mutually, and even if an easyStartClassLoader is newly built and a target class file is loaded, the class files cannot be used by the previously established class loaders;

class files depend heavily on the current environment class and class library, which need to be loaded by the environment class loader, but cannot be loaded by the easyStartClassLoader.

In view of the above problems, the embodiments of the present application adopt the following ways to solve:

each time a new easyStartClassLoader is created, the newly created easyStartClassLoader inherits the current environment classLoader (i.e., the parent classLoader that is the easyStartLoader); the mechanism of parent delegation of ClassLoader is reversed, namely, the object is loaded by the easyStartClassLoader firstly, and then the class file is processed by the inherited environment classLoader; meanwhile, safety is guaranteed by a method of limiting a loading item, namely, the easyStartClassLoader is limited to only load a target class file of a specified storage position, and all other related class files are loaded by an environment class loader inherited by the class file. The environment classLoader is a creator of the current environment, the environment refers to a current running state, namely a state in which a set of codes runs, and the classLoader loading the set of codes is the current environment classLoader.

The method specifically comprises the following steps:

in the prior art, the implementation code of classLoader is as follows:

protected synchronized Class<？>loadClass(String name，boolean resolve)

throws ClassNotFoundException

{

//First，check if the class has already been loaded

Class c＝findLoadedClass(name)；

if (c＝＝null){

try{

if(parent！＝null){

c＝parent.loadClass(name，false)；

}else{

c＝findBootstrapClass0(name)；

}

}catch(ClassNotFoundException e){

//If still not found，then invoke findClass in order

//to find the class.

c＝findClass(name)；

}

}

if(resolve){

resolveClass(c)；

}

return c；

}

as can be seen from the above code, there are two characteristics of classloader:

the first characteristic is: once a class file (called class A) is loaded, its bytecode is no longer read.

Therefore, in this embodiment, after class a is recompiled to generate class a ', an easyStartClassLoader must be newly created to read and load class a'.

The second characteristic is: the class file is preferentially loaded by the parent class loader, and if the parent class loader can load the class file, the class file is not loaded by the child class loader.

Therefore, in this embodiment, the parent delegation mechanism needs to be reversed, and for the class a' generated by re-encoding, the newly created easyStartClassLoader is loaded first, and then the parent classLoader (i.e., the environment classLoader inherited by the easyStartClassLoader) is loaded with other related class files.

Different from the prior art, in the embodiment of the present application, the easyStartLoader implementation code is as follows:

public synchronized Class<？>loadClass(String name)throws

ClassNotFoundException{

Class<？>c＝findLoadedClass(name)；

if (c！＝null){

return c；

}

try {

if(name.indexOf(targetClass)＝＝-1){

throw new Exception(″easyStartClassLoader escaped:″+

name)；

}

c＝this.findClass(name)；

System.out.println(″easyStartClassLoader loaded:″+name)；

}catch(Exception e){

c＝super.loadClass(name)；

}

return c；

}

it can be seen from the above codes that easyStartClassLoader only needs to inherit the current environment classLoader and becomes the subclassader of the current environment classLoader, and thus, the class file (i.e., at least one newly compiled class file) depends on other related class files, which can be loaded by the environment classLoader, and the environment classLoader cannot load the target.

Based on the above embodiment, in the process of loading the class file of the target into the Java application program in the running state, the external environment can call the newly loaded class file of the target generally by means of an interface in Java or a Java reflection mechanism.

An interface in Java is a declaration of a series of methods, which is a collection of method features, and an interface in Java has only the method features and no method implementation, so that the methods can be implemented by different classes in different places, and the implementations can have different behaviors (i.e., functions). The class file is also inherited to the interface in Java, so in the external environment, the object or set of objects that are loaded are used by a strong transition to the interface in Java after being instantiated.

In this embodiment, one or a set of class files loaded by the easy StartClassLoader are used in the external environment.

ClassLoader classloader＝new

EasyStartClassLoader(new URL[]{url}，moduleClassName)；

moduleClass＝

classloader.loadClass(moduleClassName)；

module＝(Module)moduleClass.newInstance()；

The class file (hereinafter referred to as a loaded module) realizes using an interface in Java, and simultaneously ensures that the interface in Java is loaded by an environment class loader serving as a parent class loader of an easyStartClassLoader, rather than the easystlassloader, so that the environment class loader can use the module loaded by the easyStartClassLoader, because the modules loaded by different classloaders cannot be commonly used in general. Thus, the easyStartClassLoader inherits the environment classLoader, so that the module loaded by the easyStartClassLoader can access the interface in the Java loaded by the environment classLoader, and the external environment can call the module loaded by the easyStartClassLoader through the interface in the Java. The external environment is an environment that calls an easy startclassloader load with respect to an easy startclassloader load, and is referred to as an external environment.

The so-called Java Reflection mechanism (called Reflection), on the other hand, allows loading, ascertaining, using, and using completely unknown class files during compilation of a Java application at runtime, in other words, a Java application can load a class file whose name is known only at runtime, learn its complete structure, and generate its object entities. For example, the Java reflection mechanism is class. For any object, any method of the object can be called; therefore, by adopting a Java reflection mechanism, after the Java application program loads the object class file, the external environment can call the object class file.

Finally, Jvm executes the Java application in accordance with the reloaded class file, and the newly loaded class file can be used for its functions.

In the embodiment of the application, a new hot deployment tool is developed, and a target class file is loaded at a specified storage position and loaded into a Java application program in a running state through a newly-built easystartClassLoader inheriting a classloader in the current environment, so that the updating of the Java application program is completed, and thus, the hot deployment of the Java application program is realized only by loading a recompiled target class file, and the updating efficiency of the Java application program is improved; moreover, the principle structure of the easy StartClassLoader is simple, the stability is high, the memory consumption and the extra system consumption are not increased, the hot deployment can be realized infinitely and rapidly without cost, and the practicability is high; further, the core code of the new hot deployment tool can be expanded with a small amount of development according to the Java application framework and the application state, can be used for hot deployment of full-code full-operation, and has a wide application range.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims (10)

1. A method for updating a Java application, comprising:

the method comprises the steps that the name of a target class file generated by coding in a code editor is checked through a Jvmti interface of a Java virtual machine, and when the name of the target class file is determined to be consistent with the name of a class file to be replaced, at least one compiled target class file is obtained;

establishing a corresponding class loader for the acquired at least one target class file, and only loading the at least one target class file into a Java application program in an operating state by adopting the class loader, wherein the class loader inherits the current environment loader;

and loading other related class files depended by the at least one target class file by adopting the environment loader.

2. The method of claim 1, wherein establishing a corresponding class loader for the obtained at least one target class file comprises:

if the number of the obtained target class files is one, establishing a corresponding class loading program corresponding to the target class files;

and if the number of the acquired target class files is more than one, establishing at least one class loading program corresponding to each target class file.

3. The method of claim 1 or 2, wherein loading the at least one target class file into the running Java application only using the class loader comprises:

firstly, loading the at least one target class file by adopting the class loading program;

and loading other related class files depended on by the at least one target class file by adopting the environment loading program.

4. The method of claim 3, wherein loading the at least one target class file only into a running Java application using the class loader further comprises:

and adopting the class loader to inherit the environment loader, and loading all interfaces in Java by the environment loader so as to enable an external environment to call the at least one target class file through the interfaces in the Java.

5. The method of claim 3, wherein loading the at least one target class file only into a running Java application using the class loader further comprises:

and adopting a Java reflection mechanism to enable an external environment to call the at least one target class file.

6. An apparatus for updating a Java application, comprising:

the system comprises an acquisition unit, a storage unit and a processing unit, wherein the acquisition unit is used for checking the name of a target class file generated by coding in a code editor through a Jvmti interface of a Java virtual machine, and acquiring at least one compiled target class file when determining that the name of the target class file is consistent with the name of a class file to be replaced;

the processing unit is configured to establish a corresponding class loader for the acquired at least one target class file, and load the at least one target class file into the Java application program in the running state by using the class loader, where the class loader inherits the current environment loader, and load other related class files on which the at least one target class file depends by using the environment loader.

7. The apparatus according to claim 6, wherein when the corresponding class loader is established for the obtained at least one target class file, the processing unit is specifically configured to:

if the number of the obtained target class files is one, establishing a corresponding class loading program corresponding to the target class files;

and if the number of the acquired target class files is more than one, establishing at least one class loading program corresponding to each target class file.

8. The apparatus according to claim 6 or 7, wherein said processing unit employing said class loader to load only said at least one target class file into a running Java application comprises:

firstly, loading the at least one target class file by adopting the class loading program;

and loading other related class files depended on by the at least one target class file by adopting the environment loading program.

9. The apparatus as recited in claim 7, wherein said processing unit, when said class loader is employed to load only said at least one target class file into a running Java application, is further to:

and adopting the class loader to inherit the environment loader, and loading all interfaces in Java by the environment loader so as to enable an external environment to call the at least one target class file through the interfaces in the Java.

10. The apparatus as recited in claim 6, wherein said processing unit, when said class loader is employed to load only said at least one target class file into a running Java application, is further to:

and adopting a Java reflection mechanism to enable an external environment to call the at least one target class file.