metabit  

metabit mconfig

Description

A library to access configurations.

  • Type-safe
  • Zero dependencies
  • Exact origin traceability for every configuration entry
  • Self-healing
  • Late-binding with dynamic updates
  • Hierarchical settings, e.g. user settings override system-wide ones
  • Multiple sources, from files over network/cloud to hardware
  • Automatic OS detection and convention-aware config locations
  • Validation, range checking, defaults

Usage

The mconfig library is available as Maven artifacts. Since it is modular, the artifacts can be included selectively, reducing dependencies and footprint. There are predefined sets for an easy start:

basic (mConfigBasic)

Best for: Lightweight Java projects which require standard filesystem support.

Maven

<dependency>
    <groupId>org.metabit.platform.support.config</groupId>
    <artifactId>mconfigbasic</artifactId>
    <version>${mconfig.version}</version>
    <type>pom</type>
</dependency>

Gradle

implementation 'org.metabit.platform.support.config:mconfigbasic:${mconfig.version}'

standard mature set (mConfigStandard)

Best for: Modern cloud applications. Includes Environment Variables, Windows Registry, Slf4j, and full JSON/YAML support via Jackson. Add Cloud modules (Vault, AWS Secrets, ZooKeeper, etc.) depending on use case.

Maven

<dependency>
    <groupId>org.metabit.platform.support.config</groupId>
    <artifactId>mconfigstandard</artifactId>
    <version>${mconfig.version}</version>
    <type>pom</type>
</dependency>

Gradle

implementation 'org.metabit.platform.support.config:mconfigstandard:${mconfig.version}'

Documentation

for mconfig documentation, see mConfig documentation

Source repository

mConfig had been hosted on this page for over a decade.

Starting 2026, the mconfig library is available on github, at https://github.com/meta-bit/mconfig

Current version

check github releases for the most recent version.

Examples

working example code is found at github subdirectory

1. Replace Hardcoded Strings and Ports

Problem: Ports and hosts scattered in code are hard to change and deploy.

Config cfg = ConfigUtil.quickConfig("mycompany", "myapp", "network");
String peer = cfg.getString("peer");
int port = cfg.getInteger("port");
double prob = cfg.getDouble("probability");

Place: e.g. ~/.config/mycompany/myapp/network.properties on Linux, or respective paths on Windows, Android etc. (auto-discovered).

mConfig searches OS standards (XDG, AppData), supports formats (properties, YAML, JSON, TOML, ...), and reloads live.

2. Environment Variables to Structured Config

Problem: Environment variable handling gets messy when hierarchical configuration is needed.

Dependency: mConfigSourceEnvVar

Environment variables:

myapp_network_peer=localhost
myapp_network_port=8080
try (ConfigFactory f = ConfigFactoryBuilder.create("myco", "myapp").build()) {
    String peer = f.getConfig("network").getString("peer");  // env automatically in SESSION scope
}

Why? Uses the <app>_<config>_<key> convention and layers over files.

3. Type-Safe Config with Defaults and Validation

Problem: Runtime NumberFormatException and scattered defaults.

Schema file: src/main/resources/.config/myco/myapp/network.schema.json

[{"name":"port","type":"int","default":8080,"min":1,"max":65535}]
ConfigSchema schema = ConfigSchema.fromClasspath("network.schema.json");
Config cfg = factory.getConfig("network", schema);
int port = cfg.getInteger("port");  // Validates!

Why? Centralized schema, so there are no call-site defaults.

4. Hot-Reload on File Changes

Problem: Restart for config tweaks? No thanks.

Config cfg = factory.getConfig("network");  // Watches files
// Edit network.properties → cfg.getInteger("port") updates instantly

Why? Built-in watcher; no polling or Spring @Refresh.

5. Discover Available Configs

Problem: Where's my config?

factory.listAvailableConfigurations().forEach(cdi ->
    System.out.println(cdi.getConfigName() + " @ " + cdi.getUri())
);

more such code snippets to demonstrate use are part of the documentation.