4 ms·

The main problem with Java is its concurrency model, which gives incentive to the creation of threads that fight for resources and introduce bugs. This seemed a

The main problem with Java is its concurrency model, which gives incentive to the creation of threads that fight for resources and introduce bugs. This seemed a wise choice in the 90s, but as concurrency has increased several-fold in the last 25 years, the model cannot scale to real software needs. It is the Java equivalent to pointers in C.

kasperni 6y ago
> the model cannot scale to real software needs. And somehow it is still widely used within Google, Facebook, Amazon, Twitter...
- conjectures 6y ago
  This isn't actually a rebuttal of the point.
- coliveira 6y ago
  C/C++ are also used at Google, FB, Amazon, etc. It doesn't mean that it's not a problem.
  - tomc1985 6y ago
    I'd bet you're alienating well over half the entire field of software engineering with calling Java, C, and C++ "problems".
    - coliveira 6y ago
      You're misinterpreting what I said. I talked about the "main problem with Java", and with C/C++. Saying that a tool has a problem doesn't mean it is useless, far from it.
- brown9-2 6y ago
  Most of those companies are not writing one-thread-per-request servers, they write non-blocking / async IO Java.
  - Matthias247 6y ago
    Some will do for sure - but it might not even be "most". There is a suprising amount of thread-per-request code out there. And actually it's doing fairly well - even at the scale of the companies you listed if you are using it in the right place. Right place here means don't use it for a frontend proxy which needs to manage 100k keepalive connections. But for a service which needs to handle 500 concurrent requests at maximum and doesn't have to deal with TLS anymore it will be fine. And there's enough of those services out there. A lot of the Java code in bigger companies is also written based on older frameworks like earlier versions of Servlet and J2EE. Those programs will also not make any use of async mechnanisms and prefer a simple programming model instead.
apta 6y ago
What alternative model would you suggest? Green threads still introduce bugs (race conditions), and fight over resources (DB connections, filesystem, etc.)
plmpsu 6y ago
Can't wait for project Loom: https://openjdk.java.net/projects/loom https://openjdk.java.net/projects/loom
spullara 6y ago
Amusingly, Loom, which will likely appear in the Java 17 time-frame will allow you to use all that blocking code and it automatically transforms it into non-blocking code. Going to make coding high-concurrency applications a lot easier. Check out the few lines of code needed to convert Jetty from blocking to non-blocking: https://github.com/rodrigovedovato/jetty-loom/blob/master/src/main/java/io/github/rodrigovedovato/letty/infrastructure/LoomThreadPool.java https://github.com/rodrigovedovato/jetty-loom/blob/master/sr...
- hilbertseries 6y ago
  I'm very skeptical of this conversion into loom. Jetty bounds the number of concurrent requests it serves based on the size of its thread pool (of course Jetty also uses a few of the threads to run its acceptors and selectors). The implementation provided here, replaces Jetty's fixed sized thread pool with an unbounded thread pool. This is going to lead to some terrible failure states when the service slows down.
  - kasperni 6y ago
    The computational resources of a machine is finite no matter what language you use. You got to put limits somewhere.
neeleshs 6y ago
Akka streams and actor model make it better
Reelin 6y ago
This is just silly. What concurrency model doesn't "fight for resources and introduce bugs"? Threads (and pointers, which you compared them to) are the abstraction at the hardware level - everything else has to be built on top of them in one way or another. Just because you have access to threads (or pointers) doesn't mean you have to make poor architectural decisions. I'd like to draw your attention to Doom Eternal which takes the thread pool model through to its logical conclusion. (https://twitter.com/axelgneiting/status/1241487918046347264 https://twitter.com/axelgneiting/status/1241487918046347264) I hope you'll agree that's an example of meeting the needs of real software. (I'm sure it's not the first or only example of that approach, it was just on my mind because it came up recently.)
jjav 6y ago
> the model cannot scale to real software needs Most of the highest performance server code across many industries in written in Java. So... I wonder what do you consider could possibly compete with Java in this space?

kasperni 6y ago

> the model cannot scale to real software needs. And somehow it is still widely used within Google, Facebook, Amazon, Twitter...

conjectures 6y ago
This isn't actually a rebuttal of the point.
coliveira 6y ago
C/C++ are also used at Google, FB, Amazon, etc. It doesn't mean that it's not a problem.
- tomc1985 6y ago
  I'd bet you're alienating well over half the entire field of software engineering with calling Java, C, and C++ "problems".
  - coliveira 6y ago
    You're misinterpreting what I said. I talked about the "main problem with Java", and with C/C++. Saying that a tool has a problem doesn't mean it is useless, far from it.
brown9-2 6y ago
Most of those companies are not writing one-thread-per-request servers, they write non-blocking / async IO Java.
- Matthias247 6y ago
  Some will do for sure - but it might not even be "most". There is a suprising amount of thread-per-request code out there. And actually it's doing fairly well - even at the scale of the companies you listed if you are using it in the right place. Right place here means don't use it for a frontend proxy which needs to manage 100k keepalive connections. But for a service which needs to handle 500 concurrent requests at maximum and doesn't have to deal with TLS anymore it will be fine. And there's enough of those services out there. A lot of the Java code in bigger companies is also written based on older frameworks like earlier versions of Servlet and J2EE. Those programs will also not make any use of async mechnanisms and prefer a simple programming model instead.

apta 6y ago

What alternative model would you suggest? Green threads still introduce bugs (race conditions), and fight over resources (DB connections, filesystem, etc.)

plmpsu 6y ago

Can't wait for project Loom: https://openjdk.java.net/projects/loom https://openjdk.java.net/projects/loom

spullara 6y ago

Amusingly, Loom, which will likely appear in the Java 17 time-frame will allow you to use all that blocking code and it automatically transforms it into non-blocking code. Going to make coding high-concurrency applications a lot easier. Check out the few lines of code needed to convert Jetty from blocking to non-blocking: https://github.com/rodrigovedovato/jetty-loom/blob/master/src/main/java/io/github/rodrigovedovato/letty/infrastructure/LoomThreadPool.java https://github.com/rodrigovedovato/jetty-loom/blob/master/sr...

hilbertseries 6y ago
I'm very skeptical of this conversion into loom. Jetty bounds the number of concurrent requests it serves based on the size of its thread pool (of course Jetty also uses a few of the threads to run its acceptors and selectors). The implementation provided here, replaces Jetty's fixed sized thread pool with an unbounded thread pool. This is going to lead to some terrible failure states when the service slows down.
- kasperni 6y ago
  The computational resources of a machine is finite no matter what language you use. You got to put limits somewhere.

neeleshs 6y ago

Akka streams and actor model make it better

Reelin 6y ago

This is just silly. What concurrency model doesn't "fight for resources and introduce bugs"? Threads (and pointers, which you compared them to) are the abstraction at the hardware level - everything else has to be built on top of them in one way or another. Just because you have access to threads (or pointers) doesn't mean you have to make poor architectural decisions. I'd like to draw your attention to Doom Eternal which takes the thread pool model through to its logical conclusion. (https://twitter.com/axelgneiting/status/1241487918046347264 https://twitter.com/axelgneiting/status/1241487918046347264) I hope you'll agree that's an example of meeting the needs of real software. (I'm sure it's not the first or only example of that approach, it was just on my mind because it came up recently.)

jjav 6y ago

> the model cannot scale to real software needs Most of the highest performance server code across many industries in written in Java. So... I wonder what do you consider could possibly compete with Java in this space?