JavaMelody: twenty years of application monitoring as a Maven dependency

A README that is almost entirely links, and what that means

The README states one sentence of purpose: the goal is to monitor Java or Java EE applications in QA and production environments. Everything after that is a link. Project home, screenshots showing charts, a user guide and release notes all live in the GitHub wiki, with downloads on the releases page, discussion on issues and pull requests.

That is a deliberate division of labour and it has a practical consequence. Nothing about configuration, the report URL, retention or agent setup is in the repository, so you cannot resolve an operational question from a clone alone. The badges do tell you what to check: the Maven Central version for `net.bull.javamelody/javamelody-core`, a build status for the Maven workflow, and a percentage-of-issues-still-open badge from isitmaintained.com, which is a blunt instrument but an honest one for a project of this age.

The license is Apache-2.0, stated in the README and in the LICENSE file, which matters more than usual here because you are likely to ship this inside a commercial application.

Eleven modules that describe the architecture

The module list is the most informative thing in the repository. `javamelody-core` is the agent, the artifact most integrations depend on. `javamelody-collector-server` is the optional aggregation server, published as a WAR and described in the release notes as not needed in most use cases, which is the single most useful sentence about it.

Then there is a pair that matters for Spring users: `javamelody-spring-boot-starter` and `javamelody-spring-boot4-starter`, the latter for Spring Boot 4. Having a separate starter per Spring generation is itself a sign of the project's staying power, and it is also a maintenance obligation.

The rest covers the deployment shapes. `javamelody-for-standalone` instruments a non-web Java application, `javamelody-swing` is a desktop monitoring client, and `javamelody-offline-viewer` reads reports without connecting to a server. `javamelody-for-spring-boot` sits alongside the starters, and `javamelody-objectfactory` exists so the agent can be woven into objects for which bytecode advice is awkward. `javamelody-demo-webapp` and `javamelody-test-webapp` are there for development.

Incidentally, `.project`, `.settings/` and `javamelody-release.cmd` show an Eclipse-based build and a Windows release script, which is what a project built incrementally over two decades looks like on disk.

Version numbering that jumped from 1.99 to 2.7

The release history is more informative than it first appears. `javamelody-core-1.99.4` was published on 2025-12-16, followed by `javamelody-core-2.7.0` on 2026-04-26 and `javamelody-core-2.8.0` on 2026-05-24. Nothing was published as 2.0 through 2.6 in this repository, so the numbering does not describe a simple linear progression from the outside.

What the older release attachment shows is the distribution shape. Alongside the agent jar for integration into a webapp there is a separate WAR for the collect server, and then a plugin list: Atlassian products covering JIRA, Confluence, Bamboo and Bitbucket, Jenkins, Liferay, Alfresco, Sonar and Grails. That list is a decent map of where JavaMelody tends to be deployed, from build pipelines to document repositories to content management systems.

Each release note points installation back to the wiki's dependencies section rather than inlining a long procedure, and version-specific notes are the reason the current releases mention a distinct starter per Spring Boot generation. The last push was 2026-09-21, with 3040 stars on an Apache-2.0 Java project.

Who this fits, and who should look elsewhere

There is a clear case. If you have a Java or Java EE application in QA or production and you want response times, session data and charts without standing up a modern observability stack, a monitoring agent you add as a dependency and read in a browser is a reasonable answer. The QA framing in the stated goal is worth taking seriously, because comparing a build against a baseline is the easiest thing this kind of tool does well.

The trade-offs follow from the age and the platform. A collector server and Swing client belong to a monitoring generation that assumed a server you controlled, and the module set has no obvious path to modern distributed tracing, metrics backends or dashboards you would use today. If your estate already runs a metrics and tracing pipeline, JavaMelody is a second system to operate rather than a replacement.

Two things to verify before committing: what the user guide says about report retention and data storage, since that determines whether the collector server is optional in practice, and what the release notes say for the exact version you intend to pin. Both live in the wiki rather than here, which is the main thing to know about this repository before you start.

Editorial conclusion

JavaMelody is worth understanding mostly for what it has not needed to change. The stated goal, monitoring Java and Java EE applications in QA and production, has been unchanged for two decades, and the answer has stayed a Maven dependency that instruments a webapp rather than a collector you must operate to see anything. The module list shows the compromises: a separate collector server for aggregating across instances, a Swing client and an offline viewer for when the monitored host is not reachable, and dedicated Spring Boot starters including a Spring Boot 4 one that only makes sense for a framework version most of these modules predate. If you want no infrastructure at all, `javamelody-for-standalone` and `javamelody-swing` are the pair to look at. The README is short and hands installation to the wiki, so the useful reading order is the user guide first, then the release notes.

Frequently asked questions

Official sources

1. Issues
2. javamelody/javamelody on GitHub
3. License: Apache-2.0
4. README
5. Releases