---
title: 'ACE: Java Constraint Solver'
url: https://www.emergentmind.com/topics/ace
type: topic
---

# ACE: Java Constraint Solver

Searching arXiv for the specified ACE solver paper and closely related CP/XCSP3 context.
ACE is an open-source constraint solver developed in Java for Constraint Programming, intended to solve combinatorial constrained problems, notably instances represented in XCSP3 format. It focuses on integer variables, including \(0/1\)-Boolean variables, and supports state-of-the-art table constraints, popular global constraints, search heuristics, and mono-criterion optimization. Within the modeling-and-solving workflow described with PyCSP3 on the modeling side and XCSP3 on the instance side, ACE occupies the solver layer: problem instances can be directly generated from models and data, and then solved by ACE [2302.05405].

## 1. Position in the CP workflow

Constraint Programming is presented as a technology for modeling and solving combinatorial constrained problems arising in scheduling, planning, data-mining, cryptography, bio-informatics, organic chemistry, and related domains. In that workflow, a library like PyCSP3 is used for modeling, while ACE is used for solving instances, notably those represented in XCSP3 format [2302.05405].

The top-level entry point of the solver is the class `main.Head`, whose alias is `ace`. Its execution path is explicit: it parses XCSP3 instances, builds a `Problem` object, instantiates a `Solver` object, and launches preprocessing followed by backtrack search. The documented invocation form is `java ace airTraffic.xml -t=10s`, which makes the intended usage model concrete: ACE is a command-line solver centered on XCSP3 ingestion and CP search.

ACE is also positioned as an implementation platform rather than only a monolithic executable. It is accessible on GitHub under the MIT license, and its internal decomposition exposes the main solver services as Java packages and interfaces. This suggests a design intended both for direct use in competitions or batch solving and for extension within a research codebase.

## 2. Software architecture and implementation organization

ACE is organized into 13 packages, reflecting a decomposition into parsing, domains, constraints, propagation, learning, heuristics, optimization, and runtime control [2302.05405].

| Package | Representative contents |
|---|---|
| `main` | `Head`, `HeadExtraction` |
| `dashboard` | `Control`, `Input`, `Output` |
| `interfaces` | observer and tag interfaces |
| `utility` | `Stopwatch`, `Reflector`, `Bit`, `Kit` |
| `sets` | `SetLinked`, `SetDense`, `SetSparse`, reversible variants |
| `problem` | `Problem`, `Features`, `Reinforcer`, XCSP3 parser |
| `variables` | integer/symbolic variables, domains, `TupleIterator` |
| `constraints` | `Constraint`, intension, extension, global subpackages |
| `solver` | `Solver`, `FutureVariables`, `Decisions`, `Solutions`, `Restarter`, `LastConflicts`, `Statistics` |
| `propagation` | `Forward` and `Backward` propagation |
| `learning` | `Nogood`, `Ips`, `NogoodReasoner`, `IPsReasoner` |
| `heuristics` | variable and value heuristics |
| `optimization` | `Optimizer*`, `ObjectiveVariable` |

This package structure makes clear that ACE integrates the full CP pipeline internally: parsing and problem construction, domain and constraint representation, filtering, search control, learning, and optimization. The propagation layer distinguishes `Forward` methods such as FC, AC, SAC, and GIC from `Backward` methods such as BT and GT. The solver package also makes restart management, conflict handling, and statistics first-class components.

The paper also notes a specific architectural limitation: the main class still inherits unused interfaces left over from AbsCon, and a refactoring is planned [2302.05405]. That observation is significant because it situates ACE historically as an evolved codebase rather than a greenfield implementation.

## 3. Variables, domains, and internal state representation

ACE handles only integer and symbolic variables [2302.05405]. Boolean variables are encoded as `DomainBinary`, with values \(\{0,1\}\), and symbolic values are mapped to small integers. The solver is therefore finite-domain in orientation, with symbolic support reduced internally to integer reasoning.

A central implementation choice is the representation of integer domains through “dancing links,” implemented as a reversible doubly-linked list of value indices in `sets.SetLinked`. This representation preserves increasing order and supports \(O(1)\) removal and restoration at backtrack levels. Internally, an \(n\)-value domain is stored with arrays `next[]` and `prev[]` of size \(D\), together with head and tail pointers and a level marker for each removed value [2302.05405].

This choice is technically consequential. It aligns domain maintenance with chronological backtracking and reversibility, and it avoids reconstructing domains during search. A plausible implication is that ACE prioritizes low-level state restoration efficiency over more elaborate domain abstractions. The paper also explicitly states a limitation here: handling of very large domains is poor because ACE has no sparse-set domains nor interval merging, and improvements are foreseen [2302.05405].

## 4. Constraint coverage and propagation mechanisms

ACE implements all XCSP3-core constraints over finite integers [2302.05405]. The supported constraints are grouped into generic, language-based, comparison-based, counting, connection, and packing-and-scheduling families.

The generic layer contains `ConstraintIntension`, which supports any Boolean expression tree, and `ConstraintExtension`, which supports table constraints. ACE handles ordinary tables \(T \subseteq D_1 \times \dots \times D_k\), starred tables with `*` wildcards, and hybrid or smart tables. For extension constraints on variables \(\vec X\) of arity \(k\), satisfaction holds iff the current tuple \(t \in D_1 \times \dots \times D_k\) belongs to the static table \(T\). Arc-consistency requires that for each variable \(X_i\) and each value \(a \in D_i\), there is at least one tuple in \(T\) consistent with \(a\) [2302.05405].

For extension filtering, ACE provides VA, STR1, STR2, STR3, and CT. The CT implementation is the Compact-Table algorithm with reversible sparse bitsets. On large table-constraint benchmarks, this CT implementation yields \(2\times\)–\(10\times\) speedups over older STR variants [2302.05405]. This makes table processing a defining strength of the solver.

The language-based family includes `ConstraintRegular`, for conformance of \(\vec X\) to a DFA, and `ConstraintMDD`, for conformance of \(\vec X\) to an MDD structure. Comparison-based constraints include `alldifferent`, `allDifferentList`, `allEqual`, `increasing`, `decreasing`, `lexIncreasing`, `lexDecreasing`, and `precedence`. Counting constraints include `sum`, `count`, `nValues`, and `cardinality`. Connection constraints include `maximum`, `maximumArg`, `minimum`, `minimumArg`, `element`, and `channel`. Packing and scheduling constraints include `noOverlap`, `cumulative`, `binPacking`, and `knapsack` [2302.05405].

Propagation is expressed through specific propagators; the interface signature shown in the paper is a method `runPropagator(Variable evt)` returning `false` on domain wipeout. The solver’s default search mode uses forward arc-consistency, but the package layout indicates broader support for FC, AC, SAC, and GIC, together with backward mechanisms BT and GT [2302.05405]. The current `noOverlap` propagator is explicitly described as naive; a full edge-finding or “not-first/not-last” implementation is on the to-do list.

## 5. Search control, heuristics, learning, and optimization

ACE uses classic chronological backtracking with constraint propagation, with forward arc-consistency by default [2302.05405]. To address heavy-tailed behavior, it uses restarts, either geometric or Luby, together with nogood recording from restarts.

Variable ordering is implemented through subclasses of `HeuristicVariablesDynamic` by overriding `scoreOf(Variable x)`. The documented heuristics include `dom`, `wdegOnDom` and weighted-degree variants such as `UNIT`, `CACD`, and `CHS`, as well as `frbaOnDom`, `pickOnDom`, `rand`, `DDegOnDom`, `Activity`, and `Impact`. The conflict-based heuristic variants E, M, and L differ in where blame is assigned: early blames the decision variable, midway blames all variables touched during propagation, and late blames the last constraint to produce a wipeout [2302.05405]. Variable-ordering selection is exposed at the command line through options such as `-varh=WdegOnDom -wt=cacd`, and ACE can mix three heuristics through `-rr`, yielding the configuration referred to as ACE-mix.

Value ordering is implemented through subclasses of `HeuristicValuesDirect` or `HeuristicValuesIndirect` by overriding `computeBestValueIndex()`. The documented heuristics are `Rand`, `First`, `Last`, `Robin`, `RunRobin`, and `Bivs`, selectable for example with `-valh=Rand` [2302.05405]. ACE also includes `LastConflicts`, which remembers the last conflict decision point to guide subsequent variable choice, and solution-based phase saving: on COPs, when a bound is improved, ACE first tries the value found in the previous best solution.

Optimization is mono-criterion. Objectives implement the interface `Optimizable`, and the simplest case is a single objective variable. The branch-and-bound ramp-down strategy is handled by `OptimizerDecreasing`: whenever a solution \(S\) of cost \(B = obj(S)\) is found, ACE updates a special objective constraint to
\[
obj < B.
\]
Other strategies are `OptimizerIncreasing` and `OptimizerDichotomic`, corresponding respectively to ramp-up and binary search on the bound [2302.05405].

ACE also contains a learning layer with `Nogood`, `Ips`, `NogoodReasoner`, and `IPsReasoner`. However, IPS learning is currently deactivated for maintenance reasons and may be reactivated in the future [2302.05405].

## 6. Competitive performance, strengths, and known limitations

ACE has competed in XCSP3 competitions from 2022 to 2024 [2302.05405]. In the 2024 XCSP3 COP track, the default configuration “ACE,” described as default \(wdeg^{CACD}\), scored very well on proof-oriented plots, while “ACE-mix,” based on a heuristic portfolio through `-rr`, excelled in search-oriented performance by finding high-quality bounds quickly. The paper also notes that SAT-based solvers dominate in proofs, which places ACE’s performance in a mixed CP/SAT competitive landscape rather than presenting it as universally dominant.

Several implementation limitations are identified explicitly. The inheritance of unused interfaces in the main class remains as technical debt from AbsCon. Handling of very large domains is poor because ACE lacks sparse-set domains and interval merging. The current `noOverlap` constraint uses only a naive propagator, with edge-finding and “not-first/not-last” listed as future work. IPS learning is disabled for maintenance reasons [2302.05405].

Taken together, these features characterize ACE as a compact, extensible, and competitive Java CP solver centered on integer CSPs and COPs, with especially strong support for XCSP3-core modeling, reversible domain maintenance, state-of-the-art table filtering, and a broad search-and-restart apparatus [2302.05405]. This suggests a solver aimed simultaneously at practical benchmark performance and at serving as a research platform for CP implementation techniques.

Source: https://www.emergentmind.com/topics/ace