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.

This is exactly the core problem that JPlus aims to solve.

t’s true that JPlus holds a similar position to TypeScript. However, it is a programming language. Here’s a definition quoted from the main page of the TypeScript website -> “TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.”

Similarly,

JPlus is a Java superset programming language — fully compatible with Java, offering modern language features like null safety, boilerplate code generation, and other enhancements to reduce developer burden and maximize productivity.

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.

JPlus follows standard Java syntax while aiming to be an “Upgraded Java” by adding features that Java developers consider practically useful in real-world projects. This allows existing Java developers to utilize new features with minimal learning curve. All features are added on top of Java syntax. For example, null-safety syntax (type?, ?.) and boilerplate code generation syntax (apply). As a result, developers can experience an enhanced version of Java while continuing to use existing Java code and libraries without modification. This should clarify exactly where JPlus fits in the ecosystem.

Thank you for the excellent question.

1. How does JPlus handle null safety in Java library interfaces?

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

2. If nullability information is a type metadata extension for compile-time checking, does that inevitably break on library interfaces when I create both library and consuming app with JPlus?

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

Didn't I make myself clear? If you find it uncomfortable because you think it's an advertisement, just move along. What do you think you're doing? Look at the project I'm working on before you speak. You have no idea how much effort has gone into it. Calling it a scam is truly absurd.

First of all, thank you for your interest in the JPlus project. I also apologize if anything I said earlier came across as rude.

The point I think was misunderstood is that, while the content of the posts is similar, the links they contain are different. To clarify once again, the link in this post directs to the JPlus GitHub repository, whereas the link in the post you mentioned points to the JPlus blog on Hashnode. Please check again.

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.

This isn’t an accusation, but was this comment written with AI? There’s a glaring logical error here which I think a human would catch easily, but an LLM (which is just a natural language generator, not a logic processor) could possibly overlook.

Specifically, your arguments don’t really make a lot of sense. They’re also not targeted at my claim. It reads more like a defense of JPlus. To which I want to clarify, I merely took issue with the specific claim I quoted, I wasn’t trying to say there’s no point to JPlus. There’s no need to defend JPlus in general. So I’m going to dismiss runtime behaviors since that has nothing to do with the syntax.

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.

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.

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.