Coarse‑grained auto‑export vs. manual module‑info.java for Ceylon JPMS

Answer first

No. With Ceylon 1.3.4 you cannot add a selective JPMS export qualifier, and manual module-info.java editing after compilation is not acceptable for reproducible builds.

The compiler is archived and will not gain a new visibility qualifier. The only build-safe options are to accept coarse exports, split internal APIs into separate Ceylon modules, or apply a deterministic build-time rewrite of the generated module descriptor.

Confirmed facts

• Ceylon 1.3.4 is the final release from 2017. JPMS descriptor generation is best-effort and predates widespread JPMS adoption.
• The Java backend maps every Ceylon package that contains a shared declaration to an exports clause in the generated module-info.class. There is no language annotation to distinguish Ceylon-internal visibility from JPMS export visibility.
• Ceylon's own module system uses shared for inter-module visibility. JPMS descriptor generation is a separate coarse-grained pass that treats all shared packages as public exports.
• Eclipse Ceylon is archived. No active compiler development exists to add a shared java or similar qualifier, and no ecosystem tooling updates will follow.
• Post-compilation patching of module-info.class changes the artifact hash and breaks reproducible builds unless the rewrite is deterministic and part of the build script.

Likely explanation vs uncertainty

It is likely that the original design treated shared as public API for both Ceylon and Java consumers. The uncertainty is whether a qualifier would be useful: it would require a compiler fork, spec change, IDE and build plugin updates, and would still need to be back-ported to a dead toolchain. That cost is not justified.

Manual module-info.java editing is technically possible but not acceptable for CI/CD that requires bit-for-bit reproducibility. Editing after compilation means source no longer matches binary and hashes diverge on every build.

Steps needed for this case

1. Verify current exports.

jdeps --print-module-deps your-module.jar
javap -verbose -module -cp your-module.jar module-info

Confirm every shared package appears in exports.

2. Choose a build-safe containment strategy.
• Split internal APIs into a separate Ceylon module that Java consumers do not depend on. Only the public-facing module is published to Java 9+.
• If splitting is not possible, add a deterministic rewrite step to the build. Example approaches used in practice: Maven Shade Plugin with ModuleTransformer, or a custom ASM visitor that rewrites module-info.class in a scripted, reproducible way. The rewrite must be part of the build, not a manual edit, and must be idempotent.
• Alternative: publish a hand-written module-info.java as a Multi-Release JAR entry for Java 9+ alongside the Ceylon-built jar. This keeps the Ceylon build untouched while providing a precise descriptor for Java consumers.
3. Lock reproducibility.

Compile twice and compare hashes of the final artifact. If you use a rewrite, ensure the rewrite is deterministic and its inputs are versioned.

One diagnostic that changes recommendation

Are the internal shared packages also imported by other Ceylon modules you ship? If yes, splitting into a separate module is more invasive and a deterministic build-time rewrite is the more practical path. If no, module split is the cleanest encapsulation.