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.
Thank you for the excellent question.
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.
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.
“Yeah, Kotlin. The real The End”, just kidding :)
Ok, didn’t want to discourage you!
Thank you for your interest. We hope you’ll continue to follow the project’s progress!
AFAIK Kotlin and Java code can co-exist as source level. Never tried it though. I guess it depends on the end case scenario what to use.
JPlus retains almost all of Java’s syntax while providing conveniences like null checks, allowing Java developers to use it immediately without additional learning. In contrast, Kotlin can utilize Java classes but requires learning Kotlin syntax and its libraries, and it cannot use Java syntax directly or automatically guarantee null safety. Therefore, JPlus offers a distinct advantage over Kotlin.
Things can get confusing if the explanation is too long, so here’s a concise way to put it.
It’s not entirely clear whether Groovy includes 100% of Java syntax, but in my view, Groovy focuses on enhancing the language itself, addressing areas where it falls short compared to modern languages.
On the other hand, JPlus is similar to how TypeScript addresses JavaScript’s lack of type safety: it focuses on strengthening Java’s safety while improving developer convenience through features like boilerplate code generation. Importantly, JPlus code always compiles down to standard Java, which means it can be integrated seamlessly into existing Java projects without changing the build environment or toolchain.
In short:
Groovy: Focuses on enhancing the expressive power of Java, adding modern language features and syntactic flexibility.
JPlus: Focuses on enhancing language safety and developer convenience, while maintaining full compatibility with Java. This allows developers to adopt JPlus without worrying about breaking existing Java projects.
Might be useful to some, but the underlying assumption that “more features = better” is questionable in general.
You’re right. more features don’t always mean better. JPlus isn’t just about adding features; Our goal is to reduce boilerplate and enforce null-safety in existing Java code without rewriting it. Even when adding new functionality, JPlus avoids features that would be difficult for existing Java developers to adopt. All new features are designed to feel natural to Java, keeping the learning curve minimal so developers can use them intuitively without extra study. Its value comes from practical safety and developer convenience, rather than simply having more language features
Isn’t kotlin a better option?
Kotlin is great for null-safety, but JPlus allows you to enforce null-safety without rewriting your existing Java code, which can be easier for teams working in legacy projects or who prefer staying in pure Java.
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.