OpenHFT is the parent module that pulls the active Chronicle modules together

A build parent, not a callable library

The repository description is a single phrase, and it is the right one to start from: parent module to include active modules. The top level is a Maven structure with a `pom.xml` at the root, a `root-parent-pom/` directory, a `java-parent-pom/` directory, a `chronicle-bom/` directory and a `third-party-bom/` directory, alongside `docs/`, a `docker/` directory and the `SECURITY.md` file.

A parent module is a Maven construct for sharing configuration across a family of modules. It does not appear on your application's classpath and it is not something you call. What it does is decide, once, what the child modules inherit, which versions they use and how they are built together. So this repository is where you go to find out how the Chronicle pieces fit together and which set of them is currently active.

Two details are worth noticing before you go further. The primary language of the repository is recorded as Shell, which says more about this repository than about the products: the code that matters lives in the sibling Chronicle projects, and what is here is the glue. And the default branch is `ea`, which is not `main` or `master`, so a clone that does not specify a branch gets the enterprise all set rather than the open source default.

The homepage is openhft.net, the licence is LGPL-3.0, and the last push was on 2026-10-09.

What Chronicle says it builds

The README in this repository is a Chronicle overview, and it opens by saying that Chronicle Software provides libraries to help with fast data, and that the majority of its customers are in financial services. Everything that follows is a product line, and each one tells you what problem shape to expect.

The FIX and ITCH engine is described as a low latency FIX and ITCH engine in Java for all versions of FIX, and the README states it can parse and generate messages within 1 microsecond. That figure is the vendor's own claim in its own README, not something measured in this article.

The Microservices Framework is described as efficient, easy to build, test and maintain, with high throughput, low latency and transparent HA and DR. The Matching Engine is the backbone for an exchange solution, providing order matching, validation and risk checks, with a modular design that lets it run stand-alone or be integrated with the FIX engine and the services framework.

EFX sits on top of the microservices framework and contains components for aggregation, pricing, hedging, position keeping, P&L, market gateway and algo containers, and the README frames the trade-off as the customer using off the shelf functionality built and maintained by Chronicle, or extending it with their own algos and IP, described as the best compromise of buy versus build.

Two more complete the set. Chronicle Queue and Chronicle Queue Enterprise are for low latency message passing, providing an effectively unlimited buffer between producers and consumers and a complete audit trail of every message sent, with the Enterprise edition adding lower latencies and additional delivery semantics, for example only processing a message once it is guaranteed replicated to another host. Chronicle Map is a key-value store sharing persisted memory between processes, on one server or across networks, storing data off-heap to minimise heap usage and garbage collection, with sub-microsecond latency, cited with OPRA market data as an example of the update rates it supports.

The BOM is where the releases live

The recent releases listed for this repository are all BOM artefacts rather than library tags: `chronicle-bom-2.25.140` from 2026-10-09, `chronicle-bom-2026.26` from 2026-10-06 and `chronicle-bom-2026.23` from 2026-08-14.

That naming shows two version schemes in use at once, a numeric scheme and a calendar scheme, and the dates sit close together. The bom is what tells a consuming build which versions of the sibling modules belong together, which is the practical reason a parent module like this is published at all: without it, every project pins its own set of versions and the combinations drift.

Two other top level files point at the distribution side. `nexus-access.adoc` and `nexus-access.pdf` document how to get access to the artifact repository, and the presence of `checkout-enterprise.sh` next to `checkout.sh` says that some modules are not in the open set. The `third-party-bom/` directory is the counterpart for dependencies the Chronicle modules pull in, so the same pinning discipline covers the libraries underneath as well as the ones above.

For a reader who only wants to use one component, this is the part that says whether the pieces are available to you. The open source modules are obtained through the checkout scripts, and the enterprise ones are a separate arrangement with its own access requirements, and the README points to a contributor agreement at chronicle.software for code as well.

The shell scripts are the working interface

Because the primary language of the repository is Shell, the scripts at the top level deserve more attention than they usually get. There is `checkout.sh`, `checkout-enterprise.sh`, `checkout.bat` for Windows, `allstatus.sh`, `status.sh` and `update_gitignore.sh`, plus a `system.properties` file and a `docker/` directory.

The division of labour is readable from the names. The checkout scripts pull the working set of modules onto your machine, and the enterprise variant is separate because those modules are not in the open set. The status scripts report on the state of the checkouts, which in a repository of this size is a real need, because the working set is assembled from several upstream projects rather than being one clone. The `.bat` file exists so that the same operation is available on Windows, and `update_gitignore.sh` exists because a working set assembled from many upstream repositories needs its ignore rules maintained as those repositories change.

So the daily workflow of contributing to Chronicle is not clone and build. It is run the checkout script, check the status, build, and remember that the `ea` branch is the default and that the enterprise set is a separate opt-in. The `docker/` directory suggests the same set can be worked on in a container, and the `docs/` directory holds the reference documents described in the next section.

Support matrices live in AsciiDoc, not in the README

The README has a section titled Documentation in this repo, and it lists what is there. `docs/Java-Version-Support.adoc` documents which versions of Java and the JVM are supported by the Chronicle libraries. `docs/Platform-Support.adoc` documents which operating systems are supported. `docs/Version-Support.adoc` explains Chronicle's version numbers and release timetable. `docs/Anatomy.adoc` shows a graphical representation of the OpenHFT projects and their dependencies, and `docs/Reducing-Garbage.adoc` contains tips and tricks to reduce garbage.

Two of those are the ones people actually need. The Java version support document is the check to run before choosing a JDK, because a low latency Java library tends to care about the specific runtime it was compiled and tested against, and the platform support document answers whether your operating system is in scope at all.

`Anatomy.adoc` is the document that makes this repository worth reading on its own. A dependency graph of the projects, in a repository that has no code, tells you which module depends on which, which is the question a new user of Chronicle FIX, Map or Queue asks first and which the product pages answer badly. The reducing garbage document is the more specialised one, aimed at the same audience that cares about the sub-microsecond and off-heap claims elsewhere in the README.

The documentation is AsciiDoc, which is consistent with the README file itself being named `README.adoc` rather than `README.md`, and it is edited in the same repository as the build files, so a version bump and a documentation change can land together.

Security reports and the contributor agreement

The README has a section on reporting security issues, and it is specific. If you discover a security vulnerability in any Chronicle or OpenHFT library, you are asked to report it by emailing [email protected], and explicitly not to open a public GitHub issue or pull request for security vulnerabilities. The repository carries a `SECURITY.md` file for the details of what to include and what to expect.

That instruction is worth honouring literally. A public issue on a low latency trading library discloses the existence of a defect, and a report that also contains a proof of concept discloses a great deal more.

Contributions have their own condition. The README says that to accept contributions to open source libraries, contributors are required to sign the contributor agreement, with the link at chronicle.software/contributor-agreement/. In practice that means a pull request to this repository is not a purely technical act, which is worth knowing before you prepare one, particularly if your employer has an opinion about the agreement.

On licensing, the repository is under LGPL-3.0. The enterprise components that the checkout script pulls separately are a different arrangement, and the README's product descriptions make clear which pieces are commercial. This is not legal advice, and the distinction between the open source modules and the enterprise ones is the thing to take to your own counsel rather than the licence identifier alone.

When this repository is the wrong thing to adopt

The clearest case for confusion is treating OpenHFT as a dependency. If your team wants a FIX engine, a message queue or an off-heap key-value store, the artefact you add to your build is a Chronicle module and the version you want is in the BOM. OpenHFT itself is the parent that holds those modules together and the place where the support documentation and the checkout scripts live. Adding it does nothing on its own.

The second case is expecting the enterprise behaviour. The README is explicit that some capabilities sit in the Enterprise editions, for example the additional delivery semantics in Queue Enterprise where a message is only processed once it is guaranteed replicated to another host, and the replication of Chronicle Map, which the README attributes to Chronicle Map Enterprise. If your design needs that guarantee, you are buying a product, and no amount of reading this repository changes it.

The third is a non financial workload. The README says the majority of the customers are in financial services, and the product descriptions are written for exchange, order book and market data problems. The engineering is general, but the tuning, the support and the vocabulary are aimed at that domain, and a team solving a different problem should look at the individual modules rather than adopt a family of libraries shaped by someone else's trade.

One practical note for any of these cases. The default branch is `ea`, and the `checkout.sh` and `checkout-enterprise.sh` scripts behave differently, so the first thing to check is which set you actually have on disk.

Editorial conclusion

Adopt the OpenHFT repository as the place to read how the Chronicle modules fit together, as a reference for the Java and platform support matrices, and as a way to obtain the correct set of source trees for a build. Do not treat it as a dependency you add to a project, since it is a parent module and a documentation home rather than a runtime library, and do not assume the enterprise components come with it, because they are pulled separately and need repository access. Verify first which branch you are on, since the default branch is `ea`, check the Java version support document against the JDK your build uses, and confirm that the BOM version you pick matches the module versions your project needs.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. OpenHFT/OpenHFT on GitHub
3. Project website
4. README
5. Releases