FF4j Feature Flags for Java: Setup and Architecture

FF4j's Runtime Control for Java Applications

FF4j addresses the need to change application behavior without deploying a new build. It is aimed at Java developers who want guarded code paths, gradual releases, operational toggles, or centralized feature state. The README identifies FF4j as an implementation of Martin Fowler's Feature Toggle pattern and says that feature code can contain multiple paths selected by dynamic predicates.

The scope extends beyond a single on or off value. Features can also be evaluated against roles and groups, which the README associates with canary release control. Applications can define custom predicates through the Strategy pattern. FF4j includes strategies for allow and deny lists, time-based evaluation, and expression-based evaluation, while its extension points also permit integration with external rule engines such as Drools.

This makes FF4j relevant to code that needs operational controls rather than deployment-time configuration. A static environment property can select one implementation for a whole build. FF4j instead represents flag evaluation as part of the running application, with storage, administration, and event collection around that decision. It is less appropriate when a boolean buried in one configuration file already provides enough control.

FF4j Evaluation Paths Across Code, AOP, and APIs

FF4j supports several ways to connect feature state to an application. The direct model places a dynamic predicate around alternative paths in Java code. The project also offers AOP-driven toggling through `ff4j-aop`, allowing application code to use annotations instead of maintaining deeply nested conditional branches. The README states that Spring AOP selects the target implementation at runtime according to feature status.

Administration has a separate path. `ff4j-web` packages a servlet web console for features and properties, while `ff4j-webapi` exposes a REST API. The README specifically presents the REST API as an option for clients written in other languages, including JavaScript frontends. It also mentions `FeatureStoreHttp` as a way to avoid connecting a microservice directly to the database.

These entry points address different operational boundaries. Embedded code and AOP are relevant inside a JVM application. The REST API serves remote administrators or clients outside that process. The web console and JMX interface serve administrators and external operational tools. `ff4j-cli` provides a command-line route that interacts directly with storage, which is relevant when production web ports are unavailable. The repository layout shows these as separate modules, so adoption does not automatically mean deploying every interface.

FF4j Stores, Caching, and Runtime State

Feature state must come from somewhere, and FF4j treats persistence as an extension point. The repository contains dedicated modules for relational and nonrelational systems, including Spring JDBC, MongoDB, Redis, Cassandra, Couchbase, Neo4j, DynamoDB, Google Cloud Datastore, Hazelcast, Ignite, HBase, Elasticsearch, ArangoDB, Consul, Archaius, Commons Configuration, and Spring Cloud Config. The README describes support for more than 20 database technologies. That breadth is useful when an application already has an approved data system, but it also means the core library does not remove the need to choose and configure a store.

Predicate evaluation can otherwise place repeated read pressure on storage. The README says FF4J offers local and distributed caches through JSR-107-compatible cache implementations. It also states that editing a feature evicts relevant cache entries. This design separates frequent evaluation from management changes, but it adds another configuration concern when distributed caching is selected.

FF4j also stores general properties in addition to feature states. Those properties can be consumed through integrations including Spring, Archaius, Commons Configuration, and Consul. This can consolidate runtime configuration, but it may also blur responsibility between feature controls and ordinary application settings. The documentation does not prescribe a migration or rollback procedure, so existing configuration ownership should be settled before moving property management into FF4j.

FF4j Installation and First Use Through the Project Guide

The README does not provide a Maven dependency declaration, Java class example, configuration file, or complete command sequence. It instead directs new users to the project documentation at `http://ff4j.github.io/#10min` and links the repository wiki for reference documentation. Because the available project documentation does not show the version-specific coordinates or module setup in this README, this review does not invent a `pom.xml` snippet or startup command.

A first useful setup should be scoped to one Java module and one storage choice. Based on the repository layout, an application using Spring AOP would examine `ff4j-aop`; one using the web console would also examine `ff4j-web`; one calling FF4j from another service would examine `ff4j-webapi-client` or `FeatureStoreHttp`. The exact dependency and configuration must come from the linked getting-started guide or the selected module's own documentation.

For the first real flag, the documentation's stated pattern is to protect alternative code paths with a dynamic predicate. A developer should confirm the flag identifier and selected strategy before connecting that predicate to business behavior. This review cannot provide verified executable code because the README contains no such example. The getting-started page is the authoritative next step for installation and initial wiring.

FF4j Monitoring, Audit History, and Administrative Scope

FF4j records that a predicate has been evaluated, allowing applications to collect execution events and metrics. The README says these records can support dashboards and graphs of feature use over time. This is more informative than merely reading the current boolean value, especially when a flag gates a feature that many requests reach continuously.

The project also describes an audit trail for create, update, delete, and toggle actions. It links identity attribution to `AuthorizationManager`, which can identify users who performed operations when suitable permissions management is configured. The repository includes separate security modules for Shiro and Spring, while the web components provide the console and API surfaces through which administration occurs.

These capabilities also define the operational attack surface. A feature store may contain control decisions, and an administrative interface may allow changes to those decisions. The README does not document authentication defaults, transport configuration, backup procedures, or recovery behavior. Those points should should be checked against the chosen web, security, and storage modules before exposing FF4j outside a trusted environment.

FF4j Module Boundaries and Upgrade Cost

FF4j is organized as a multi-module Maven repository. Core evaluation lives in `ff4j-core`, with separate modules for AOP, configuration formats, JMX, CLI support, security integrations, storage systems, web administration, REST clients, testing, JSON utilities, and Drools strategies. This structure allows an application to avoid carrying unrelated integrations, although it also requires deliberate module selection.

The latest listed release is 3.0.0, published on 2026-09-30, following `3.0.0-RC1` on 2026-08-04. The repository was not archived, and its last push was on 2026-10-16. Those facts support recent development activity, but they do not document migration requirements from 2.0.0 or compatibility with every storage module.

FF4j is licensed under Apache-2.0. The license permits use and modification under its stated terms, including preservation of copyright and license notices and the patent conditions described by Apache-2.0. That is a factual summary, not legal advice. Upgrade planning should focus on the release notes, module-specific dependency changes, persistent data compatibility, and the behavior of custom strategies or stores, none of which can be determined from the truncated README.

FF4j Compared with a Plain Java Configuration Switch

The closest alternative is a plain environment property, JVM system property, or `application.properties` boolean checked directly in Java. That approach has a different philosophy: configuration is read by the application, and the code follows a fixed conditional. It avoids FF4j's feature store, cache, web console, audit trail, strategy modules, and API surfaces.

FF4j fits the larger problem when several application instances need runtime decisions that operators can inspect and change, when rules depend on roles, groups, time, expressions, or external engines, or when administrators need a central interface. The strategy model is also the meaningful difference for canary and rule-driven releases. A plain boolean can represent a toggle, but it does not itself provide FF4j's predicate types or execution monitoring.

Conversely, FF4j is excessive for a service with one rarely changed switch and no shared administration requirement. The additional modules and persistence choices create configuration and upgrade work that a local boolean avoids. A distributed feature-flag service could serve multiple languages through its own API, while FF4j is described primarily as a Java library whose REST API also supports external clients. The correct comparison is therefore control-plane requirements, not simply the number of available features.

Editorial conclusion

FF4j is appropriate for Java teams that need runtime control, multiple storage options, and administrative access beyond a basic configuration switch. It is a poor fit for a small application with one isolated boolean and no operational need for flag evaluation or administration. Before adopting version 3.0.0, verify the chosen storage module, the framework integrations, and the deployment requirements of the web console or REST API. For version 3.0.0 adoption, the first project-specific check is whether the required store and web components match the application's existing Java and persistence stack.

Frequently asked questions

Official sources

1. ff4j/ff4j on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases