Extending java.util classes for that bit of extra convenience :)
Hardcoding is bad. Taking configuration out of the code is better. Taking configuration out of the deployment is best.
Technical debt is costly. Refactoring is expensive. Retesting is time consuming.
Reusing the same interfaces and replacing them with a more modern implementation is minimizing the blast radius.
Keep the apps as they are and move the configuration out of them. Here are some examples how.
| Class | Test | Description |
|---|---|---|
| EnvResourceBundle | EnvResourceBundleTest | Retrieves resources from the environment variables. Useful for runtimes that automatically provide configuration. |
| MapResourceBundle | MapResourceBundleTest | General purpose Map wrapper. Useful with any data provider that returns a map. |
| PrefixedKeyResourceBundle | PrefixedKeyResourceBundleTest | Base class. Adds a key prefix. Useful when working with large resource bundles, but only need a subset of keys. |
| PrefixedKeyResourceBundleWrapper | PrefixedKeyResourceBundleWrapperTest | Adds prefix functionality by wrapping existing ResourceBundles. |
| ParameterStoreResourceBundle | ParameterStoreResourceBundleTest | Retrieves resources from AWS SSM Parameter Store. Useful to keep configuration in the cloud. |
| VaultResourceBundle | VaultResourceBundleTest | Retrieves resources from HashiCorp Vault. Useful to keep secrets in the cloud. |
| CachingResourceBundle | CachingResourceBundleTest | Caches values for ttl in milliseconds. Useful to avoid the expensive IO, and reuse last known values when backing bundle is not accessible. |
| ResourceBundleChain | ResourceBundleChainTest | Searches for configuration in a chain of bundles. Useful for overriding. Typical chain usually goes from most flexible to least flexible. e.g.: Cache -> Parameter Store -> Secrets Store -> Environment -> File. |