Skip to content

ASSERT-KTH/jdbl

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

JDBL DepTrim logo

build Maven Central Quality Gate Status Maintainability Rating Reliability Rating Security Rating Vulnerabilities Bugs Code Smells Lines of Code Duplicated Lines (%) Technical Debt codecov

What is JDBL?

JDBL is a Java DeBLoat tool. With JDBL, developers can automatically specialize Java libraries at build-time through dynamic debloating. JDBL executes the library and removes the methods, classes, and dependencies that are not needed to provide the expected output. The result is a smaller bundled file (e.g., JAR or WAR), which is tailored to the specific needs of the client. Using JDBL is great because it saves space on disk, reduces the attack surface, and improves performance of the client application. JDBL can be used as a Maven plugin (see usage), with minimal or zero configuration effort.

How does JDBL work?

JDBL is executed before the package phase of the Maven build lifecycle. First, JDBL compiles and instruments the bytecodes of the application and its dependencies. Then, JDBL collects accurate coverage information by executing the application based on a given workload. All the API members (e.g., classes and methods) used during the execution are collected at runtime. For more details about the coverage technique employed by JDBL read this blog post. JDBL removes the rest of unused API members through bytecode transformations using the ASM library. Finally, the debloated application is validated through the Maven package phase and it is bundled as a JAR or WAR file.

NOTE: JDBL produces a smaller, debloated version of the Java application without modifying its source code. The modified version is automatically packaged as a JAR file as resulting from the Maven build lifecycle.

Why is JDBL different?

Existing debloating tools for Java (e.g., Proguard) are rather conservative when removing API members because they rely on static analysis. In contrast, JDBL takes advantage of dynamic analysis to shrink all the bytecode that is not used during a particular execution trace. This way, JDBL outperforms competitors by removing more unnecessary while keeping the desired functionality. JDBL is fully automatic; no configuration is required.

Usage

To use JDBL as a Maven plugin, first clone this repository and run mvn clean install. Then, add the plugin to the pom.xml of the Maven project to be debloated:

<plugin>
    <groupId>se.kth.castor</groupId>
    <artifactId>jdbl-maven-plugin</artifactId>
    <version>1.0.0</version>
    <executions>
        <execution>
            <goals>
                <goal>${strategy}</goal>
            </goals>
        </execution>
    </executions>
</plugin>

The property ${strategy} can take one of the two following values, depending on the debloating strategy adopted:

  • test-based-debloat Removes the API members that are not covered by the test suite of the Maven project.
  • entry-point-debloat Removes the API members that are used after compiling and executing the Maven project from a given entry-point.

Optional parameters

In the case of the entry-point strategy, the following additional configuration parameters can be provided:

Name Type Description
<entryClass> <String> Fully qualified name of the class used as the entry point of the application. Typical value is: Main.
<entryMethod> <String> Fully qualified name of the method in the <entryClass> used as the entry point of the application. Typical value is: main./
<entryParameters> Set<String> Parameters of the <entryMethod> used provided. Only string values separated by commas are permitted.
<skipJDBL> boolean Skip plugin execution completely. Default value is: false.

License

JDBL is distributed under the MIT License. See LICENSE for more information.

Funding

JDBL is partially funded by the Wallenberg Autonomous Systems and Software Program (WASP).

Wallenberg Autonomous Systems and Software Program (WASP)