Eclipse Jifa turns a heap dump into a browser tab

Four JVM diagnostic file formats, one web frontend

Jifa is an online analyzer for four kinds of JVM diagnostic output: heap dumps, GC logs, thread dumps and JFR recordings. The problem it addresses is unglamorous and very real. When a Java service degrades, the evidence is a file, and the file formats are proprietary enough that most people cannot read them without a specific tool. A heap dump in particular can be hundreds of megabytes of binary data that only a dedicated parser will open. Jifa's approach is to make those files viewable in a browser tab instead of a desktop profiler, which suits two situations well. The first is the on-call engineer on someone else's machine who needs a quick read rather than a profiling session. The second is a reviewer who wants to share a finding with colleagues, since a URL and a screenshot travel better than a proprietary project file. The project is hosted by the Eclipse Foundation, is published under the Eclipse Public License 2.0, and maintains a Chinese version of the readme alongside the English one. Documentation beyond the readme lives on GitHub Pages, and a public playground instance is also linked.

The Docker quick start is a one-liner shell script

Running Jifa locally is documented as a short shell script that fetches and runs a container. The default service address is port 8102, and the script accepts a port override, a list of local files to analyze, and JVM options for the analyzer itself:

# Default service address is at http://localhost:8102
curl -fsSL https://raw.githubusercontent.com/eclipse/jifa/main/jifa.sh | bash

# Change the server port
curl -fsSL https://raw.githubusercontent.com/eclipse/jifa/main/jifa.sh | bash -s -- -p <port>

# Analyze local files
curl -fsSL https://raw.githubusercontent.com/eclipse/jifa/main/jifa.sh | bash -s -- <file1 path> <file2 path> ...

# Set JVM Options
curl -fsSL https://raw.githubusercontent.com/eclipse/jifa/main/jifa.sh | bash -s -- --jvm-options "<JVM options>"

The file arguments are the interesting part, because they turn the tool from a browser application into a batch one. Pointing the script at a heap dump path opens that dump in the running analyzer instead of making you upload it somewhere. Docker has to be installed first, which the readme states plainly. Note that the script is fetched over the network and piped straight into a shell, which is a reasonable convenience for a developer tool and a habit worth thinking about on a locked-down workstation. If you want the analyzer without a container, the jpackage route packages it as a stand-alone binary installation using the jpackage command from Java 14 and above, through the jifa-jpackage.sh or jifa-jpackage.bat script in the repository root.

A two stage container build with a deliberately small runtime image

The Dockerfile in the repository root explains the runtime shape more clearly than the readme does. The build stage starts from node:18, installs openjdk-17-jdk, copies the whole tree, and runs the Gradle wrapper to build the project while skipping tests. The interesting step is the unpacking: the jifa.jar is extracted into a dependency directory so that the BOOT-INF/lib, META-INF and BOOT-INF/classes directories can be copied separately into the final image. The runtime stage is eclipse-temurin:17-jdk, which means the analyzer itself runs on Java 17 regardless of the Node toolchain used to build the frontend. The entry point is a plain classpath launch rather than a fat jar:

EXPOSE 8102
ENTRYPOINT ["java","--add-opens=java.base/java.lang=ALL-UNNAMED","--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED","-Djdk.util.zip.disableZip64ExtraFieldValidation=true","-cp","jifa:jifa/lib/*","org.eclipse.jifa.server.Launcher"]

Three flags in that line are worth noticing. The two --add-opens entries relax module access so the analyzer can reflect into the JDK internals it needs for parsing, and the zip flag relaxes validation of the zip64 extra field, which large heap dumps can trigger. Both are the kind of detail that explains why the tool works on big files and would otherwise be invisible to a user.

A Gradle multi-module layout with a separate frontend

The repository is a Gradle build with a settings file and a version file, and the top level directories map onto the runtime pieces. The server directory holds the backend that reads the diagnostic files and serves the analysis. The frontend directory is the browser interface, built with Node in the container, which is why node:18 appears in the build stage. The analysis directory holds the parsing and analysis code, the common directory holds shared pieces, and package holds the packaging configuration. The site directory is the documentation that is published to GitHub Pages. There is a jifa.gradle file for the project specific build logic and a license_helper.pl, plus a NOTICE file and an EPL-2.0 LICENSE at the root, with a check workflow for commits. The build script skips tests in the container, so the image is not a verified build in the strict sense; the commit check workflow is where the test coverage lives. For a reader deciding whether the tool can be extended, this layout says the parsing logic and the web layer are separable, which is the structure you would want if you needed to add a file format.

What the licensing and release history imply about commitment

Jifa is published under the Eclipse Public License 2.0, the same terms the readme's own header comment reproduces, and the SPDX identifier appears alongside the copyright notice. EPL-2.0 is a file level copyleft licence, and third party components bundled into the distribution keep their own terms, which the NOTICE file is there to record. No interpretation of that is offered here beyond noting that the licence and the notice file are the two documents to read before embedding the tool in a product. The maintenance picture is mixed and worth stating plainly. The last push to the repository was on 2026-07-28, which is inside a six month window from today, so the code is moving. The release history is thinner: there is a single tagged release, v0.2.0, dated 2023-10-24, with the name Release v0.2.0. A project with one tag from three years ago and commits landing more recently is a project where the main branch is the interesting artifact and the tagged release is not a reliable upgrade target. The version is also kept in a plain version file at the repository root, so it can be read by tooling rather than only by a human.

Where Jifa stops, and what it is the wrong tool for

Several limits come directly from the design. There is no documented command line that emits analysis as JSON or any other machine readable format; the output is a web interface, so scripted use means scraping a UI, and the readme does not document an API. The analyzer holds the file it is given on the machine where it runs, which is a genuine advantage over an upload service, but it is still a server listening on a port with no authentication described anywhere in the documentation, so binding it beyond localhost deserves thought. Analysis of a large heap dump is a memory problem: the analyzer needs heap of its own, which is what the --jvm-options flag in the startup script exists for. And the tool reads files, it does not attach to a running JVM, so it cannot tell you what is happening right now, only what happened when the dump was taken. If your question is live JVM behaviour, this is the wrong tool. If your question is what a captured file contains, it is the right one.

Editorial conclusion

Eclipse Jifa fits an on-call engineer or a JVM performance reviewer who has a heap dump, a GC log or a thread dump on disk and wants a readable answer in the browser without installing a desktop profiler. It does not fit a pipeline that needs machine readable output, a team that cannot run Docker, or an environment where dumps may not leave the machine, because the whole application is a web backend and a frontend that you run yourself. Verify first that the JDK version of your target process matches what the analyzer expects, that port 8102 is free, and that the analyzer's own JVM has enough heap for the dump you intend to open. The last push was on 2026-07-28 and the only tagged release is v0.2.0 from 2023-10-24.

Frequently asked questions

Official sources

1. eclipse-jifa/jifa on GitHub
2. License: EPL-2.0
3. Project website
4. README
5. Releases