@ConfigurationProperties binding of a List<JavaBean> can loop until OutOfMemoryError in 4.1.0 (was a bounded BindException in 4.0.6)

[Lumenol]

Spring Boot version

• Reproduced on 4.1.0
• Behaves differently on 4.0.6 (no OOM — see below)
• JVM: Eclipse Temurin 25.0.3+9 (LTS) · OS: macOS 26.5.1 (arm64)
• (the binder logic is plain Java, so it is unlikely to be JVM/OS-specific, but this is the configuration I verified)

Describe the bug

When a @ConfigurationProperties object has a List<SomeJavaBean> property, and an indexed element
(prefix.list[i]) resolves to a non-null but empty value, binding does not terminate: the application
fails to start with a deterministic java.lang.OutOfMemoryError: Java heap space during context
initialization. The heap is exhausted allocating ConfigurationPropertyName instances inside
IndexedElementsBinder.bindIndexed.

On 4.0.6 the exact same setup does not OOM — binding stops quickly with a clear, bounded error:

Failed to bind properties under 'app.routes[0]' to com.example.demo.DemoApplication$RouteConfig

So a previously bounded failure has become an unbounded allocation / OOM.

I hit this while upgrading a real application from 4.0.6 to 4.1.0 (the app's context OOMed on startup binding a
List<...> @ConfigurationProperties). The snippet below is a reduced, standalone reproduction.

Stack trace (4.1.0)

Caused by: java.lang.OutOfMemoryError: Java heap space
    at org.springframework.boot.context.properties.bind.IndexedElementsBinder.bindIndexed(IndexedElementsBinder.java:117)
    at org.springframework.boot.context.properties.bind.IndexedElementsBinder.bindIndexed(IndexedElementsBinder.java:92)
    at org.springframework.boot.context.properties.bind.IndexedElementsBinder.bindIndexed(IndexedElementsBinder.java:76)
    at org.springframework.boot.context.properties.bind.CollectionBinder.bindAggregate(CollectionBinder.java:50)
    at org.springframework.boot.context.properties.bind.JavaBeanBinder.bind(JavaBeanBinder.java:127)
    at org.springframework.boot.context.properties.bind.JavaBeanBinder.bind(JavaBeanBinder.java:115)
    at org.springframework.boot.context.properties.bind.JavaBeanBinder.bind(JavaBeanBinder.java:71)

How to reproduce

Full runnable project (just spring-boot-starter, single Java file, run.sh with a small heap):
https://github.com/Lumenol/spring-boot-4.1-binder-oom — flip the parent version between 4.1.0 and
4.0.6 in pom.xml.

The two relevant files are inlined below.

DemoApplication.java:

package com.example.demo;

import java.util.ArrayList;
import java.util.List;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.event.ApplicationEnvironmentPreparedEvent;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.context.ApplicationListener;
import org.springframework.core.env.PropertySource;

@SpringBootApplication
@EnableConfigurationProperties(DemoApplication.AppProperties.class)
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(DemoApplication.class);
        // A high-priority, NON-iterable property source (registered before the application config) that
        // returns a non-null EMPTY value for every app.routes[i]. This is the shape of a non-iterable
        // source that answers a whole prefix (similar in spirit to RandomValuePropertySource for random.*).
        app.addListeners((ApplicationListener<ApplicationEnvironmentPreparedEvent>) e ->
                e.getEnvironment().getPropertySources().addFirst(new PropertySource<Void>("misbehaving") {
                    private boolean isRoutesIndex(String n) { return n.matches("app\\.routes\\[\\d+\\]"); }
                    @Override public boolean containsProperty(String n) { return isRoutesIndex(n); }
                    @Override public Object getProperty(String n) { return isRoutesIndex(n) ? "" : null; }
                }));
        app.run(args);
    }

    @ConfigurationProperties("app")
    public static class AppProperties {
        private List<RouteConfig> routes = new ArrayList<>();
        public List<RouteConfig> getRoutes() { return routes; }
        public void setRoutes(List<RouteConfig> routes) { this.routes = routes; }
    }

    public static class RouteConfig {
        private String id;
        public String getId() { return id; }
        public void setId(String id) { this.id = id; }
    }
}

src/main/resources/application.yaml:

spring:
  main:
    web-application-type: none
app:
  routes:
    - id: r0

Result:

• 4.1.0 → Terminating due to java.lang.OutOfMemoryError: Java heap space (stack above).
• 4.0.6 (only change: parent version) → no OOM; Failed to bind properties under 'app.routes[0]'.

Expected behavior

Binding should terminate (as on 4.0.6). At minimum, an empty / non-convertible indexed element should not
cause an unbounded loop that allocates up to Integer.MAX_VALUE and OOMs — turning a bounded, diagnosable
failure into a heap exhaustion is a regression.

---

🤖 Optional: AI-assisted root-cause analysis — please feel free to ignore

Disclaimer. Everything in this collapsed section was put together with AI assistance. I'm sharing it
only in case it saves you time; I personally don't have the expertise to vouch for it, so please treat it as
a hint, not a claim, and skip it entirely if it's noise. The reproduction above stands on its own.

Suspected mechanism. IndexedElementsBinder.bindIndexed stops only when an element binds to null:

for (int i = 0; i < Integer.MAX_VALUE; i++) {
    ConfigurationPropertyName name = appendIndex(root, i);
    Object value = elementBinder.bind(name, Bindable.of(elementType), source);
    if (value == null) { break; }
    collection.get().add(value);
}

Comparing v4.0.6...v4.1.0, the binder change appears to be the new fallbackToDefaultValue path
(Binder / JavaBeanBinder / ValueObjectBinder / DataObjectBinder). In Binder.bindObject:

catch (ConverterNotFoundException ex) {
    boolean fallbackToDefaultValue = ObjectUtils.isEmpty(property.getValue());
    Object instance = bindDataObject(name, target, handler, context, allowRecursiveBinding, fallbackToDefaultValue);
    ...
}

In ValueObjectBinder.bind, when the target is a plain JavaBean (valueObject == null) and
fallbackToDefaultValue is true, it now returns a non-null default instance instead of null:

if (fallbackToDefaultValue) {
    return getNewDefaultValueInstanceIfPossible(context, target.getType());
}
// getNewDefaultValueInstanceIfPossible(...) for a JavaBean ends at:
return (resolved != null) ? BeanUtils.instantiateClass(resolved) : null;   // non-null

So an empty-valued routes[i] now yields a non-null empty bean, the loop never reaches null, and it
allocates a ConfigurationPropertyName per index up to Integer.MAX_VALUE → OOM. On 4.0.6 the same element
surfaced the ConverterNotFoundException as a bounded BindException.

Possibly related issues/PRs (again, AI-surfaced, may be wrong):

• Configuration properties containing empty arrays, collections or maps fail with ConverterNotFoundException #50756 / PR Map properties bound from empty strings fail with ConverterNotFoundException #50773 — introduced the fallbackToDefaultValue behavior (empty arrays/collections/maps).
• Allow empty objects to be loaded from YAML #48958 — explicitly-empty YAML nodes now materialize empty-string properties (how an empty value can appear
  at an indexed name in real apps).
• Reinstate IndexElementBinder filter optimization removed in 3.5.4 #46196 — IndexedElementsBinder filter optimization removed in 3.5.4 (the index-binding area is noted as
  regression-prone).
• Got a java.lang.IllegalStateException during validation of configuration properties #50795 — another 4.1.0 @ConfigurationProperties binding regression ('validationType' must not be null).

[wilkinsona]

Thanks for the report. Can you provide some more details about the non-iterable property source in your real-world app? It looks like it contains an empty string property for every app.routes[n] property which seems rather unusual. If I've understood things correctly, it would cause a problem, even before the changes in Boot 4.1, when binding to something like List<String>.

[Lumenol]

Thanks — you're right to be suspicious of that source. And you're right that it would already misbehave on 4.0.6 (e.g. binding List<String>) — which is exactly why it was a poor reproduction. The empty-string-per-index source was a repro artifact; our app uses neither empty strings nor List<String>. Here's the real trigger, reduced to a minimal sample: https://github.com/Lumenol/spring-boot-4.1-binder-oom (run.sh runs it on both 4.1.0 and 4.0.6; Diagnostic.java prints the why; ANALYSIS.md has the full breakdown).

Two ingredients — no empty strings, no configured data needed:

1. A non-iterable PropertySource registered before the application config. Ours is a custom lazy source (resolves keys on demand). Being non-enumerable, its adapter answers containsDescendantOf(app.items[i]) = UNKNOWN, which skips the early-exit in Binder.bindObject. Your RandomValuePropertySource is also non-iterable and ordered before the config, but answers ABSENT for unrelated names — so the difference is UNKNOWN vs ABSENT, not ordering.
2. The list element bean has an Optional property, which binds to a non-null Optional.empty() at every index, so IndexedElementsBinder's loop never reaches a null element and allocates up to Integer.MAX_VALUE.

@ConfigurationProperties("app")
class AppProperties { List<Item> items = new ArrayList<>(); /* getter/setter */ }
class Item { Optional<String> regex = Optional.empty(); /* getter/setter */ }

• 4.1.0 → OutOfMemoryError (IndexedElementsBinder.bindIndexed → CollectionBinder → JavaBeanBinder)
• 4.0.6 → starts cleanly — same source, same code

Granted, our source is less precise than your built-ins (it could answer ABSENT outside its prefix, which does work around it). But since the identical setup is clean on 4.0.6 and OOMs on 4.1.0, this looks like a regression in how the indexed binder terminates. I haven't bisected the exact commit.

[seonwooj0810]

Would the team be open to a PR for this?

The regression looks real and self-contained: IndexedElementsBinder.bindIndexed only breaks its for (i = 0; i < Integer.MAX_VALUE; i++) loop when an element binds to null. With the 4.1.0 fallbackToDefaultValue path, a non-iterable source that answers a whole app.routes[i] prefix with an empty (but non-null) value now yields a non-null bound element for every index, so the loop never terminates and allocates ConfigurationPropertyNames until the heap is exhausted — whereas 4.0.6 stopped with a bounded Failed to bind properties under 'app.routes[0]'. Turning a bounded, diagnosable failure into an unbounded OOM at startup seems worth guarding against.

If it's welcome, I'd be glad to open a PR that bounds indexed binding against this fallback-driven non-termination, with a regression test built from the reduced reproducer above. Happy to align on the preferred approach (e.g. not treating a fallback-only default as a "present" element during indexed binding) before implementing.

[elephant-y]

Hi @wilkinsona, thanks for the initial triage. @Lumenol, thanks for the excellent reproducer and analysis — it made identifying the root cause much easier.

I've opened a PR (#51143) to address this. The fix introduces a PropertyBinding record in DataObjectPropertyBinder that captures whether a bound value actually came from a configuration source. JavaBeanBinder and ValueObjectBinder now use fromSource() instead of relying on null checks, which fail for non-null defaults like Optional.empty().

@seonwooj0810 — apologies if you were still working on this! I saw the analysis you shared and it was very helpful in understanding the problem. Happy to collaborate if you'd like.

Would appreciate any feedback on the approach. Thanks!