3w ago

JPlus - A fully Java-compatible superset language

GitHub - nieuwmijnleven/JPlus

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.

General Programming Discussion @lemmy.ml

JPlus @programming.dev

3w ago

Seeking Opinions on Default Value Support in Named Parameter Feature

github.com /nieuwmijnleven/JPlus

Open Source @europe.pub

cm0002 @mander.xyz

3w ago

JPlus - A fully Java-compatible superset language

github.com /nieuwmijnleven/JPlus

Java @programming.dev

JPlus @programming.dev

3w ago

Introducing JPlus - A fully Java-compatible superset language

github.com /nieuwmijnleven/JPlus

24 comments

Notably, there is currently no ‘superset’ language that keeps Java syntax almost intact
There's groovy iirc.
- 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
  
  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.
  Groovy introduces dynamic typing
  Java has dynamic typing already. Groovy introduced it first, but it's not a Groovy exclusive feature anymore. It's also optional.
  additional syntax
  There being additional syntax doesn't matter if it's optional. We're talking here about whether Java code works in Groovy/JPlus, and it does. Not the other way around. At least that's what I understood.
  JPlus also adds the nullsafe and elvis operators, so it also adds additional syntax and JPlus code won't work when compiled with Java directly.
  Groovy is highly compatible with Java and most Java code runs in Groovy without changes. However, it’s not 100% identical.
  JPlus also doesn't guarantee being 100% identical. It says "mostly" the same.
  Basically, none of the arguments really compare the two in the context given. The runtime behavior is the only real difference listed here, but that's irrelevant in the context of them being supersets.
- And Scala
How does this post differ from this one? Why make two posts for the same thing?
- As the title suggests, this page is an introduction to the project, while the other posts focus on how to use it.
  
  This is a distinction without a difference. Both introduce and explain how to use the project.
Kotlin. The end.
- "Yeah, Kotlin. The real The End", just kidding :)
How does JPlus handle compile time null checks against Java library interfaces? Does it consider them all nullable and to be handled as nullable?
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?
- 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.

24 comments

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

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?