EMMA is a tool for measuring coverage of Java software. It helps teams detect dead code and verify what parts of an application are actually exercised by test suites or interactive usage. This guide focuses on practical setup and deployment patterns from the original EMMA overview, especially for J2EE-style environments.
Originally published on 2013-05-17; fully revised and updated.
What EMMA is designed to do
The original EMMA design goals emphasized fast iterative development while still producing rich coverage information. In practical terms, teams used EMMA to keep coverage checks lightweight enough for frequent local and CI usage.
- Measure code coverage for Java applications.
- Highlight unexercised code paths and potential dead code.
- Keep build-time and runtime overhead low enough for frequent feedback loops.
- Support both small standalone applications and larger enterprise codebases.
Installation options for command-line usage
The original article describes two primary ways to make EMMA available from the command line.
| Method | How it works | When teams used it | Trade-off |
|---|---|---|---|
| JRE extension | Copy emma.jar into the JRE lib/ext directory used by your command-line Java runtime. | Convenient for repeated local use. | Introduces a third-party JAR as a global runtime extension. |
| Explicit classpath | Pass emma.jar in each EMMA Java invocation. | Safer when you do not want global JRE modification. | Slightly more verbose command lines. |
# Explicit classpath invocation pattern
java -cp /path/to/emma.jar emma [tool-arguments]
java -cp /path/to/emma.jar emmarun [run-arguments]Code language: PHP (php)On-the-fly vs offline instrumentation
The source distinguishes two usage modes. For many J2EE servers, offline instrumentation is the more reliable approach because of container-specific class loading behavior.
| Mode | Best suited for | Instrumentation timing | Notes from the original guidance |
|---|---|---|---|
| On-the-fly | Standalone applications | During runtime loading | Can be harder in some J2EE environments because class loading may bypass EMMA expectations. |
| Offline | J2EE framework-based applications | After compile, before packaging/deployment | Recommended sequence is compile, instrument, package, deploy, run tests, collect coverage, generate report. |
Offline instrumentation workflow for J2EE deployments
For app servers such as WebLogic, WebSphere, Tomcat, or JBoss, the article recommends offline instrumentation to avoid class loader mismatches and missing reports.
flowchart TD
A[Compile Java classes] --> B[Instrument classes or jars with EMMA instr]
B --> C[Package artifacts war ear jar]
C --> D[Deploy to application server]
D --> E[Run tests or interactive flows]
E --> F[Request coverage dump with ctl coverage.get]
F --> G[Generate coverage report]
- Instrument target classes as a post-compilation step, or instrument JARs directly.
- Package your application normally, but do not include emma.jar inside WAR/EAR application libraries.
- Place emma.jar in the container JRE extension path, or add it to the server classpath using server-specific configuration.
- Deploy the instrumented artifacts and exercise the application through test cases or interactive usage.
- Collect a coverage dump; the source recommends using the coverage.get control command via the ctl tool.
# Example pattern for offline instrumentation
java -cp /path/to/emma.jar emma instr -ip build/classes -outmode fullcopy -d build/instrumented
# After deploying and running tests, request a coverage dump
java -cp /path/to/emma.jar emma ctl [connection-options] coverage.getCode language: PHP (php)References and related integration pointers
Original reference links from the source post:
- http://emma.sourceforge.net/faq.html#q.runtime.appservers
- http://emma.sourceforge.net/reference/ch02s03.html#tool-ref.instr.outmodes
- http://primates.ximian.com/~flucifredi/emma-HOWTO.html
- http://groovy.329449.n5.nabble.com/EMMA-Code-Coverage-has-problem-with-Groovy-classes-td360560.html
The original post also mentions EMMA integration topics for Sonar, Hudson, and CruiseControl.
Common pitfalls and best practices
- Prefer offline instrumentation for complex J2EE containers where class loading is not straightforward.
- Keep instrumentation as an explicit build step so coverage behavior is reproducible.
- Avoid bundling emma.jar inside application-level WAR/EAR libs when following the server-level setup model described in the source.
- Use a consistent coverage collection step (for example, coverage.get) in your test pipeline.
- Validate old external documentation links and command arguments against your exact EMMA version before automating.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals
