JADEx (Java Advanced Development Extension) is a safety layer that makes Java safer by adding Null-Safety and Final-by-Default semantics without modifying the JVM.

• GitHub: https://github.com/nieuwmijnleven/JADEx
• Tutorial
  • Making Your Java Code Null-Safe without Rewriting it
  • Applying JADEx to a Real Java Project: Making OntheGoDataBase Null-Safe

Null-Safety

NullPointerException (NPE) is one of the most common sources of runtime failures in Java applications.
Although modern Java provides tools such as Optional and static analysis, null-related bugs are still fundamentally a runtime problem in most Java codebases.

JADEx addresses this problem by introducing explicit nullability into the type system and enforcing safe access rules at compile time.

In JADEx:

• Type → non-nullable by default
• Type? → nullable
• ?. → null-safe access operator
• ?: → Elvis operator (fallback value)

This design ensures that developers must explicitly acknowledge and handle nullable values before accessing them.

For example:

String? name = repository.findName(id);
String upper = name?.toLowerCase() ?: "UNKNOWN";

When compiled by JADEx, this code is translated into standard Java:

JADEx compiles null-safe expressions into standard Java using a small helper API(SafeAccess).

@Nullable String name = repository.findName(id);
String upper = SafeAccess.ofNullable(name).map(t0 -> t0.toLowerCase()).orElseGet(() -> "UNKNOWN");

In this example:

name is explicitly declared as nullable.

The ?. operator safely accesses toLowerCase() only if name is not null.

The ?: operator provides a fallback value if the result is null.

Instead of writing repetitive null-check logic such as:

if (name != null) {
    upper = name.toLowerCase();
} else {
    upper = "UNKNOWN";
}

JADEx allows the same logic to be expressed safely and concisely.

Most importantly, JADEx prevents unsafe operations at compile time. If a nullable variable is accessed without using the null-safe operator, the compiler will report an error.

This approach shifts null-related problems from runtime failures to compile-time feedback, helping developers detect issues earlier and build more reliable software.

Readonly (Final-by-Default)

JADEx also introduces optional readonly semantics through a final-by-default model.

In large Java codebases, accidental reassignment of variables or fields can lead to subtle bugs and make code harder to reason about. While Java provides the final keyword, it must be manually applied everywhere, which often results in inconsistent usage.

JADEx simplifies this by allowing developers to enable readonly mode with a single directive:

apply readonly;

Once enabled:

• Fields, local variables, and parameters become final by default

• JADEx automatically applies final where appropriate

• Reassignment attempts are reported as compile-time errors

Example:

apply readonly;  
  
public class Example {  
    private int count = 0;  
  
    public static void main(String[] args) {  
        var example = new Example();  
        example.count = 10; // compile-time error  
    }  
}

Since count is generated as final, the reassignment results in a standard Java compile-time error.

If mutability is intentionally required, developers can explicitly opt in using the mutable modifier:

private mutable int counter = 0;

This approach encourages safer programming practices while keeping the code flexible when mutation is necessary.

When compiled, JADEx generates standard Java code with final modifiers applied where appropriate, ensuring full compatibility with the existing Java ecosystem.

//apply readonly;

@NullMarked
public class Example {
    private final int count = 0;

    public static void main(final String[] args) {
        final var example = new Example();
        example.count = 10; // compile-time error
    }
}

Summary

JADEx introduces two complementary safety mechanisms:

Null-Safety

• Non-null by default

• Explicit nullable types

• Safe access operators (?., ?:)

• Compile-time detection of unsafe null usage

Readonly (Final-by-Default)

• Final by default

• Explicit opt-in for mutability

• Automatic final generation

• Prevention of accidental reassignment

Together, these features strengthen Java’s type system while remaining fully compatible with existing Java libraries, tools, and workflows.

JADEx does not replace Java.
It simply adds a safety layer that makes Java safer while keeping full compatibility with the existing ecosystem.