[mrjoelkemp]

In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations). If concurrency isn't an issue, then the massive amount of libraries can help you a lot.

In high-traffic environments, that ignorance punishes you. I've always felt Java and the JVM are of the mindset that you need a Ph.D. to even understand how it works or how to configure it, and if you can't get it, then you're just a bad programmer.

You need to know if you're blocking threads, if there's memory contention, and if libraries you pull in are using the forkjoin common pool (which you're likely using as a default threadpool). And when something blows up, finding the reason (even for any of the above issues) is really tough. You can use flight recorder, heap dumps and gc logs all day, but good luck navigating it all unless you're a genius. I've seen too many devs end up shrugging and hoping the issues are transient.

Even figuring out proper threadpool usage isn't straightforward. Look at the number of concurrency abstractions just to model concurrency in your system: https://www.youtube.com/watch?v=yhguOt863nw. It's ridiculous.

Lots of large tech companies "seem" to "make it work." But if my experience is at all similar, they're just relying on a handful of Ph.D.'s to hold the hands of the rest of the company when it comes to troubleshooting.

Part of the reason I fell in love with Elixir/Erlang and the BEAM is that it provides a simple (actor) concurrency model (with a single concurrency primitive, a process) and guardrails (time-slice scheduling) to prevent libraries from shooting you in the foot. OTP's observer makes finding bottlenecks a breeze.

For the web, taming concurrency feels way more important than any cpu-crunching perf gains the JVM can give you. I'm too stupid for the JVM; I'll stick to tools that take away numerous categories of complexity and get me closer to mastering my system.

[coldtea]

>In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations)

Huh? Java is used in huge traffic backends, including HFT with minimal latencies acceptable all the way to Google and Twitter scale.

If anything, Java is much more fast and low level than the typical languages used for huge high-traffic services -- Rails, Python, etc - never mind about what's used in "low-traffic situations".

[lostcolony]

OP isn't comparing it to Rails, Python, etc. He's comparing it to Erlang.

ANd, to that, I'd agree. I've built high traffic stuff in Java. We built it, load tested it, it was terrible. After multiple rounds of profiling, tweaking GC settings, tweaking threadpool sizes, rewriting things to be async, finding out that a client library wasn't reusing connections properly, etc, we finally had acceptable performance...that still was less than I'd gotten out of the box in similar, IO bound services, written as unoptimized Erlang.

[jacques_chester]

> You need to know if you're blocking threads, if there's memory contention, and if libraries you pull in are using the forkjoin common pool (which you're likely using as a default threadpool). And when something blows up, finding the reason (even for any of the above issues) is really tough. You can use flight recorder, heap dumps and gc logs all day, but good luck navigating it all unless you're a genius.

I've seen the same troubles with alternatives, just without the amazing tools, featuresome standard library or widely-accepted conventions.

Erlang is amazing and is places concurrency in a more central position. I'm hopeful Project Loom will greatly diminish the gap while carrying legacy code forward unchanged.

[The_rationalist]

There's tooling such as Blockhound

[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 :/

[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.

[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++.

[deepakarora3]

There are a lot of points which I simply cannot agree with. 1) concurrency as an issue - you make it sound as if doing concurrent programming in Java is hard. Its not if you read through the documentation. In todays world of spinning up small servers, when done right, it scales to massive levels. 2) Blocking threads, memory contention etc. - i think you may be comparing against the likes of single thread programming models like Vert.x or Node.js etc. The flip side which in my opinion is more severe is that if you get even a small thing wrong on the other side, it blows up even more which is more difficult to isolate and debug. Plus the need to learn a whole new programming paradigm which is not easy to wrap your head around. 3) Lot of tech companies seem to make it work - while I agree that corporates will pretty much make everything seem to work, it requires a few engineers who understand software design principles to create design and abstractions that work well. You imply that only PhDs understand that kind of stuff whereas I am sayin that there are many other who understand and who are genuinely making things work in the Java world. I can tell you, when concurrency done right in Java, it is so performance that many will simply not believe. Just my thoughts and happy to differ.

[dnautics]

Just try playing around with the other vm for a bit. It's just crazy easy.

[miskin]

I believe there are few runtimes out there that have such a good monitoring and profiling tools for free and out of the box as Java. Java Flight Recorder, remote debugging and monitoring can be really useful for rare production performance issues.

[lostcolony]

It's funny you should mention that in response to a post talking about Erlang. :P Because, yes, there are few. The BEAM happens to be one that definitely beats the JVM on that front.

[The_rationalist]

In which précise aspect does it outperform jvm tooling?

[lostcolony]

So monitoring and profiling are pretty similar in what sort of things they tell you, but the meaningfulness tends to feel higher due to the programming model. Here's a fairly recent blog post giving an example from someone trying the BEAM for the first time, coming from the JVM - https://medium.com/@mrjoelkemp/jvm-struggles-and-the-beam-4d...

But when it comes to remote debugging, and more specifically, a general "I want to understand what is happening in production", the ability to attach a REPL, alongside your tools, is amazing. I can insert a breakpoint, sure (if I for some reason built my production instance with debug info), but just as easily (without any debug info compiled in!), and more usefully, I can query actor state, mailboxes, etc, fire a message to a process to see what happens, etc...all the things you'd get with a REPL running locally in your dev environment, basically. Do stuff like query for internal state for a process, then call a function with it to see what happens to the data, all in isolation from the normal execution flow (since immutable data gives you a degree of safety to actually run that live code, with copies of the live data, and see what happens). I can even remotely load new code, if I want, effectively allowing me to deploy a hotfix without taking the node down. And I can do all of this in prod. All of this is, of course, super dangerous, but with great power etc etc.

[matsemann]

I hardly know anything about those things, and write java backends powering one of the most used services in my country. So I disagree with it being that complicated.

If you write the service stateless it's incredible what you can achieve with a couple small instances of a default spring boot container.

[kbrisso]

I work on a lot of legacy systems in financial services, the biggest issues related to threads is variable scope regarding servlet design patterns. I just migrated a 18 year old app off Weblogic to TomEE and we had issues with struts tags. The main app I work on has around 350 concurrent users. I have JMX on all the time and monitor it for long running threads and tune it when needed. The problem I have with Java is the massive amount of libraries that can be used and developers who copy and paste code and don't think about what the code does. The verbosity kills me too, it's so over done. I've decided to learn Go just because I'm tired of reading Java code, especially legacy code. But yes you are correct there is a lot of settings in the JVM and a lot to read to understand it. It's a powerful language with a lot of features.

[The_rationalist]

Regarding the verbosity you would be better off with Kotlin

[apta]

> If concurrency isn't an issue, then the massive amount of libraries can help you a lot.

Can you point to another language that has anything remotely comparable to `java.util.concurrent`? Also, Java is getting green threads by means of Project Loom.

[jjav]

> In my opinion, Java as a web language is good when you don't need to really understand what's happening (like in low-traffic situations). If concurrency isn't an issue, then the massive amount of libraries can help you a lot.

Not sure how to interpret this comment.. If high concurrency and high performance matter, that is precisely where Java shines. The only other reasonable option would be C++ but it brings so much pain with it that Java is the way to go.

If traffic is low and performance doesn't matter (which is most sites), then sure, use whatever favorite scripting language.