Regaining JAVA: Why is this programming language not working?

The full text is 2322 words, and the expected learning time is 6 minutes

In order to cope with the new job, the author has been re-acquainting with an old friend: JAVA in the past two weeks. I started my software business with JAVA and worked with it for about two and a half years. But with the advent of containers and microservices, JAVA quickly disappeared. To this day, it has been three years since I last used Java to write code seriously. I didn't expect it to appear again, especially in the field of microservices.

How is this going? The answer is simple: the ubiquitous microservices are overwhelming.

· Easy to expand

· High availability

· Simpler code base, no need to worry about concurrency and multithreading

· Portability brought by containerization

All of this makes people question Java (more specifically the JVM), not to mention Java's most notorious Spring framework.

Sometimes people are immersed in technologies such as Kubernetes and feel that the era of Java is history, and Java performs poorly in the container and microservice ecosystem (the key to software scalability and high availability). Although shaken by the simplicity and elegance of languages such as Python (the author's current preferred language), as a former fan of Java, the author believes that Java still has unquestionable advantages in certain areas.

For example, Java has powerful threading capabilities, and I used them directly in key banking applications early in my career. Although it is not fair to compare the performance indicators of compiled languages with scripting languages, the rock-solid performance of Java is truly unparalleled.

For horizontal scalability and microservice architecture, the inherent performance of this language has little effect, because people can directly generate more containers to obtain excellent performance. Obviously, these scripting languages, coupled with the ability to instantly zoom in or zoom out within the container, can make Java go home. The author is convinced that Java is dead, at least in the field of microservices.

In the new job, the author is further convinced and painfully aware of how disgusting, irritating, and confusing this language is (partly due to outdated rigid frameworks such as Spring).

The seriousness of Java and Spring

First talk about the notorious Spring framework. Just like five years ago, Spring is huge and puzzling, full of endless comments. Developers either have to resort to tutorials or sample codes each time, or they can only study the lengthy documentation provided by Spring.

Spring has adopted a very rigid language, which is covered by single-line comments and seemingly simplified wrappers, thereby exacerbating the severity of this problem. These wrappers will bring a bunch of calls and class instantiations, usually sent Not useful.

All developers agree on this: the controllability, instruction and transparency of the language are the keys to efficient software development. In short, developers want to know exactly what happened in the code and which routines were executed (at least at a high level). But Spring has a huge obstacle here.

If you have to insert six running task annotations at the top of the class, they are intricately related to each other in the Spring environment, then your situation is complicated. Not only Spring, but the Lombok library as an example. This is the first line description on its homepage:

"The Lombok project is a Java library that will be automatically inserted into your editor and build tools to add luster to your Java. There is no need to write another getter or equals method. An annotated class will have a fully functional Generator, automatic execution of logging variables, etc."

The goal of compressing Java code is just to follow the script, and it cannot really work.

Java should stop matching the simplicity of scripting languages. First, this sacrifices the consistency of the Java code: imagine returning to Java and discovering that all getters and setters have disappeared, replaced by a single-line comment @NoArgsConstructor. How can there be consistency?

Secondly, it adds an abstract array that is already inexplicable. For example, Spring can set up autowiring (bean injection) in the background, which is understandable, but where is Lombok located in the application environment and how to coordinate messages? If each class has six annotations, how many other routines or classes are instantiated by these annotations to accomplish this simple task?

Every developer does not want additional code lurking around. However, this is the Java code I encountered three years later, without any changes. In fact, small changes will only make the situation worse. Java still focuses on stupid rules that specify the class name that should be used, the package it is in, and whether the variable is private or protected. But no one cares about these.

In contrast, Python directly responds to the lack of language access specifiers: "Everyone is an adult". This one-line reply is ironic and attractive. It immediately resonated with me. I used to think that the absurd and useless concept was much more reasonable under its influence.

Keep it simple, programmers

Source: unsplash

In the software industry, you often hear people say "KISS": Keep it simple, Stupid. Java can only survive if this is seriously considered.

Nowadays, the microservice model is almost ubiquitous in the software industry, and even many organizations that run ancient applications are increasingly replacing their old ones to simplify design and improve scalability. For programmers, this means breaking down their huge code base or complex business logic into simpler and concise functions-a paradigm that does not require state management in the code, thereby avoiding concurrency and multithreading problems .

In the final analysis, no matter what kind of service, it only processes data in a certain format (JSON or XML), and then passes them to the message bus (such as Kafka) for further processing. Even in such a simple setting, Java and Spring are still copying outdated and rigid code syntax: Application Contexts, bean injections, autowiring, POJO mappers, JVM that requires a lot of memory, and annoying class loader.

Regaining JAVA: Why is this programming language not working?

Guess you like