Red Hat Releases OptaPlanner 8

Red Hat has released OptaPlanner 8, a lightweight, embeddable planning engine to efficiently solve AI constraint optimization problems. The framework can be used to solve planning challenges such as rostering, vehicle routing, scheduling, or any other constraint satisfaction problem. OptaPlanner can solve these challenges without having to code everything yourself or solving the puzzle by hand.

OptaPlanner 8 improved support for new technologies like Quarkus and GraalVM, while still supporting Spring Boot and plain Java.

This new version introduces the OptaPlanner quickstarts repository that contains examples for various OptaPlanner features. They are built using the different technologies OptaPlanner supports. The guides help developers to quickly get up to speed and start using the different OptaPlanner features with their preferred Java framework.

OptaPlanner 8 is a major release with breaking changes. Red Hat plans major releases approximately every three years. In this latest release, the deprecated methods from OptaPlanner 7 and dependencies, such as Guava and Reflections, have been removed. One of the other new features is the ability to explain why a solution has a specific score. Consider the following example to demonstrate how to use the ScoreExplanation interface to retrieve relevant score information with methods such as getScore(), getSolution() and getSummary().

ScoreExplanation<TimeTable, HardSoftScore> scoreExplanation = 
   scoreManager.explain(timeTable);

InfoQ reached out to Geoffrey De Smet, creator and leader of the OptaPlanner project at Red Hat, to learn more about the current and future releases.

InfoQ: Can you tell everyone a bit more about yourself? What's your role at OptaPlanner and what does your day look like?

Geoffrey De Smet: I started OptaPlanner in the summer of 2006 as a hobby. The first few years, I worked on it during the weekend, but after getting married and having kids, this was not really sustainable. Luckily, Red Hat offered me a job in 2010, so my hobby became my work.

Over the years, with a lot of help from my team at Red Hat, the project grew into a robust, scalable, well-documented planning engine, used across the globe from governments and Fortune 500 companies to startups and nonprofit organizations.

My role is that of a technical lead. My day consists of coding, team discussions, PR reviews, and talking to customers. I also regularly speak at conferences.

Most of our discussions are in the open, so if you want to participate, join our online chat.

InfoQ: OptaPlanner 8 requires Java 11 or higher. How was the user's response to that announcement since many organizations still use Java 8?

De Smet: So far, I haven't seen users complain about it yet, but that's probably because at the last moment we ended up releasing Java 8 compatible JAR files :)

Officially, however, OptaPlanner 8.x only supports Java 11 or higher, because Java 8 is end of life, so we won't be able to guarantee Java 8 compatibility in future 8.x releases. Furthermore, Java 11 has APIs that are marked deprecated for removal, and to avoid using those, especially once Java 17 is out next year, we may need to use APIs that didn't exist yet in Java 8.

To use Java 8 with OptaPlanner, I recommend using OptaPlanner 7.x (7.47.0.Final was just released in December 2020).

InfoQ: The quickstarts repository is one of the new features. Are you planning to include quickstarts for all the different features of OptaPlanner?

De Smet: We currently have six quickstarts, all modern web applications with a REST API. On the other hand, we still have 21 examples in our Swing examples, that cover all the different features, such as Real-Time Planning, Continuous Planning and Non-Disruptive Replanning.

But let's face it: most people don't want to put Swing applications in production anymore. So over time, we'll migrate most of the Swing examples into modern web application quickstarts.

InfoQ: Which feature of this release was the most challenging to implement and why?

De Smet: The integration with Quarkus and Spring Boot proved challenging, as both the Quarkus extension and Spring Boot starter APIs could benefit from more documentation, but in the end, it has been more than worth it: they remove a lot of boilerplate code for our users that use either of those platforms. We'll even take a step further once we start generating a solver REST API automatically in Quarkus.

For the Java quickstarts, supporting Gradle, besides Maven of course, was more difficult than expected. Our CI checks for those build.gradle files are still weak; we're working on it.

The Kotlin quickstart on the other hand was surprisingly easy to write. I'd love to include a Python/Jython quickstart too, but I don't see how yet.

InfoQ: Which one is your favorite feature of OptaPlanner 8?

De Smet: That's easy: the Quarkus extension.

I can code an entire OptaPlanner application during a 1-hour presentation from scratch. It includes REST services, database persistence, and of course OptaPlanner optimization. And it starts up crazy fast. I can even compile the whole thing natively with mvn clean install -Dnative.

But most importantly with quarkus:dev mode, I can add a constraint and see it in action on my schedule - half a second later - simply by refreshing my browser. Regardless of what code I change, it's never stale. Simply amazing. It revolutionized my development and my presentations.

InfoQ: What is the most requested new feature from customers for a future release?

De Smet: VRP simplification and Constraints Stream improvements.

To model a Vehicle Routing Problem in OptaPlanner, unlike most other use cases, users currently need to model a linked list, through what we call "chained variables". It works quite efficiently, but it's complex to use and hard to reason over. So instead, we also want to support "list variables", so class Vehicle can have a simple List<Visit> instead.

Our ConstraintsStreams API introduced a year ago is a big success; it makes it a lot easier for Java developers to implement incremental constraints quickly, without the burden of actually dealing with incremental calculation. However, in this fairly young API, users are still discovering API gaps. We've already plugged most of those gaps and we'll continue to plug the remaining ones in the future, such that no constraint is too hard to implement.

Furthermore, we're working on an effort to dramatically improve the performance of ConstraintStreams further.

InfoQ: Which features are you working on for the next version(s)?

De Smet: VRP simplification and ConstraintsStreams improvements, of course.

Also, we're working on generating a REST solver service automatically from the model, in Quarkus (and later maybe Spring Boot). This will remove the last pieces of boilerplate code in the quickstarts, so a user basically defines the model and the constraints and everything else is handled automatically. Of course, it's fully extensible; a user can replace any piece with custom code (write his/her own REST solver API) if he/she so wishes.

We're also experimenting with Gizmo to replace all reflection with generated code, increasing performance further.

OptaPlanner 8 is available as OpenSource based on the Apache License 2.0 license. Apart from that, an enterprise solution will be included in Red Hat Decision Manager 7 which is scheduled for the first half of 2021.