justicecoder

joined 1 day ago
[–] justicecoder@programming.dev 2 points 20 hours ago* (last edited 19 hours ago) (2 children)

Kotlin isn’t a superset, you can’t just compile a java file with kotlin and have it work afaik. That seems to be the point here.

This is more like a preprocessor anyway, like SASS to CSS. The compiler spits out Java source code, not jvm bytecode.

Exactly, as you said, Kotlin isn’t a Java superset. you can’t just compile a Java file with Kotlin and have it work. JPlus works similarly in that it outputs standard Java source code rather than JVM bytecode.

However, JPlus is not merely a “preprocessor.” It actually parses Java source like a compiler, performs null-safety checks and boilerplate code generation on the generated parse tree, and finally produces standard Java code. In that sense, JPlus should be considered a compiler. The only difference is that its output is Java code; if the code generation step were extended to produce JVM bytecode directly, it could bypass the Java source entirely and generate bytecode straightaway.

The key point is that, just like TypeScript addresses JavaScript’s lack of type safety, JPlus fills in some of Java’s gaps. It allows you to keep almost all of your existing Java code while adding features like null-safety and automatic boilerplate generation, improving both safety and developer convenience.

[–] justicecoder@programming.dev 2 points 20 hours ago (2 children)

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

[–] justicecoder@programming.dev 2 points 21 hours ago* (last edited 21 hours ago) (2 children)

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

[–] justicecoder@programming.dev 3 points 21 hours ago (2 children)

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

[–] justicecoder@programming.dev 3 points 21 hours ago (2 children)

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.

view more: ‹ prev next ›