Why I Built JADEx Instead of Switching to Kotlin

[-]

joemwangi@reddit

Great tool honestly and very quite good ergonomics it's brings, but the author is underestimating the planned nullness in java with the mis-characterisation that will only be for runtime, which won't be the case. It will also be a powerful static analysis implementation, including narrowing nullness types implicitly.

[-]

Delicious_Detail_547@reddit (OP)

You're probably referring to Project Valhalla. Even when that era arrives, JADEx will still remain meaningful. Here's why:

Q: Shouldn’t we just wait for Project Valhalla?

A: Valhalla is the future of the JVM and JADEx lets you experience Valhalla-style null-safety in today’s Java.

However, JADEx is not a temporary workaround while waiting for Valhalla. It is a tool that remains valuable even after Valhalla arrives.

From a null-safety perspective, the key difference is this: - Valhalla helps you avoid null. it does not eliminate null. - JADEx makes NPEs structurally impossible to write.

	Valhalla	JADEx
Default	nullable	non-null
Primary goal	Performance / modeling	NPE elimination
Target code	Mostly new code	Legacy code
Null-safe operators	❌	`?.`, `?:`
Gradual adoption	Limited	Core design principle
Output focus	Bytecode	Human-readable Java

Even after Valhalla ships:

String s = foo();
s.length();

This code will still: - Compile successfully - Potentially crash at runtime - Exist across billions of lines of legacy Java

Valhalla does not infer or enforce null contracts in existing APIs.

In JADEx,

String s = foo(); // compile-time error if foo() is nullable

The problem surfaces at authoring time, not in production.

Q: How is this different from Valhalla’s non-null types?

A: ① Valhalla’s non-null is opt-in and conservative

Point! p;

Developers must explicitly opt in
Data-flow analysis is limited
It does not change Java as a whole

👉 The default is still nullable

In other words, Valhalla introduces non-null selectively, without redefining Java’s baseline assumptions.

② JADEx is non-null by default

String name;    // non-null
String? nick;   // nullable

This difference is immediately noticeable in daily development.

“Java, where every type must be doubted” vs. “JADEx, where you only add ? when you actually mean nullable”

Q: Can Valhalla and JADEx Be Used Together?

A: Absolutely. In fact, they are an ideal combination.

1. Clear Separation of Responsibilities

Project Valhalla
- Evolves the JVM’s runtime and memory model
- Introduces value-based objects for better performance
- Supports enhanced type annotations, such as nonnull, at the JVM level
JADEx
- Enhances null-safety and type safety at the source code level
- Generates plain Java code that is fully compatible with existing JVM features

2. Why They Work Well Together

No conflicts arise between Valhalla and JADEx; they operate at different layers:
- Valhalla → runtime and memory optimizations (JVM Level)
- JADEx → source-level null-safety and expressiveness (Source Code Level)
After Valhalla is released, JADEx-generated code can include Valhalla’s nonnull annotations automatically.
- This means that developers gain clear, explicit information about which types are nullable or non-nullable directly in the source code.
- As a result, developers can write safer and more predictable code, confidently knowing which variables can or cannot be null, without extra manual annotations or runtime checks.
Neither project replaces the other; instead, they complement each other, improving both performance and developer productivity.

[-]

joemwangi@reddit

This is what I'm referring to. Of course null-restricted types in java main goal is to ensure optimisation of java objects and to optimise flattening of value types, because value types have null markers, so that semantic meaning of nullable types becomes consistent in all types, even with types without identity. As such, java will try to ensure null-restricted types are enforced both through nullness at compile time and runtime. Hence saying "Valhalla → runtime and memory optimizations (JVM Level)" is just part of the story, and compile time null-checking will also be a factor feature.

Therefore, features like

P? x = getP();

if (x != null) {
  P! p = x; // safe
}

Are handled through compile time analysis where possible, with runtime enforcement as fallback. Or

P? x = null;
P! p = x;       // compile-time warning, runtime failure if executed unless x is initialised

In some situation, even

P! x = getP(); //if return is P?, narrowing nullness conversion may warn at compile time, runtime check if not provably safe

Which is based on java moving toward unifying binding and checked extraction as evidently shown in P! x = getP();. This is part of the enhanced local variable declaration work currently planned for a future preview explicitly leans on applicability and exhaustiveness checks at compile time.

[-]

Delicious_Detail_547@reddit (OP)

You're right that Valhalla will include compile-time static analysis for null-restricted types — I should have been more precise in the FAQ. That's a fair point.

However, the fundamental difference remains: Valhalla's null-restricted types are opt-in. Developers will still need to decide, for every type, whether to append ! or not — meaning the default assumption is still nullable. That cognitive burden doesn't go away.

JADEx flips this entirely. Every type is non-null by default. You only add ? when you explicitly mean nullable. No second-guessing every declaration.

Also worth considering: Valhalla's timeline is uncertain. The general consensus is at least 2+ more years before it ships in a stable form. JADEx is available today, works with your existing Java 21 codebase, and requires no JVM changes.

How long are you willing to wait?

[-]

programming-ModTeam@reddit

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.

[-]

programming-ModTeam@reddit

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.

[-]

Delicious_Detail_547@reddit (OP)

That comment was actually quoted directly from the project's FAQ.

[-]

tuxwonder@reddit

Giving AI responses to people's questions about your brand new project is kinda lame and personally would not make me want to invest time into something that I'm now concerned is just a vibe-coded house of cards

[-]

Delicious_Detail_547@reddit (OP)

That comment was actually quoted directly from the project's FAQ. If you'd taken 5 minutes to look at the commit history or read through the codebase, you wouldn't be saying this. more than 6 months commits, Jadex to java transpiler, an IntelliJ plugin built on the Intellij Platform SDK, and a published Gradle plugin. Don't make assumptions without looking at the code.

[-]

programming-ModTeam@reddit

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.

[-]

tuxwonder@reddit

It's a nice idea, but the thing that will make or break an idea like this is the tooling.

Will Intellij/Eclipse/Github/Markdown/whatever highlight this correctly? Will the language server still provide suggestions and analysis though it's technically a different language? Will you see red squiggles and error indicators despite everything compiling correctly?

And of course, the ultimate final test: will your coworkers and management approve it?

[-]

Delicious_Detail_547@reddit (OP)

JADEx currently provides both an IntelliJ Plugin and a Gradle Plugin. Once you install the IntelliJ Plugin, you get not just syntax highlighting for JADEx, but also features like Code Completion — everything works seamlessly out of the box.

Feel free to follow the examples in the JADEx project below. It's never too late to evaluate after you've actually tried it.

Q: Shouldn’t we just wait for Project Valhalla?

Q: How is this different from Valhalla’s non-null types?

Q: Can Valhalla and JADEx Be Used Together?

Links