I built a practical null-safety solution for Java

[nieuwmijnleven]

Select Topic Area

Show & Tell

Body

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.

[suresurya]

This is a really clean idea. Bringing Kotlin-style null safety (?., ?:) to plain Java without touching the JVM is genuinely useful, especially for teams stuck on large Java codebases who can't just migrate overnight.
The final-by-default with apply readonly; is a nice touch too. Enforcing immutability by convention rather than discipline is something Java has always lacked, and having the compiler catch accidental reassignments is a real win.
A few things I'm curious about:

How does JADEx handle interop with existing libraries that return raw Object or unannotated types? Does it treat those as nullable by default?
Is the SafeAccess helper available at runtime, or is it fully compiled away?
Any plans to support records and sealed classes with null-safety semantics?

The compilation output being standard Java is smart — it means CI pipelines, IDEs, and existing tooling don't need to change at all.
Solid project. Following the GitHub. 👍

[nieuwmijnleven]

Thanks for the kind words and great questions!

Interop with unannotated types: Currently, JADEx treats types from java.* and javax.* packages as nullable by default, while types from other packages are assumed non-null. That said, we're planning to integrate bytecode instrumentation (e.g. ASM) down the line to make nullability inference significantly more accurate for third-party libraries.

SafeAccess at runtime: SafeAccess<T> is a interface that exists at runtime — it's not compiled away. It serves as an Optional replacement designed to propagate checked exceptions through lambdas, so it only appears when you explicitly use it. The null-safety operators (?., ?:) themselves are compiled down to standard Java null checks with zero runtime overhead.

Records and sealed classes: Good point — records are definitely on our radar. Because the compiler auto-generates code internally (constructor, accessors, etc.), we're planning to strengthen the nullability analyzer to properly handle those generated members. Sealed classes work as-is with the same null-safety semantics as regular classes, no JADEx-specific changes needed.

Appreciate the follow — feedback like this helps a lot!

[itxashancode]

I would start by checking how this integrates with standard build pipelines. Since JADEx introduces new syntax, does it run as a Maven or Gradle plugin wrapping javac, or as a standalone preprocessor? I ran into similar compiler extensions that broke IDE indexing and CI caching because they required swapping out the default toolchain. Exposing it through the standard compiler plugin configuration would make adoption much easier.

I am also curious about how you handle stack traces after source transformation. If the ?. and ?: operators get rewritten into SafeAccess calls, line numbers will shift. I would recommend generating a source map or adding a compiler flag to preserve original line metadata so debugging stays straightforward.

What is the measured performance overhead of SafeAccess.ofNullable() compared to a direct null check in hot paths?

[nieuwmijnleven]

• JADEx operates as a standalone preprocessor. As a result, it is clearly decoupled from javac or javaCompile tasks. The workflow follows a specific sequence: JadexCompile precedes javaCompile.

• JADEx generates source maps during the Java transformation process. However, we do not officially support debugging within JADEx yet. We will certainly consider your suggestion of adding a compiler flag to preserve line metadata when we implement debugging features in the future.

• We do not currently have benchmarks comparing SafeAccess performance directly against manual null checks. Since the SafeAccess API is similar to Optional, it is likely to cause a noticeable performance hit in hot paths, much like Optional does. The primary goal of introducing SafeAccess was to improve readability and handle checked exceptions, which Optional cannot do. That said, since performance in hot paths is a critical factor, we plan to add an option to generate plain-code null checks instead.

Thank you for your valuable suggestions, and we look forward to your continued interest in JADEx.