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.

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 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.

But you can't look at a method signature and instantly know who handles the null check. You need to inspect code and calls to know for sure. This will lead to paranoia, sooner or later

The problem is that when an project is too big and a method is called from multiple contexts it's very easy to lose track of the context where the null check has been done and where it hasn't. This leads to a lot of duplicated null checks around the project and the constant paranoia of "can this be null here?".

A much better way of doing this is using the Optional when an Object can be "null" and a direct instance where it cannot. This way, at any given context you know for absolute sure if a null check is needed or not. However, even with annotations this does not throw a compile error...