Solver Integrations
ojAlgo's ExpressionsBasedModel is solver-agnostic: the formulation is not tied to the engine that solves it. Optimatika maintains a set of integration modules connecting that model to external solvers, all in a single repository — ojAlgo-extensions.
This integration work is also what the Optimisation Service is built on. The Service draws on the open source, licence-compatible modules; which of them it uses is an implementation detail that changes as solvers improve, and no specific solver is promised. Commercial solvers are not part of it.
All the modules — commercial integrations included — are available directly to Optimatika Subscription holders, together with the right to request new builds against current solver versions. An integration module is not a solver licence: the commercial modules let you reach a solver you have already licensed from its vendor, and do not come with one.
Commercial solvers
The leading commercial solvers offer the highest performance, especially on large MIP models where they are meaningfully ahead of any open source alternative. They are the industry standard for a reason.
Purchasing, licensing and installing a commercial solver is up to you — these integration modules provide access from Java to a working solver you already have. They are not solver licences and do not come with one. Pricing is usually quote-gated, and licence terms can restrict how and where the software runs; the solvers themselves are native code, so platform-specific binaries, licence servers or licence files must be managed alongside your Java application.
The integrations use the Java interfaces — typically JNI-based — provided by the solver vendors themselves.
| Module | Solver | Types | Release |
|---|---|---|---|
ojAlgo-cplex | IBM ILOG CPLEX | LP, QP, MIP |  |
ojAlgo-gurobi | Gurobi | LP, QP, MIP |  |
ojAlgo-mosek | MOSEK | LP, QP, MIP |  |
ojAlgo-xpress | FICO Xpress | LP, QP, MIP |  |
ojAlgo-copt | COPT | LP, QP, MIP |  |
Other Java solver libraries
There are a few other pure Java solver libraries, and ojAlgo has integrations for them so they can be tried as drop-in alternatives.
In practice ojAlgo outperforms all of them, both in speed and in the number of models solved successfully. Hipparchus is the most capable alternative and still fails on roughly half the standard LP test models. Commons Math is older and more limited — Hipparchus is its maintained fork — and JOptimizer's QP work is largely superseded by ojAlgo's own.
| Module | Solver | Types | Licence | Release |
|---|---|---|---|---|
ojAlgo-hipparchus | Hipparchus | LP, QP | Apache 2.0 |  |
ojAlgo-commons-math3 | Apache Commons Math | LP | Apache 2.0 |  |
ojAlgo-joptimizer | JOptimizer | QP | Apache 2.0 |  |
ojAlgo-choco | Choco | MIP | BSD-3-Clause |  |
ojAlgo-ssclp | SSC-LP | LP, MIP | GPLv3 | GPL is incompatible with ojAlgo's MIT licence, so no release |
Open source native solvers
When models grow past what pure Java can do, open source native solvers are a strong option. HiGHS has become the leading open source solver for LP, QP and MIP. Google's CP-SAT is one of the strongest solvers available for pure integer programs. SCIP, OSQP and Clarabel each cover different problem types.
As with the commercial solvers, installing or building the actual solver is not part of the integration — the difference is that you do not have to pay for or licence anything. These are C, C++ or Rust libraries that must be compiled or packaged as platform-specific binaries for every target environment.
Unlike the commercial integrations, these modules integrate directly with the native code using Java's Foreign Function & Memory API (FFM, formerly "Panama") — there is no intermediate dependency. The two exceptions are the older integrations: ojAlgo-ortools depends on the OR-Tools fat jar, which bundles Java glue code and native libraries for multiple solvers into a single artifact — ojAlgo-cpsat exists as the direct FFM replacement, talking to the CP-SAT solver without that fat jar. Similarly, ojAlgo-clarabel4j goes through the third-party clarabel4j wrapper, and ojAlgo-clarabel replaces it with a direct FFM integration.
The Optimisation Service takes care of the problem of dealing with native code altogether.
| Module | Solver | Types | Language | Licence | Release |
|---|---|---|---|---|---|
ojAlgo-highs | HiGHS | LP, QP, MIP | C++ | MIT |  |
ojAlgo-ortools | Google OR-Tools | LP, MIP | C++ | Apache 2.0 |  |
ojAlgo-clarabel4j | Clarabel via clarabel4j | LP, QP | Rust | Apache 2.0 |  |
ojAlgo-clarabel | Clarabel | LP, QP | Rust | Apache 2.0 |  |
ojAlgo-cpsat | Google CP-SAT | MIP | C++ | Apache 2.0 |  |
ojAlgo-osqp | OSQP | LP, QP | C | Apache 2.0 |  |
ojAlgo-scip | SCIP | LP, QP, MIP | C | Apache 2.0 |  |
The ojAlgo-extensions repository also holds integrations that are not solvers — JFreeChart and RocksDB among them.
What is public, and what a subscription adds
Public, on Maven Central
- Every module with a version badge above, from Maven Central
- MIT licensed, like ojAlgo itself
- Each release is built against one specific solver version
With a subscription
- The
ojAlgo-extensionssource repository - A build against the solver version you run, on request
- Pre-release builds and migration guides before a public release ships
- Someone to ask when a vendor upgrade breaks the binding — by email, within two business days
The modules exist so you never write JNI glue. The subscription exists so you never maintain it either.