CometD is a server push implementation with a version table that tells you when to move

Server push, in Java on the server and JavaScript in the browser

CometD is a scalable comet implementation for web messaging, and the repository is the project itself rather than a wrapper around something else. The layout in the readme shows the shape of the effort. There is a directory for the Java server and the Java client libraries, a directory for the JavaScript client libraries in their ES6 and jQuery forms, a directory of Maven archetypes for quick application development, a demo of the Java server with those clients, and a documentation directory. There is also a distribution directory for the release bundle, a top level Maven project file, a Jenkinsfile for the build, a copyright header file for contributors, a security policy and a contributing guide. Two clients in two styles is the detail that tells you about the audience, because the jQuery client exists for applications that cannot be rewritten, while the ES6 one is for new code, and a project that still supports both is a project whose users are often large and slow moving. The protocol is a long-lived HTTP connection rather than a websocket, which is the detail that has historically kept CometD deployable in environments where a websocket upgrade was awkward.

The version table is the compatibility contract

The most useful thing in the readme is a table of CometD versions against minimum Java versions, minimum Jetty versions, servlet APIs and status. The 9.0 line needs Java 17, Jetty 12.1.x and the EE11 namespace of the jakarta servlet packages, and it is marked stable. The 8.0 line also needs Java 17, but Jetty 12.0.x and the EE10 namespace, also stable. The 7.0 line drops to Java 11 with Jetty 11.0.x and EE9, and is marked as end of community support, as is the 6.0 line with Java 11, Jetty 10.0.x and the older javax namespace, and the 5.0 line with Java 8, Jetty 9.4.x and EE7. That table is the whole upgrade decision in one place, and it also says something about the direction of travel. The two lines that are easiest to deploy onto an existing container, the ones that still use the javax namespace, are the ones the project will not support, so a long-lived deployment on an old stack is on its own. The default branch is 9.0.x, which tells you where the project is being worked on.

Running the demo takes one Maven command

If you have downloaded the release bundle, the readme says the project is already built for you, and the demo can be run with Maven after unzipping the bundle.

$ cd cometd-demo
$ mvn jetty:run

You then point a browser at the local port. The alternative deployment is the one that shows what the artifact actually is, a war file you drop into any Servlet 2.5 or later server, with Jetty, Tomcat and GlassFish named as examples, and the readme shows the copy of the built war into the web applications directory of your server followed by starting it.

$ cp cometd-demo/target/cometd-demo/target/cometd-demo-*.war  $MY_SERVER/webapps/cometd.war

That is a useful thing to know about the project, because it tells you the deployment story is ordinary servlet deployment, not a bespoke runtime. If you cloned the source instead of downloading a bundle, the build instructions point at the project documentation, and the short form is a single Maven install command, which builds and installs every module into the local repository.

$ mvn install

The benchmark is a client and a server you run yourself

The project ships a benchmark, and it can be run interactively or in batch mode. The interactive version is two processes, and the readme is explicit that the client is run in another terminal window and potentially on another machine, which is how you get load from a separate host rather than from the same box. The server side is started from the benchmark server directory with a Maven exec goal, after which you follow the instructions printed in the terminal, and the client side does the same from the benchmark client directory to generate the load. That arrangement, a load generator separate from the server under test, is the difference between a benchmark and a demonstration, and it is a sign that the project takes measurement seriously. The benchmark documentation lives in the reference section of the project documentation site, alongside the build instructions, and the readme points there for both.

Apache 2.0, a public bug tracker and a support policy that ends

The licensing is one line, the source code is released under the Apache 2.0 licence, and the licence file sits at the top of the tree. Issues, bugs and requests for enhancements are filed at a public tracker rather than a private channel, which is the right arrangement for a project whose users are integrators who need to know what is broken. The security policy file is a separate document, which for a project that terminates connections across networks is the right thing to have. The support statuses in the version table are the part with a policy attached, since two of the five lines are marked as end of community support and one of them points at a different issue, which suggests the earlier lines were retired at different times rather than all at once. For a project that has been around long enough to have five major lines and a decade of deployment history, that is a normal pattern, and the table is how you navigate it. The final piece of the picture is the archetypes, since a project that ships Maven archetypes for quick application development is trying to make the first integration a template rather than a tutorial.

Editorial conclusion

CometD earns its place for a Java team that has to push updates to browsers and cannot take a dependency on a hosted service, because the server is a plain servlet you deploy anywhere, the protocol is implemented in both languages, and the project still ships a maintained branch. It is the wrong choice if you are starting a new real time feature today, because the current lines track modern servlet namespaces and modern Jetty versions, and the older lines that are simpler to deploy are explicitly marked as end of community support. Verify three things before you pick a branch: which Java and Jetty versions you actually run, since the table maps each CometD line to a minimum Java version, a Jetty version and a servlet namespace, whether the client libraries you need are the ES6 ones or the jQuery ones, since both are in the repository, and whether the deployment you have in mind is a servlet container, because the demo war file is designed to be dropped into one. The licence is Apache-2.0, the last push was on 2026-10-21, and the newest release is 9.0.1 from 2026-06-10.

Frequently asked questions

Official sources

1. cometd/cometd on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases