Ceylon 1.3.3 JVM Module to Java Interop: Resolving Module Versioning and Classloader Conflicts

Goal

The objective is to integrate a Ceylon 1.3.3 module into a Java application by compiling the module to Java bytecode and wiring it into a standard Maven or Gradle build. The integration must preserve semantic versioning, avoid class‑loader isolation issues, and eliminate the requirement for the Ceylon runtime at runtime.

Constraints and Uncertainty

Ceylon’s module system uses a custom version scheme (major.minor.patch[-qualifier]) that has no direct mapping to Maven coordinates. Because the Herd repository is offline, any remote dependency resolution must rely on locally vendored JARs or a self‑hosted mirror. Additionally, Ceylon modules are loaded by a dedicated module classloader; when the same Java library is also loaded by the application classloader, ClassCastException can occur. Finally, the ceylon compile --java flag generates Java source that still references ceylon.language types, implying a runtime dependency that may not be desirable.

Key Questions

1. Is there a recommended strategy for mapping Ceylon module version strings to Maven coordinates that ensures binary compatibility across builds?

2. What configuration or classloader strategy can prevent ClassCastException when a shared Java library is loaded by both the Ceylon module classloader and the application classloader?

3. Can the Java sources produced by ceylon compile --java be used without retaining the Ceylon runtime on the classpath, or is the runtime mandatory for correct operation?