Release Notes 6.3

We are happy to announce a 6.3 Final release of OptaPlanner. OptaPlanner is a lightweight, embeddable planning engine written in Java™ to solve AI constraint optimization problems efficiently. Use cases include Vehicle Routing, Employee Rostering, Maintenance Scheduling, Task Assignment, School Timetabling, Cloud Optimization, Conference Scheduling and many more.

Download
9.44.0.Final

Documentation
9.44.0.Final

Status of OptaPlanner

Stable: Lots of unit, integration and stress tests
Reliable: Used across the world in production
Scalable: To billions of constraint matches with minimal RAM and CPU time
Documented: Read the detailed reference manual and the many examples
Open Source: Apache License 2.0

Note for Red Hat Decision Manager customers

The RHDM version differs from the OptaPlanner version:

RHDM version	OptaPlanner version
7.8	7.39
7.9	7.44
7.1	7.48
7.11	8.5 (and 7.52)
7.12	8.11 (and 7.59)
7.13	8.13 (and 7.67)

New and noteworthy

Easier solver configuration

Defining the optimization algorithms and their parameters is now optional (but still possible and desirable for power users). If you don’t define any solver phases, a default Construction Heuristic followed by a default Local Search is used.

<solver>
  ...
  <scoreDirectorFactory>
    ...
  </scoreDirectorFactory>

  <!-- No longer required to configure <constructionHeuristic> and <localSearch> -->
</solver>

Automatic scanning for annotated classes

Instead of declaring all annotated classes:

<solver>
  <solutionClass>org.optaplanner.examples.cloudbalancing.domain.CloudBalance</solutionClass>
  <entityClass>org.optaplanner.examples.cloudbalancing.domain.CloudProcess</entityClass>
  ...
</solver>

Planner can now also automatically scan for them instead:

<solver>
  <scanAnnotatedClasses/>
  ...
</solver>

It’s even possible to limit the scan to specific packages.

Field annotations

Instead of getter annotations (on JavaBean properties), Planner now also supports field annotations:

@PlanningEntity
public class CloudProcess {

    @PlanningVariable(valueRangeProviderRefs = {"computerRange"})
    private CloudComputer computer;

    ...
}

@PlanningSolution
public class CloudBalance ... {

    @ValueRangeProvider(id = "computerRange")
    private List<CloudComputer> computerList;

    @PlanningEntityCollectionProperty
    private List<CloudProcess> processList;

    ...
}

Unfolding move selectors for multiple entity classes or multiple planning variables

With multiple planning variables, it’s no longer needed to specify each variable name:

      <changeMoveSelector>
        <valueSelector>
          <variableName>period</variableName>
        </valueSelector>
      </changeMoveSelector>
      <changeMoveSelector>
        <valueSelector>
          <variableName>room</variableName>
        </valueSelector>
      </changeMoveSelector>

Instead, this now works:

      <changeMoveSelector/>

With multiple entity classes, it’s no longer needed to specify each entity class:

      <changeMoveSelector>
        <entitySelector>
          <entityClass>...CoachEntity</entityClass>
        </entitySelector>
      </changeMoveSelector>
      <changeMoveSelector>
        <entitySelector>
          <entityClass>...ShuttleEntity</entityClass>
        </entitySelector>
      </changeMoveSelector>
      <swapMoveSelector>
        <entitySelector>
          <entityClass>...CoachEntity</entityClass>
        </entitySelector>
      </swapMoveSelector>
      <swapMoveSelector>
        <entitySelector>
          <entityClass>...ShuttleEntity</entityClass>
        </entitySelector>
      </swapMoveSelector>

Instead, this now works:

      <changeMoveSelector/>
      <swapMoveSelector/>

This applies to the programmatic API too, of course.

VariableListeners now trigger in a smart order

In advanced use cases with multiple custom shadow variables (or even just one), the immediate order in which a VariableListener was triggered could drive a developer insane because (s)he had to deal with intermediate, inconsistent states for which not all of the genuine variables were already changed.

This has been fixed. OptaPlanner now triggers the VariableListener.after*() methods in the order defined by the shadow variable dependency graph. It guarantees that the first VariableListener triggers after the last genuine variable has changed. It also guarantees that the second VariableListener triggers after all the first VariableListener calls are done, and so on.

Shadow variable order

New Benchmarker bluePrints

There are 2 new benchmarker blueprints:

EVERY_LOCAL_SEARCH_TYPE
EVERY_CONSTRUCTION_HEURISTIC_TYPE_WITH_EVERY_LOCAL_SEARCH_TYPE

It’s now even easier to try out all Local Search algorithms:

<plannerBenchmark>
  <benchmarkDirectory>local/data/cloudbalancing</benchmarkDirectory>
  <inheritedSolverBenchmark>
    ...
  </inheritedSolverBenchmark>
  <solverBenchmarkBluePrint>
    <solverBenchmarkBluePrintType>EVERY_LOCAL_SEARCH_TYPE</solverBenchmarkBluePrintType>
  </solverBenchmarkBluePrint>
</plannerBenchmark>

New example: Investment asset class allocation

To optimize an investment portfolio. See this video. Partially contributed by Satish Irrinki.

Other improvements

A bi-directional relationship with a planning variable is now also supported for a non-chained variable.
2 shadow variables can now share the same VariableListener instance.
ValueRangeProvider now supports long ranges with createLongValueRange(from, to) too.
ValueRangeProvider now supports BigInteger ranges with createBigIntegerValueRange(from, to) too.
Improved Move.toString() methods for more clearer log messages.
Benchmarker report mentions logging level used. Contributed by Matej Čimbora.
Documentation for Android. Contributed by Tomáš David.
Benchmarker’s <solverBenchmark> name now allows non-ASCII characters too (for example Japanese characters).
An OSGi features.xml that includes optaplanner-engine
Drools score calculation now support multiple constraint matches in the consequences part of a rule.
More JavaDocs, including package JavaDocs.
Various bugs resolved. See our issue tracker.