True immutability with @ConfigurationProperties and @ConstructorBinding

[kraspasov]

The current behavior has been reported previously here #1547.

I want to lay down the arguments why this doesn't make sense to work this way.

The current situation is that the feature works this way and is expected to work like this to achieve immutable configurations upon context refresh, in other words, those are just beans ignored by the refresh event, even if you have them marked as @RefreshScope.

The first argument against "this is how it should work" is, if I want to not refresh some properties, i.e. refresh context events are not affecting the configuration bean, I will just not put the @RefreshScope annotation.

The second argument against this statement in the original issue - "protecting jr developers during testing is not a strong enough argument for what is likely a non trivial feature to support". In my team we have had an actual production issue by the same thing.

I.e. when I think of immutability, I think of it that a single instance of bean/object is immutable. If I want it to be @RefreshScope, then I want to be able to create new bean instances with a new immutable state. If I want a bean instantiation immutability, I will just not make it part of the refresh scope event.

In simple terms I want to have the following code:

@RefreshScope
@Configuration
@ConfigurationProperties(prefix = "config.app")
public class MyConfig {

  private Map<String, String> map;

@ConstructorBinding
public MyConfig(Map<String, String> map) {
   map = Collections.unmodifiableMap(map);
}

And I want the following behavior:

1. The map inside the MyConfig bean is immutable runtime. I.e. stream, filters, etc. can't modify it.
2. I want the map property of the MyConfig to be immutable, i.e. no setters. I don't want someone accidentally to change the map reference.
3. I still want to be able to update the properties on refresh application context events.

This way I am ensuring no more bugs on production from filters, streams, etc. and changed object references. I.e. true Java immutability. The way the feature is working currently I can't ever achieve true immutability of the bean's properties runtime, while still be able to update/refresh the properties

[ryanjbaxter]

I am not sure this is even possible. It might be out of our control if the field is immutable. It would need to be investigated