Unused dependency identification method in java application and related device

Abstract

The invention discloses an unused dependency identification method in a java application and a related device, relates to the field of computers, and aims at jumping out of an mvn dependency static analysis mode in related technologies and adopting a more accurate java agent dynamic analysis mode. The method comprises the following steps of: setting a class loader for loading a java application and an agent code module as an Application ClassLoader class loader; a class loader for loading the Core code module is a Profiler AgentClassLoader class loader, and a class loader for loading the Core code module is a Profiler AgentClassLoader class loader; according to the method, the agent code module and the java application are separated from each other, and the Application ClassLoader class loader and the Profiler AgentClassLoader class loader are brother class loaders, so that the agent code module and the java application are separated from each other. According to the method, a Bridge code module is introduced into a dependency analysis agent. The Bridge code module is loaded by using a parent class loader, namely a BootstrapClassLoader class loader, which is visible to both the dependency analysis agent and the java application, so that the aim of calling a static enhancement processing function in the Core code module through the Bridge code module when the java application calls an enhancement code of the agent code module is fulfilled; therefore, the purpose of obtaining the dependency of java application calling in the running process of the java application is achieved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and a related device for identifying unused dependencies in a Java application. Background Art

[0002] When a Java project is compiled, all dependencies required for the Java project to run will be packaged into a Jar package, i.e., a Java application. Dependencies in a Jar package can be divided into two types: actual use dependencies and unused dependencies. Actual use dependencies are dependencies that the Java application will actually call during the running of the Java application; unused dependencies are dependencies that the Java application will not call during the running of the Java application.

[0003] There may be many reasons for introducing unused dependencies, the most common of which are incorrectly introducing dependencies during Java application configuration or not updating dependencies in time after modifying Java applications. Unused dependencies are equivalent to redundant parts in Java applications, which will lead to a series of problems, such as longer Java application startup time, slowing down daily development; larger Java application size, slowing down project deployment, etc.

[0004] Therefore, there is an urgent need for a method for screening unused dependencies in Java applications, so as to delete the unused dependencies in Java applications, so as to reduce the size of Java applications and speed up the startup of Java applications. Summary of the invention

[0005] In view of the above problems, the present application provides a method and a related device for identifying unused dependencies in Java applications to achieve the purpose of screening unused dependencies in Java applications. The specific scheme is as follows:

[0006] In a first aspect, the present application provides a method for identifying unused dependencies in a Java application, comprising:

[0007] If the instruction to start the Java application is detected, the storage path of the dependency analysis agent is obtained;

[0008] The dependency analysis agent includes an Agent code module, a Bridge code module and a Core code module; the Agent code module includes a premain method, a calling interface for calling the Bridge code module and a preset correspondence between a code module and a class loader; the Bridge code module includes a calling interface for calling a static enhancement processing function in the Core code module, loading location information and a setBridge method; the static enhancement processing function is used to obtain the dependency called within the life cycle of the static enhancement processing function, the path for calling the dependency and the name of the class loader for calling the dependency; the loading location information includes the start and end of each method loaded by the Agent code module into the Java application; the setBridge method is used to set the enhancement code;

[0009] Obtaining the dependency analysis agent from the storage path;

[0010] From the preset correspondence between code and class loader, find the ApplicationClassLoader class loader corresponding to the Agent code module, the BootstrapClassLoader class loader corresponding to the Bridge code module, and the ProfilerAgentClassLoader class loader corresponding to the Core code module;

[0011] Wherein, the parent class of the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader is the BootstrapClassLoader class loader;

[0012] Loading the Java application into the Java virtual machine through the ApplicationClassLoader class loader;

[0013] Loading the Core code module into the Java virtual machine through the ProfilerAgentClassLoader class loader;

[0014] Loading the Bridge code module into the Java virtual machine through the BootstrapClassLoader class loader;

[0015] Calling the setBridge method in the Bridge code module to convert the Agent code module into an enhanced code;

[0016] Injecting the enhanced code into the beginning and end of each method in the Java application in the Java virtual machine through the ApplicationClassLoader class loader based on the loading location information to obtain a tested application;

[0017] Running the tested application through the Java virtual machine;

[0018] If the tested application is finished running, the dependency correspondence relationship obtained by the static enhancement processing function is obtained, where the dependency correspondence relationship includes the name of the dependency being called, the path for calling the dependency, and the name of the class loader for calling the dependency;

[0019] The name of the class loader for calling the dependency is obtained from the dependency correspondence, and the name of the class loader for calling the dependency is the ApplicationClassLoader class loader, and the path of calling the dependency is not the target dependency of the code module included in the dependency analysis agent;

[0020] It is determined that all dependencies corresponding to the Java application except the target dependency are unused dependencies.

[0021] A second aspect of the present application provides a device for identifying unused dependencies in a Java application, comprising:

[0022] The first acquisition module is used to acquire the storage path of the dependency analysis agent if an instruction to start the Java application is detected;

[0023] The dependency analysis agent includes an Agent code module, a Bridge code module and a Core code module; the Agent code module includes a premain method, a calling interface for calling the Bridge code module and a preset correspondence between a code module and a class loader; the Bridge code module includes a calling interface for calling a static enhancement processing function in the Core code module, loading location information and a setBridge method; the static enhancement processing function is used to obtain the dependency called within the life cycle of the static enhancement processing function, the path for calling the dependency and the name of the class loader for calling the dependency; the loading location information includes the start and end of each method loaded by the Agent code module into the Java application; the setBridge method is used to set the enhancement code;

[0024] A second acquisition module, used for acquiring the dependency analysis agent from the storage path;

[0025] A search module, used to search for the ApplicationClassLoader class loader corresponding to the Agent code module, the BootstrapClassLoader class loader corresponding to the Bridge code module, and the ProfilerAgentClassLoader class loader corresponding to the Core code module from the preset correspondence between the code and the class loader;

[0026] Wherein, the parent class of the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader is the BootstrapClassLoader class loader;

[0027] A first loading module, used to load the Java application into the Java virtual machine through the ApplicationClassLoader class loader;

[0028] A second loading module is used to load the Core code module into the Java virtual machine through the ProfilerAgentClassLoader class loader;

[0029] A third loading module, used to load the Bridge code module into the Java virtual machine through the BootstrapClassLoader class loader;

[0030] A conversion module, used for calling the setBridge method in the Bridge code module to convert the Agent code module into an enhanced code;

[0031] An injection module, used for injecting the enhanced code into the beginning and end of each method in the Java application in the Java virtual machine through the ApplicationClassLoader class loader based on the loading location information, so as to obtain a tested application;

[0032] A running module, used to run the tested application through the Java virtual machine;

[0033] A third acquisition module is used to obtain the dependency correspondence obtained by the static enhancement processing function if the tested application is completed, wherein the dependency correspondence includes the name of the called dependency, the way to call the dependency, and the name of the class loader that calls the dependency;

[0034] A fourth acquisition module is used to acquire, from the dependency correspondence, a name of a class loader for calling a dependency, which is the ApplicationClassLoader class loader and a path for calling the dependency is not a target dependency of a code module included in the dependency analysis agent;

[0035] The determination module is used to determine that all dependencies corresponding to the Java application except the target dependency are unused dependencies.

[0036] A third aspect of the present application provides a computer program product, including computer-readable instructions. When the computer-readable instructions are executed on a server, the server implements the above-mentioned first aspect or any implementation method of the first aspect in a Java application without using a dependency identification method.

[0037] A fourth aspect of the present application provides a server, comprising at least one processor and a memory connected to the processor, wherein:

[0038] The memory is used to store computer programs;

[0039] The processor is used to execute the computer program so that the server can implement the unused dependency identification method in the Java application of the first aspect or any implementation of the first aspect.

[0040] A fifth aspect of the present application provides a computer storage medium, which carries one or more computer programs. When the one or more computer programs are executed by a server, the server can use a Java application of the first aspect or any implementation of the first aspect without using a dependency identification method.

[0041] By means of the above technical solution, the present application provides a method for identifying unused dependencies in java applications, which jumps out of the mvn dependency static analysis mode in the related art and adopts a more accurate java agent dynamic analysis mode. The present application sets the class loader for loading java applications and agent code modules as the ApplicationClassLoader class loader; the class loader for loading the Core code module is the ProfilerAgentClassLoader class loader; and the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader are sibling class loaders, thereby realizing the isolation of the agent code module from the java application. The dependency analysis agent in the present application introduces the Bridge code module. The Bridge code module is loaded using the BootstrapClassLoader class loader, a parent class loader visible to both the dependency analysis agent and the java application, thereby realizing the purpose of calling the static enhancement processing function in the Core code module through the Bridge code module when the java application calls the enhancement code of the agent code module, thereby realizing the purpose of obtaining the dependency called by the java application during the running of the java application. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale.

[0043] Figure 1 A schematic diagram of unused dependencies obtained through mvn dependency:analyze provided in an embodiment of the present application;

[0044] Figure 2 A flowchart of a method for identifying dependencies not used in a Java application provided in an embodiment of the present application;

[0045] Figure 3 A schematic diagram of the code for starting the container provided in an embodiment of the present application;

[0046] Figure 4 A schematic diagram of the code for stopping the PicoContainer provided in an embodiment of the present application;

[0047] Figure 5 A schematic diagram of a code for starting a dependency analysis agent provided in an embodiment of the present application;

[0048] Figure 6 A schematic diagram of a display method of unused dependencies provided in an embodiment of the present application;

[0049] Figure 7 A schematic diagram of the parent-child relationship of each class loader and the loading relationship between each Jar package provided in the embodiment of the present application;

[0050] Figure 8a to Figure 8b A schematic diagram of a code for setting a premain entry point provided in an embodiment of the present application;

[0051] Fig. 9 A schematic diagram of key codes in the ProfilerClassFileTransformer class provided in an embodiment of the present application;

[0052] Fig.10 A schematic diagram of code for completing the most critical Bridge code module settings, instrumentation settings, and container startup in the construction method of the ProfilerClassFileTransformer class provided in an embodiment of the present application;

[0053] Fig.11 A schematic diagram of the interface of the IDEA plug-in provided in the embodiment of the present application;

[0054] Fig.12 A schematic diagram of the interface of Build Tools provided in an embodiment of the present application;

[0055] Fig.13 A schematic diagram of the output format of the command provided in the embodiment of the present application;

[0056] Fig.14 A schematic diagram of the structure of the spring project provided in the embodiment of the present application;

[0057] Fig.15 A code diagram of the clean operation provided in an embodiment of the present application;

[0058] Fig.16 A schematic diagram of the code for the package operation provided in the embodiment of the present application;

[0059] Fig.17 A schematic diagram of part of the code of the tar package provided in the embodiment of the present application;

[0060] Fig.18 A schematic diagram of the UI interface of the IDEA plug-in provided in an embodiment of the present application;

[0061] Fig.19A schematic diagram of a structure of a Java application that does not use a dependency identification device provided in an embodiment of the present application;

[0062] Fig. 20 A schematic diagram of the structure of a server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0063] The following describes the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. The terms used in the implementation method section of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.

[0064] The embodiments of the present application are described below in conjunction with the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0065] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, which is only to describe the distinction mode adopted by the objects of the same attributes when describing in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0066] In the related art, the method of screening unused dependencies in Java applications is to use the mvn dependency:analyze command in the Maven dependency management tool to perform static analysis on the Java application. The Unused declareddependencies found part in the analysis result is the unused dependencies. Figure 1 , which is a schematic diagram of unused dependencies obtained through mvndependency:analyze provided in an embodiment of the present application. Figure 1 Dependencies marked with [WARNING] are unused dependencies that can be considered for removal.

[0067] However, the mvn dependency:analyze command can only analyze static dependencies but not dynamic dependencies and indirect dependencies, which may lead to the following problems: If reflection, dynamic proxy or other runtime code generation technologies are used in the Java application, the mvn dependency:analyze command may not be able to detect dynamic dependencies and indirect dependencies, resulting in some unused dependencies recorded in Unused declared dependencies found being actually used dependencies. If dynamic dependencies or indirect dependencies are deleted, the Java application will run abnormally.

[0068] Based on this, the present application dynamically analyzes dependency relationships when the Java application is running, that is, the present application chooses to use the Javaagent technology to detect dependencies when the Java application is started and within a certain period of time after the startup is completed, so as to obtain the actual usage dependencies called by the Java application during the running process; and determine that the dependencies other than the actually used dependencies among the dependencies already set in the Java application are unused dependencies.

[0069] The following terms are involved in the present application embodiments and are explained as follows:

[0070] Class loader: classloader, the loader that loads Class files in the Java virtual machine.

[0071] Dependency: Dependency between classes or between Java applications. Dependency modes include, but are not limited to, chain-like dependencies (a→b→c) and tree-like dependencies (a→b→c, a→e→f). Dependency types provided in the embodiments of the present application include, but are not limited to, dynamic dependencies, indirect dependencies, and static dependencies.

[0072] Reference Figure 2 , Figure 2 A flowchart of a Java application that does not use a dependency identification method is provided in an embodiment of the present application, such as Figure 2 As shown, a method for identifying unused dependencies in a Java application provided in an embodiment of the present application may include steps S201 to S212, and these steps are described in detail below.

[0073] Step S201: if an instruction to start a Java application is detected, the dependency analysis agent storage path is obtained.

[0074] The dependency analysis agent includes an Agent code module, a Bridge code module and a Core code module; wherein the Agent code module includes a premain method, a calling interface for calling the Bridge code module and a preset correspondence between a code module and a class loader; the Bridge code module includes a calling interface for calling a static enhancement processing function in the Core code module, loading location information and a setBridge method; the static enhancement processing function is used to obtain the dependencies called within the life cycle of the static enhancement processing function, the path for calling the dependencies and the name of the class loader for calling the dependencies; the loading location information includes the start and end of each method loaded by the Agent code module into the Java application; the setBridge method is used to set the enhancement code.

[0075] In an optional implementation, the dependency analysis agent also includes an API code module, which includes a communication address of a developer who deletes the dependency; exemplarily, the dependency identification method not used in the Java application also includes: loading the API code module into the Java virtual machine through the ProfilerAgentClassLoader class loader.

[0076] Exemplarily, the API code module further includes: instruction information for instructing the enterprise internal communication tool on how to display unused dependencies. The communication address of the R&D personnel mentioned above refers to the communication address corresponding to the enterprise internal communication tool of the R&D personnel.

[0077] In an optional implementation, the dependency analysis agent also includes: a Common code module and an Extension code module, the Common code module stores preset methods and preset constants; the Extension code module is used to extend the functionality of the dependency analysis agent; the dependency identification method not used in the Java application also includes: loading the Common code module and the Extension code module into the Java virtual machine through the ProfilerAgentClassLoader class loader.

[0078] Exemplarily, the Common code module may include common methods widely used in other code modules. In order to reduce code duplication in the code modules, the present application sets this code module to enhance the maintainability of the dependency analysis agent.

[0079] Exemplarily, the Extension code module can support the dependency analysis agent to integrate other functions in the form of plug-ins. The present application sets up this code module in order to enhance the extensibility of the dependency analysis agent.

[0080] It is understandable that the dependency analysis agent includes Agent code module, Bridge code module, Core code module, Common code module, Extension code module and Api code module. The dependency analysis agent includes 6 code modules, which are relatively large. Therefore, there is a problem of complex packaging. It requires a tool with the following characteristics for packaging: the writing of automated operation scripts can be completed quickly; local installation is flexible and simple, reducing the installation burden on developers; when executing scripts, there is no need to enter commands, and complex operations can be completed by clicking; portability requires that it can be used under both Unix / Linux and Windows operating systems; considering the above four characteristics, it was finally decided to use the Makefile tool to perform automated compilation and other operations in the local development phase of the Maven project to improve development efficiency.

[0081] In the embodiment of the present application, the Agent code module, the Bridge code module, the Core code module, the Common code module, the Extension code module, the Api code module and the Java application are all jar packages.

[0082] The dependency analysis agent is developed with reference to the Java agent technology. Java agent is a parameter of the Java command. The parameter Java agent can be used to specify a jar package, and there are two requirements for the java package: Requirement 1, the MANIFEST.MF file of the jar package must specify the Premain-Class item; Requirement 2, the class specified by Premain-Class must implement the premain method.

[0083] For example, Java Agent is implemented through the Instrumentation API of JVM. The Instrumentation API provides the ability to modify bytecode before or after the JVM loads a class. It is usually used for monitoring, diagnosis, performance analysis, code injection, etc. of Java applications. Java Agent provides two entry points: premain method and main method. The premain method can transform Java application classes before they are loaded.

[0084] In the embodiment of the present application, the premain method of the Premain-Class class, i.e., the ProfilerAgentBoostrap class, is the entry method of the dependency analysis agent, and the premain method is set in the Agent code module. Therefore, the Agent code module is first run in the process of running the dependency analysis agent.

[0085] The premain method of the Premain-Class class is the entry method of the agent and will be loaded by the ApplicationClassLoader class loader. Therefore, the Premain-Class class and the custom class loader, namely the ProfilerAgentClassLoader class loader, are placed in a separate jar package, namely the agent code module, which is loaded by the ApplicationClassLoader class loader, and the core logic of the dependency analysis agent is placed in other jar packages and loaded by the custom class loader.

[0086] Step S202: Acquire the dependency analysis agent from the storage path.

[0087] Step S203: From the preset correspondence between code modules and class loaders, search for the ApplicationClassLoader class loader corresponding to the Agent code module, the BootstrapClassLoader class loader corresponding to the Bridge code module, and the ProfilerAgentClassLoader class loader corresponding to the Core code module.

[0088] Among them, the parent class of the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader is the BootstrapClassLoader class loader.

[0089] It can be understood that the Java application corresponds to the ApplicationClassLoader class loader.

[0090] Exemplarily, the above-mentioned “correspondence between preset codes and class loaders” may be stored in an agent code module.

[0091] Step S204: Load the Java application into the Java virtual machine through the ApplicationClassLoader class loader.

[0092] Step S205: Load the Core code module into the Java virtual machine through the ProfilerAgentClassLoader class loader.

[0093] Step S206: Load the Bridge code module into the Java virtual machine through the BootstrapClassLoader class loader.

[0094] Exemplarily, the main services in the jar packages of the six code modules included in the dependency analysis agent are all executed in the PicoContainer container. The embodiment of the present application independently develops a dependency analysis agent by implementing a class isolation strategy, and realizes the LifeCycle function to obtain the dependencies actually called by the Java application during operation when the PicoContainer container itself is started and stopped. When used, the bytecode is enhanced in the form of a Java agent before the Java application runs (i.e., the premain method), and the dependencies called in the Java application are monitored, so as to count the dependencies called in the methods used by the Java application within a specified time range, so as to accurately and quickly provide dependency usage information for the Java application, help to troubleshoot useless dependencies, and help shorten the compilation / deployment time of the Java application. Shortening the deployment time of the Java application mainly refers to shortening the startup time of the Java application. Shortening the startup time helps developers to start and self-test locally faster; helps to release versions faster and test faster in the test environment; and can also be repaired faster when the production environment encounters a situation where a patch needs to be issued.

[0095] During the development process, the inline IDE plug-in of Makefile is introduced and configured to facilitate the writing of Makefile and related operations; the structural analysis and writing of Makefile are completed independently in combination with actual projects to assist in local project construction and deployment operations.

[0096] Since the main services in the jar packages of the six code modules included in the dependency analysis agent are all executed in the PicoContainer container, the start and stop methods of the PicoContainer container are the most important. Figure 3 As shown, it is a code schematic diagram of starting the container provided in an embodiment of the present application.

[0097] like Figure 3As shown, the various functional components written in the Extension code module are loaded in the startup code, among which the Lifecycle function needs to obtain the dependencies actually called by the Java application during the operation when the PicoContainer container itself is started and stopped; and the EventListener function needs to operate on the Event in the PicoContainer container execution. The unused dependency statistics developed in this application are realized by implementing the Lifecycle interface.

[0098] like Figure 4 As shown, it is a code schematic diagram of stopping the PicoContainer container provided in an embodiment of the present application.

[0099] like Figure 4 As shown, the operation of stopping the PicoContainer container in the stop code is mainly to stop the PicoContainer container and subsequently send the collected unused dependencies to the communication address of the specified user by calling the enterprise internal communication tool interface.

[0100] This application implements functions mainly through Extension code modules, which are loaded into Java applications in the form of Extensions, which is conducive to adding custom functions later.

[0101] The key code logic in the Extension code module is as follows Figure 4 As shown in the figure, in the stop method of Lifecycle, that is, the stop phase of the entire PicoContainer container, the defined collect method is called to count which dependencies are not used during the start and stop process of the entire PicoContainer container. Finally, the URL (Uniform Resource Locator) of the jar package of the unused dependency is counted for subsequent notification sending.

[0102] For example, if you need to use the dependency analysis agent, you need to put the tarball of the dependency analysis agent anywhere on the server and decompress it, then press Figure 5 The startup command starts the dependency analysis agen.

[0103] like Figure 5 As shown, the key startup parameters include the following two startup parameters:

[0104] Startup parameter 1: -Dspring-agent-213734.app.Enterprise internal communication tool.user=213734,k61859

[0105] Startup parameter 2: -Dspring-agent-213734.app.health.check.timeout=20

[0106] The startup parameter 1 is used to set the result after the dependency analysis agent runs, that is, the unused dependency, which will be sent to the communication address in the API code module in the form of a notification of the internal communication tool of the enterprise. The number of communication addresses can be one or more. The above startup parameter 1 takes the number of communication addresses as 2 as an example, for example, the communication addresses are the communication address with user ID 213734 and the communication address with user ID k61859. Multiple user IDs are separated by commas.

[0107] The second startup parameter is used to set the statistical duration of the dependency analysis agent. Here, the statistical duration is set to 20, which means that the statistics will end 20 minutes after the dependency analysis agent is successfully started.

[0108] In an optional implementation, there are multiple presentation forms of unused dependencies sent to the communication address, and the present application embodiment provides but is not limited to Figure 6 As shown. Figure 6 As shown, it is a schematic diagram of the presentation method of unused dependencies provided in an embodiment of the present application.

[0109] Figure 6 The figure shows the presentation form of unused dependencies of notifications of internal enterprise communication tools.

[0110] It is understandable that since dynamic analysis is used for statistics, if a method of a dependency is not called within the statistical time period, it will be counted as an unused dependency. Therefore, in actual applications, the statistical time length set by startup parameter 2 will be set slightly larger to ensure that all types of dependencies actually used can be called within the time period to ensure the accuracy of statistics.

[0111] Step S207: calling the setBridge method in the Bridge code module to convert the Agent code module into enhanced code.

[0112] Step S208: injecting the enhanced code into the beginning and end of each method in the Java application in the Java virtual machine based on the loading location information to obtain the tested application.

[0113] It is understandable that the dependency analysis agent and the Java application need to be loaded into the Java virtual machine through a class loader. If the dependency analysis agent and the Java application are loaded using the same class loader, the following problems may occur:

[0114] Problem 1: Because each code module contained in the dependency analysis agent also needs to call dependencies, if the dependency analysis agent and the Java application are loaded using the same class loader, it is impossible to distinguish whether the final dependency is called by the dependency analysis agent or the Java application, resulting in the inability to determine which dependencies are unused dependencies of the Java application.

[0115] Question 2: If the dependency analysis agent and the Java application use different versions of the same dependency, it will cause dependency conflicts between the dependency analysis agent and the Java application.

[0116] In view of the above two problems, this application requires a class isolation strategy. The premain method of Premain-Class (i.e., ProfilerAgentBoostrap in this application) is the entry method of the dependency analysis agent. When started, the dependency analysis agent is loaded into the Java virtual machine by the ApplicationClassLoader class loader. According to the class loading principle, the Java application of this application will also be loaded into the Java virtual machine by the ApplicationClassLoader class loader, and the class isolation strategy cannot be implemented. To implement the class isolation strategy, the class loading principle must be broken.

[0117] The class loading principle mentioned above refers to the class loader that loads the current class, which is also used to load the classes that the current class depends on, or follows the parent delegation principle, where the parent loader loads the classes that the current class depends on.

[0118] In the embodiment of the present application, the implementation of the agent tool, namely Arthas, is referenced when implementing the class isolation strategy. Like Arthas, the present application is implemented by a custom ClassLoader, namely ProfilerAgentClassLoader class loader.

[0119] In the process of developing the dependency analysis agent, the applicant found that: since the premain method of the Premain-Class class is the entry method of the dependency analysis agent, it must be loaded to the Java virtual machine by the ApplicationClassLoader class loader. Therefore, Premain-Class and the custom class loader, namely the ProfilerAgentClassLoader class loader, are placed in a separate jar package - the agent code module, which is loaded by the ApplicationClassLoader class loader, and the core logic of the dependency analysis agent is placed in other jar packages (i.e., the code modules in the dependency analysis agent except the agent code module), which are loaded into the Java virtual machine by the ProfilerAgentClassLoader class loader.

[0120] In order to enable those skilled in the art to better understand the parent-child relationship of each class loader and the loading relationship between each jar package in the embodiment of the present application, the following is combined with Figure 7 To explain, Figure 7 As shown, it is a schematic diagram of the parent-child relationship of each class loader and the loading relationship between each Jar package provided in an embodiment of the present application.

[0121] like Figure 7 As shown, the subclass of the BootstrapClassLoader class loader is the ExtClassLoader class loader; the subclasses of the ExtClassLoader class loader include: ApplicationClassLoader class loader and ProfilerAgentClassLoader class loader. The ApplicationClassLoader class loader loads the application.jar of the Java application and the startup-agent.jar of the agent code module into the Java virtual machine. The ProfilerAgentClassLoader class loader loads the startup-core.jar of the Core code module, the startup-api.jar of the Api code module, the startup-Common.jar of the Common code module, and the startup-extension.jar of the Extension code module into the Java virtual machine. The BootstrapClassLoader class loader loads the startup-bridge.jar of the Bridge code module into the Java virtual machine.

[0122] like Figure 7As shown in the figure, the ProfilerAgentClassLoader class loader is customized in the startup-agent.jar of the agent code module.

[0123] According to the parent delegation principle of class loaders, the classes loaded by the parent class loader (such as the BootstrapClassLoader class loader) are visible to the child class loaders (such as the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader), while the classes loaded by the child class loader are not visible to the parent class loader, and the classes loaded by the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader are not visible to each other. In other words, the dependency analysis agent and the Java application share the underlying APIs such as JMX (classes loaded by BootstrapClassLoader and ExtClassLoader), so this application can obtain the actual call dependencies when the Java virtual machine runs the Java application by calling some JDK APIs.

[0124] If you want to observe the startup process of a Java application and the subsequent running process over a period of time, you need to enhance the Agent code module before it is loaded, and then load the enhanced Agent code module. This application chooses the premain method of javaagent to implement it. In summary, this application will inject some code into the Java application for enhancement. Since the classes loaded by the ApplicationClassLoader and ProfilerAgentClassLoader class loaders are invisible, the Java application cannot directly call the Agent code module, and there will be a ClassNotFoundException or ClassCastException.

[0125] This application adopts the solution in Arthas and introduces the Bridge code module, which is equivalent to building a bridge between the Java application and the Agent code module. The Bridge code module includes the Bridge class file, which is loaded by the BootstrapClassLoader class loader, so the Bridge class file is visible to both the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader. The Java application implements code enhancement of the Agent code module through the Bridge class file.

[0126] For example, the Bridge class file defines the loading location information and static enhancement processing functions, and the specific processing logic is implemented by the EventDispatcher subclass of the abstract class AbstractBridge. Because AbstractBridge is an internal static class of the Bridge class file and a static property is defined in the Bridge class file, AbstractBridge will also be loaded by the BootstrapClassLoader class loader. EventDispatcher is implemented in the Core code module, so it will be loaded by the ProfilerAgentClassLoader class loader.

[0127] Therefore, this application can convert the Agent code module into enhanced code by calling the setBridge method of the Bridge code module. Because AbstractBridge is loaded by the BootstrapClassLoader class loader and EventDispatcher is loaded by the ProfilerAgentClassLoader class loader, the EventDispatcher instance can be converted to an AbstractBridge instance to complete the assignment operation.

[0128] Combination Figure 7 The Bridge code module is loaded using the BootstrapClassLoader class loader, a parent class loader visible to both the dependency analysis agent and the Java application. This enables the Java application to call the static enhancement processing function in the Core code module through the Bridge code module when calling the enhancement code of the agent code module, and then call the AbstractBridge instance to implement method enhancement.

[0129] In order for those skilled in the art to better understand the process of setting the premain entry point in the embodiment of the present application, the following is an explanation with reference to the code.

[0130] like Figure 8a to Figure 8b As shown, it is a schematic diagram of a code for setting a premain entry point provided in an embodiment of the present application.

[0131] Figure 8a It is the code that specifies Premain-Class in the manifest configuration of the jar packaging plug-in of the pom; Figure 8b Add a premain method to the specified class.

[0132] Figure 8aThe main functions of the code shown and the code "File spyJarFile = new File(LIB_HOME + BRIDGE_JAR)" include but are not limited to the following two points:

[0133] 1. Add the dependency analysis agent jar package, spring-profiler-bridge.jar, to the search path of the BootstrapClassLoader class loader.

[0134] 2. According to the parent delegation principle of class loading, when loading the Bridge code module, it will be delegated to the BootstrapClassLoader class loader first, so the Bridge code module will be loaded by the root class loader (that is, the BootstrapClassLoader class loader) instead of the ProfilerAgentClassLoader class loader.

[0135] Figure 8b The main functions of the code shown include but are not limited to the following two points:

[0136] 1. Load the initialization class ProfilerClassFileTransformer of the Core code module through the ProfilerAgentClassLoader class loader.

[0137] 2. Initialize the Java application by instantiating it through reflection calling.

[0138] For example, Fig. 9 As shown, it is a schematic diagram of the key codes in the ProfilerClassFileTransformer class provided in an embodiment of the present application.

[0139] Fig. 9 The code shown mainly implements the transform method in ClassFileTransformer.

[0140] like Fig.10 As shown, it is a code schematic diagram for completing the most critical Bridge code module setting, instrumentation setting and container startup in the construction method of the ProfilerClassFileTransformer class provided in an embodiment of the present application.

[0141] Step S209: running the tested application through the Java virtual machine.

[0142] It can be understood that since the Agent code module after adding the code is located at the beginning and end of each method in the Java application. In the process of running the tested application, when entering each method of the Java application, the atEnter method of EventDispatcher in the Core module is first executed through the enhanced code of the Agent module to start monitoring the activity of the method. The Agent code module can call the Bridge code module by calling the calling interface of the Bridge code module; thereby, the Bridge code module calls the static enhanced processing function in the Core code module, at which time the life cycle of the static enhanced processing function begins, so that the static enhanced processing function can obtain the dependencies called by the method during operation. When exiting the method, the Agent code module is still running, and the axExit method of EventDispatcher in the Core module is called through the enhanced code of the Agent module to end monitoring the activity of the method, and the actual usage dependencies collected during the activity are counted. At this time, the life cycle of the static enhanced processing function ends, and the static enhanced processing function can obtain the dependencies called during the operation of the method.

[0143] Step S210: If the tested application is finished running, the dependency correspondence relationship obtained by the static enhancement processing function is obtained, and the dependency correspondence relationship includes the correspondence relationship between the name of the called dependency, the path of calling the dependency, and the name of the class loader that calls the dependency.

[0144] The following example illustrates the dependency relationship.

[0145] Dependency relationships include but are not limited to:

[0146] Depends on A1, Agent code module, ApplicationClassLoader class loader; depends on A2, Bridge code module, BootstrapClassLoader class loader; depends on A3, Core code module, ProfilerAgentClassLoader class loader; depends on A4, java application, ApplicationClassLoader class loader.

[0147] Step S211: obtaining from the dependency correspondence that the name of the class loader for calling the dependency is the ApplicationClassLoader class loader and the path of calling the dependency is not the target dependency of the code module included in the dependency analysis agent.

[0148] The calling dependency path is not a code module included in the dependency analysis agent, which means that the calling dependency path is not the 6 code modules included in the dependency analysis agent.

[0149] Taking the dependency correspondence including but not limited to: dependency A1, Agent code module, ApplicationClassLoader class loader; dependency A2, Bridge code module, BootstrapClassLoader class loader; dependency A3, Core code module, ProfilerAgentClassLoader class loader; dependency A4, java application, ApplicationClassLoader class loader as an example, the target dependency is dependency A4.

[0150] Step S212: Determine that all dependencies corresponding to the Java application except the target dependency are unused dependencies.

[0151] The embodiment of the present application provides a method for identifying unused dependencies in a java application, which jumps out of the mvn dependency static analysis mode in the related art and adopts a more accurate java agent dynamic analysis mode. The present application sets the class loader for loading java applications and agent code modules as the ApplicationClassLoader class loader; the class loader for loading the Core code module is the ProfilerAgentClassLoader class loader; and the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader are sibling class loaders, thereby achieving the isolation of the agent code module from the java application. The dependency analysis agent in the present application introduces the Bridge code module. The Bridge code module is loaded using the BootstrapClassLoader class loader, a parent class loader visible to both the dependency analysis agent and the java application, thereby achieving the purpose of calling the static enhancement processing function in the Core code module through the Bridge code module when the java application calls the enhancement code of the agent code module, thereby achieving the purpose of obtaining the dependency called by the java application during the running of the java application.

[0152] In order for those skilled in the art to better understand the technical solution provided in the embodiments of the present application, the use of Makefile is described in detail below.

[0153] You can compile and build Makefile with one click. To execute Makefile, you must first install make, and then use make to execute the Makefile script. The following describes the process of installing make on a Windows system, which includes steps A11 to A12.

[0154] Step A11: Download the make executable file. For the specific download address, see the link in the document appendix. Then execute the executable file locally to complete the installation. The default installation directory is acceptable.

[0155] Step A12: After completing the installation of make, you need to install an IDE plug-in for make, such as the IDEA plug-in.

[0156] For example, the Maven project development IDE plug-in is described as an IDEA plug-in.

[0157] The process of installing the IDEA plug-in is as follows. First, install the plug-in in the IDEA plug-in by loading the zip package through Install Plugin from Disk. After the installation is complete, you can see the corresponding plug-in in the Plugins interface in the Settings of the IDEA plug-in. For more information, see Fig.11 , which is a schematic diagram of the interface of the IDEA plug-in provided in an embodiment of the present application.

[0158] like Fig.12 As shown, it is a schematic diagram of the interface of Build Tools provided in an embodiment of the present application.

[0159] After the installation is complete, you can find the Make configuration in BuildTools under Settings-Build, Execution, Deployment, and enter the path where Make was installed. Cygwin here refers to an open source project that provides a Unix-like environment on the Windows operating system, providing GNU and open source tools that can run on Windows, such as bash shell, GNU command line, etc.

[0160] It can be understood that after the installation is complete, you can use the version command to verify the installation. You can output the "installation path of the make executable file configured in the previous step" --version command on the cmd page. If the command output format is as follows Fig.13 If the following code is displayed, it means that make has been installed successfully and configured correctly. Fig.13 The figure is a schematic diagram of the output format of the command provided in the embodiment of the present application.

[0161] After installing make, you can write makefile according to the actual project structure. The following is an example using the spring project. Fig.14 As shown, it is a schematic diagram of the structure of the spring project provided in the embodiment of the present application.

[0162] like Fig.14As shown, six code modules, namely Agent code module, Bridge code module, Core code module, Common code module, Extension code module and Api code module, are directly linked to the parent project. The Extension code module is independent and requires separate Maven operations.

[0163] In the related art, each time you re-send a package locally, you need to repeatedly click the cleaninstall package in the UI interface of the Maven plugin, which wastes time on the one hand; on the other hand, it is difficult to ensure that there will be no misoperation or omission during the manual operation. Considering that if new functions need to be added to the spring project in the future, this application introduces the Extension code module, and the number of repetitions of the above operations will increase by one, and the burden and risk of local packaging will also increase.

[0164] This application can effectively solve the above problems by adding Makefile to the spring project. First, take a simple clean operation as an example to explain the writing of Makefile. Fig.15 As shown, it is a code diagram of the clean operation provided in an embodiment of the present application.

[0165] There are two structures in Makefile, namely targets and pseudo-targets, which are used to define build rules and operations.

[0166] A target is a rule in a Makefile that specifies how to generate files. Each target usually corresponds to one or more dependencies and a set of commands to generate the target file. The make tool determines which files need to be regenerated based on the target and dependency relationships. The following example illustrates the target.

[0167] #Goal: Compile Utils class

[0168] Utils.class: Utils.java

[0169] javac Utils.java

[0170] #Goal: compile main class

[0171] main.class: main.java

[0172] javac main.java

[0173] Pseudo targets are special types of targets in Makefiles, which are used to indicate a mark for performing certain operations rather than indicating how to generate files. Pseudo targets are usually used to define some operations, such as cleaning files, installing software, packaging projects, etc. Pseudo targets are usually declared using .PHONY and do not correspond to actual file names. All the targets used in the Makefile writing of this application are pseudo targets.

[0174] Fig.15 This is the implementation of the basic clean operation. Here, `ifeq ($(strip $(VERSION)),)` means that if the value of the VERSION variable after removing the leading and trailing spaces is empty, the operation in the condition is executed. The main operation is to complete the mvn clean operation in the main pom directory and then cd to the extension module directory to perform mvn clean. Depending on whether the VERSION variable is specified in the Makefile, the corresponding script will also be slightly different.

[0175] Combined with the previously mentioned problem of introducing new modules in the form of Extension code modules, it can be easily solved during local development through Makefile. Just add a new line cd .. / module_name && ${MVN} package -Dmaven.test.skip=true to the script, which greatly improves efficiency.

[0176] Secondly, taking a load package operation as an example, the writing of Makefile is briefly explained.

[0177] like Fig.16 As shown, it is a code diagram of the package operation provided in the embodiment of the present application.

[0178] Package: clean install in Makefile means that the clean and install operations will be executed in sequence before the package operation is performed separately. The package will first perform the regular mvn operation, and branches will be formed according to whether there is a VERSION parameter. After the packaging operation is completed, it is necessary to create a new final output directory / build and clean up the old output packages in the output directory to avoid errors when the new packaging is completed.

[0179] It is understandable that the command sets of Windows and Linux / Unix systems are different, and the following distinctions need to be made when executing locally on different systems. Fig.16As shown in the figure, Maven commands are consistent on different systems, while commands other than Maven, the commented and uncommented parts have the same effect in the Spring project. There is a big difference between the two.

[0180] After completing the basic Maven operations, you can directly connect the various steps of packaging through a pseudo goal, so that developers can complete all the command execution required for packaging with only one operation after completing the development locally.

[0181] like Fig.17 The figure is a partial code diagram of the tar package provided in the embodiment of the present application.

[0182] After the make IDEA plug-in is installed, you can click to execute commands through the IDEA plug-in UI. Fig.18 , which is a schematic diagram of the UI interface of the IDEA plug-in provided in an embodiment of the present application.

[0183] In the embodiment of the present application, by introducing the two simple and easy operations of Makefile plug-in + self-writing project Makefile, the automation of build deployment operation during local self-testing / debugging of developers is quickly realized. While facilitating the operation of developers, it also reduces the possibility of errors when performing complex operations.

[0184] The dependency analysis agent developed in the embodiment of the present application has been used in the internal management system group of the enterprise, and has successfully identified some actually redundant dependencies, many of which are dependencies with similar functions, one of which is only called in individual methods. During the version iteration process, due to the deletion of some methods, the dependency became an unused dependency. For example, Jackson and Fastjson, which both perform JSON processing, the main body of the project uses Jackson, and some methods use Fastjson. After all the methods using Fastjson are removed, the Fastjson dependency is not removed in time. This problem was successfully discovered and solved by using the Dependency Analysis Agent. It helps the Endeavour project save 7-8 seconds of compilation / deployment time each time after removing useless dependencies.

[0185] The dependency analysis agent is also used in the automated test environment of other business system groups. Since the automated interface test coverage is high and the methods tested are relatively complete, the use of the dependency analysis agent in the automated test environment can accurately obtain the actual usage of each dependency in the project. Through the scheduled execution of automated tests, the situation of unused dependencies in the project can also be obtained regularly.

[0186] This application discloses the specific installation process of the make tool and introduces the writing method of Makefile in detail through specific project cases. Makefile can realize one-click execution of many complex compilation and packaging operations, which provides great convenience for the local development process of the development team.

[0187] The above describes a method for identifying unused dependencies in a Java application provided by an embodiment of the present application. The following describes a device for executing the method for identifying unused dependencies in a Java application.

[0188] See also Fig.19 , Fig.19 , is a schematic diagram of a structure of a Java application provided in an embodiment of the present application that does not use a dependency identification device. Fig.19 The device shown comprises:

[0189] The first acquisition module 1901 is used to acquire the storage path of the dependency analysis agent if an instruction to start a Java application is detected;

[0190] The dependency analysis agent includes an Agent code module, a Bridge code module and a Core code module; the Agent code module includes a premain method, a calling interface for calling the Bridge code module and a preset correspondence between a code module and a class loader; the Bridge code module includes a calling interface for calling a static enhancement processing function in the Core code module, loading location information and a setBridge method; the static enhancement processing function is used to obtain the dependency called within the life cycle of the static enhancement processing function, the path for calling the dependency and the name of the class loader for calling the dependency; the loading location information includes the start and end of each method loaded by the Agent code module into the Java application; the setBridge method is used to set the enhancement code;

[0191] A second acquisition module 1902, configured to acquire the dependency analysis agent from the storage path;

[0192] The search module 1903 is used to search the ApplicationClassLoader class loader corresponding to the Agent code module, the BootstrapClassLoader class loader corresponding to the Bridge code module, and the ProfilerAgentClassLoader class loader corresponding to the Core code module from the preset correspondence between the code and the class loader;

[0193] Wherein, the parent class of the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader is the BootstrapClassLoader class loader;

[0194] A first loading module 1904 is used to load the Java application into the Java virtual machine through the ApplicationClassLoader class loader;

[0195] The second loading module 1905 is used to load the Core code module into the Java virtual machine through the ProfilerAgentClassLoader class loader;

[0196] The third loading module 1906 is used to load the Bridge code module into the Java virtual machine through the BootstrapClassLoader class loader;

[0197] The conversion module 1907 is used to call the setBridge method in the Bridge code module to convert the Agent code module into an enhanced code;

[0198] An injection module 1908, configured to inject the enhanced code into the beginning and end of each method in the Java application in the Java virtual machine through the ApplicationClassLoader class loader based on the loading location information, so as to obtain a tested application;

[0199] A running module 1909, configured to run the tested application through the Java virtual machine;

[0200] The third acquisition module 1910 is used to obtain the dependency correspondence obtained by the static enhancement processing function if the application under test is completed, wherein the dependency correspondence includes the correspondence between the name of the called dependency, the way to call the dependency, and the name of the class loader that calls the dependency;

[0201] A fourth acquisition module 1911 is used to acquire, from the dependency correspondence, a target dependency of a code module whose name is the ApplicationClassLoader class loader and whose calling dependency path is not included in the dependency analysis agent;

[0202] The determination module 1912 is used to determine that all dependencies corresponding to the Java application except the target dependency are unused dependencies.

[0203] In an optional implementation, the dependency analysis agent further includes an API code module, the API code module includes a communication address of a developer who deletes the dependency; and further includes:

[0204] The fourth loading module is used to load the Api code module into the Java virtual machine through the ProfilerAgentClassLoader class loader.

[0205] In an optional implementation, the method further includes:

[0206] A sending module is used to send the unused dependency to the communication address.

[0207] In an optional implementation, the dependency analysis agent further includes: a Common code module and an Extension code module, wherein the Common code module stores preset methods and preset constants; the Extension code module is used to extend the functions of the dependency analysis agent; and further includes:

[0208] The fifth loading module is used to load the Common code module and the Extension code module into the Java virtual machine through the ProfilerAgentClassLoader class loader.

[0209] Fig. 20 A schematic diagram of the structure of a server is provided, such as Fig. 20 As shown, the server includes a bus 2001, a processor 2002, a communication interface 2003 and a memory 2004. The processor 2002, the memory 2004 and the communication interface 2003 communicate with each other via the bus 2001.

[0210] The bus 2001 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig. 20 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0211] The processor 2002 may be any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0212] The memory 2004 may include a volatile memory, such as a random access memory (RAM). The memory 2004 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0213] Among them, the memory 2004 can be used to store software codes related to the unused dependency identification method in the Java application, and the processor 2002 can execute the steps of the unused dependency identification method in the Java application of the chip, and can also schedule other units to implement corresponding functions.

[0214] It should be understood that the server can be a centralized or distributed device, and the processor of the server can be a hardware circuit (such as an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a general-purpose processor, a digital signal processor (DSP), a microprocessor or a microcontroller, etc.), or a combination of these hardware circuits. For example, the processor can be a hardware system with an instruction execution function, such as a CPU, DSP, etc., or a hardware system without an instruction execution function, such as an ASIC, FPGA, etc., or a combination of the above-mentioned hardware systems without an instruction execution function and hardware systems with an instruction execution function.

[0215] In an optional implementation, the dependency analysis agent is stored in the server, and the Java virtual machine runs in the server.

[0216] An embodiment of the present application also provides a computer program product, including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any of the Java applications provided in the embodiments of the present application. The dependency identification method is not used.

[0217] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the unused dependency identification methods in the Java application provided in the embodiment of the present application.

[0218] It should also be noted that the device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. In addition, in the drawings of the device embodiments provided by the present application, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.

[0219] Through the description of the above implementation mode, the technicians in the field can clearly understand that the present application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by special hardware including special integrated circuits, special CPUs, special memories, special components, etc. In general, all functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be various, such as analog circuits, digital circuits or special circuits. However, for the present application, software program implementation is a better implementation mode in more cases. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, a U disk, a mobile hard disk, a ROM, a RAM, a disk or an optical disk, etc., including a number of instructions to enable a computer device (which can be a personal computer, a training device, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0220] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0221] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a training device, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, training device, or data center. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device, a data center, etc. that includes one or more available media integrations. The available medium may be a magnetic medium, (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

Claims

1. A method for identifying unused dependencies in a Java application, characterized in that: include: If the instruction to start the Java application is detected, the storage path of the dependency analysis agent is obtained; The dependency analysis agent includes an Agent code module, a Bridge code module and a Core code module; the Agent code module includes a premain method, a calling interface for calling the Bridge code module and a preset correspondence between a code module and a class loader; the Bridge code module includes a calling interface for calling a static enhancement processing function in the Core code module, loading location information and a setBridge method; the static enhancement processing function is used to obtain the dependency called within the life cycle of the static enhancement processing function, the path for calling the dependency and the name of the class loader for calling the dependency; the loading location information includes the start and end of each method loaded by the Agent code module into the Java application; the setBridge method is used to set the enhancement code; Obtaining the dependency analysis agent from the storage path; From the preset correspondence between code and class loader, find the ApplicationClassLoader class loader corresponding to the Agent code module, the BootstrapClassLoader class loader corresponding to the Bridge code module, and the ProfilerAgentClassLoader class loader corresponding to the Core code module; Wherein, the parent class of the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader is the BootstrapClassLoader class loader; Loading the Java application into the Java virtual machine through the ApplicationClassLoader class loader; Loading the Core code module into the Java virtual machine through the ProfilerAgentClassLoader class loader; Loading the Bridge code module into the Java virtual machine through the BootstrapClassLoader class loader; Calling the setBridge method in the Bridge code module to convert the Agent code module into an enhanced code; Injecting the enhanced code into the beginning and end of each method in the Java application in the Java virtual machine through the ApplicationClassLoader class loader based on the loading location information to obtain a tested application; Running the tested application through the Java virtual machine; If the tested application is finished running, the dependency correspondence relationship obtained by the static enhancement processing function is obtained, where the dependency correspondence relationship includes the name of the dependency being called, the path for calling the dependency, and the name of the class loader for calling the dependency; The name of the class loader for calling the dependency is obtained from the dependency correspondence, and the name of the class loader for calling the dependency is the ApplicationClassLoader class loader, and the path of calling the dependency is not the target dependency of the code module included in the dependency analysis agent; It is determined that all dependencies corresponding to the Java application except the target dependency are unused dependencies.

2. According to claim 1, the dependency identification method is not used in the Java application, characterized in that: The dependency analysis agent further includes an API code module, wherein the API code module includes a communication address of a developer who deletes dependencies; and further includes: The Api code module is loaded into the Java virtual machine through the ProfilerAgentClassLoader class loader.

3. According to claim 2, the dependency identification method is not used in the Java application, characterized in that: Also includes: The unused dependencies are sent to the communication address.

4. The method for identifying dependencies not used in a Java application according to any one of claims 1 to 3, characterized in that: The dependency analysis agent further includes: a Common code module and an Extension code module, wherein the Common code module stores preset methods and preset constants; and the Extension code module is used for extending the functions of the dependency analysis agent; The Java application does not use the dependency identification method and further includes: The Common code module and the Extension code module are loaded into the Java virtual machine through the ProfilerAgentClassLoader class loader.

5. A java application does not use a dependency identification device, characterized in that: include: The first acquisition module is used to acquire the storage path of the dependency analysis agent if an instruction to start the Java application is detected; The dependency analysis agent includes an Agent code module, a Bridge code module and a Core code module; the Agent code module includes a premain method, a calling interface for calling the Bridge code module and a preset correspondence between a code module and a class loader; the Bridge code module includes a calling interface for calling a static enhancement processing function in the Core code module, loading location information and a setBridge method; the static enhancement processing function is used to obtain the dependency called within the life cycle of the static enhancement processing function, the path for calling the dependency and the name of the class loader for calling the dependency; the loading location information includes the start and end of each method loaded by the Agent code module into the Java application; the setBridge method is used to set the enhancement code; A second acquisition module, used for acquiring the dependency analysis agent from the storage path; A search module, used to search for the ApplicationClassLoader class loader corresponding to the Agent code module, the BootstrapClassLoader class loader corresponding to the Bridge code module, and the ProfilerAgentClassLoader class loader corresponding to the Core code module from the preset correspondence between the code and the class loader; Wherein, the parent class of the ApplicationClassLoader class loader and the ProfilerAgentClassLoader class loader is the BootstrapClassLoader class loader; A first loading module, used to load the Java application into the Java virtual machine through the ApplicationClassLoader class loader; A second loading module is used to load the Core code module into the Java virtual machine through the ProfilerAgentClassLoader class loader; A third loading module, used to load the Bridge code module into the Java virtual machine through the BootstrapClassLoader class loader; A conversion module, used for calling the setBridge method in the Bridge code module to convert the Agent code module into an enhanced code; An injection module, used for injecting the enhanced code into the beginning and end of each method in the Java application in the Java virtual machine through the ApplicationClassLoader class loader based on the loading location information, so as to obtain a tested application; A running module, used to run the tested application through the Java virtual machine; A third acquisition module is used to obtain the dependency correspondence obtained by the static enhancement processing function if the tested application is completed, wherein the dependency correspondence includes the name of the called dependency, the way to call the dependency, and the name of the class loader that calls the dependency; A fourth acquisition module is used to acquire, from the dependency correspondence, a name of a class loader for calling a dependency, which is the ApplicationClassLoader class loader and a path for calling the dependency is not a target dependency of a code module included in the dependency analysis agent; The determination module is used to determine that all dependencies corresponding to the Java application except the target dependency are unused dependencies.

6. The unused dependency identification device in the Java application according to claim 5, characterized in that: The dependency analysis agent further includes an API code module, wherein the API code module includes a communication address of a developer who deletes dependencies; and further includes: The fourth loading module is used to load the Api code module into the Java virtual machine through the ProfilerAgentClassLoader class loader.

7. The java application according to claim 6 does not use a dependency identification device, characterized in that: Also includes: A sending module is used to send the unused dependency to the communication address.

8. A computer program product, characterized in that The method comprises computer-readable instructions, which, when executed on a server, enable the server to implement the unused dependency identification method in a Java application as claimed in any one of claims 1 to 4.

9. A server, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the server can implement the unused dependency identification method in a Java application as described in any one of claims 1 to 4.

10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by a server, the server can implement the unused dependency identification method in a Java application as described in any one of claims 1 to 4.

Images