Packaging a Java application #

Java (like C# or Python) is a precompiled language, meaning that source code is compiled into a machine-independent representation called bytecode.

Bytecode can be distributed and executed on any machine.

In Java, by convention, a source file MyClass.java is compiled into a bytecode file MyClass.class.

A Java Virtual Machine (JVM) is a program in charge of executing Java bytecode.

A packaged Java program is usually a zip file that contains:

• bytecode,
• metadata,

and possibly:

• dependencies,
• other resources (data, images, etc.).

Jar file #

A jar (for Java ARchive) file is a zip file with extension .jar. This is the most common packaging format for Java applications.

A jar can be:

• a thin jar (i.e. excluding dependencies) or a fat (a.k.a. über) jar (i.e. including dependencies),
• runnable or non-runnable.

A jar contains a text file META-INF/MANIFEST.MF that provides metadata about the package, as a set of key: value pairs (one per line). Among others, it may contain:

• the name, version and author(s) of the program,
• the entry point of the program (i.e. the class that contains the main method),
• paths to additional .class files that are part of the program,
• etc.

Details can be found here.

Note. A jar for an application (including the META-INF/MANIFEST.MF file) is usually created via a build automation tool (like Maven or Gradle).

But if you are curious, you can also build a (toy) jar via command line. A good illustration can be found on the website of the 22-23 course.

Note. Unit tests (and test-related resources) are usually not included in the release of a program. Therefore in Java, these are generally absent from a jar.