[MattBDev]

Description

FAWE's config.yml is now loaded into read-only Java records. Each setting's default is written next to the setting, and code changes a setting with a method reference such as Settings.History::compressionLevel.

Removed API

Before	After
Settings.settings().QUEUE.PARALLEL_THREADS	Settings.settings().queue().parallelThreads()
Settings.IMP	Settings.settings()
Settings.settings().EXPERIMENTAL.PERSISTENT_BRUSHES = false	Settings.override(Settings.Experimental::persistentBrushes, false)
Settings.settings().reload(File)	Settings.set(Settings.load(Path))
Settings.settings().save(File)	settings.save(Path)
Settings.settings().LIMITS.get("default")	Settings.settings().defaultLimits()
Settings.settings().PROTOCOL_SUPPORT_FIX	FaweCache.INSTANCE.setProtocolSupportFix(boolean)
Config and its annotations	@Comment, @Default

Performance

The new code loads and reloads about twice as fast, works out limits 2.4 to 3 times as fast, and allocates less memory, except when saving. Reading a setting costs the same.

Saving is slower. It takes about 12% longer on the stock file and about 50% longer with 8 limit groups, which is 0.1 to 0.5 ms more, and it allocates 3 to 4 times as much memory. That's the cost of writing through SnakeYAML instead of by hand. FAWE only saves at startup and on /fawe reload.

Benchmark	Old	New	Speed-up	Old alloc	New alloc
getLimit, player in no group, stock file	261 ± 19 ns	88 ± 8 ns	2.97×	640 B	264 B
getLimit, player in two groups, 8 groups	1.14 ± 0.04 µs	478 ± 13 ns	2.39×	2 KB	752 B
Six setting reads	2.14 ± 0.05 ns	2.21 ± 0.08 ns	0.97×	0 B	0 B
Load, stock file	1.22 ± 0.06 ms	0.63 ± 0.03 ms	1.95×	1.31 MB	515 KB
Reload, stock file	1.89 ± 0.07 ms	0.95 ± 0.02 ms	1.99×	1.42 MB	830 KB
Forced save, stock file	0.78 ± 0.05 ms	0.88 ± 0.07 ms	0.89×	96 KB	306 KB
Forced save, 8 groups	0.98 ± 0.07 ms	1.48 ± 0.16 ms	0.66×	209 KB	769 KB

A speed-up below 1× means the new code is slower.

[Copilot]

🔵 Needs a closer look

It is an explicitly Work-In-Progress draft that rewrites the core configuration system and mechanically touches ~70 call sites, which warrants human review before approval.

3 open issues

• Misspelled advisory text in comment · New
• Duplicate comment line in expected output · New
• Misspelled numerical in option comment · New

What changed in this PR

This PR replaces FAWE's legacy reflection-based Config.java configuration system with an immutable, record-based Settings API. Configuration sections become nested Java records whose components are annotated with @Comment/@Default, and a new mapping layer (ConfigMapper, ConfigYaml, ConfigTree, LimitResolver) handles record↔YAML serialization, migration of legacy keys, and limit-group resolution. Roughly 70 call sites are mechanically migrated from uppercase field access (Settings.settings().QUEUE.PARALLEL_THREADS) to accessor methods (Settings.settings().queue().parallelThreads()). The PR is explicitly a Work-In-Progress draft.

Changes:

• Introduce an immutable record-based Settings model plus a new serialization/migration framework and comprehensive unit tests.
• Rewrite Fawe.setupConfigs() to load/save via Settings.load/save with a BuildInfo, and move the FaweCache.protocolSupportFix flag off the global settings object.
• Migrate ~70 call sites to the new accessor API and delete Config.java/ConfigOptComputation.java.

File	Description
.../​configuration/​Settings.java	New immutable record config model, load/save/migrate/defaults and BuildInfo (context only; not in diff).
.../​configuration/​ConfigMapper.java	Reflection-based record↔YAML mapping, coercion, and defaults.
.../​configuration/​ConfigYaml.java	Hand-rolled UTF-8 YAML reader/writer with quoting/escaping.
.../​configuration/​ConfigTree.java	Dotted-path tree used by migration.
.../​configuration/​LimitResolver.java	Merges limit groups into a resolved FaweLimit ("most generous" semantics).
.../​configuration/​{Option,Default,Comment}.java	Annotations/metadata driving option paths, defaults and comments.
.../​core/​Fawe.java	Rewritten setupConfigs() using Path, Settings.load/save, and BuildInfo.
.../​core/​FaweCache.java	New protocolSupportFix field + setter replacing the old global setting.
.../​test/​.../​SettingsTest.java, ConfigMapperTest.java	New unit tests covering save/load, migration, limits and fuzzed text round-tripping.
.../​test/​resources/​.../​config.yml	Expected-output fixture mirroring the @Comment/@Default text; carries over several comment typos.
~70 migrated call sites	Mechanical switch from uppercase fields to accessor methods.

_{Review effort: Balanced}

[MattBDev]

Marking the PR as ready for review but I still have to update the PR body. Should be done Saturday. I think I have a minor tweak or two to I have to push as well.

[Copilot]

🟡 Changes recommended

An unresolved critical finding remains: a typo in the config.yml comment (clipboad.on-disk instead of clipboard.use-disk) that must be mirrored in the Settings.java @Comment or the defaultsAreWrittenAsExpected test will fail.

1 open issue

• Fix typo in clipboard option name in generated comment · New

3 resolved since last review

• Misspelled numerical in option comment
• Duplicate comment line in expected output
• Misspelled advisory text in comment

_{Review effort: Balanced}

[SirYwell]

What is the future updating strategy with this? E.g., if we want to rename entries etc.

[MattBDev]

What is the future updating strategy with this? E.g., if we want to rename entries etc.

Migration is handled in Settings.migrate(). It is a fairly straightforward process.

[MattBDev]

@copilot Apply the following suggested code to the Settings.java file.

private static final MutableCallSite INSTANCE =
        new MutableCallSite(MethodHandles.constant(Settings.class, defaults()));
private static final MethodHandle GET = INSTANCE.dynamicInvoker();

public static Settings settings() {
    try {
        return (Settings) GET.invokeExact();
    } catch (Throwable e) {
        throw new AssertionError(e);
    }
}

public static void set(Settings settings) {
    INSTANCE.setTarget(MethodHandles.constant(Settings.class, Objects.requireNonNull(settings)));
    // Makes other threads see the new settings
    MutableCallSite.syncAll(new MutableCallSite[] {INSTANCE});
}

[Copilot]

@copilot Apply the following suggested code to the Settings.java file.

private static final MutableCallSite INSTANCE =

...

Applied the suggested MutableCallSite pattern in Settings.java and kept the overrideOption path consistent with the updated call-site-backed settings holder. 9ab76e9

[SirYwell]

This should probably delegate to the set method?

[Copilot]

Updated to delegate through set(...), matching the shared update path and keeping this change minimal.