Split package conflict when Ceylon module shares a package also used by a JPMS module

Direct answer

No. Ceylon's shared package mechanism cannot be mapped directly to JPMS exported packages without risking split-package violations. JPMS forbids the same package name from appearing in two different modules on the module path, and it enforces that rule at module resolution. Ceylon reached end-of-life in 2018 and has no official JPMS migration path, no generated module-info.java, and no documented support for running Ceylon modules as named modules on the JPMS module path. Ceylon code can still execute on JDK 9 and later through the classpath as part of the unnamed module, but that is not JPMS module-path support.

Confirmed facts versus likely explanation

Confirmed facts: JPMS split-package prohibition is well established since JDK 9. Ceylon module descriptors allow the same package to be declared across multiple Ceylon modules, which JPMS classifies as a split package. Ceylon is end-of-life, so there is no vendor-supported resolution for this mismatch.

Likely explanation: If you repackage Ceylon output as JPMS modules without changing package boundaries, any package shared by two Ceylon modules will cause the JVM to reject the module graph at startup. The conflict is not caused by Ceylon itself; it is caused by forcing a Ceylon shared-package model into a JPMS model that does not permit it.

Steps for this case

1. Inspect each Ceylon module descriptor and list every package declared in more than one module. Those are your split-package candidates.
2. For each shared package, choose one of two refactors: consolidate all types for that package into a single Ceylon module, or rename the packages so each package name exists in exactly one module.
3. Build the refactored Ceylon output to JARs, add module-info.java files that export only the packages you intend to expose, and place those JARs on the JPMS module path.
4. If you cannot refactor, keep Ceylon artifacts on the classpath and run them in the unnamed module. Do not place shared-package JARs on the module path.

Verification

Assumes JDK 9 or later and Ceylon output packaged as JARs. Use read-only inspection to find repeated packages across two modules:

jar tf module-a.jar | grep '\.class$' | sed 's|/|.|g; s|\.class$||' | sort
jar tf module-b.jar | grep '\.class$' | sed 's|/|.|g; s|\.class$||' | sort

Compare the two sorted lists manually. Any repeated package name across both outputs is a split-package candidate; JPMS will reject the module graph when both JARs are on the module path.

Missing diagnostic detail

Does the consuming application require Ceylon artifacts as named modules on the JPMS module path, or is execution on the classpath in the unnamed module acceptable? This changes the recommendation: classpath execution needs no refactor, while named-module execution requires eliminating shared packages first.