Why Java Is Dying

The Ceremony of Java and Spring

Let’s start with the notorious Spring framework.

Spring is as bulky and convoluted as it was five years ago, riddled with interminable annotations that leave developers at the mercy of tutorials or sample code every time they need to get things done. It’s either that or the arduous task of perusing Spring’s own exhaustive documentation.

My beef, in fact, is more with frameworks like Spring than Java itself. Spring adds to the problem by taking an already ceremonious language, veiling it with one-line annotations and seemingly reductionist wrappers that end up summoning a carnival of invocations and instantiations of classes that you often don’t need. As any developer would agree, control, command, and transparency of a language are crucial to efficient software development. Quite simply, as a developer, you want to know precisely what goes on in your code and what routines are executed — at least at a high level. But Spring painfully deters you in this aspect.

If you have to drop six annotations on top of your class, with each one doing its own thing, intricately interconnected in the mesh of spring contexts, you are in murky territory. And this is not just Spring. Take, for example, the Lombok library. This is its front line as advertised on their homepage:

“Project Lombok is a java library that automatically plugs into your editor and build tools, spicing up your java. Never write another getter or equals method again, with one annotation your class has a fully featured builder, Automate your logging variables, and much more.”

This regurgitated goal of compacting Java’s code is frustrating and painfully works against the language rather than doing any real good.

Java should simply stop trying to match the brevity of scripting languages. Firstly, this sacrifices consistency in Java code: Imagine coming back to Java only to find all your getters and setters gone (something we once learned was critical to Spring autowiring), now replaced with the one-line annotation @NoArgsConstructor. Where is the consistency in that?

Secondly, it adds to the already convoluted array of abstractions. Here, for instance, Spring is understandably setting up autowiring (bean injections) behind the scenes, but then where does Lombok live in the application context and how is message passing orchestrated between the two? If I have six annotations for each of my classes, how many other routines or classes were instantiated by these annotations to do this simplistic job? No real developer would want all this extra code lurking in the corners. Sadly enough, this is the kind of Java code I run into after three years. Not a single thing has changed. In fact, even the little changes that have happened have only made it worse.

Java’s focus still appears to be on silly rules that dictate what class names should be, what packages they should be in, and if variables should be private or protected. Seriously, who cares?

In contrast, “We’re all adults here” is literally Python’s official response to the absence of access specifiers in the language. This derisive yet compelling one-line response instantly struck a chord with me. It finally provided some sanity to a concept that I often felt was absurd and unnecessary.

from Hacker News https://ift.tt/34qbUex