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

What sort of financial situation are you in that 40$/month is sufficient?

I survive each day with just a bag of potato chips. Now, I’m reaching a point where even that is no longer possible. But rather than begging, I believe it’s right to offer my skills, bring value to others, and earn rewards in return. In the midst of a very difficult time, I came up with the idea for JPlus, and I’m deeply grateful for that. Without this project, I would have been in a much more troubled mental state. Through this project, I continue to dream of a hopeful future.

Okay. You must realize it is weird to use the term “development team” to describe a one person side project. Also, are you willing to disclose to what extent and which models were used to create this project?

JPlus is an open-source project. Anyone can review the implementation details on GitHub: https://github.com/nieuwmijnleven/JPlus

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

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.

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.

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.

Please check this post: Making your Java code null-safe without rewriting

Is this your first time here? The link in this post leads to the GitHub JPlus repository, while the other posts ultimately link to explanations on how to handle null safety using the JPlus IntelliJ plugin. Aside from the brief introduction, check out the additional links.

“Yeah, Kotlin. The real The End”, just kidding :)

As the title suggests, this page is an introduction to the project, while the other posts focus on how to use it.

Ok, didn’t want to discourage you!

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

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.

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.

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.

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.

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