I love Java, especially Java 8. But as the article points out, what frustrates me is threading. You can't do much without quickly running into threading issues. I played audio files in a game I made and it created up to 2,000 threads and crashed. Once I wrapped audio in an explicitly created thread this issue magically went away. Any kind of UI, timers, file I/O and network activity also involves threads.
The really horrible thing about these threads in Java is how hard it is to not share memory across them, because if you do terrible things happen. In other platforms you don't have to involve threads unless you want to, and you definitely aren't boxed into a situation where it becomes easy to accidentally share memory across theads.
I like Go's way of handling this. node.js is single threaded but the event loop makes it possible to do non-blocking IO without crazy Jave thread issues. Using synchronized, atomic properties and locks is not the right way to do these things as your code gets really complicated when trying to do basic things.
That gets me to my other pet peeve with Java. Just how much boiler plate there is to do basic things like opening up encrypted TLS TCP connections. Tons of cruft.
Anyway, having said that, I love Java and use it, but these things need addressing. I like Scala's Akka, I hope Java comes around and improves the horrible thread situation. I will have to check out Quasar. I know I just need to become more familiar with threading in Java in general. I'm actually pretty new to Java.
Sounds like it's the implementation of the audio library using thread in the wrong way. Has nothing to do with threading in Java. Nodes could have the problem of starving the audio playback if other parts of your code hogging too long of processing time. It's just shifting the problem around.
What's great about java is the number of libs out there for this. You don't have to use native java threads in this day and age with things like akka out there.
I find akka's java interface amazing to work with (yeah it's a bit odd in some parts)
You could also get used to thread pools and executors.
There is nothing wrong with Java Threads, it gives you low-level access which can be complicated and cumbersome but, when mastered, can be powerful. I believe that Akka uses Java Threads underneath the covers.
Using synchronized, atomic properties and locks is not the right way to do these things as your code gets really complicated when trying to do basic things.
One point being made in the op is that you don't have to. Of course, you may be constrained by how the libraries you want to use are structured, but I don't think this is necessarily the case. What if you used the op author's actor framework?
> basic things like opening up encrypted TLS TCP connections
IIRC that's sort of a special-case: It's painful because the designers wanted to weave-in policies and integration with sys-admin stuff on the host OS. There's an impedance mismatch between how Enterprise IT wants to handle that versus what a lone-developer would like to create.
There's plenty of stuff like this, though, in the JDK and in third-party libraries. Think about how much effort it takes to read the contents of a file into a string!
I don't think this is a fatal flaw, just a reflection of the attitudes and priorities the founders of Java. Concision for small tasks just wasn't seen as important. I don't think it was until the generation of scripting languages like Python and Ruby (and that other one, the moustache guy's one) came along that benefits of having a comfortable raft of easy ways to do small things became clear.
Java is far and away my favourite language, but even i'm embarrassed that it took until Java 7 to get a standard way to compare two possibly null variables for equality.
Go makes it even harder not to share mutable memory, as it has no 'final'. But if you read the whole article you'll see that Java now has lightweight threads with cheap blocking - just like Go or Erlang.
The really horrible thing about these threads in Java is how hard it is to not share memory across them, because if you do terrible things happen. In other platforms you don't have to involve threads unless you want to, and you definitely aren't boxed into a situation where it becomes easy to accidentally share memory across theads.
I like Go's way of handling this. node.js is single threaded but the event loop makes it possible to do non-blocking IO without crazy Jave thread issues. Using synchronized, atomic properties and locks is not the right way to do these things as your code gets really complicated when trying to do basic things.
That gets me to my other pet peeve with Java. Just how much boiler plate there is to do basic things like opening up encrypted TLS TCP connections. Tons of cruft.
Anyway, having said that, I love Java and use it, but these things need addressing. I like Scala's Akka, I hope Java comes around and improves the horrible thread situation. I will have to check out Quasar. I know I just need to become more familiar with threading in Java in general. I'm actually pretty new to Java.