Implementing Null Safety in Ceylon with Flow-Sensitive Typing

The Problem: Runtime Null Pointer Exceptions

In many languages, any object reference can be null, leading to unpredictable runtime crashes when a null value is dereferenced. Ceylon solves this by making nullability a part of the type system. By default, a type T is non-nullable. To allow a variable to hold a null value, you must explicitly declare it as T? (a union of the type and the Null singleton).

The primary challenge is handling these nullable types without cluttering code with repetitive manual casts. Ceylon uses flow-sensitive typing, where the compiler tracks the state of a variable. If a variable is checked for existence, the compiler "narrows" the type to non-nullable within that specific code block.

Prerequisites

• Ceylon SDK version 1.3.0 or later installed and configured in your system PATH.
• A terminal environment with permissions to execute ceylon compile and ceylon run.

Implementation Procedure

1. Define a Null-Safe Function

Create a file named NullDemo.ceylon. The following example demonstrates a function that processes an optional string. Note the use of String? for the input and the exists operator to guard the dereference.

// NullDemo.ceylon
shared void run() {
    // Case 1: Providing a value
    print("Result 1: " + process("hello"));
    
    // Case 2: Providing null
    print("Result 2: " + process(null));
}

String process(String? input) =>
    if (exists input) then 
        // Inside this block, 'input' is narrowed from String? to String
        input.uppercased 
    else 
        "empty";

2. Compile and Execute

Run the following commands in your terminal from the directory containing the file:

# Compile the source file
ceylon compile NullDemo.ceylon

# Execute the run function
ceylon run NullDemo

Expected Result: The program should output Result 1: HELLO and Result 2: empty without any runtime exceptions.

3. Verify Compiler Enforcement

To confirm that the type system is actually protecting the code, attempt to remove the exists guard. Modify the process function as follows:

String process(String? input) => input.uppercased;

Run ceylon compile NullDemo.ceylon again. The compiler will fail with an error indicating a possible null dereference or that it cannot infer the type Null for the variable input. This proves that the compiler prevents unsafe access to nullable types.

Handling Java Interoperability

When calling Java methods from Ceylon, the compiler must make assumptions about nullability because Java does not enforce it at the type level. By default, the Ceylon compiler treats plain Java return types as nullable (T?).

If a Java method String javaGet() is called, Ceylon sees the result as String?. You must use an exists guard or the nonnull operator before calling methods on that result. If the Java code is annotated with @NonNull, the Ceylon compiler will treat the return type as a non-nullable String.

Diagnostic Checks and Limitations

Scenario	Expected Behavior	Verification Method
Standard Nullable	Compile error on direct access	Remove exists guard and compile
Guarded Access	Successful compilation	Use if (exists x)
Java Interop	Treated as nullable by default	Call unannotated Java method; check for compile error

Limitations: Flow analysis is conservative. In complex scenarios—such as deep nesting or variables modified inside loops—the compiler may lose track of the null state. In these cases, you must use an explicit non-null assertion: val nonNullVar = input.nonnull;

Rollback and Recovery

Because this operation only involves source code changes and compilation, rollback consists of reverting the .ceylon file to its previous state using your version control system (e.g., git checkout NullDemo.ceylon). If you encounter unexpected compilation errors, verify your environment version using ceylon version to ensure you are on 1.3.0 or later.