Introduction

In IntelliJ IDEA, creating a JAR is usually an artifact configuration problem rather than a one-click export wizard. The workflow is different from Eclipse, but once you understand artifacts, manifest entries, and dependencies, packaging a runnable JAR is straightforward.

Understand What IntelliJ Is Building

A JAR is just a zip-like archive of compiled classes and resources. A runnable JAR also needs a manifest entry that points to the class containing main.

Here is a minimal Java program you can package:

1public class HelloApp {
2    public static void main(String[] args) {
3        System.out.println("Hello from a JAR");
4    }
5}

If IntelliJ compiles this class but the manifest does not declare HelloApp as the main class, java -jar will fail even though the build succeeded.

Create a JAR Artifact in IntelliJ

The closest IntelliJ equivalent to Eclipse export is an artifact.

1. Open File and then Project Structure.
2. Select Artifacts.
3. Click +, then choose JAR, then From modules with dependencies.
4. Pick the module that contains your entry point.
5. Select the main class.
6. Choose how to handle libraries.

The dependency choice matters:

• 'extract to the target JAR creates a single larger JAR by unpacking dependencies'
• 'copy to the output directory and link via manifest keeps dependency JAR files beside your main JAR'

If you want one distributable file, a fat JAR is often easier. If you want smaller and clearer outputs, separate dependency JAR files are acceptable.

After saving the artifact configuration, build it from Build, then Build Artifacts, then select your artifact and choose Build.

Verify the Result Outside the IDE

Do not stop after IntelliJ says the build succeeded. Run the file the same way a user or deployment system will run it.

cd out/artifacts/HelloApp_jar
java -jar HelloApp.jar

If the JAR is correctly packaged, you should see:

Hello from a JAR

That external check catches the two most common packaging errors: missing manifest configuration and missing dependencies.

When to Prefer Gradle or Maven

IntelliJ artifacts are useful for quick manual packaging, but they should not become the long-term build source of truth for a serious project. If the project already uses Gradle or Maven, define packaging there and let IntelliJ invoke the build.

For example, a simple Gradle application plugin setup can build a runnable distribution consistently on any machine:

1plugins {
2    id 'application'
3}
4
5application {
6    mainClass = 'HelloApp'
7}

Then build with:

./gradlew build

The advantage is reproducibility. A teammate, CI job, or release pipeline can produce the same output without opening IntelliJ and clicking through dialogs.

Choosing Between Plain and Fat JARs

A plain JAR contains your classes only. It is fine when your program has no external libraries or when you are happy to ship additional dependency files next to it.

A fat JAR includes your dependencies in one archive. That is easier to distribute, but it can hide version conflicts or create larger files than necessary. For desktop tools and simple command-line apps, fat JARs are often the least painful option.

For server applications, it is usually better to rely on the project build tool and deployment process rather than ad hoc IDE packaging.

Common Pitfalls

The biggest pitfall is forgetting to choose the main class. IntelliJ will happily build a JAR that cannot be started with java -jar.

Another common problem is assuming compiled code implies bundled dependencies. It does not. Your app may run inside the IDE because IntelliJ manages the classpath, then fail outside the IDE because required libraries were never packaged.

A third problem is editing artifact settings by hand while also using Gradle or Maven. That splits packaging logic across two systems. If the project already has a build tool, keep packaging there unless you have a very specific reason not to.

Summary

• IntelliJ uses artifacts instead of an Eclipse-style export wizard.
• A runnable JAR needs both compiled classes and a manifest with the correct main class.
• Dependency handling determines whether you get a plain JAR, a fat JAR, or a JAR plus separate libraries.
• Always test the result with java -jar outside IntelliJ.
• For repeatable team builds, prefer Gradle or Maven over IDE-only packaging.