Strata is OpenGamma's market risk library, and the module split is the API

A library with a production user attached to it

The repository contains the source of Strata, the open source analytics and market risk library from OpenGamma, released under the Apache 2.0 licence. The status paragraph is short and unusually concrete. Strata is described as well maintained, tested and functional, and it is used in production as the core of the company's SaaS Analytics offering, with the API maintained with backwards compatibility in mind. That last sentence is the important one for an adopter, because it tells you that the library is not a research prototype that will be reshaped whenever the authors feel like it, but a foundation somebody else's product is built on. The topics give the domain, with derivatives, exchange traded derivatives, market risk, over the counter and quantitative finance, which is a specialised library rather than a general purpose one, and the practical consequence is that the value is in the domain model rather than in the plumbing.

Eleven modules, and the names tell you the layering

Strata is formed from a number of modules, each with its own readme, and the list is a readable description of the architecture. There is `Basics` and `Collect`, which are the utility and aggregation layers. `Market` and `Data` cover market data and the data structures that carry it. `Product` is where the financial instruments are modelled, and `Pricer` is where they are valued. `Measure` is the analytics layer, the calculations that turn a priced product into a risk number, and `Report` is the presentation layer that renders those numbers. `Calc` is the calculation runner, and `Loader` handles loading, which in a market data system is a problem of its own. `Examples` is the sample project. The reason this layering matters is that it is the API a consumer sees, since you depend on `strata-measure` and `strata-pricer` separately, and the dependency graph is a design decision you inherit rather than one you make.

Consuming it is a Maven dependency and a Java floor

To use Strata, Java SE 8u40 or later is required, and the JAR files are on Maven Central under the `com.opengamma.strata` group. A dependency looks like this:

<dependency>
  <groupId>com.opengamma.strata</groupId>
  <artifactId>strata-measure</artifactId>
  <version>2.12.75</version>
</dependency>

The JAR files, the command line tool and the examples are also available from the Strata releases page on GitHub, which is the route to take if you want the command line tool without resolving a dependency tree. Two practical notes follow from the module structure and the licence. First, the licence is Apache 2.0, which is a permissive grant with an explicit patent clause, and the repository carries both a `LICENSE.txt` and a `NOTICE.txt`, so the attribution obligations are visible rather than implied. Second, the version in your build file is a hard pin, and given the release cadence below you will want to update it deliberately.

Building it means Maven and a Java 8 base

The source is cloned with git from GitHub, and the projects use Apache Maven as the build system, with version 3.5.0 or later required. The build itself is one command:

git clone https://github.com/OpenGamma/Strata.git
mvn install

The documentation is unusually clear about the Java matrix, and it is the kind of clarity that only comes from a project that has been through several JDK generations. Strata is based on Java SE 8, the continuous integration regularly builds on both Java 8 and Java 11, and on Java 8 you need version 8u40 or later because of bugs in the earlier ones. The documentation also says plainly that it does not recommend non-LTS releases such as Java 9, 10 and 12 to 16, which is an unusual thing for a project to state and tells you the build matrix is deliberately narrow. The build providers recommended are OpenJDK distributions from other vendors, notably Amazon Corretto and Adoptium, rather than Oracle's own build.

The JavaFX examples are the awkward corner of the build

The Strata examples project includes a graphical user interface built on JavaFX, and this is the one part of the build that behaves differently depending on the JDK. On Java 8, the GUI is excluded from compilation if JavaFX is not available in the JDK, which was a real packaging difference between the Oracle JDK of that era and the open builds. On Java 11, OpenJFX is included as a JAR from Maven Central, so the GUI is always compiled. The practical consequence for a contributor is that the same checkout produces a different set of artefacts depending on which JDK you use, and that anyone building the examples on Java 8 needs to know their JDK ships JavaFX at all. It is a small thing, and it is also the kind of detail a project documents when it has been bitten by it, which is a fair signal about the state of the rest of the build.

Backwards compatibility is a policy, not an accident

The status section says the API will be maintained with backwards compatibility in mind, and the release history is consistent with that policy rather than with a project that breaks its API freely. The listed releases are v2.12.77 on 2026-10-05, v2.12.76 on 2026-09-30 and v2.12.75 on 2026-09-23, which is a patch release roughly every week, all within the same minor version. That pattern is what a library used in production looks like, since the increments are fixes and small additions rather than rewrites, and it means a consumer can schedule its own upgrades on a predictable cadence. The trade is that the version numbers move constantly, so a build that pins an exact version needs a process for bumping it, and a project that wants long term stability has to read the release notes rather than track the branch. The repository also carries a `SECURITY.md` and a `RELEASE.md`, which are the files to look for when you want to know how changes are communicated.

What to check before you depend on Strata

The practical checklist is short, and most of it comes from the documentation rather than from the code. Decide which modules you need, because a pricing and risk stack is a large dependency and the module split is there so you do not have to take all of it. Confirm the JDK you will build and run on, since the library targets Java SE 8 and the recommendation is to use a Corretto or Adoptium build rather than a vendor JDK. Then check the two things that usually decide a project like this. The first is the data layer, since `Market` and `Data` determine how you get prices and curves into the system at all, and a pricing library is only as good as the market data behind it. The second is the measure layer, since `Measure` is where the risk numbers come from and where the assumptions about a trade live. The library has been in production use at OpenGamma, and the licence is Apache 2.0, so the risk is not in the code but in the size of the thing you are adopting.

Editorial conclusion

Strata suits a team that has to value derivatives and measure risk and does not want to write the pricer and the measure layer from scratch, since the module structure and the immutable data model are the asset. It is a poor fit if you need something small and quick, because the dependency footprint of a pricing stack is large and the build is Maven and Java 8 era. It is a poor fit if you need a modern Java baseline, since the library is based on Java SE 8 and the CI runs on Java 8 and 11. Before you adopt it, check three things: which modules you actually need, since pulling the whole set is a large dependency for a small job, the Java version you will build on, where the documentation recommends Amazon Corretto or Adoptium rather than Oracle builds, and the release cadence you will pin to, with v2.12.77 published on 2026-10-05 and frequent patch releases since.

Frequently asked questions

Official sources

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