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.

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.

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.

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.

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.

Thanks for your interest in JADEx. Please give it a try and feel free to share your feedback.

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.

We hope you continue to show great interest in JADEx. Thank you :)

Let me correct a misunderstanding. JADEx was created as a Java superset language to strengthen Java’s insufficient null-related type system. In JADEx, Java’s reference types are assumed to be non-null by default, and through the nullability static analysis results provided by JADEx, developers can explicitly choose to mark types as nullable. Because of this, there is no problem using null-safe access operators and the Elvis operator.

To summarize:

• Java: All types are nullable; there is no non-null type. Therefore, Elvis operators and null-safe access operators cannot be used.
• JADEx: Both nullable and non-null types exist. Therefore, Elvis operators and null-safe access operators can be used.

I believe that if a company is a large corporation, it should provide financial support and take responsibility for large-scale bug reporting.

What sort of financial situation are you in that 40$/month is sufficient?

I survive each day with just a bag of potato chips. Now, I’m reaching a point where even that is no longer possible. But rather than begging, I believe it’s right to offer my skills, bring value to others, and earn rewards in return. In the midst of a very difficult time, I came up with the idea for JPlus, and I’m deeply grateful for that. Without this project, I would have been in a much more troubled mental state. Through this project, I continue to dream of a hopeful future.

Okay. You must realize it is weird to use the term “development team” to describe a one person side project. Also, are you willing to disclose to what extent and which models were used to create this project?

JPlus is an open-source project. Anyone can review the implementation details on GitHub: https://github.com/nieuwmijnleven/JPlus

It’s true that the project is still in its early stages and not very large yet. I believe that with consistent effort, the number of people contributing to this project, as well as those who want to use JPlus, will grow over time. Thank you.

This is exactly the core problem that JPlus aims to solve.

t’s true that JPlus holds a similar position to TypeScript. However, it is a programming language. Here’s a definition quoted from the main page of the TypeScript website -> “TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.”

Similarly,

JPlus is a Java superset programming language — fully compatible with Java, offering modern language features like null safety, boilerplate code generation, and other enhancements to reduce developer burden and maximize productivity.

Thank you for your opinion.

I hope you’ll continue to follow and support the growth of JPlus!

The C Preprocessor also does all of those things. That’s expected of a preprocessor. If you say “you can write java code with a bit of extra sugar and JPlus turns it back into ‘regular’ java,” then that’s a preprocessor.

A simple preprocessor only performs code transformation and cannot analyze the meaning of the code or ensure type safety. However, JPlus goes beyond mere transformation by providing static analysis capabilities, such as generating a parse tree and checking nullability. It also includes functionality to automatically generate necessary Java code through the apply syntax. As a result, the combination of performing nullability static analysis and generating code via apply cannot be expressed or handled using any existing Java syntax alone.

JPlus follows standard Java syntax while aiming to be an “Upgraded Java” by adding features that Java developers consider practically useful in real-world projects. This allows existing Java developers to utilize new features with minimal learning curve. All features are added on top of Java syntax. For example, null-safety syntax (type?, ?.) and boilerplate code generation syntax (apply). As a result, developers can experience an enhanced version of Java while continuing to use existing Java code and libraries without modification. This should clarify exactly where JPlus fits in the ecosystem.

Thank you for the excellent question.

1. How does JPlus handle null safety in Java library interfaces?

• JPlus is currently implemented at the MVP level. Therefore, all Java library interfaces are treated as non-null by default. As a result, developers need to manually check for nullability when interacting with Java libraries.

• When referencing Java library objects, always declare the variables as nullable (type?) and use the null-safe operator (?.) when accessing them to prevent null pointer exceptions (NPEs).

• In future implementations, we plan to leverage nullability annotations in Java library code to add null-checking logic. However, since not all Java libraries include such annotations, developers will still need to manually handle null checks. The same applies to Kotlin: platform types are used, so developers are responsible for performing null checks.

2. If nullability information is a type metadata extension for compile-time checking, does that inevitably break on library interfaces when I create both library and consuming app with JPlus?

• In the current JPlus MVP, when converting to Java code, nullability information specified in the JPlus files is not converted into @Nullable/@Nonnull annotations.

• Therefore, using static analysis tools that rely on these annotations may cause issues at compile time.

• This feature will be supported in the next version, which will include conversion to @Nullable/@Nonnull. Thank you for your valuable feedback.

Finally, for faster responses, please post any future questions on the JPlus GitHub Discussions page: https://github.com/nieuwmijnleven/JPlus/discussions.

Didn’t I make myself clear? If you find it uncomfortable because you think it’s an advertisement, just move along. What do you think you’re doing? Look at the project I’m working on before you speak. You have no idea how much effort has gone into it. Calling it a scam is truly absurd.