Eliminating Startup Decisions: How Feat Moves Runtime Choices to Compile Time for Faster Cold Starts

Move configuration injection to runtime while making decisions at compile time.

Startup latency isn’t Java’s fault

In the cloud‑native era, applications are expected to start quickly, consume few resources, and run anywhere. Containers are frequently started and stopped in Kubernetes, Serverless platforms charge by cold‑start time, and auto‑scaling demands second‑level readiness. Java is often blamed for slow starts and high memory usage, but the real bottleneck lies in framework initialization: scanning classes, loading configurations, resolving placeholders, and detecting the current environment. Each task is reasonable on its own, yet performing all of them during startup creates a heavy cumulative load.

Feat’s approach is straightforward: anything that can be decided at compile time must never be deferred to startup.

Three‑layer configuration, each handling a distinct concern

Feat splits configuration into three layers, each answering a single question:

How to run at startup → CloudOptions : Port, scan range, external beans, and other fine‑tuning parameters are defined here without altering code structure.

What differs between environments → feat.yml paired with profiles. Differences among development, test, and production are compiled into separate code artifacts, so at startup the application simply loads the pre‑generated artifact for the target environment without reading, merging, or evaluating anything.

Where do sensitive values come from → ${} placeholders : Database passwords, third‑party keys, and other secrets are injected at runtime from system properties or environment variables.

The core principle of this three‑layer division is: "Structure is fixed early, values are injected at runtime." The repository stores only the configuration skeleton; actual secrets and dynamic values are supplied by the deployment environment.

${} : A simple implementation of externalized configuration

${}

is the most recent addition to Feat’s configuration system and directly implements the Cloud Native "configuration externalization" principle.

Usage is straightforward: write the entire value as ${name} or ${name:default}. For example, a database password can be expressed as ${db.password} and injected at startup via an environment variable: DB_PASSWORD=secret java -jar yourapp.jar Resolution priority is clear: system properties first, then environment variables, and finally the fallback default value. This aligns perfectly with Kubernetes Secrets, CI/CD pipeline variable injection, and dynamic configuration on Serverless platforms.

Feat deliberately simplifies this feature: ${} only reads external sources and never references other entries in feat.yml. It accepts only system properties and environment variables, avoiding the complexity and debugging cost of inter‑config references.

Even the application port can be externalized, e.g., ${port:8080}. When a Serverless platform assigns a dynamic port, the application adapts without code changes.

Continuous refinement: listening to feedback while staying on course

Feat’s improvements stem from two sources.

Real‑world feedback : Issues such as proxy bean injection, list‑type return adaptation, and AOT compilation error messages were addressed. These are not new features but refinements that smooth the developer experience by filling gaps discovered during cloud‑native adoption.

Architectural vision : Upgrading fastjson to 2.0.64, unifying serializers, and standardizing configuration parsing tools do not directly affect end users, yet they all serve the same goal—reducing runtime uncertainty and making compile‑time generated code more stable and predictable.

Community feedback determines what to fix; technical vision decides where to go. Together they shape Feat’s evolution.

Cloud‑native is an architectural mindset

Can Java achieve lightweight startup in cloud‑native environments? Feat’s answer is yes—without changing the language, just by changing the mindset.

By generating environment‑specific code at compile time, injecting sensitive configuration at runtime, and finalizing serialization and type handling during the build, Feat eliminates uncertainty early rather than deferring it to startup.

The essence of cloud‑native is not containers, Kubernetes, or microservices; it is an engineering choice: "Make decisions as early as possible, never postpone them to runtime." When an application starts in seconds and a single image runs everywhere, the magic lies in compile‑time answers already baked into the binary.