[masklinn]

Hard disagree. The java concurrency story was absolutely awful when it came out. It had terrible ideas which panned out as well as checked exceptions did, and got forgotten when the collections were reworked. The only things it had going for it were showing concern and a well defined memory model, but that was broken until JSR 133.

Java concurrency got a lot better with JSR 166, by accreting new APIs. But those require awareness of their existence and purpose, the langage baseline is no better.

Project loom does not fundamentally change any of that. It’s goal is to increase efficiency, aka get more wrong answers faster.

[EdwardDiego]

What do you mean by "get more wrong answers faster"? Given that volatile / synchronized have largely gone the way of the dodo, ditto Object.wait etc. , and that concurrency safe atomics and collections are de rigeur, how do green threads reverse that? (I understand your point that you need to use the good stuff to take advantage of it, and that the old bad stuff is still in the base language, but I feel that's true for pretty much every language that's 30ish years old.)

I spent years working on concurrent Java apps post JSR 166, and the only concurrency issues I met were PEBKAC, and some of the awful things people did with Vert.x and it's event bus.

[dtech]

Do you have a good resource or summary on why volatile / synchronized are problematic and java.util.concurrent should be preferred?

I always remembered the same, but was recently in a conversation with Java devs who contradicted it, and could not articulate well why this is the case. and could not find good resources on it.

[EdwardDiego]

Not off the top of my head. Just experience that they're easily used wrong.