<div dir="ltr"><div>Hi, folks:<br><br>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.<br>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.<br><br>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?”<br><br>This dives into the concept of values vs. objects. In other languages, this issue is often hidden behind syntactic sugar.<br>But in Java, new developers often have to “lift the hood” and look into the internals to truly understand it.<br><br>Although String is implemented as an object, many languages still allow value comparisons using == or ===.<br>Beginners or seasoned developers from other languages often misinterpret strings as simple value types and may not feel the need to dive deeper.<br>Personally, I believe the real confusion arises from the fact that the same operator == compares values for primitive types but compares references for classes.<br><br>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).<br>After all, operators are supposed to be used for value comparison.<br>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?”<br><br>Although the official recommendation remains to use .equals(), let’s be honest—many will still use ==, because, well...<br><br>This:<br>```<br>if (USDCurrency1 == USDCurrency2) {<br>    USDCurrency3 = USDCurrency1 + USDCurrency2;<br>}<br>```<br><br>is obviously much more readable and intuitive than:<br>```<br>if (USDCurrency1.equals(USDCurrency2)) {<br>    USDCurrency3 = USDCurrency1.add(USDCurrency2);<br>}<br>```<br><br>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.<br><br>“Problem 2” arises from syntax introduced in different Java eras—such as lambda expressions and switch expressions—which often confuse even seasoned Java developers.<br>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.<br>And after learning all the shiny new syntax, the younger folks still come back to “Problem 1”.<br><br>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.<br>Introducing new syntax always comes with trade-offs—ensuring backward compatibility and balancing the pros and cons.<br>Take JEP 465: String Templates, for example—a highly anticipated feature across languages, but it was withdrawn due to design issues.<br>Or operator overloading, which would be extremely useful for algorithm and library developers, but continues to be excluded due to the potential for misuse.<br><br>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.<br>It reduces cognitive load, visual fatigue, and even finger strain.<br>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?<br><br>But again, every syntax change comes at a cost.<br><br>This led me to:<br>- Is there a way for both junior and senior developers to work on the same codebase?<br>- Can we make it easier to introduce new syntax into an existing structure?<br>- 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?<br><br>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.<br>I forked this plugin, added a quick-input method feature, and renamed it “Advanced Java Folding Plus”.<br><br>Here’s how it works:<br>For example, when I type BigDecimal1 + BigDecimal2, the actual code is BigDecimal1.add(BigDecimal2), but the UI shows exactly what I typed.<br>When I type String1 === String2, the actual code is String1.equals(String2), and again, the UI reflects the original input.<br>PS: I currently define === as a pure value comparison to avoid semantic conflict with ==.<br><br>In the IDE, developers can toggle the display:<br>- Fold verbose syntax to reduce visual clutter<br>- Unfold simplified syntax when more clarity is needed<br><br>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.<br>No disrespect to those libraries, but many “features” in programming languages are really just syntactic sugar.<br>Even brand-new keywords or syntax in a language are often sugar-coated versions of existing constructs.<br>We all know sugar isn’t exactly healthy—but a little sweetness helps highlight the flavor of business logic.<br>Of course, everything in moderation (although I’ve noticed young developers these days really love their sweets).<br><br>That said, this is still just an IDE-bound plugin.<br>If the Java ecosystem could abstract new syntax into a layer of isolation—<br>like an automated syntax transformation layer that lets developers from different eras or different languages see code in “their” version of Java syntax—<br>maybe it could help attract more young developers and developers from other languages into the Java world.<br><br>Just a personal thought, a wish to help Java appeal to more developers from different backgrounds.<br><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>/* GET BETTER EVERY DAY */<br></div></div></div>