Unlike Java’s Optional, which is a library feature, JPlus provides null-safety at the language level. It allows developers to write code where null-safety is enforced consistently, without wrapping every value in an Optional. In that sense, JPlus brings the same kind of safety and clarity that Kotlin offers but keeps full compatibility with Java syntax and tooling.
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 your opinion.
I hope you’ll continue to follow and support the growth of JPlus!
The idea might be enough. Lots of companies running legacy code would be interested in this idea since it would make maintaining/patching it easy.
Thank you for your response. I will take your valuable feedback into careful consideration.
Yoy won’t find your target audience here on lemmy.
Instead you should look for companies that have open job/freelancer positions for maintaining legacy java code and pitch your project to them.
That’s a great idea. Thank you. However, I’m not sure if such opportunities would be available at my current stage.
Ok, didn’t want to discourage you!
Thank you for your interest. We hope you’ll continue to follow the project’s progress!
Kotlin is great for null-safety, but Kotlin isn’t a superset, you can’t just compile a java file with kotlin and have it work.
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.
There’s Groovy. Their examples use a bit different syntax, like a lack of semicolons, and Gradle might also give the wrong idea. But it’s fully compatible with Java source code iirc, just adds its own stuff on top and broadens the allowed syntax a bit.
Groovy is highly compatible with Java and most Java code runs in Groovy without changes. However, it’s not 100% identical. Groovy introduces dynamic typing, additional syntax, and runtime behaviors that can differ from Java. JPlus, on the other hand, aims to keep Java syntax almost intact while adding null-safety and boilerplate code generation making it easier to apply to existing Java projects without rewriting code
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
Notably, there is currently no ‘superset’ language that keeps Java syntax almost intact
There’s groovy iirc.
Groovy is highly compatible with Java and most Java code runs in Groovy without changes. However, it’s not 100% identical. Groovy introduces dynamic typing, additional syntax, and runtime behaviors that can differ from Java. JPlus, on the other hand, aims to keep Java syntax almost intact while adding null-safety and boilerplate code generation making it easier to apply to existing Java projects without rewriting code
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 believe that if a company is a large corporation, it should provide financial support and take responsibility for large-scale bug reporting.