Ceylon Null-Safety Constraints in Java Interoperability

Question

Type Safety and JVM InteroperabilityCeylon implements a strict distinction between nullable and non-nullable types to prevent null pointer exceptions at compile time. This static type system requires any variable capable of holding a null value to be explicitly declared as such.When compiling Ceylon code to JVM bytecode, the language must interact with Java, which does not share these same null-safety guarantees. This creates a potential conflict when passing data between a non-nullable Ceylon type and a Java method that may return or accept null values.Interoperability ConstraintsThe primary challenge lies in maintaining the integrity of Ceylon's type system while utilizing Java libraries. If a Java method is called, the compiler must determine how to treat the resulting value to avoid runtime failures while adhering to the language's safety specifications.How does the Ceylon compiler handle the mapping of Java's nullable return types to Ceylon's non-nullable type declarations?What mechanisms exist to enforce null-safety when a Java object is passed into a non-nullable Ceylon parameter?

Tasadduq Burney · Answer

Null-Safety Boundary Enforcement
The Ceylon compiler handles Java interoperability by treating all Java types as nullable by default. Because Java bytecode lacks native nullability metadata, Ceylon cannot statically guarantee that a Java method will return a non-null value.

Mapping Java Return Types
When a value from a Java method is assigned to a non-nullable Ceylon type, the compiler does not perform a static cast; instead, it inserts an implicit runtime null check at the call site. If the Java method returns null, Ceylon throws a runtime exception immediately at the boundary to prevent the null value from propagating into the non-nullable type system.

Enforcing Safety for Java Parameters
When passing data from Ceylon to Java, the safety mechanism depends on the direction of the flow:

Ceylon to Java: Passing a non-nullable Ceylon object to a Java method is inherently safe. Since Java accepts any object reference, no additional wrapping or checks are required.
  Java to Ceylon: If a Java object is passed into a non-nullable Ceylon parameter, the same implicit runtime check described above is applied. The value is validated before the Ceylon method body executes.

Implementation Summary

Scenario
      Ceylon Type
      Mechanism
      Result of null

Java Return Value
      Non-nullable
      Implicit Runtime Check
      Runtime Exception

Java Return Value
      Nullable
      Direct Assignment
      Allowed

Ceylon Argument
      Non-nullable
      Direct Pass-through
      N/A (Guaranteed non-null)

Verification Steps
To verify this behavior in a local environment, you can perform the following:

Create a Java class with a method that explicitly returns null.
  Call this method from Ceylon and assign the result to a non-nullable variable.
  Use javap -c on the resulting Ceylon class bytecode to locate the inserted null-check instructions (typically ifnonnull or similar JVM opcodes) at the call site.

Note: To provide a more specific recommendation on overriding these defaults, please specify if you are using specific Ceylon interop annotations or a custom build configuration to define Java nullability.

Ceylon Null-Safety Constraints in Java Interoperability

Type Safety and JVM Interoperability

Interoperability Constraints

1 answer

Null-Safety Boundary Enforcement

Mapping Java Return Types

Enforcing Safety for Java Parameters

Implementation Summary

Verification Steps

Your perspective belongs here.

0 question comments

Scenario	Ceylon Type	Mechanism	Result of `null`
Java Return Value	Non-nullable	Implicit Runtime Check	Runtime Exception
Java Return Value	Nullable	Direct Assignment	Allowed
Ceylon Argument	Non-nullable	Direct Pass-through	N/A (Guaranteed non-null)