JPlus is fully compatible with Java, offering modern language features like null safety, boilerplate code generation and other modern language features to reduce developer burden and maximize productivity.
Notably, there is currently no ‘superset’ language that keeps Java syntax almost intact while extending the language with features like null checks at the language level. JPlus aims to fill this gap, providing a language that existing Java developers can naturally learn and adopt.
How does JPlus handle compile time null checks against Java library interfaces? Does it consider them all nullable and to be handled as nullable?
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?
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/@Nonnullannotations. -
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.
-
How does this post differ from this one? Why make two posts for the same thing?
As the title suggests, this page is an introduction to the project, while the other posts focus on how to use it.
This is a distinction without a difference. Both introduce and explain how to use the project.
Please check this post: Making your Java code null-safe without rewriting
Is this your first time here? The link in this post leads to the GitHub JPlus repository, while the other posts ultimately link to explanations on how to handle null safety using the JPlus IntelliJ plugin. Aside from the brief introduction, check out the additional links.
Is this your first time here?
Your account is brand new and you’ve already posted now three posts related to JPlus in this community in one day. Please tell me you’re joking with this one.
This post is a GitHub link to the project. Cool, I love seeing new projects, especially when the goal is to make it harder to write buggy code.
The other post is an article that immediately links to the GitHub. The GitHub contains a link at the top to, what I can tell, the same exact article. Both the article and the GitHub README explain what JPlus is and how to use it.
Why is this two posts when they contain the same information and link to each other directly at the top?
First of all, thank you for your interest in the JPlus project. I also apologize if anything I said earlier came across as rude.
The point I think was misunderstood is that, while the content of the posts is similar, the links they contain are different. To clarify once again, the link in this post directs to the JPlus GitHub repository, whereas the link in the post you mentioned points to the JPlus blog on Hashnode. Please check again.
Kotlin. The end.
“Yeah, Kotlin. The real The End”, just kidding :)
