Ceylon's Declaration-Site Variance: What the JVM Actually Sees

The short answer

Ceylon's type system removes Java's use-site wildcards by putting variance on the type parameter itself. You write trait Source<out Value> once, and every Source<String> is automatically a subtype of Source<Object>. The compiler also infers local types aggressively, so you rarely annotate variables. The catch is that the JVM has no concept of declaration-site variance: generics are erased, so the Ceylon compiler must synthesize bridge methods and insert runtime casts to preserve safety. If you are evaluating Ceylon for a JVM project, the real decision is whether that hidden machinery is acceptable for your Java interop surface.

A worked example: covariant traits

Consider a read-only source of values. In Java you would write Source<? extends Object> at every use site. In Ceylon, variance is declared once on the trait.

trait Source<out Value> {
    shared formal Value get();
}

class ConstantSource(Value element)
        satisfies Source<Value> {
    shared actual Value get() => element;
}

void run() {
    ConstantSource<String> stringSrc = ConstantSource("payload");
    Source<Object> objSrc = stringSrc;
    Object value = objSrc.get();
}

Here out marks Value as covariant. The assignment Source<Object> objSrc = stringSrc; compiles without a cast because the compiler knows Source produces values and never consumes them. If you tried to add a formal put(Value v) to the trait, the compiler would reject the out marker because the type parameter appears in an input position.

What the compiler emits

After compiling with ceylon compile in your project directory, locate the generated .class files in the Ceylon module repository or build output directory. Inspect them with the JDK's javap tool:

javap -p -c -classpath <path-to-classes> <fully.qualified.ConstantSource>

You will not see a generic signature that matches the Ceylon source exactly. Because the JVM erases type parameters, Source becomes a raw interface at runtime. The compiler generates a bridge method in ConstantSource so that Java callers invoking Object get() through the erased interface still reach the Ceylon implementation. The Ceylon compiler also inserts a checkcast at call sites where it must prove the erased return value matches the expected type. This is the same strategy Java uses for bridge methods, but Ceylon's declaration-site variance means the compiler decides where bridges are needed, not the caller.

Type inference in practice

Ceylon infers the type of stringSrc from the initializer, so the explicit ConstantSource<String> annotation is optional. In method return positions, the compiler infers from the expression body when the return type is omitted, though shared members still require explicit types for API stability. Local type inference reduces noise, but it does not weaken the type system: every binding has a definite static type, and the compiler will reject assignments that violate variance or subtyping rules.

Immutable values

The Value type sits at the top of Ceylon's hierarchy for immutable data. When you model a value with a trait or class whose attributes are Value members, the compiler can treat instances as safely shareable across threads without defensive copying. This is not a runtime annotation; it is a compile-time guarantee that no formal or default member mutates state. The JVM still uses ordinary object references, but Ceylon's type system prevents you from writing a setter that would break the guarantee.

Where this helps

The biggest win is API design. A library author defines variance once, and consumers get safe subtyping without wildcard noise. Traits add a second layer: they compile to JVM interfaces, and the exact bytecode strategy for mixin behavior depends on the Ceylon version and target JDK, so inspect the generated classes rather than assuming a particular default-method layout. For immutable value types, Ceylon's Value hierarchy and type inference reduce the annotation overhead that makes Java DTOs verbose.

Limits and common mistakes

• Dormant ecosystem. Ceylon is no longer actively developed. Library updates, IDE support, and community answers are sparse compared with Kotlin or Scala. Treat it as a technology for contained internal tools or language study, not for long-lived production services that need ecosystem velocity.
• Java interop boilerplate. When Java code calls Ceylon, it sees erased types and bridge methods. Exposing a rich Ceylon generic API to Java often requires hand-written wrappers or explicit casts on the Java side, which erases the productivity gain.
• Toolchain rigidity. The Ceylon compiler has historically required specific JDK versions. Before committing, verify that your target JDK is supported by the exact Ceylon distribution you plan to use; do not assume the latest JDK will work.
• Assuming use-site wildcards exist. Ceylon does not have Java's <? extends T> syntax. If you mentally translate Java patterns directly, you will fight the compiler. Variance belongs on the declaration.
• Forgetting erasure at runtime. Because type parameters are erased, reflection on generic types is limited. Code that depends on runtime generic metadata will need explicit type tokens or will fail in ways the compiler cannot catch.

How to verify the behavior

Create a small module with the trait above. Attempt to assign Source<String> to Source<Object> and confirm the compiler accepts it. Then add a consumer method put(Value v) to the trait and confirm the compiler rejects the out variance marker. Finally, compile the valid version and run javap on the class files to see the bridge method and the erased signature. If the generated bytecode does not contain the expected bridge, your build output path or module configuration is wrong, not the language.

If those checks pass, you have confirmed Ceylon's core promise: declaration-site variance gives you safer, shorter source code, while the compiler absorbs the JVM's erasure cost. The remaining question is whether Ceylon's dormant status and interop friction fit your project's timeline.