[MaxBarraclough]

In defence of Java, I read somewhere it's 25 years old ;-)

Part of the reason for its success has been its strong commitment to backward compatibility, so it's to be expected that it might accumulate many ways of doing things. Python wisdom tells us this is often a Bad Thing. [0]

I imagine Java's approach to concurrency and parallelism might be quite different if it were designed today.

[0] https://wiki.python.org/moin/TOOWTDI

[thu2111]

I imagine Java's approach to concurrency and parallelism might be quite different if it were designed today.

Probably not, actually. Project Loom's initial goal was to rethink concurrency on the JVM from scratch. What they came up with was:

* Make threads really, really cheap

* Make thread locals work better (as scoped locals)

* Add a few Executor utilities to help you control sub-tasks better (structured concurrency)

It turns out that Java concurrency is pretty damn good already. It provides all the different paradigms you might want to explore, is efficient and well specified. Meanwhile they realised that many of the alternative approaches to concurrency are in reality trying to work around the high cost of kernel threads. When you make threads really cheap, a lot of the motivation for other approaches falls away and the existing set of tools in the JDK come to the fore.

[smarks]

Your characterization of Loom is, I think, pretty accurate.

There are, however, a few things in Java's early concurrency support that make various things harder, including Loom, and we're having to put some extra effort into grappling with them.

Probably the most obvious is the fact that the language and VM requires every object to have a monitor lock that can be synchronized and waited/notified. In 1996 this was viewed as "Ooooh, sophisticated, building locking and concurrency support into the platform!" In recent years this has started to get in the way. Really only a very few objects are used as locks, but the _potential_ for every object to be locked is paid by the JVM.

It also intrudes on Project Valhalla, which is trying to define "identity-less" inline types (formerly, "value types"). Ideally, we'd want all conventional objects and inline objects to be descendants of java.lang.Object. But Object has the locking APIs defined on it, and locking is intertwined with object identity. So, does Object have identity or not? There are some solutions, but they're kind of weird and special-cased.

Another issue is that the locks defined by the language/VM ("synchronized") are implemented differently from locks implemented by the library (in java.util.concurrent.locks). Loom supports virtual threads taking library-based locks, in that when a virtual thread blocks on a lock it will be dismounted from the real thread. This can't be done with language/VM locks, so there's an effort underway to migrate the those locks to delegate to library code for their implementation. This isn't an insurmountable problem, but it's yet more work to be done, and it's a consequence of some of the original designs of Java 1.0's concurrency model.

[thu2111]

That's true but if Java had been designed with a "synchronizable" keyword applied to classes, I wouldn't consider that a radically different language. The prevalence of unnecessarily lockable things is unfortunate from a JVM implementors perspective, slightly convenient from a user's perspective, but ultimately not a defining feature of the language or platform even if it may have seemed important in 1995.

When I think about Java concurrency today I tend to think of java.util.concurrent or the JMM. Perhaps that's odd.

[bandris]

Actually BEAM and Erlang pre-dates Java. ;-)

As for compatibility: why is Java 8 market share so high in 2020?

[pjmlp]

Shitty Android.

[cesarb]

Isn't Android mostly based on Java 7 (for instance, the Guava artifact you need for Android is the Java 7 one)? It can't be the reason why Java 8 is popular.

I believe that the reason why Java 8 is so popular is because there were a lot of backward compatibility problems with Java 9, compounded by the fact that Java 11 (the next LTS after Java 8; both Java 9 and Java 10 had very a very short life) removed many APIs deprecated by Java 9.

[pjmlp]

Nope, Java 8 nowadays.

https://developer.android.com/studio/write/java8-support

All libraries that matter on the Java eco-system are already on Java 11.

[saagarjha]

Android's Java is like half of Java 8 :/

[pjmlp]

Yeah, Android Java has turned into Google's own version of J++.

Worse is that Kotlin fanboys don't get it, that without access to modern Java their Java FFI is worthless, as all Java 8+ libraries on Maven Central will slowly become useless on Android no matter what.

Additionally the language cannot expose JVM capabilities, unless they had even another backend.

So it will be stuff like value types, JNI replacement, proper generics, customized JIT and SIMD on the JVM, and plain old Java 8 on ART.

[hota_mazi]

Android moved past the Java restriction ten years ago.

First by adding their own features to the JDK, and today simply by making Kotlin the main language to program in on Android.

Android is completely unshackled from Java today. Android is compeltely

[pjmlp]

On the contrary, without access to Maven Central ecosystem of Java libraries, it quickly loses interest as development platform.

[hota_mazi]

What does Maven Central have to do with the development of Java by Oracle?

That is precisely my point.

Android has completely unshackled itself from Java development. Between its reliance on Open JDK and Kotlin, it literally has zero dependencies on Java.

[pjmlp]

25 years of libraries to choose from slowly not available on Android.

If the Android team plans to rewrite all of them in Kotlin, be my guest.

Maybe they will manage before Fuchsia goes live and Flutter wipes the floor, and then everyone will be doing Dart anyway.

Have you noticed how shitty are all the languages designed at Google?

Thankfully someone that was there since Java 1.0 days bought its rights.

GraalVM would have been killed at birth.

I am also looking forward to the complete Android development environment to be running on top of Kotlin/Native, otherwise it will be so funny having to port Studio and everything else that depends on the JVM to modern versions, while Android itself is frozen into a Kotlin ecosystem + Java 8 subset.

[binaryjay]

More like shitty Java. I'm glad Java is being relegated to a second class language that is not recommended for Android development. Kotlin is the now the recommended language for Android development. I give Google 2-3 years before they deprecate Java from Android.

[MaxBarraclough]

> BEAM and Erlang pre-dates Java

That's not really fair. The point of the Erlang language was its novel and opinionated approach to concurrency. Java wasn't trying to be like Erlang, it was trying to lure programmers by having significant similarities to C/C++.