Using Ceylon’s Optional and Union Types on the JVM: A Practical Guide

Desired Outcome

Build a small Ceylon 1.3.x JVM module that demonstrates how optional types (e.g. String?) and union types (e.g. String|Integer) are represented, and how the compiler’s flow‑sensitive narrowing (exists, is, assert) eliminates null‑pointer bugs at compile time.

Prerequisites

• Java 8 (or a compatible JDK that the 1.3.x toolchain supports).
• Download the Ceylon 1.3.x command‑line distribution from the archived GitHub releases and extract it to a directory, e.g. /opt/ceylon-1.3.0.
• Add /opt/ceylon-1.3.0/bin to PATH and verify with ceylon --version (expected output: ceylon 1.3.0).
• Create a project root directory, e.g. ~/ceylon-demo, and inside it run ceylon init to generate a minimal module structure.

Focused Procedure

1. Create the module descriptor (module.ceylon) with the following content:

   module my.module "1.0.0" {
       import ceylon.language "1.3.0";
   }
   

2. Write a source file that uses optional and union types (src/my/module/Hello.ceylon):

   module my.module "1.0.0";
   
   import ceylon.language "1.3.0";
   
   shared String? maybeHello() => "Hello";
   
   shared Integer? maybeNumber() => null;
   
   shared void demo() {
       // Optional type handling
       if (exists msg = maybeHello()) {
           print("Got: ``msg``");
       } else {
           print("No message");
       }
   
       // Union type handling
       value data = maybeNumber() else 42; // fallback to a default
       if (is Integer data) {
           print("Number: ``data``");
       } else if (is String data) {
           print("String: ``data``");
       }
   }
   

3. Compile the module:

   ceylon compile my.module
   

   Expected result: the compiler emits no "possibly null" or "uninitialized value" errors. If you intentionally dereference maybeHello() without exists, the compiler will reject the code.

4. Run the demo:

   ceylon run my.module
   

   Output: No message Number: 42

5. Write tests covering both branches (test/my/module/HelloTest.ceylon):

   module my.module "1.0.0" {
       import ceylon.test "1.3.0";
       import my.module "1.0.0";
   }
   
   import ceylon.test "1.3.0";
   import my.module "1.0.0";
   
   test void testMaybeHello() {
       value msg = maybeHello();
       if (exists m = msg) {
           assert (m == "Hello");
       } else {
           fail("Expected a message");
       }
   }
   

6. Run the tests:

   ceylon test my.module
   

   All tests should pass, confirming that both the optional and union logic work as intended.

Expected Checks

• ceylon compile completes without errors related to nullability or uninitialized values.
• Running the module prints the expected output and does not throw a NullPointerException.
• All ceylon test cases pass, demonstrating that the compiler enforces flow‑sensitive narrowing at test time.

Recovery Options

• Lost narrowing after mutation: If a value is stored in a mutable attribute, copy it to an immutable local variable before performing exists or is checks.

  shared class MutableHolder(shared Integer? value) {}
  
  value holder = MutableHolder(null);
  if (exists v = holder.value) {
      // safe to use v here
  }
  

• Missing dependencies after Herd shutdown:
  • Vendor the required ceylon.language source into your project and add it to the module path.
  • Alternatively, use ceylon.interop.java to call Java libraries that provide the needed functionality, bypassing the need for a Herd module.

Practical Verification Checklist

• Run ceylon --version to confirm the toolchain is 1.3.x.
• Compile the module and verify the compiler output contains no null‑related warnings.
• Run the module and inspect the console for the expected “No message” and “Number: 42” lines.
• Execute ceylon test my.module and confirm all tests succeed.
• If any of these steps fail, check that you are using a Java 8 JDK and that the ceylon-1.3.0 distribution is correctly extracted.

Takeaway

Ceylon’s optional (T?) and union (T|U) types together with flow‑sensitive narrowing provide a compile‑time safety net that catches many null‑pointer bugs before the code runs. Even though the 1.3.x line is discontinued, the language’s design remains a useful study for languages that aim to eliminate runtime null errors through static analysis.