ACE: Java Constraint Solver

• ACE is an open-source Java constraint solver that handles integer and Boolean variables in XCSP3 instances using state-of-the-art table filtering and reversible dancing links.
• It features a modular architecture with 13 packages covering parsing, constraint propagation, heuristic search, and optimization, making it versatile for both research and competitions.
• The solver employs efficient domain restoration, diverse constraint support, and modern search strategies such as weighted-degree and restart techniques to enhance performance.

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 (Lecoutre, 2023).

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 (Lecoutre, 2023).

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 (Lecoutre, 2023).

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 (Lecoutre, 2023). 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 (Lecoutre, 2023). 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 (Lecoutre, 2023).

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 (Lecoutre, 2023).

4. Constraint coverage and propagation mechanisms

ACE implements all XCSP3-core constraints over finite integers (Lecoutre, 2023). 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 $\{0,1\}$0 and each value $\{0,1\}$1, there is at least one tuple in $\{0,1\}$2 consistent with $\{0,1\}$3 (Lecoutre, 2023).

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 $\{0,1\}$4–$\{0,1\}$5 speedups over older STR variants (Lecoutre, 2023). This makes table processing a defining strength of the solver.

The language-based family includes ConstraintRegular, for conformance of $\{0,1\}$6 to a DFA, and ConstraintMDD, for conformance of $\{0,1\}$7 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 (Lecoutre, 2023).

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 (Lecoutre, 2023). 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 (Lecoutre, 2023). 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 (Lecoutre, 2023). 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 (Lecoutre, 2023). 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 $\{0,1\}$8 of cost $\{0,1\}$9 is found, ACE updates a special objective constraint to

$O(1)$0

Other strategies are OptimizerIncreasing and OptimizerDichotomic, corresponding respectively to ramp-up and binary search on the bound (Lecoutre, 2023).

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 (Lecoutre, 2023).

6. Competitive performance, strengths, and known limitations

ACE has competed in XCSP3 competitions from 2022 to 2024 (Lecoutre, 2023). In the 2024 XCSP3 COP track, the default configuration “ACE,” described as default $O(1)$1, 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 (Lecoutre, 2023).

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 (Lecoutre, 2023). This suggests a solver aimed simultaneously at practical benchmark performance and at serving as a research platform for CP implementation techniques.