By that logic, every object-oriented language is just Smalltalk diluted with something. Dilution isn't degradation. Sometimes it's just called adoption.

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.

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

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.

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!

Thank you! I'll keep working to make JADEx a compelling option for teams in exactly that situation. Your interest and any feedback along the way means a lot.

Ok, didn’t want to discourage you!

Thank you for your interest. We hope you’ll continue to follow the project’s progress!

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

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.

I believe that if a company is a large corporation, it should provide financial support and take responsibility for large-scale bug reporting.

Thanks for your interest in JADEx. Please give it a try and feel free to share your feedback.

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

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.

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.

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.

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.

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.

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.

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.