Adopt `application.properties` as a configuration file

[radcortez]

Description

Many other runtimes already use application.* to reference configuration files (Spring, Quarkus, Micronaut, to name a few).

MicroProfile Config could benefit from adopting the same file name, making the transition between runtimes smoother and reducing configuration files if mixing the runtimes. Since it is a more neutral name, it could also help other platforms adopt MicroProfile Config.

Of course, we will still keep microprofile-config.*, deprecate it and remove it in the future.

[dmlloyd]

How would we deal with syntax and behavioral disparities between implementations?

[radcortez]

It is just the file name. Everything else is still subject to the implementation.

[ljnelson]

Do I understand right that the proposal (or the hazy sketch of it above) is to adopt something like Spring's application.properties filename without any of Spring's critical semantics of using it as a sibling of the application's packaging unit, or any of the semantics of its position within Spring Boot's deliberate hard-coded properties hierarchy, and, specifically, to make it be the source of default values, as META-INF/microprofile-config.properties is today?

Or is it to make the META-INF/application.properties classpath resource to have the same semantics as META-INF/microprofile-config.properties does today, i.e. just a straight terminal filename swap, in which case of course a META-INF/application.properties file would absolutely 100% not have any of the semantics Spring users would expect?

To put it another way: is the idea that for some unspoken reason Spring users (and/or others) will feel better about some classpath resource that contains the word application in it, even though it will bear no resemblance to the semantics of the application.properties configuration they are used to?

If any of the above is true: why? Why do any of this? For what reason? For what audience? To accomplish what use cases? Is there any benefit at all, particularly given that Spring's application.properties (which is not a classpath resource, incidentally) is not meant as a default source of values, but things like META-INF/microprofile-config.properties classpath resources are supposed to be defaults only?

Maybe the idea is simply to remove the word "microprofile" from the artifacts created by this library? If so, perhaps pick a different neutral word so users of other frameworks don't get confused?

To the extent I understand this proposal I (personally) vote a vigorous -1. Maybe what's meant is something entirely different?

[radcortez]

This is just the filename.

Currently, Jakarta is considering adopting MP Config, and having a more neutral name can help. It can be any other name, but I did propose application.* because it is already used by many runtimes (not just Spring).

In Quarkus and SmallRye Config (and any consumer, like Liberty or TomEE) we use application.properties, with the MP Config semantics, plus some of our own, which we also apply to microprofile-config.properties.

[dmlloyd]

What is the point of a specification when the most popular implementation of the specification would not comply to the specification (with good reason)? Unless the specification is something like "implementations are free to change what they want", in which case, again, what is the point of the specification?