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".
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.
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.
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.
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.
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.
When I think about Java concurrency today I tend to think of java.util.concurrent or the JMM. Perhaps that's odd.
As for compatibility: why is Java 8 market share so high in 2020?
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.
https://developer.android.com/studio/write/java8-support
All libraries that matter on the Java eco-system are already on Java 11.
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.
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
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.
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.
What are you talking about?
Android developers can use Maven Central like any other Java developers without care about what JDK these dependencies were compiled with nor even whether they were written in Kotlin (most did not, obviously).
> 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.
Again, what are you talking about? Android development happily upgrades to the latest version of Kotlin without any trouble. Porting Studio? What? Do you even understand anything about any of these matters?
My point is simply that Android development today has zero dependencies on Java but you seem to have a thick chip on your shoulder and determined to spew toxic bile at Java and its ecosystem, while feeling some vague hate at Google in general.
I have zero interest in this debate, have fun tilting at these windmills.
Stating otherwise just proves that you don't know Java.
Android Studio and the complete Android toolchain runs on top of a JVM implementation, as the JVM moves forward, JetBrains will be forced to update InteliJ to take advantage of newer JVM versions, which will force Google to update all their Android development environment.
Just for kicks they are already being forced to do this,
https://github.com/robolectric/robolectric/issues/5258#issue...
https://issuetracker.google.com/issues/139013660
Again, another proof of total lack of knowledge regarding Android
Toxic bille at Java?!?
Quite the contrary, I love Java since 1996 that is my third pillar alongside .NET and C++, what I completely hate is that Google played a Microsoft move with their flavor of Android Java (aka Google's J++), helped Sun going bankrupt withering them the revenue stream from Java deployments on Android, didn't bother to rescue Sun hoping that it would close doors without a hiss, now with its Android Java forces Java developers to create special versions of their libraries tailored to Android, and has a bunch of Silicon Valley fanboys supporting their damaging actions to the Java eco-system.
What were again your apps on Play Store?
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++.
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.
If you write the service stateless it's incredible what you can achieve with a couple small instances of a default spring boot container.
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.
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.
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.