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.
But there is a reason for null, its a really nice thing you can work with… I really don’t understand all the fuss about null safety, working against the language
I want to write functions that fail at compile time if called with a null object. You can use annotations to kinda do this, but they do not produce compile errors.
Isn’t kotlin a better option?
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.
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.
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
A preprocessor is basically a compiler which produces input for another compiler. Yes, it’s a compiler. The difference is that it produces source files, not bytecode.
From Wikipedia:
In computer science, a preprocessor (or precompiler)[1] is a program that processes its input data to produce output that is used as input in another program. […], which is often used by some subsequent programs like compilers.
The emphasis is mine.
Both Typescript and SASS are examples of preprocessors.
From Wikipedia:
In computer science, a preprocessor (or precompiler)[1] is a program that processes its input data to produce output that is used as input in another program. […], which is often used by some subsequent programs like compilers.
The emphasis is mine.
Both Typescript and SASS are examples of preprocessors.
By that logic, the C compiler would also be a preprocessor since it converts C code into assembly. Simply calling something a preprocessor just because its output is source code is not logically correct. The same applies to JPlus: the fact that it ultimately produces Java source code does not make it a preprocessor. Internally, it performs compiler-level processes such as AST generation, null-safety checks, and boilerplate code generation, so it should be regarded as a proper compiler.
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.
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.
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.
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.
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.
You can probably adopt both for a large existing project. Old files get compiled with JPlus, new files will be written in Kotlin. Old files can also gradually be ported to kotlin.
You can probably adopt both for a large existing project. Old files get compiled with JPlus, new files will be written in Kotlin. Old files can also gradually be ported to kotlin.
Exactly, that could work. You can keep the existing files as they are and compile them with JPlus, while writing new modules in Kotlin to adopt it gradually. JPlus can serve as a stepping stone before moving fully to Kotlin. However, converting all Java code in an existing project to Kotlin would not only carry significant risks but also be costly. With JPlus, you can fully leverage the proven existing Java codes.
So, it’s C#'s Nullavle Reference Types feature" but for Java, and not baked into the language.
So, it’s C#'s Nullavle Reference Types feature" but for Java, and not baked into the language.
So, it’s C#'s Nullavle Reference Types feature" but for Java, and not baked into the language.
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.
Notably, there is currently no ‘superset’ language that keeps Java syntax almost intact
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.
There is one Groovy syntax that replaces some Java syntax: code blocks now become closures.
What you can write in Java as
{ System.out.println("Hello, world!"); }You would have to write in Groovy with a label
l: { System.out.println("Hello, world!"); }Groovy doesn’t have null safety or boilerplate code generation features. That’s why JPlus was created to address what Java developers truly feel is missing. Go post that comment in the Groovy community.
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
You say:
Groovy is not 100% identical
Then you say:
JPlus aims to keep Java syntax almost intact
Which implies that it is not 100% identical either.
So why do you apply that same argument against one but not the other? Seems like marketing bs.
You say:
Groovy is not 100% identical
Then you say:
JPlus aims to keep Java syntax almost intact
Which implies that it is not 100% identical either.
So why do you apply that same argument against one but not the other? Seems like marketing bs.
As you mentioned, the phrasing might make it seem inconsistent. The key difference here is not whether they are “100% identical,” but the degree and nature of the changes.
Groovy introduces dynamic typing, optional syntax, runtime behaviors, and other language features that can fundamentally alter how Java code executes. Even if the code compiles, subtle differences in behavior can occur. In contrast, JPlus preserves nearly all standard Java syntax while only adding compile-time null-safety checks and boilerplate code generation. These changes have minimal impact on the execution of existing Java code and are primarily intended to improve safety and developer convenience.
Additionally, JPlus is currently developed based on Java 20 syntax, with added null-safety and boilerplate code generation features. Therefore, code up to Java 20 is fully compatible. Since future updates will support the latest Java syntax as well, the phrasing “almost identical” is used intentionally. In practice, JPlus will continue to be Java syntax + α.
Technically, neither language is “100% identical” to Java, but the practical impact is very different. Groovy can alter runtime behavior, whereas JPlus preserves existing behavior almost entirely while adding safety and developer convenience. This is not marketing exaggeration, but a reflection of the difference in the invasiveness of changes.
