Add a real JPMS module descriptor: com.github.zrdj.java.properties

[glaudeee]

Summary

• Ships src/main/java/module-info.java: module com.github.zrdj.java.properties (matches the
  root package), requires org.slf4j, exports all four packages that exist
  (com.github.zrdj.java.properties, .error, .naming, .store) — every class in the source
  tree is already public, so nothing is held back.
• pom.xml: version 0.2.0 -> 0.3.0. Catches up to the already-tagged 0.2.1 and goes one
  further, since this is source-incompatible for JPMS consumers, not a patch.
  maven.compiler.source/target stay at 11 — maven-compiler-plugin 3.15.0 auto-detects
  module-info.java and compiles it under source/target 11 without needing <release>.
• docs/project/decisions/2026-09-07-real-module-descriptor-instead-of-automatic-name.md: records
  the trigger and the export/requires reasoning.

Why ship a descriptor if the automatic name already works?

The published 0.2.1 jar carries neither module-info.class nor an Automatic-Module-Name
manifest entry, so the JPMS filename algorithm derives the automatic module name
java.properties — inside the java.* namespace the JDK reserves for platform modules.

Measured on 2026-09-07 against tibbots/bots (five named JPMS modules, JDK 25): that name is
not rejected. requires java.properties; compiles, the reactor builds all five modules, and
the packaged jar starts and shuts down cleanly. Maven emits only the generic automodule warning
that the same build already earns from inject-1.0.0.jar and javax.inject-1.jar. An earlier
version of this PR's decision note claimed the requires was rejected outright — that claim didn't
hold up once actually measured, and has been corrected.

The reason nothing breaks today is narrower than "it works": that consumer packages into a single
jar and starts from the classpath, where the runtime module system never resolves the name. A
module-path start, a jlink image, or a JDK that tightens the check would turn a green build red,
and nothing in either repo's test suite would catch it beforehand — the descriptor is the only
place the name appears. Shipping a real descriptor also reads as what it is:
requires com.github.zrdj.java.properties; names this library; requires java.properties; reads
like a platform module.

Consequences

• Classpath consumers (unnamed module, or a plain <dependency> with no module-info.java of its
  own) are unaffected — a modular jar keeps working unchanged when read from the classpath.
• Consumers already on 0.2.1 keep working. This removes a latent problem, not a broken state —
  nothing is urgent about adopting it.
• Nothing here is merged, released, or tagged. 0.3.0 only takes effect once this is merged
  and a GitHub Release triggers the JitPack build — that decision is left to the maintainer.

Verified in the devcontainer: ./dev build (BUILD SUCCESS) and ./dev test (32 tests green).

🤖 Generated with Claude Code

https://claude.ai/code/session_01M6eipDXiCdfdMqoQL7g68v