CN106874060B

CN106874060B - Method and equipment for judging whether JAR package is quoted

Info

Publication number: CN106874060B
Application number: CN201710028408.3A
Authority: CN
Inventors: 周维
Original assignee: Individual
Current assignee: Wu Jianwei
Priority date: 2017-01-16
Filing date: 2017-01-16
Publication date: 2020-12-18
Anticipated expiration: 2037-01-16
Also published as: CN106874060A

Abstract

The invention relates to the field of Java application development, in particular to a method for judging whether a JAR package is quoted, which comprises the following steps: decompressing JAR packets, and establishing a corresponding relation between each JAR packet file and a packet path contained in the JAR packet file; recording all packages and classes quoted by the source code, and establishing a corresponding relation between each class file and a quoted package path; and comparing whether any one of the packages referenced by the source codes is contained in the JAR package file, if so, determining that the JAR package is a necessary package, and otherwise, determining that the JAR package is a suspicious package. The embodiment of the invention preliminarily judges which packets are redundant by comparing the external packet classes quoted in the JAVA source file with the packet classes quoted in the JAR packet, thereby giving a proposal for a coder to delete unnecessary packets, not only slimming a source code program, but also avoiding the risks of packet collision and the like caused by improper introduction of the JAR packet and improving the safety of the program.

Description

Method and equipment for judging whether JAR package is quoted

Technical Field

The invention relates to the field of Java application development, in particular to a method and equipment for judging whether a JAR package is quoted.

Background

JAVA is a fully functional object-oriented programming language. Thus, JAVA programs produce the desired effect by building a structured collection of software components that interact with each other. These components are called objects and may be arranged in an object class architecture, object classes also referred to as classes for short. Instead of running directly on the operating system of the computer, the JAVA program runs on a JAVA virtual machine JVM, which is itself a program running on the operating system of the computer. Due to the object-oriented property of JAVA and the standardization of JVM, the JAVA program can realize the cross-platform property of 'one-time compiling and execution everywhere'.

In the development of an application, a large number of class files are typically involved, usually in the form of JAR packages for ease of storage and use. A JAR (JAVA archive) package is a compressed package of JAVA, and may also be considered as a set of a series of class files, and when a JAR package is used in a project, a path of the JAR package needs to be set in a related parameter (usually, a class path parameter) for specifying a class loading path, so that a virtual machine can dynamically load classes contained in the JAR package at runtime.

Today's large JAVA applications, especially JAVA WEB programs, often need to refer to a large number of third party JAR packages, which may improve development efficiency, but improperly refer to JAR packages, which may easily cause package conflicts. Especially, with the rise of an open source framework, a large number of frameworks rely on a series of components, but beginners often cannot distinguish which are core JAR packages and which are additional high-level functions, so that the situation that all references are downloaded and conflict with one JAR package of another framework often occurs. For example, a classic development framework combination struts2 spring2 hibernate3 has several package conflicts such as asm.

In addition, there is a case where the developer has not remembered that a JAR package has been added, but the package may be completely redundant from start to finish. Redundant JAR packages not only have application risks, but also need spring container escrow in many times, so that memory waste is easily caused.

In the prior art, a generally experienced developer is applied according to the specification of the corresponding JAR package, i.e. completely processed according to the specification document. Or even more, beginners rely on manpower completely, compare all packages and classes in the JAR package with own source codes one by one, try to delete suspected JAR in sequence, and then compile and run, but the method is time-consuming, labor-consuming and prone to errors.

Disclosure of Invention

In view of the above drawbacks of the prior art, an object of the present invention is to provide a method and an apparatus for determining whether a JAR package is referenced, in which an external package referenced in a JAVA source file is compared with a package in each referenced JAR package file to preliminarily determine which packages are redundant, so as to give a suggestion to an encoder to delete unnecessary packages, thereby not only slimming a source code program, but also avoiding risks such as package collision caused by improper introduction of the JAR package, and improving program security.

The embodiment of the invention provides a method for judging whether a JAR package is quoted, which comprises the following steps:

decompressing JAR packets, and establishing a corresponding relation between each JAR packet file and a packet path contained in the JAR packet file;

recording all packages and classes quoted by the source code, and establishing a corresponding relation between each class file and a quoted package path;

and comparing whether any one of the packages referenced by the source codes is contained in the JAR package file, if so, determining that the JAR package is a necessary package, and otherwise, determining that the JAR package is a suspicious package.

Further, in the above method, after decompressing the JAR packet, the method further includes:

and establishing the corresponding relation between each package path in the JAR package file and the specific class contained in the JAR package file.

Further, in the above method, after recording all the packages and classes referenced by the source code, the method further includes:

and establishing the corresponding relation between each package path referenced by the source code and the specific class contained in the package path.

Further, in the above method, if the package path of the decompressed JAR package file is consistent with the package path referenced by the source code, it is compared whether the JAR package file contains a specific class contained in the package path referenced by the source code, if so, the JAR package is a necessary package, otherwise, the JAR package is a suspicious package.

Further, in the above method, all references of classes referenced by the source code to external classes are referenced in an import header.

The device for judging whether the JAR package is quoted provided by the embodiment of the invention comprises the following components:

the JAR package decompressor is used for decompressing the JAR package and establishing the corresponding relation between each JAR package file and the package path contained in the JAR package file;

the source code reader is used for recording all the packages and classes quoted by the source codes and establishing the corresponding relation between each class file and the quoted package path;

and the comparer is used for comparing whether any one of the packages referenced by the source codes is contained in the JAR package file, if so, the JAR package is a necessary package, and otherwise, the JAR package is a suspicious package.

Further, the JAR packet decompressor is further configured to:

Further, the source code reader is further configured to:

Further, the comparator is further configured to:

if the package path of the decompressed JAR package file is consistent with the package path quoted by the source code, comparing whether the JAR package file contains the specific class contained in the package path quoted by the source code, if so, the JAR package is a necessary package, otherwise, the JAR package is a suspicious package.

Further, all class references to external classes referenced by source code in the source code reader are referenced at the header with import.

Compared with the prior art, the method outputs the dependent packet path from the source code, outputs the existing packet path from the JAR file, and finally compares the two paths to determine whether the JAR file is listed as a suspicious packet or not. The embodiment of the invention preliminarily judges which packets are redundant by comparing the external packet classes quoted in the JAVA source file with the packet classes quoted in the JAR packet, thereby giving a proposal for a coder to delete unnecessary packets, not only slimming a source code program, but also avoiding the risks of packet collision and the like caused by improper introduction of the JAR packet and improving the safety of the program. The comparison process is automatic, manual operation is replaced, and efficiency is improved. The end result, while only reducing the JAR package, may improve performance. Meanwhile, the possibility of JAR packet collision is reduced to a certain extent.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.

FIG. 1 is a first flowchart of a method for determining whether a JAR package is referenced according to the present invention;

FIG. 2 is a schematic diagram of a decompression JAR packet according to the present invention;

FIG. 3 is an exemplary diagram of a package and classes referenced by a source code provided by the present invention;

FIG. 4 is a flowchart of a method for determining whether a JAR package is referenced according to the present invention;

fig. 5 is a schematic structural diagram of a device for determining whether a JAR package is referred to according to the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The invention outputs the dependent packet path from the source code, outputs the existing packet path from the JAR file, and finally compares the two paths to determine whether the JAR file is classified as a suspicious packet or not. The embodiment of the invention preliminarily judges which packets are redundant by comparing the external packet classes quoted in the JAVA source file with the packet classes quoted in the JAR packet, thereby giving a proposal for a coder to delete unnecessary packets, not only slimming a source code program, but also avoiding the risks of packet collision and the like caused by improper introduction of the JAR packet and improving the safety of the program.

The embodiments of the present invention will be described in further detail with reference to the drawings attached hereto.

As shown in fig. 1, an embodiment of the present invention discloses a method for determining whether a JAR package is referred to, where the method includes:

step S101, decompressing JAR packets, and establishing a corresponding relation between each JAR packet file and a packet path contained in the JAR packet file;

step S102, recording all packages and classes quoted by the source code, and establishing the corresponding relation between each class file and the quoted package path;

step S103, comparing whether any one of the packages referenced by the source code is contained in the JAR package file, if so, the JAR package is a necessary package, otherwise, the JAR package is a suspicious package.

Specifically, in step S101, the JAR packet is also a compressed packet, and may be decompressed as in the case of the ZIP compressed packet. For example, a JAR file: jar, using command: jar xf xxx. Jar, see all the package structures and all the classes in the package, as shown in figure 2. Therefore, only one JAVA runtime is needed to run JAR command generation.

In step S102, the source code refers to a code class written by the developer, and records all packages and classes referred by the source code. As shown in fig. 3, the source code: package com. mike references 10 classes of three packages, java.

In the above step S103, in most practical cases, it is only necessary to compare from the level of the package, that is, to compare whether any one of the packages referenced by the source code is contained in the JAR package file. For example: after a JAR package file test. JAR is output through the decompressor, as long as any one of java.io., java.net., and java.util.) is contained, the JAR package is a necessary package, otherwise, if any one of the test. JAR is not contained, the JAR package is classified as a suspicious package.

The embodiment of the invention outputs the dependent packet path from the source code of the embodiment, outputs the existing packet path from the JAR file, and finally compares the two paths to determine whether the JAR file is classified as a suspicious packet or not.

Compared with the prior art, the invention has the advantages that the comparison process is automatic, the manual operation is replaced, and the efficiency is improved. The end result, while only reducing the JAR package, may improve performance. Meanwhile, the possibility of JAR packet collision is reduced to a certain extent.

In a specific implementation, in the embodiment of the present invention, the step S102 may be placed before the step S101, that is, the sequence of the step S101 and the step S102 is not limited in the present invention.

Optionally, as shown in fig. 4, an embodiment of the present invention discloses a method for determining whether a JAR package is referred to, where the method includes:

step S401, recording all packages and classes quoted by the source code, and establishing a corresponding relation between each class file and the quoted package path;

step S402, decompressing JAR packets, and establishing a corresponding relation between each JAR packet file and a packet path contained in the JAR packet file;

step S403, comparing whether the JAR package file contains any one of the packages referenced by the source code, if yes, the JAR package is a necessary package, otherwise, the JAR package is a suspicious package.

The embodiment of the invention preliminarily judges which packets are redundant by comparing the external packet classes quoted in the JAVA source file with the packet classes quoted in the JAR packet, thereby giving a proposal for deleting unnecessary packets to encoding personnel, not only slimming the source code program, but also avoiding the risks of packet collision and the like caused by improper introduction of the JAR packet and improving the safety of the program.

In the embodiment of the present invention, after decompressing the JAR packet, there may be the following two outputs:

establishing a corresponding relation between each JAR package file and a package path contained in the JAR package file;

and (II) establishing the corresponding relation between each package path in the JAR package file and the specific class contained in the JAR package file.

In the embodiment of the present invention, after recording all packets and classes cited by the source code, the following two outputs may be available:

establishing a corresponding relation between each class file and a referenced package path;

establishing a corresponding relation between each package path quoted by the source code and a specific class contained in the package path;

In implementation, if two JAR files are found to have the same package path (which is less likely to occur), the embodiment of the present invention needs to compare from the class level, that is, compare whether the JAR package file contains a specific class included in the package path referenced by the source code. As shown in fig. 2 and 3, for example: both test1.jar and test2.jar contain java.net packets after being decompressed and output, and thus test1.jar and test2.jar should be listed as pending. And continuing to start class level comparison, wherein whichever of the test1.jar and the test2.jar comprises the java.net.URI and the java.net.HttpURLConnection is the necessary package, and the other is the suspicious package.

According to the JAVA coding specification, all classes are referenced to external classes by import at the head, so that all lines with the head beginning with import can be read.

It should be noted that the embodiment of the present invention outputs only one suggestion that may not be cited, and is not a definite value. Sometimes the JAR package is not necessarily referenced in a class, possibly loaded after run; or may be referenced in a configuration file by a container (e.g., a container of a spring framework), neither of which can be missed; in addition, the JAR packages that are referenced are not directly referenced by source code developed by themselves, but there may be cyclic references between themselves. Therefore, the operation is not deleted without trade, and repeated testing is required.

Based on the same technical concept, the embodiment of the present invention further provides a device for determining whether the JAR package is referred to, where the device may execute the method embodiment, and since a principle of the device for solving the problem is similar to the method for determining whether the JAR package is referred to, the implementation of the device may refer to the implementation of the method.

As shown in fig. 5, an apparatus for determining whether a JAR package is referred to according to an embodiment of the present invention includes:

a JAR package decompressor 501, configured to decompress a JAR package, and establish a correspondence between each JAR package file and a package path included therein;

a source code reader 502, configured to record all packages and classes referred by source codes, and establish a correspondence between each class file and a referred package path;

and the comparator 503 is used for comparing whether any one of the packages referenced by the source code is contained in the JAR package file, if so, the JAR package is a necessary package, otherwise, the JAR package is a suspicious package.

Specifically, the JAR packet is also a compressed packet, and can be decompressed as well as the ZIP compressed packet. For example, a JAR file: jar, using command: jar, xf xxx. Jar, we see all the package structures and all the classes in the package as unwrapped. Therefore, only one JAVA runtime is needed to run JAR command generation.

The source code refers to the code class written by the developer, and the source code reader 502 is a simple recorder which records all the packages and classes referenced by the source code. For example, the source code: package com. mike, quotes 10 classes of three packages, java.

In most practical cases, the comparer 503 only needs to compare from this level of the package, i.e. to compare whether any of the packages referenced by the source code are contained in the JAR package file. For example: after a JAR package file test. JAR is output through the decompressor, as long as any one of java.io., java.net., and java.util.) is contained, the JAR package is a necessary package, otherwise, if any one of the test. JAR is not contained, the JAR package is classified as a suspicious package.

Further, the JAR packet decompressor 501 is further configured to:

In the embodiment of the present invention, the JAR packet decompressor 501 is configured to:

Further, the source code reader 502 is further configured to:

In this embodiment of the present invention, the source code reader 502 is configured to:

further, the comparator 503 is further configured to:

In implementation, in the embodiment of the present invention, if two JAR files are found to have the same package path (this is less the case), the comparator needs to compare from the class level, that is, compare whether the JAR package file contains a specific class included in the package path referenced by the source code. For example: both test1.jar and test2.jar contain java.net packets after being decompressed and output, and thus test1.jar and test2.jar should be listed as pending. And continuing to start class level comparison, wherein whichever of the test1.jar and the test2.jar comprises the java.net.URI and the java.net.HttpURLConnection is the necessary package, and the other is the suspicious package.

Further, all class references to external classes referenced by source code in the source code reader 502 are referenced at the head with import.

According to the embodiment of the invention, all classes are referenced to external classes by import at the head according to the JAVA coding specification, so that a source code reader only needs to read all lines with the head beginning with the import.

In summary, the present invention outputs the dependent packet path from its own source code, outputs the existing packet path from the JAR file, and finally compares the two paths to determine whether to list the JAR file as a suspicious packet. The embodiment of the invention preliminarily judges which packets are redundant by comparing the external packet classes quoted in the JAVA source file with the packet classes quoted in the JAR packet, thereby giving a proposal for a coder to delete unnecessary packets, not only slimming a source code program, but also avoiding the risks of packet collision and the like caused by improper introduction of the JAR packet and improving the safety of the program. The comparison process is automatic, manual operation is replaced, and efficiency is improved. The end result, while only reducing the JAR package, may improve performance. Meanwhile, the possibility of JAR packet collision is reduced to a certain extent.

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.

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 invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A method for judging whether a JAR package is referred to or not, which is characterized by comprising the following steps:

and comparing whether any one of the packages referenced by the source codes is contained in the JAR package file, if so, judging that the JAR package is a necessary package, otherwise, judging that the JAR package is an unnecessary package.

2. The method of claim 1, wherein after decompressing the JAR packet, further comprising:

3. The method of claim 2, wherein after recording all packages and classes referenced by the source code, further comprising:

4. The method according to claim 3, wherein if the package path of the decompressed JAR package file is consistent with the package path referenced by the source code, comparing whether the JAR package file contains the specific class contained in the package path referenced by the source code, if so, determining that the JAR package is a necessary package, otherwise, determining that the JAR package is a suspicious package.

5. The method of claim 1 or 4, wherein all class references to external classes referenced by the source code are referenced at a header by import.

6. An apparatus for determining whether a JAR package is referenced, the apparatus comprising:

7. The apparatus of claim 6, wherein the JAR packet decompressor is further configured to:

8. The apparatus of claim 7, wherein the source code reader is further configured to:

9. The apparatus of claim 8, wherein the comparator is further configured to:

10. The apparatus of claim 6 or 9, wherein all class references to external classes referenced by source code in the source code reader are referenced with import at the head.