Chapter 2. Red Hat Build of OptaPlanner 8.38 new features This section highlights new features in Red Hat Build of OptaPlanner 8.38. Note Bavet is a feature used for fast score calculation. Bavet is currently only available in the community version of OptaPlanner. It is not available in Red Hat Build of OptaPlanner 8.38. 2.1. Performance improvements in pillar moves and nearby selection OptaPlanner can now auto-detect situations where multiple pillar move selectors can share a precomputed pillar cache and reuse it instead of recomputing the pillar cache for each move selector. If you combine pillar moves, for example, PillarChangeMove and PillarSwapMove , you should see significant performance inprovements. This also applies if you use nearby selection. OptaPlanner can now auto-detect situations where a precomputed distance matrix can be shared between multiple move selectors, which saves memory and CPU processing time. As a consequence of this enhancement, implementations of the following interfaces are expected to be stateless: org.optaplanner.core.impl.heuristic.selector.common.nearby.NearbyDistanceMeter org.optaplanner.core.impl.heuristic.selector.common.decorator.SelectionFilter org.optaplanner.core.impl.heuristic.selector.common.decorator.SelectionProbabilityWeightFactory org.optaplanner.core.impl.heuristic.selector.common.decorator.SelectionSorter org.optaplanner.core.impl.heuristic.selector.common.decorator.SelectionSorterWeightFactory In general, if solver configuration asks the user to implement an interface, the expectation is that the implementation will be stateless or not try to include an external state. With the these performance improvements, failing to follow this requirement will result in subtle bugs and score corruption because the solver will now reuse these instances as it sees fit. 2.2. OptaPlanner configuration improvement Various configuration classes, such as EntitySelectorConfig and ValueSelectorConfig , contain new builder methods which make it easier to replace XML-based solver configuration with fluent Java code. 2.3. PlanningListVariable support for K-Opt moves A new move selector for list variables, KOptListMoveSelector , has been added. KOptListMoveSelector selects a single entity, removes k edges from its route, and adds k new edges from the removed edges' endpoints. KOptListMoveSelector can help the solver escape local optima in vehicle routing problems. 2.4. SolutionManager support for updating shadow variables SolutionManager (formerly ScoreManager ) methods such as explain(solution) and update(solution) received a new overload with an extra argument, SolutionUpdatePolicy . This is useful for users who load their solutions from persistent storage (such as a relational database), where these solutions do not include the information carried by shadow variables or the score. By calling these new overloads and picking the right policy, OptaPlanner automatically computes values for all of the shadow variables in a solution or recalculates the score, or both. Similarly, ProblemChangeDirector received a new method called updateShadowVariables() , so that you can update shadow variables on demand in real-time planning. 2.5. Value range auto-detection In most cases, links between planning variables and value ranges can now be automatically detected. Therefore, @ValueRangeProvider no longer needs to provide an ID property. Likewise, planning variables no longer need to reference value range providers through the valueRangeProviderRefs property. No code changes or configuration changes are required. Users who prefer clarity over brevity can continue to explicitly reference value range providers.

Commands: