Why Java slows down and fails to introduce new features

No, it's not a performance issue. A bit of backstory.

Back in 2018, fintech shared an insight that in the early tens, the return on electronic exchange trading was $1 on $1,000 of invested money. By 2018, it had fallen to 1 cent from $1,000. Apparently, the returns are even lower now. Transaction decisions have to be made very quickly, every microsecond is worth its weight in gold. Fintech is choosing Java. So we Java programmers are fine with speed.If you want to grow your skills in Java , you can use this platform.

The question "Why is Java slow then?" - more about features

For example, about a trivial String. repeat(X). It's hard to imagine, but back in 2009, the task "How to repeat a string?" on StackOverflow gathered 720 likes and has several original solutions. Java 11 put an end to it by adding the coveted method to the Standard Library.

Well, how did it set it? In early 2022, only a third of projects use version 11 or higher of Java, while the rest are exploiting older versions of the JVM, and for them the task is not obsolete.

"So what, String. repeat(Y), what a rubbish!" - you may say. Perhaps you haven't seen the task of implementing String. repeat(Z) logic at a job interview.

Not everything is all right with asynchronous programming in Java too. And this is not a trifle either. The point is that Moore's Law no longer works. Moore's original observation is "the number of transistors in a chip doubles every year". This was the case from 1975 until about 2010, and after that doubling ended.

It used to be that a programmer, if his project wasn't moving fast enough, could pause for a year or two, buy new hardware, and achieve the required performance figures.

Such tricks don't work any more. In order to increase performance, several processors had to be used simultaneously. This is where Amdahl's law comes in. On the contrary, it has never been cancelled. It is very difficult to parallelize a program. It turns out that some part of calculations is always essentially sequential and some part can be executed on several cores simultaneously. The ratio of these parts strongly depends upon the speed of work on several processors.

We even have to distribute tasks between different machines, and then inevitably one starts waiting for the other. Both in local and global parallel computations we have to wait for results asynchronously. Asynchronous programming is our present and at least the near future. In classical Java, this future is sad. Locking programming for a large number of threads is hindered by resources. The words thenApply, thenCombineAsync, exceptionally strike terror in the heart of anyone who has dealt with non-blocking Core Java.

Alternatives to Java. What are they?

Alternative programming languages to Java have been around in the JDK ecosystem for a long time. For example, Scala in 2003 or Clojure in 2007. What can we say about these languages? A lot of good.

According to some reports, a Clojure specialist is paid twice as much as a Java programmer, similarly (one and a half times) as much as a Scala specialist. However, the job market for these languages is smaller than for Java. There is no serious competition from their side. Most likely, the use of such languages is niche and is related precisely to high parallelism.

In 2016, the 1.0 version of Kotlin is released. By now, being younger than Java, Kotlin has gained one-fourth of its market share in the labour market. In the Android application niche, Kotlin has even become the de facto standard. Why has this happened?

First, Kotlin has special libraries that facilitate asynchronous programming. These are so-called Kotlin coroutines. They allow you to operate something like lightweight tracks. Lightweight here means cheap in the sense of resource allocation per instance.

Second, asynchronous Kotlin constructs are easier to interface with each other than the puzzling interfaces of non-blocking Java.

Third, the Kotlin coroutine library implements the concept of structural competitiveness.

The term "Structural Competitiveness" was coined by Martin Sustric, the creator of ZeroMQ. He was followed brilliantly by Nathaniel Smith in his "Notes on Structural Competitiveness". There are now several implementations of this approach for a wide variety of programming languages. They include libdill (C), Trio (Python), async_nursery (Rust), Venice (Swift) and, of course, Kotlin coroutines.

The principle of structural competitiveness allows for correct error handling. In particular, release limited resources: close file descriptors, sockets and so on. We don't want applications in a mobile device to "eat up" memory, resources and permanently "slow down" the device in the process, do we? Google doesn't want that either. This is how Kotlin got the upper hand over Java on Android.

A little about the Loom project

Back to Java and the topic of lightweight tracks. There are plans to add a feature to the language that is currently under development. This is the Loom project, which had its first public release back in 2018. But the project flew both past the 17th LTS release of the JDK and past the passable 18th release. Judging by the pace at which new commits are being thrown into the project's repository right now, Loom might not even be in release 19.

This means that the Kotlin coroutines got a head start to cement their position in the market and become the de facto standard in this area as well. Whoever wanted lightweight tracks had already chosen Kotlin.

There is another negative factor for Loom: it has no plans to introduce structural competitiveness in the first phase. That is, the battle for Android is not in the plans of the Java language builders.

The second factor that prevents Loom-based distributed systems from being built is the lack of reactive libraries at the start that support the concept of back-pressure.

Briefly about reactivity. While in the classical server-side interaction model the client regulates the rate at which it sends data, in the reactive model the role of the regulator is played by the server. The consumer works the same way we drink tea: sip from the cup as much as we can swallow. In a classical interaction model, the server can choke.

Examples of reactive interaction implementations include Project React and Kotlin Coroutines. The Spring framework uses them interchangeably. It will take some time to create a similar library for Loom. And that will further delay the introduction of the new feature.

It would be appropriate to quote James Gosling, the creator of Java, saying outside the public part of the 2020 interview, "At first we were wary of C#, but when we realized that all it could do was copy Java, our fears dissipated." Well, C# has grown tremendously since its introduction. The number of its users is already comparable to Java's audience, and the salaries and satisfaction of using the language seem to be higher.

It has been ten years since C# was added async / await constructs, which open the door to writing sane asynchronous code. Except that by the number of artifacts of all sorts of open libraries (6 times) Microsoft's development is significantly inferior to Gosling's brainchild. And in a broader sense - the whole ecosystem, because libraries can be used from Closure, Scala, Kotlin and other JVM languages.

To summarise

The importance of backwards compatibility support for language development can't be overstated. That said, the impression is that the language developers are aiming for more. We see new semantics being added to the language in a backwards compatible way.

If we take a particular Apache Tomcat and build it using the Loom prototype without changing the source code, the web server shows unprecedented performance. It seems that backwards compatibility is already becoming a fetish. It slows down both the development of the language and the ecosystem as a whole. Java should not be slowed down so much.