JADEx: A Practical Null-Safety Solution for Java

submitted by

github.com/nieuwmijnleven/JADEx

14
1
7

Log in to comment

Hot Top New Old

Comments in Programming@programming.dev

Based on the readme this basically brings some Kotlin null handling and immutability as an add-on to Java projects. For a fresh project I recommend Kotlin. For an existing project this might add some value.

As for immutability Java already has options for that like the final keyword or immutable collections.

Overall an interesting idea. NPEs are way too common in Java code. Even the original creator of null feels it was a mistake to begin with.

 reply
2
OP

JADEx is a solution designed to enhance null-safety in Java. Its key advantage is that existing Java developers can gain null-safety and immutability without any learning curve. As a result, compared to migrating to Kotlin, JADEx offers a much more cost-effective way to significantly improve the stability of the legacy Java codebases that many companies continue to operate.

In addition, JADEx provides immutability, allowing developers to strengthen immutability without the verbose use of the final keyword.

 reply
-2
edited

I think null safety is an important step into software security. I like any approaches in that direction. But personally, I would just use kotlin. Kotlin and Java are so good with Interoperability that the transition is quite smooth and easy. Furthermore you get a better and more modern programming language without decades of technical dept.

 reply
3
OP

JADEx is a solution designed to enhance null-safety in Java. Its key advantage is that existing Java developers can gain null-safety and final-by-default semantics without any learning curve. As a result, compared to migrating to Kotlin, JADEx offers a much more cost-effective way to significantly improve the stability of the legacy Java codebases that many companies continue to operate.

 reply
1

Comments in Opensource@programming.dev

Mit as well use Kotlin at that point

 reply
4
OP

JADEx enhances Java with null-safety and readonly (final-by-default) semantics without requiring developers to switch languages. Existing Java developers can adopt these safety features with virtually no learning curve.

Compared to migrating to Kotlin, JADEx provides a significantly more cost-effective way to improve the reliability of large legacy Java codebases that many organizations still rely on.

 reply
1
edited

I have an excruciatingly hard time believing anyone who maintains a legacy codebase is going to look at a brand-new Java extension and say “Yup, that’s the basket we want to put all our eggs in” – compared to a robust, well-tested adjacent language that has vastly more benefits. If an organization is already extensively changing their legacy codebase to comport with some fledgling Java extension, they may as well just port to Kotlin.

 reply
2
OP

I think there may be a bit of misunderstanding about what JADEx actually is.

JADEx is designed as a Java safety layer, not a new programming language. It behaves more like a tool that sits on top of Java and strengthens null-safety while keeping full compatibility with the existing Java ecosystem.

The workflow is essentially:

Java (input) -> JADEx tool -> null-safe Java (output)

In other words, developers still work within the Java ecosystem, and the final output is standard Java source code that can be compiled with the regular Java compiler.

The key idea is that existing Java code does not need to be rewritten. You can gradually apply JADEx to strengthen null-safety in legacy codebases without migrating the language itself.

Migrating a large legacy codebase to Kotlin, on the other hand, is closer to a language migration project. It typically requires substantial effort: rewriting parts of the codebase, updating tooling, and spending significant time validating and testing the migrated code.

Because of that, the cost and risk profile are very different.

JADEx aims to provide a lower-friction path to improve safety in existing Java systems, especially for teams that must remain in the Java ecosystem.

Kotlin is a great language and an excellent choice for many projects.

In fact, a very reasonable approach could be:

  • strengthen existing legacy Java systems with JADEx
  • write new components in Kotlin if the team prefers it

Those two approaches are not mutually exclusive and they simply solve different problems.

 reply
1

OP, your documentation on your GitHub is unreadably sprawling, and despite that, you only have one tiny section addressing Kotlin, the most blatantly obvious answer imaginable to nearly everything you’ve created here (the response reads like it was generated by an LLM, just saying):

Q: Is JADEx trying to replace Kotlin or Java?

A: No.

  • Kotlin : a separate JVM language, designed independently
  • JADEx : a Java language extension, enhancing Java with null-safety and type expressiveness

Key Point:

JADEx does not aim to replace Java; it simply extends Java, making it safer and more expressive while staying fully compatible with existing Java code.

This really addresses absolutely nothing about why someone would use JADEx over Kotlin when they’re already willing to use non-default Java. IntelliJ can convert existing Java code to Kotlin code. I agree constant by default is nice, but it’s hard to imagine, weighed against Kotlin’s benefits, that it would get someone to stay on Java (especially some fledgling extension of it) if they really want null safety.

 reply
2
OP

The key point about JADEx is that it’s not intended to compete with Kotlin or replace it.

Kotlin is a separate JVM language with its own ecosystem, compiler, and language model. Migrating a large legacy Java codebase to Kotlin is essentially a language migration project. Even though IntelliJ can automatically convert a lot of Java code, in practice teams still need to review the generated code, adapt APIs, update tooling, and spend time validating the behavior of the migrated system.

JADEx tries to address a different scenario: teams that must stay within the Java ecosystem but still want stronger null-safety guarantees.

Rather than introducing a new runtime or replacing the language, JADEx works as a source-level safety layer:

Java source → JADEx analysis & operators → null-safe Java source

The output is still ordinary, human-readable Java that compiles with the standard Java compiler and works with existing Java libraries and tooling.

Because of that, the adoption model is different from Kotlin. Instead of migrating the entire codebase, teams can apply JADEx gradually to specific parts of an existing Java project to strengthen null-safety.

Kotlin is a great choice for many projects, especially for new development. JADEx is mainly aimed at improving safety in large existing Java codebases where a language migration is not practical.

I’ll restructure the README so that the core idea of the project is easier to grasp and expand the Kotlin comparison section in the documentation, since it’s clearly one of the first questions people have when they see the project.

Thank you for your feedback.

 reply
0

Or why not just use Kotlin

 reply
1
OP

JADEx enhances Java with null-safety and readonly (final-by-default) semantics without requiring developers to switch languages. Existing Java developers can adopt these safety features with virtually no learning curve.

Compared to migrating to Kotlin, JADEx provides a significantly more cost-effective way to improve the reliability of large legacy Java codebases that many organizations still rely on.

 reply
1
Insert image