Release Notes 7

In this release, we continue deprecating some rarely used methods for which there are now better alternatives. We encourage everyone to check out our updated upgrade recipe to adapt accordingly.

With this release, we are deprecating some rarely used methods for which there are now better alternatives. We encourage everyone to check out our updated upgrade recipe to adapt accordingly.

That said, we remain committed to our existing API compatibility guarantees and we will not remove any of the deprecated APIs on the 7.x stream of OptaPlanner.

The run script automates setup steps that would otherwise have to be carried out manually and simplifies the run command.

Before:

After:

To learn more about the run script, read the documentation or watch this video:

We have introduced the Constraint Verifier API, allowing you to easily test constraints developed using the Constraint Streams API. Consider the following constraint:

The following example uses the Constraint Verifier API to create a simple unit test for the preceding constraint stream:

We have added several new constraint collectors: toList(), toSet(), toSortedSet(), toMap() and toSortedMap(). Also, the min() and max() collectors have been extended to BiConstraintStream, TriConstraintStream` and QuadConstraintStream as well. To use these collectors, look for the ConstraintCollectors class.

With recent improvements to the constraint streams API, we have been able to add ConstraintProvider implementations to more and more examples. This release brings constraint stream support to the following examples: investment, machinereassignment and scrabble.

The constraint streams API continued to evolve, gaining support for conditional propagation. The following example penalizes computers which have at least one process running:

Note the use of the ifExists() building block. Conversely, the ifNotExists() building block is also available.

A SolverManager is a facade for one or more Solver instances to simplify solving planning problems in REST and other enterprise services. Its solve(…​) methods differ from the normal Solver.solve(…​) method:

SolverManager supports batch solving, but also live solving that shows progress to the end-user, for example:

OptaPlanner now includes a Spring Boot starter out of the box. This avoids common pitfalls in the Spring ecosystem (such as classloading) and enables application.properties to overwrite the solver configuration:

In fact, a solverConfig.xml file is no longer needed on Spring Boot. The starter automatically detects @PlanningSolution and @PlanningEntity annotations, so the solver config XML file is optional, used only for rare use cases that do power tweaking.

Furthermore, it automatically injects a SolverManager, SolverFactory and/or SolverConfig in your code:

To use the starter with Maven, add this dependency to your pom.xml file:

For Gradle, add this dependency to your build.gradle file:

For more information on how to use this starter, read the detailed guide on spring.io.

The constraint streams API improved further. You can now modify your streams using the groupBy() building block.

To run OptaWeb Vehicle Routing or OptaWeb Employee Rostering on OpenShift, use the new script in their distribution zips:

Two new tabs for OptaWeb Employee Rostering and OptaWeb Vehicle Routing have been added to Download and Documentation pages.

Go to Download and switch to Employee Rostering or Vehicle Routing tab to download a full distribution.

Go to Documentation and switch to Employee Rostering or Vehicle Routing tab to access documentation.

The constraint streams API received a major update, introducing support for streams of 4 facts. Please refer to constraint streams documentation for details.

The optaplanner-webexamples module was removed from distribution and the Git repository. It has been superseded by OptaWeb Vehicle Routing.

PillarSwapMove and PillarChangeMove improved under the hood and are now faster. We observed increases in throughput of around 5 %. Your mileage may vary.

PillarSwapMove and PillarChangeMove now support sequential sub pillars, bringing better scores on examples with clear entity succession, such as employee shift rostering. The simplest configuration of sequential sub pillars looks like this:

For more information, please refer to Documentation.

The programmatic API now supports a more fluent form too, because of the new with*() methods:

Deciding the correct weight and level for each constraint is difficult. It often involves negotiating with different stakeholders and their priorities. Furthermore, quantifying the impact of soft constraints is often a new experience for business managers, so they’ll need a number of iterations to get it right.

So don’t hard-code the constraint weights. Put them in a new constraint configuration class:

Here, the theme track conflict constraint has a default weight of 10soft and the content conflict constraint of 100soft. When we expose these properties in a UI, the business manager can change those numbers, based on negotiations with the different stakeholders.

In DRL, call the new reward() and penalize() methods to change the score by the constraint weight (optionally multiplied a match weight parameter):

Devoxx and Voxxed organizers can now import conference data directly from the CFP REST API, just by specifying the conference instance’s api url (e.g. http://dvbe18.confinabox.com/api/conferences/dvbe18 for Devoxx Belgium 2018). OptaPlanner will then take care of importing all the data and you can start solving and generating the schedule right away.

Optionally, configure a score difference threshold by which the best score must improve in the specified time. For example, if the score doesn’t improve by at least 100 soft points every 30 seconds or less, it terminates:

OptaPlanner can now solve one dataset (without partitioning) with multiple threads to take advantage of multiple CPU cores.

Even with just a few CPU cores, it triples the score calculation speed:

Multithreaded incremental solving is easy to activate. Just add a <moveThreadCount> line in your solver config:

This basically donates 4 extra CPU cores to the solver. Use AUTO to have OptaPlanner deduce it automatically. Optionally, specify a <threadFactoryClass> for environments that don’t like arbitrary thread creation.

For more information about the complex challenges behind this feature, read this blog post.

The TOC is now collapsed by default for a better overview.

Use the new search field to find a phrase in the TOC:

To make it easier to understand why a solution is infeasible during development (before the UI makes use of the ConstraintMatch API), use explainBestScore() after solving:

For example, it might print:

To pin down an assignment and force OptaPlanner to leave it untouched, simply add the @PlanningPin annotation on a planning entity’s boolean property and make it true for those that are immovable:

This is syntactic sugar for the more flexible and more verbose movableEntitySelectionFilter.

Assign each conference talk to a timeslot and a room. Timeslots can overlap. Read/write to/from an *.xlsx file that can be edited with LibreOffice or Excel too.

Hard constraints:

Soft constraints:

PlannerBenchmark has a new method benchmarkAndShowReportInBrowser() to automatically open the benchmark report in the default browser after the benchmark has finished.

Variable Neighborhood Descent is useful for certain use cases with a limited scale. To use it, configure it like this:

There isn’t a valid excuse anymore to not use the benchmarker. You can now run it in just a few lines of Java code (no XML code):

This builds and runs a vanilla benchmark that gives insight in the performance and scalability of your implementation. To get more insight, switch to the XML configuration.

OptaPlanner now integrates with the Guided decision table editor. Modify the score with a build-in OptaPlanner actions that can be accessed in the Action BRL fragment column type.

The KIE Server now exposes an interface to update a problem dataset while the solver is running. Use Java client or REST interface to submit your ProblemFactChange implementations.

It’s now easier to power tweak the Construction Heuristic’s move selectors if desired. This especially useful to improve scaling for use cases with multiple planning variables.

For example, in course scheduling this will first assign a period to lecture and then a room to a lecture (instead of the combination of both which is the default behaviour):

This means that it will evaluate a lot less moves, resulting in a Construction Heuristic that end much quicker at the cost of solution quality (which Local Search can usually make up for in the time gained).

The Workbench examples now include the dinnerparty project, which uses a Guided decision table to define score constraints.

OptaPlanner 7.x now requires Java 8 or higher to run. The 6.x releases remain compatible with Java 6 or higher.

The API and implementation now make use of Java 7 and Java 8 features (such as lambdas).

OptaPlanner now has out of the box support for solving a single dataset by partitioning across multiple threads. So it makes use of multiple CPU cores for a single problem.

Partitioned Search can implement geo-fencing for Vehicle Routing use cases. For example, we can split up Great Britain into 4 parts and solve those parts separately:

This can potentially reduce solution quality, but for big datasets (usually above 5000 entities) the performance gains normally outweighs the long-term quality loss, because when a result is needed within hours or less, the solution quality is still higher.

Especially for Construction Heuristics, it can deliver an initial, feasible solution in a fraction of the time. For example, we’ve benchmarked a 30 time speed increase by partitioning Construction Heuristics in 4 parts running on 4 CPU cores, on an 8 core machine for a dataset with 4800 entities and 1200 planning values. This speed is attributed not just to the utilization of more CPU cores (at most a times 4 increase), but mainly to the problem search space size reduction per part thread.

Partitioned Search is configured like any other solver phase:

There is support to limit the number CPU cores OptaPlanner consumes (to avoid CPU starving other processes and thread) through runnablePartThreadLimit. Furthermore, it is also possible to configure a threadFactoryClass.

For now, you still need to implement the SolutionPartitioner interface, but we’ll add out of the box strategies (such as geo-fencing) soon:

To explain a score in your UI, use the Indictment API to visualize the broken constraints:

Call ScoreDirector.getIndictmentMap() to extract the score per planning entity:

It’s even possible to break it down further, to see which specific constraints that lecture actually triggered.

Your solution class no longer needs both have the @PlanningSolution annotation and implement the Solution interface. No need to repeat yourself anymore. The Solution interface is now deprecated (but still works for backwards compatibility): only the @PlanningSolution annotation suffices.

Instead of implementing the old interface methods, annotate your Score getter with @PlanningScore. If you’re using Drools score calculation, annotate all problem fact getters (or fields) with @ProblemFactCollectionProperty or @ProblemFactProperty.

Solving hasn’t changed:

Contributed by Lukáš Petrovický.

Planner now picks it up automatically from the domain model.

To marshall a Score from or to XML or JSON, use the appropriate binder for XStream, JAXB or Jackson in optaplanner-persistence-xstream, optaplanner-persistence-jaxb and optaplanner-persistence-jackson.

These will create pretty XML:

And beautiful JSON:

See the documentation on how to configure them.

To test each score rule individually, to assure it does what the business expects it to do, use the new ScoreVerifier support classes in optaplanner-test.

Assign tasks to employee and take into account required skills, affinity with the customer and task priority. This example also demonstrates real-time producing and consuming of tasks.

OptaPlanner Solver editor screen now supports adding all termination types, including composite termination. Phase configuration section allows to tweak Construction Heuristic settings and select Local Search algorithm to optimize your planning problem.

OptaPlanner now integrates with the Guided rule editor. Modify the score with a build-in OptaPlanner action.

Examples are now part of the Workbench and they work offline too. Leverage tag-based filtering to quickly access projects from the field you are interested in.

OptaPlanner domain editor can now specify a planning entity difficulty. Navigate through the object hierarchy and define the sorting attributes. Several Construction Heuristic algorithms use this information to construct a better initial solution.

ServiceResponse wrapper has been removed from OptaPlanner service responses returned by KIE Execution Server. This allows an easier processing of the responses on the client side.