Please Read: Requiring default values for 2.0 + related changes

[A248]

Requiring Default Values
On our existing trajectory, DazzleConf 2.0 will be taking a more expansive role with respect to providing default values. We may therefore require the existence of default values when a configuration is defined, e.g. via @DefaultBoolean, @DefaultInteger, @DefaultString and related annotations.

Requiring default values would invalidate the "defaults from a resource file" approach documented in The two ways of using DazzleConf. However, that approach seems to be much rarer (if it exists at all) compared to the mainstream, common style.

Please comment here and describe your use-case if you use DazzleConf 1.x without defaults annotations. We would like to support all library usages when developing DazzleConf 2.x. However, we need your feedback if you use this

Related Plans
Sometimes, software may want to supply a different default value depending on whether a whole fresh configuration is generated versus an individual option was missing due to an upgrade. For example, I might introduce an option whose default setting changes behavior in the new version, but wish to keep backwards compatibility for existing configurations. DazzleConf should address this use-case by defining a default value as well as an "if missing" value. For example, @DefaultString("default for fresh configuration", ifMissing = "default for when the option itself is missing").

Migration should also be supported for configurations, with existing values being taken from other configuration options, sections, and even separate files and sub-sections of other files. We further need to account for the dynamic case of multiple new options inheriting from multiple previous options in an interacting fashion, i.e. a M:N relationship between old and new options. Such feature will require caller hooks to handle the specifics of migration.