Serguey Asael Shinder: Micronaut 5.2.13 stops @Nullable from erasing a @Bindable default
Micronaut 5.2.13, published on 2 October, is a two-line release. One of the two lines is a behaviour change that is worth knowing about if you bind configuration into records or constructors.
The bug. When a property was not set, Micronaut's constructor-argument binding checked whether the argument was declared nullable and, if so, returned null straight away. Only after that did it look at @Bindable(defaultValue = ...). So a nullable record component in a @ConfigurationProperties bean never got its default. The pull request shows it in one record:
@ConfigurationProperties("test")
record Config(@Bindable(defaultValue = "2s") @Nullable Duration warnWait) {}
With no test.warn-wait set, warnWait() returned null. Remove @Nullable and the same code returned two seconds. Meanwhile the generated configuration schema, which reads the annotation, still advertised "default": "2s". Micronaut's own PythonPoolConfiguration had exactly this shape, so its pool never warned about slow waits even though the documentation said it would after two seconds.
The fix. Both resolution paths, the one used by generated constructor-argument code and the one in AbstractInitializableBeanDefinition, now consult the @Bindable default first, then return null for a nullable argument, and only then throw the missing-property exception. That is the order the annotation's own contract describes: the default is what you get when no value is present.
What changes for you. A nullable constructor argument or record component that declares a @Bindable default now receives that default when unconfigured, instead of null. If your code treated null as "not configured" and branched on it, that branch stops being taken. The pull request lists two cases it deliberately leaves alone: JavaBean setters still ignore a @Bindable default on their parameter, and Optional<T> arguments still resolve to empty rather than to the default.
One more fix on the same line. 5.2.11, out on 1 October, fixed a ClassCastException for @Value("#{...}") expressions on Optional<String> constructor and method parameters: the expression value was returned bare while the generated code cast it to Optional. Fields already wrapped it. 5.2.11 also pulls in a Jackson vulnerability fix for the 5.2 line.
No JDK runs on the machine this note was written on; the behaviour described is the one stated in the linked pull requests and their tests.