Mutability discussion

[Emily-Jiang]

Do we want to support mutability?

[radcortez]

No.

[dmlloyd]

No. Mutability is something an implementation can support.

We do however need to be careful to ensure that the SPIs developed by this specification do not exclude the capability for implementations to support mutability in an implementation-specific manner. This might be challenging to get right unless at least one vendor supports mutability right from the start (it won't be us though 😉).

[radcortez]

Agree that implementations are free to support mutability if they want to do it.

[ljnelson]

Shortest possible answer: no.

Nuances:

I see configuration as a spectrum:

(In terms of the spectrum, this discussion incorporates aspects of the yellow/left side (suppose configuration changes; how will the component get notified of the change?) and of the cyan/left side (how shall a change to configuration-on-disk be made available to a running application?).)

However, whether we like it or not, developers always want to change a file on disk and have an application react to it in some way. (Certificate rotation jumped to mind—I'm not saying it's good, just…it's an example of this sort of thing that people have asked for in the past.) Is this good? Probably not. Is it ubiquitous? Yes. Should we support this case? Yuck. Bleagh. Maybe, though?

For the record: I do not support any facility in Jakarta Config to change configuration-on-disk from within the application. (Some people may see "mutability" and think "setters on configuration objects" or other mutator methods; I think that would be a terrible idea and I don't think that's what is meant here.)

[radcortez]

My big issue with mutability is not the technical difficulty or the API required to achieve it but the expectation it creates. How do you know that changing a specific configuration is going to have some effect on your running instance? You don't!

I believe that one of the primary goals of Config is to provide a way to configure the Jakarta platform. A lot of Jakarta specifications already provide properties for configuration, but I think none of them have any effect if you reload them after the runtime is mid-flight. So, most likely, Jakarta does not need configuration mutability.

User configuration is another story. I do see the use case, but in a time where everyone is moving to the immutable container world, do we need to provide such capability?

[otaviojava]

No