ojAlgo: a zero-dependency Java library for matrices and mathematical programming

The dependency problem ojAlgo is built to avoid

Java numerical work usually forces a choice. You can take a native BLAS or LAPACK binding, which means shipping platform-specific binaries and dealing with JNI loading, or you can take a pure Java library and accept slower dense operations. Optimisation adds a second layer: LP, QP and MIP solvers are typically commercial products or native libraries with their own licensing and deployment constraints. ojAlgo's stated position is that it removes both layers. The README describes it as "pure Java with zero dependencies", with LP, QP and MIP solvers included, and it notes that integrations with third-party solvers also exist. That combination is the reason to look at this project rather than a matrix library alone. The audience is Java engineers who need to solve a linear program or factorise a matrix inside an application they ship, where adding a native artifact to the build is not acceptable. It is not aimed at people doing exploratory numerical work in Python or R, and the README does not present it as a replacement for those environments.

Arrays as the substrate, not just a matrix class

The README is explicit that the linear algebra is built on top of the array classes rather than the other way round. Those arrays can be sparse or dense, used as 1-, 2- or N-dimensional structures, and hold number types beyond double, including complex numbers, rational numbers and quaternions. Memory can be allocated off heap or in a file instead of on the Java heap. That last detail matters more than it reads. An off-heap or file-backed allocation changes what happens when a matrix grows past the point where the garbage collector becomes the bottleneck, and it is a design decision that a plain double[][] cannot make. The trade-off is that you are working through ojAlgo's abstraction rather than raw arrays, so interop with code that expects double[] requires a copy or an adapter. The README does not describe the cost of that boundary, and I could not confirm from the supplied material how the off-heap path interacts with the solver classes.

Solvers, and the claim the README makes about speed

The optimisation side covers LP, QP and MIP. The README does not describe the algorithms, the presolve steps, or how the MIP branch-and-bound is configured, so anyone evaluating solver quality has to go to the source or the blog posts. On speed, the README states that ojAlgo is "the fastest pure Java linear algebra library available" and attributes that to the Java Matrix Benchmark, which it describes as a third party benchmark not written by anyone associated with the project. That is a stronger form of evidence than a self-reported number, but it is still a claim in a README, and the benchmark's problem sizes and hardware are not reproduced in the material I have. Treat the ranking as a pointer to the benchmark, not as a result. The honest position is that pure Java performance is a different question from native BLAS performance, and the README does not attempt to compare the two.

Getting it into a build

Consumption is a single Maven coordinate. The README gives this example, with the version left as a placeholder:

<dependency> <groupId>org.ojalgo</groupId> <artifactId>ojalgo</artifactId> <version>X.Y.Z</version> </dependency>

The artifact is published to Maven Central, and the README links to the versions listing there. The latest releases in the supplied material are v57.2.0, v57.1.1 and v57.1.0, dated August and July 2026, on the develop branch. Building from source requires Java 11 or newer and uses the Maven Wrapper, so a separate Maven install is not needed:

git clone https://github.com/optimatika/ojAlgo.git cd ojAlgo ./mvnw compile ./mvnw test ./mvnw package -DskipTests

Note that the default branch is develop, so a clone gives you the development line rather than a release tag. The README also states that the source code is part of the documentation and that you should read it, which is a fair warning that the Javadoc and blog posts will not cover every case.

Where the documentation model breaks down

The README points to blog posts at ojalgo.org for user documentation and to a multi-file gist for all example code from those posts. There is no reference manual in the repository. For a library whose surface includes N-dimensional arrays, multiple number types, off-heap allocation and three solver families, that is a real constraint. The maintainers are upfront about it: "The source code is (part of) the documentation, and you should read it." That is defensible for a project of this kind, but it shifts cost onto the adopter. Expect to read solver class internals to find out which configuration options exist, because the README does not list them. A second limitation is more structural. If your problem is a large dense factorisation and you already have a native BLAS in the deployment, ojAlgo's zero-dependency property buys you nothing and you are giving up the native path. The README's own framing, "fastest pure Java", is a qualified claim, and the qualification is the whole point.

Alternatives and the actual difference in approach

The obvious comparison is EJML, another pure Java linear algebra library. EJML is oriented around dense matrix operations and decompositions with a strong emphasis on runtime performance for those operations; ojAlgo's README positions the array abstraction as the foundation and treats optimisation as a first-class, in-package capability. If your work is matrix math and nothing else, the two overlap heavily and the deciding factor is which API you prefer. If your work includes a linear program or a mixed-integer program, EJML is not the comparison, because it does not ship solvers. The other comparison is a native stack: a BLAS/LAPACK binding for the linear algebra plus a separate solver. That route gives you access to solver implementations with published benchmark histories, at the cost of native artifacts per platform and, for MIP in particular, licensing. ojAlgo's answer is to collapse both into one JAR. The README also mentions that the Optimatika subscription provides "third-party solver integrations", which suggests the maintainers themselves see the built-in solvers as one option among several rather than the final word.

Licence, maintenance and what a version bump costs you

ojAlgo is MIT licensed, which permits commercial use and modification with the usual requirement to retain the copyright and permission notice. That is a permissive licence, and it is worth contrasting with the commercial solver route where MIP licensing is often the blocking item. The maintenance picture from the supplied material: the repository is not archived, the last push is dated 2026-09-10, and three releases landed between July and August 2026. That is a steady cadence, but the version numbers move fast (57.x within roughly two months), so pinning an exact version is the practical move rather than tracking a range. The README does not describe a deprecation policy or an API stability guarantee, so treat minor-version upgrades as something to test rather than assume. Nothing in the material indicates a changelog file in the repository, so the release notes on Maven Central are the place to check what changed. If you depend on solver behaviour, that check is not optional, because a change in presolve or branching can alter which optimal solution you get on a degenerate problem even when the objective value is the same.

Editorial conclusion

Adopt ojAlgo if your build must stay pure Java and you need matrices and a mathematical programming solver in one dependency. Do not adopt it if your workload is dominated by large dense factorisations where a native BLAS-backed library is already in place, or if you need a solver with published benchmark results for your problem class. Before committing, verify three things: that your JDK is 11 or newer, that the Maven coordinates resolve to the version you intend to pin, and that the blog posts at ojalgo.org cover the specific solver interface you plan to call, because the README points to the source code as the documentation.

Official sources

1. License: MIT
2. optimatika/ojAlgo on GitHub
3. Project website
4. README
5. Releases