Replace if-else Sprawl with a 100KB Java Rule Engine
Business-rule churn is a constant cost center. Easy Rules gives Java teams a low-ceremony way to decouple rules from application code so changes don't require recompilation or redeployment when using expression-language or YAML definitions. The trade-off is that the project is in maintenance mode, so teams betting on it accept a frozen feature set in exchange for a tiny, fast, and well-understood engine.
A single discount-calculation method can balloon past 300 lines as promotions, user tiers, and seasonal events pile on. Easy Rules, a 100KB open-source Java library from the j-easy team, moves each condition-action pair into its own class or expression string. Rules register in an ordered set, and a rules engine evaluates them against a shared Facts context, executing only those whose conditions hold.
Four definition styles cover the spectrum from hardcoded annotations to MVEL/SpEL/JEXL expressions stored in a database or YAML config. Composite rules — UnitRuleGroup, ActivationRuleGroup, and ConditionalRuleGroup — handle AND logic, exclusive-or priority selection, and conditional chaining without nested if statements. A listener API hooks into every lifecycle step for logging, metrics, or debugging.
The library entered maintenance mode in late 2020 at version 4.1.x, so it won't gain new features, but its core is stable. It suits systems with dozens to a few hundred rules; for thousands of rules or decision-table workloads, a Rete-algorithm engine like Drools fits better.
Easy Rules occupies a deliberate middle ground: heavier than hand-rolled if-else maps stored in a database, but far lighter than a full Rete-based engine. That makes it a pragmatic stepping stone — start simple, migrate to Drools only when rule count or complexity forces the move.
The library's maintenance-mode status is a double-edged signal. It means the API is frozen and won't surprise you with breaking changes, but it also means no community-driven improvements for modern Java features like records or pattern matching will arrive.
Storing rules as MVEL or SpEL strings in a database or config file is the feature that unlocks zero-downtime rule changes, yet the article notes this still requires a custom hot-reload mechanism. Out of the box, expression-based rules still need an application restart unless you build the reload logic yourself.
Haha, seeing this feels so familiar. When I was doing Java, I also stacked a pile of if-else — a single coupon calculation method was almost 400 lines 😂 Later I switched to Python for crawlers and price monitoring systems, and found that Python actually has a wilder way to handle rule complexity — just write a yaml config file, validate it with pydantic, then use a simple dispatch function with reflection to call it. It's not as engineered as Easy Rules, but it's enough for small to medium scale. But honestly, if I were still on the Java side back then, Easy Rules is indeed way better than pure if-else, at least you don't have to recompile and redeploy every time you add a rule.