Bridging Java Generations: Making Syntax Intuitive for All Developers

[tzengshinfu]

Hi, folks:

Although Java has recently adopted many modern features, a lot of legacy
syntax still remains in the codebase due to concerns about backward
compatibility and semantic consistency.
In our company, this often means that whenever new developers join, I have
to re-explain some core concepts of Java—especially to those who have never
worked with it before.

For example, newcomers usually notice that you can concatenate strings
using String1 + String2 (to be honest, it’s this syntactic sugar that makes
“Problem 1” harder to explain), and then immediately ask the FAQ “Problem
1”: “Why can’t we compare strings with String1 == String2?”

This dives into the concept of values vs. objects. In other languages, this
issue is often hidden behind syntactic sugar.
But in Java, new developers often have to “lift the hood” and look into the
internals to truly understand it.

Although String is implemented as an object, many languages still allow
value comparisons using == or ===.
Beginners or seasoned developers from other languages often misinterpret
strings as simple value types and may not feel the need to dive deeper.
Personally, I believe the real confusion arises from the fact that the same
operator == compares values for primitive types but compares references for
classes.

If we truly want to compare references, it should be done through an object
method, like Object.addressEquals(Object1, Object2) (assuming such a method
exists).
After all, operators are supposed to be used for value comparison.
Even if Java introduces JEP 401: Value Classes and Objects, I bet newcomers
will still ask, “Why can I use == to compare what is obviously an object?”

Although the official recommendation remains to use .equals(), let’s be
honest—many will still use ==, because, well...

This:
```
if (USDCurrency1 == USDCurrency2) {
    USDCurrency3 = USDCurrency1 + USDCurrency2;
}
```

is obviously much more readable and intuitive than:
```
if (USDCurrency1.equals(USDCurrency2)) {
    USDCurrency3 = USDCurrency1.add(USDCurrency2);
}
```

Sure, methods provide clearer semantics, but sometimes simple operations
are more immediately understandable with operators. Operators visually
separate arguments more intuitively, while methods with long names can blur
the lines between method and arguments, especially when the names get
lengthy.

“Problem 2” arises from syntax introduced in different Java eras—such as
lambda expressions and switch expressions—which often confuse even seasoned
Java developers.
Even the latest proposal, JEP 477: Implicitly Declared Classes and Instance
Main Methods, helps younger developers learn faster, but at the same time
increases the learning curve for veteran developers.
And after learning all the shiny new syntax, the younger folks still come
back to “Problem 1”.

This made me realize: the later a JEP (Java Enhancement Proposal) is
introduced, the less likely it is to bring major syntax changes or
optimizations.
Introducing new syntax always comes with trade-offs—ensuring backward
compatibility and balancing the pros and cons.
Take JEP 465: String Templates, for example—a highly anticipated feature
across languages, but it was withdrawn due to design issues.
Or operator overloading, which would be extremely useful for algorithm and
library developers, but continues to be excluded due to the potential for
misuse.

Syntax evolution—its additions, changes, or simplifications—impacts
developers the most. Cleaner syntax can help developers focus on business
logic instead of fighting with quirky syntax.
It reduces cognitive load, visual fatigue, and even finger strain.
If syntax updates can’t make the developer’s life easier, they become
handcuffed. And in the AI age, how can Java attract developers from other
languages (especially Python) without offering comparable simplicity?

But again, every syntax change comes at a cost.

This led me to:
- Is there a way for both junior and senior developers to work on the same
codebase?
- Can we make it easier to introduce new syntax into an existing structure?
- Can we write and read code as concisely as a script while keeping the
strict semantics of Java—hiding implementation details when focusing on
business logic, and expanding them on demand?

With that thought, I discovered an IntelliJ IDEA plugin: “Advanced Java
Folding”. It enables both new and experienced developers to collaborate on
the same codebase without modifying the source code.
I forked this plugin, added a quick-input method feature, and renamed it
“Advanced Java Folding Plus”.

Here’s how it works:
For example, when I type BigDecimal1 + BigDecimal2, the actual code is
BigDecimal1.add(BigDecimal2), but the UI shows exactly what I typed.
When I type String1 === String2, the actual code is
String1.equals(String2), and again, the UI reflects the original input.
PS: I currently define === as a pure value comparison to avoid semantic
conflict with ==.

In the IDE, developers can toggle the display:
- Fold verbose syntax to reduce visual clutter
- Unfold simplified syntax when more clarity is needed

This plugin can serve as a workaround for the lack of operator overloading.
In theory, it could support most syntax transformations and even replace
certain libraries, like Lombok or Manifold.
No disrespect to those libraries, but many “features” in programming
languages are really just syntactic sugar.
Even brand-new keywords or syntax in a language are often sugar-coated
versions of existing constructs.
We all know sugar isn’t exactly healthy—but a little sweetness helps
highlight the flavor of business logic.
Of course, everything in moderation (although I’ve noticed young developers
these days really love their sweets).

That said, this is still just an IDE-bound plugin.
If the Java ecosystem could abstract new syntax into a layer of isolation—
like an automated syntax transformation layer that lets developers from
different eras or different languages see code in “their” version of Java
syntax—
maybe it could help attract more young developers and developers from other
languages into the Java world.

Just a personal thought, a wish to help Java appeal to more developers from
different backgrounds.


/* GET BETTER EVERY DAY */
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250410/71cc3a5e/attachment.htm>