Optimisation Solvers

Mathematical optimisation means finding the best solution to a problem defined by an objective function and a set of constraints. Solvers are the engines that do this work. They take a model — variables, constraints and an objective — and return the optimal values. The three most common model types are LP (linear programming), QP (quadratic programming) and MIP (mixed-integer programming), each allowing progressively more complex problem formulations.

ojAlgo includes solvers for all three: LP, QP and MIP — pure Java with zero dependencies. You formulate your problem using ExpressionsBasedModel, call minimise() or maximise(), and the built-in solvers handle the rest. For many real-world problems this is all you need, and it works anywhere Java runs — no native libraries, no platform-specific builds, no licence keys.

If your models outgrow the built-in solvers, there are alternatives. ExpressionsBasedModel lets you swap in a third-party solver without changing your model code. The extensions listed below each connect a different solver to ExpressionsBasedModel. You choose the solver; the way you formulate the model stays the same.

See the LP & QP benchmark for current performance data comparing ojAlgo to several of the solvers listed below.

Commercial solvers

The leading commercial solvers — CPLEX, Gurobi and MOSEK — offer the highest performance, especially on large MIP models where they are significantly ahead of any open source alternative. They are the industry standard for a reason.

The downsides are substantial. Annual licence fees typically range from thousands to tens of thousands of dollars, and pricing is often quote-gated — you may not know the cost until you talk to sales. The solvers themselves are native code (C/C++), so you need to package and deploy platform-specific binaries alongside your Java application. Licence servers or licence files must be managed, and licence terms can restrict how and where the software is deployed. For teams in regulated environments or with strict procurement processes, the overhead can be considerable.

Other Java solver libraries

If you want to stay in pure Java and avoid native code entirely, there are a few other solver libraries. ojAlgo has extensions that integrate them with ExpressionsBasedModel, so you can try them as drop-in alternatives.

In practice, ojAlgo consistently outperforms all of them — both in speed and in the number of models successfully solved. Hipparchus is the most capable alternative but fails on roughly half the standard LP test models and is significantly slower when it does solve. Commons Math and JOptimizer are older and more limited. The benchmark has the detailed numbers.

Open source native solvers

When models grow large enough that pure Java solvers reach their limits, open source native code solvers are a strong option. HiGHS in particular has become the leading open source solver for LP, QP and MIP, and OR-Tools bundles Google’s GLOP simplex solver alongside CP-SAT and other algorithms.

The downside is deployment complexity. These are C, C++ or Rust libraries that must be compiled or packaged as platform-specific binaries for every target environment — x86 Linux, ARM macOS, Windows, and so on. Your build pipeline needs to produce and test artifacts for each platform. JNI or Foreign Function calls bridge the gap between the JVM and native code, adding a layer that can be fragile across JDK versions. If something goes wrong at the native boundary, debugging is harder than with pure Java. None of this is insurmountable, but it is real engineering work that pure Java avoids entirely.

Optimisation Service

Each of the alternatives above comes with a trade-off: commercial solvers are expensive and licence-encumbered, other Java libraries are slower and solve fewer models, and open source native solvers require significant build and deployment work.

Optimatika’s Optimisation Service addresses all of these. It is a solver server that you deploy in your own cluster from the AWS, Azure or Google Cloud marketplace — infrastructure you most likely already use. A small pure Java client configures ExpressionsBasedModel to solve through it, so no native code enters your application and no solver licences need to be managed.

Under the hood, the service runs a suite of best-of-breed native open source solvers. The combined power of multiple solvers greatly surpasses what any single solver can do alone. You get native-code performance without any of the native-code deployment work, at a fraction of the cost and complexity of a commercial solver licence. For models that outgrow the built-in solvers, this is by far the simplest path to more solving power.

All extensions

For the complete list of extension modules — solvers and others — see the Extensions page.