// the find
apache/incubator-kie-optaplanner
AI constraint solver in Java to optimize the vehicle routing problem, employee rostering, task assignment, maintenance scheduling, conference scheduling and other planning problems.
OptaPlanner is a mature Java constraint solver for NP-hard planning problems: shift scheduling, vehicle routing, task assignment. It's a proper operations research tool — not an LLM wrapper — using tabu search, simulated annealing, and constraint streams to find near-optimal solutions. Target audience is Java backend developers who need to solve real scheduling problems and want something battle-tested over building their own metaheuristic.
The Constraint Streams API (Bavet engine) is a genuinely good design: you write constraints as Java streams, and the engine incrementally maintains scores rather than recalculating from scratch on every move — this makes it viable for large solution spaces where naive recalculation would be prohibitively slow. The score types (HardSoftScore, BendableScore, etc.) are well-thought-out and force you to correctly separate constraint priorities instead of magic-numbering everything into a single objective. Ships with 20+ worked examples covering real problem domains, and the examples include realistic dataset sizes, not toy inputs. Quarkus and Spring Boot integration are first-class, so wiring it into an existing Java service is straightforward.
Now under Apache incubation as 'KIE OptaPlanner', which means the project governance is in transition — the original Red Hat team drove this for years and it's not yet clear what the Apache-era velocity looks like; the README still links to the old kiegroup GitHub org. The DRL (Drools Rule Language) constraint backend is still present and documented, which is dead weight for anyone starting fresh — it's the legacy path and you shouldn't touch it, but the docs don't make that obvious enough. Getting good solution quality requires tuning the solver configuration (phase sequences, move selectors, termination conditions), and the defaults are rarely optimal for a specific problem; expect to spend real time on this before results are production-worthy. No Python or non-JVM bindings, so if your stack isn't Java/Kotlin/Quarkus, you're either wrapping it in a service or looking elsewhere.