Understanding EasyRules: Core Execution Flow and Design of the Java Rule Engine

Introduction

EasyRules is a lightweight Java rule engine that simplifies rule‑based decision making. The article analyses the engine’s core execution flow and the design decisions behind its source code.

Project Structure

The EasyRules repository is organized into several Maven modules:

easy-rules-archetype – project scaffolding

easyrules-core – core rule engine functionality

easyrules-mvel – integration with the MVEL expression language

easyrules-spel – integration with Spring Expression Language (SpEL)

easy-rules-jexl – JEXL support

easyrules-support – utilities such as YAML rule definitions

easyrules-tutorials – example applications

The analysis focuses on the four core modules: easyrules-core , easyrules-mvel , easyrules-spel , and easyrules-support .

Facts Container

The Facts class stores input data for rules. Internally it holds a Set<Fact<?>> and provides methods such as put(String name, T value), add(Fact<T> fact), remove(String name), get(String name), asMap(), iterator(), and clear(). The article shows screenshots of the source and example usage:

Facts facts = new Facts();
facts.put("weather", "sunny");
Fact<String> f = new Fact<>("temperature", "20C");
facts.add(f);
String w = facts.get("weather");
Map<String, Object> map = facts.asMap();

Rule Definition

Rules implement the Rule interface, which defines evaluate(Facts facts) (condition) and execute(Facts facts) (action). Each rule has a name, description, and priority (lower value = higher priority). The article presents a simple HelloWorldRule class and the corresponding interface diagram.

Rule Registration and Dynamic Proxy

Rules are collected in a Rules object via register(rule). When a rule is annotated rather than directly implementing Rule, RuleProxy.asRule(rule) creates a dynamic proxy that implements Rule and Comparable. The proxy validates the rule definition, intercepts method calls, and maps @Condition and @Action annotations to the engine’s evaluation and execution steps.

Engine Implementations

Two engine classes implement RulesEngine:

DefaultRulesEngine – iterates the rule set once, evaluates each rule, and executes actions for rules whose conditions are true. Suitable for independent rules.

InferenceRulesEngine – after executing a rule, re‑evaluates all rules, allowing newly satisfied conditions to trigger further rules. Suitable for dependent or recursive rule sets.

Example code creates a DefaultRulesEngine and fires the rules:

RulesEngine engine = new DefaultRulesEngine();
engine.fire(rules, facts);

Fire Method (doFire) Workflow

The doFire method follows these steps:

Check if the rule set is empty and log a warning.

Log engine parameters, rules, and facts.

Iterate over each rule, checking the priority threshold.

Invoke pre‑listener interceptors ( shouldBeEvaluated).

Call rule.evaluate(facts) to decide execution.

Handle exceptions according to configuration.

If evaluation is true, call rule.execute(facts) and record the outcome.

Control flow may skip remaining rules based on parameters.

The article also shows how the dynamic proxy forwards evaluate and execute calls to the annotated methods.

Conclusion

The EasyRules source demonstrates a clean separation of concerns: facts as a data container, rules as isolated condition‑action units, and engines that orchestrate execution. The use of dynamic proxies to adapt annotated classes, together with the modular Maven layout, provides a practical example of designing an extensible, lightweight rule engine for Java applications.