Incremental Updates of JAR Files via Command Line on Linux/Windows Servers

Excluding traditional WAR package deployment, and focusing on the currently commonly used JAR packages, there are roughly three scenarios for updating services on the server:

Scenario 1: Incremental updates of certain class files in the JAR package.
Scenario 2: Executable JAR packages and lib dependency packages are packaged separately, requiring incremental upgrades of certain lib dependency packages.
Scenario 3: Updating dependency JARs in a fat JAR package or class files in the JAR package (Spring Boot defaults to packaging a fat JAR, which bundles all dependencies and source packages into one JAR). When only a small amount of code has changed, updating the service is very unfriendly, as a full update requires transferring a very large JAR package.

Now, let’s take examples of how to use the command line to update for these three scenarios. Please ensure that the Java environment variables are configured on the server or locally, and that the jar command can be found normally.

Scenario 1

Incremental updates of certain class files in the JAR package.

Extract the filetype.properties configuration file from the JAR package, modify the configuration information, and then update it back; for incremental updates of the top/wys/utils/ClassUtils.class file, you can first use the vim command to check the file path in the JAR package before extraction.

Start Extraction

# Only extract the required files, no need to extract the entire JAR jar xvf ZmlTools-1.4.2.jar top/wys/utils/ClassUtils.class filetype.properties

Command Breakdown

Let’s break down this command into several parts:

jar: This is the name of the command, representing the Java Archive Tool. It is used to create and manage .jar files. JAR files are essentially ZIP format compressed files used to package Java class files, metadata, and resources (such as images, configuration files, etc.).
xvf: This is a set of options passed to the jar command, which together define the operation to be performed. The order of the options is usually not important, but they must follow the jar command.

x: Represents “extract”. This is the main operation to be performed by the command, which is to extract files from the archive.
v: Represents “verbose”. Using this option will display detailed operations in standard output (usually your terminal), such as which files are being extracted, their names, and sizes.
f: Represents “file”. This option tells the jar command that the name of the archive file to be operated on is specified on the command line (in this case, ZmlTools-1.4.2.jar). If the f option is not used, the jar command will attempt to read the archive content from standard input.

ZmlTools-1.4.2.jar: This is the name of the target JAR file to perform the extraction operation.

top/wys/utils/ClassUtils.class and filetype.properties: These are two space-separated file path parameters. They specify the specific files to be extracted from the ZmlTools-1.4.2.jar file.

jar command allows you to specify one or more files for extraction.
If no files are specified here, the jar command will default to extracting all files in the JAR package.

Command Execution Process

When you execute this command in the terminal, the following occurs:

jar tool will open the archive file named ZmlTools-1.4.2.jar.
It will look for the files top/wys/utils/ClassUtils.class and filetype.properties in the archive file.
Once the files are found, the jar tool will extract and copy them to your current directory.
For files with paths (like top/wys/utils/ClassUtils.class), the jar command will create the corresponding folder structure in the current directory (i.e., top/wys/utils/), and then place the ClassUtils.class file inside it.
Since the v option was used, during the extraction process, the terminal will print out information similar to the following, informing you of the detailed progress of the operation:
```
created: top/created: top/wys/created: top/wys/utils/inflated: top/wys/utils/ClassUtils.classinflated: filetype.properties
```

After the operation is completed, the original ZmlTools-1.4.2.jar file remains unchanged.

Sample Screenshot

This is an operation screenshot under Windows, which can be operated directly on the server without downloading the JAR package to the local machine.

image.png

Start Compressing Updates

After modifications are completed, compress the files back into the JAR package.

jar uvf ZmlTools-1.4.2.jar top/wys/utils/ClassUtils.class filetype.properties

image.png

Command Breakdown

Let’s break down each part of the command:

jar: This is still the command for the Java Archive Tool.
uvf: This is a set of options passed to the jar command. The key here is u.

u: Represents “update”. This is the main operation to be performed by this command. It will add new files to the specified archive file or replace existing files with the same name in the archive.
v: Represents “verbose”. Using this option will display detailed operations in the terminal, such as “adding: top/wys/utils/ClassUtils.class”, allowing you to clearly see which files have been added or updated.
f: Represents “file”. This option tells the jar command that the name of the archive file to be operated on is specified on the command line (i.e., ZmlTools-1.4.2.jar).

ZmlTools-1.4.2.jar: This is the name of the target JAR file that is being updated. This file must already exist.

top/wys/utils/ClassUtils.class and filetype.properties: These two parameters specify the source files used for the update. These files must exist in your current directory when executing the command.

Command Execution Process

When you execute this command, the following occurs:

jar tool will open the archive file named ZmlTools-1.4.2.jar for modification.
It will look for the source files top/wys/utils/ClassUtils.class and filetype.properties in your current local file system.

Important Note:jar tool expects to find a folder named top in the current directory, which contains a wys folder, which in turn contains a utils folder, ultimately containing the ClassUtils.class file. It also expects to find the filetype.properties file in the current directory.

For each specified source file, the jar tool will perform the following checks:

If the local source file is updated (timestamp is later), the jar tool will replace the old file in the JAR package with the local file.
If the local source file is not updated (timestamp is the same or earlier), the jar tool will skip this file and perform no operation.

If a file with the same name does not exist in the JAR package: The jar tool will directly add this new file to the JAR package while maintaining its directory structure.
If a file with the same name already exists in the JAR package: The jar tool will compare the modification timestamps of the local source file and the file in the JAR package.

This update operation is performed directly on the original ZmlTools-1.4.2.jar file, modifying this file.

Since the v option was used, during the update process, the terminal will print a list of files that were added or replaced.

Core Differences

Command	`<span>jar xvf ...</span>`	`<span>jar uvf ...</span>`
Operation	Extract	Update
Data Flow	From JAR package -> To local file system	From local file system -> To JAR package
Impact on JAR package	No modification to the original JAR package	Direct modification of the original JAR package

Scenario 2

Packaging method uses a separation of dependency lib packages and executable source JAR packages.

Tomcat has a vulnerability, and its dependencies need to be upgraded.

1. Copy the upgraded JAR packages

Copy the three Tomcat JAR packages from the lib directory to the corresponding service lib directory, back up the original lower version JAR packages, and then delete them.

# Enter the lib directory and back up tar -zcvf tomcat-20240416-bak.tar.gz tomcat-*.jar # Move the backup file to the parent directory mv tomcat-20240416-bak.tar.gz ../ # Remove lower version JAR packages rm -rf tomcat-*.jar # Manually place the higher version JAR packages

image.png

2. Modify the version number of the dependent JAR packages

Update the version number of Tomcat in the original running JAR package’s MANIFEST.MF file to 9.0.87

Taking flowCharge as an example:

Extract the MANIFEST.MF file from the JAR package.

# jar xvf xxx.jar META-INF/MANIFEST.MF extracts the MANIFEST.MF file from the META-INF directory of xxx.jar to the current directory, maintaining the extracted file directory as META-INF/MANIFEST.MF jar xvf fee-0.0.1-SNAPSHOT.jar META-INF/MANIFEST.MF

Edit the META-INF/MANIFEST.MF file using vim, changing the version numbers of the three Tomcat JAR packages: tomcat-annotations-api, tomcat-embed-core, tomcat-embed-websocket to 9.0.87, then save and exit!

Update the META-INF/MANIFEST.MF file back into the original JAR package.

# 1️⃣ Before updating, back up the original JAR package (name the compressed package as you like) tar -zcvf fee-0.0.1-SNAPSHOT.jar-202404161452-bak.tar.gz fee-0.0.1-SNAPSHOT.jar # 2️⃣ Update the MANIFEST.MF file into the JAR package # Command example: jar uvfm xxx.jar META-INF/MANIFEST.MF # Note: When updating general files into a JAR package, use the uvf parameters. The reason for adding the m parameter here is that MANIFEST.MF is an archive file jar uvfm fee-0.0.1-SNAPSHOT.jar META-INF/MANIFEST.MF

Command Breakdown

Let’s break down each part of the command:

jar: This is still the command for the Java Archive Tool.
uvfm: This is a set of options passed to the jar command.

u: Represents “update”. Indicates that an update operation is to be performed on the specified JAR package.
v: Represents “verbose”. When executing the command, detailed operation information will be printed in the terminal.
f: Represents “file”. Indicates that the name of the JAR package to be operated on is specified on the command line (i.e., fee-0.0.1-SNAPSHOT.jar).
m: Represents “manifest”. This is a very critical option. It tells the jar command that you will provide an external manifest file, the contents of which will be used to create or overwrite the internal META-INF/MANIFEST.MF file of the JAR package.

Order of Parameters (Very Important) When the m option is used, the jar command has strict requirements on the order of subsequent parameters:jar <options> <target jar file name> <source manifest file name> [other files to add...]

So in this command:

fee-0.0.1-SNAPSHOT.jar is the target JAR file being updated.
META-INF/MANIFEST.MF is the external manifest file used as source data.

Command Execution Process

jar tool will prepare to update the archive file named fee-0.0.1-SNAPSHOT.jar.
Due to the presence of the m option, the jar tool will recognize the parameter immediately following the JAR file name (i.e., META-INF/MANIFEST.MF) as the path to the source manifest file.
jar tool will look for the file named META-INF/MANIFEST.MF in your current working directory. This means that there must be a META-INF folder in your current directory, containing a MANIFEST.MF file.
jar tool will read the contents of this external MANIFEST.MF file.
Then, it will open the fee-0.0.1-SNAPSHOT.jar file and completely replace the original internal META-INF/MANIFEST.MF file with the contents of the external manifest file just read.
This operation is directly modifyingfee-0.0.1-SNAPSHOT.jar file itself.
Since the v option was used, the terminal will print information similar to “adding: META-INF/MANIFEST.MF” to confirm that the operation has been executed.

3. Verify that the MANIFEST.MF file in the JAR package has been successfully updated

vim fee-0.0.1-SNAPSHOT.jar # Move the cursor to the line where MANIFEST.MF is located, press the ENTER key to enter the MANIFEST.MF file, and confirm that the version number has been successfully modified.

Scenario 3

Updating dependency JARs in a fat JAR package.

This uses the default packaging method of Spring Boot. To upgrade the Tomcat version in the JAR package, you cannot directly delete files within the JAR package; you need to extract it first and then repackage it.

1. Backup and Extract

# Backup the original JAR package tar -zcvf log-0.0.1.jar-202404161511-bak.tar.gz log-0.0.1.jar # Create a temporary directory and move the log-0.0.1.jar file to that directory for processing, avoiding unnecessary impacts from other configuration files in the same directory during subsequent packaging mkdir tmp mv log-0.0.1.jar tmp cd tmp jar xvf log-0.0.1.jar # Enter the lib directory and delete the old dependency packages cd BOOT-INF/lib rm tomcat-embed-* # Place the upgraded JAR packages in this directory # Confirm that the new packages have been placed in this directory ll|grep tomcat-

image.png

# Switch back to the tmp directory and start preparing to repackage cd ../../

image.png

2. Repackage the JAR

# Use store mode to repackage # 0 indicates to the jar command to package files in store mode instead of the default deflate compression mode # You can also specify the original MANIFEST.MF file for packaging jar cfm0 log-0.0.1.jar META-INF/MANIFEST.MF ./ jar cfM0 log-0.0.1.jar ./ # Move log-0.0.1.jar back to the original directory mv log-0.0.1.jar ../

jar cfM0 log-0.0.1.jar ./ This command’s function is: Create a new, completely uncompressed JAR file named log-0.0.1.jar, which contains all files and subdirectories in the current directory, and does not automatically generate a manifest file (MANIFEST.MF).

Command Breakdown

jar: This is the command for the Java Archive Tool.
cfM0: This is a combination of options that defines the specific operations to be performed by the jar command.

c: Represents “create”. Indicates that a new archive file is to be created.
f: Represents “file”. Indicates that the name of the archive file to be created is specified on the command line (i.e., log-0.0.1.jar).
M: Represents “no-manifest”. This is a key option. By default, the jar command automatically generates a META-INF/MANIFEST.MF manifest file when creating an archive. Using the M option can prevent this behavior.
0 (zero): Represents “store only; do not use ZIP compression”. This is another key option. By default, JAR files are compressed using the ZIP algorithm to reduce file size. Using the 0 option tells the jar tool to completely disable compression, simply storing the files as they are in the archive.

log-0.0.1.jar: This is the name of the JAR file to be created.
./: This specifies the source of the content to be added to the JAR package.

. represents the current directory.
./ is an explicit representation of the current directory.
This parameter tells the jar command: “Package all files and subdirectories (recursively) in the current directory.”

In-depth Analysis of Key Options `M` and `0`

Why use `M` (do not create Manifest)?

META-INF/MANIFEST.MF file is the metadata center of the JAR package, containing version information, creator information, and most importantly, the Main-Class attribute (used to make the JAR executable). You may not want to create it in the following cases:

Creating library files: If you are packaging a library that is not a standalone executable program but is referenced by other applications, then it does not need a Main-Class, and the manifest file is not necessary.
Custom Manifest: You may plan to manually add a more detailed MANIFEST.MF file later.
Packaging non-Java content: Although uncommon, the jar tool is essentially a ZIP tool, and you may just use it to archive some non-Java resources, in which case the manifest file is meaningless.

Why use `0` (do not compress)?

Disabling compression may seem counterintuitive, as we usually want files to be as small as possible. However, in certain specific scenarios, not compressing can be advantageous:

Performance and Speed:

Packaging Speed: Not compressing makes the packaging process very fast, as the CPU does not need to perform compute-intensive compression operations.
Reading Speed: Some application servers or class loaders can read files directly from the JAR package. If the files are not compressed, the decompression step can be skipped, potentially speeding up class loading.

Content Already Compressed: If the content you are packaging is already in a compressed format (e.g., .jpg, .png, .mp3, .zip files), compressing them again will hardly reduce the size and will waste CPU resources. In this case, disabling compression is a wise choice.

Summary of Execution Process

When you run the jar cfM0 log-0.0.1.jar ./ command:

jar tool prepares to create a new file named log-0.0.1.jar.
It begins to recursively scan all content in the current directory (./).
It directly stores every scanned file and directory structure into log-0.0.1.jar, without any compression.
Throughout the process, it will not createMETA-INF/ directory and MANIFEST.MF file.
Ultimately, you get an archive package that may be larger (due to no compression) but created very quickly and does not contain a manifest file.

Incremental Updates of JAR Files via Command Line on Linux/Windows Servers

Scenario 1

Start Extraction

Command Breakdown

Command Execution Process

Sample Screenshot

Start Compressing Updates

Command Breakdown

Command Execution Process

Core Differences

Scenario 2

1. Copy the upgraded JAR packages

2. Modify the version number of the dependent JAR packages

Command Breakdown

Command Execution Process

3. Verify that the MANIFEST.MF file in the JAR package has been successfully updated

Scenario 3

1. Backup and Extract

2. Repackage the JAR

Command Breakdown

In-depth Analysis of Key Options `<span>M</span>` and `<span>0</span>`

Why use `<span>M</span>` (do not create Manifest)?

Why use `<span>0</span>` (do not compress)?

Summary of Execution Process

Leave a Comment Cancel reply

Scenario 1

Start Extraction

Command Breakdown

Command Execution Process

Sample Screenshot

Start Compressing Updates

Command Breakdown

Command Execution Process

Core Differences

Scenario 2

1. Copy the upgraded JAR packages

2. Modify the version number of the dependent JAR packages

Command Breakdown

Command Execution Process

3. Verify that the MANIFEST.MF file in the JAR package has been successfully updated

Scenario 3

1. Backup and Extract

2. Repackage the JAR

Command Breakdown

In-depth Analysis of Key Options <span>M</span> and <span>0</span>

Why use <span>M</span> (do not create Manifest)?

Why use <span>0</span> (do not compress)?

Summary of Execution Process

Related posts

Leave a Comment Cancel reply

In-depth Analysis of Key Options `<span>M</span>` and `<span>0</span>`

Why use `<span>M</span>` (do not create Manifest)?

Why use `<span>0</span>` (do not compress)?