4 ms·
Ok, but now you're speaking about a different thing - memory safety. And that is an obvious advantage of Java over C. But C is a very low bar to compare to. The
by pkolaczk 4y ago
Ok, but now you're speaking about a different thing - memory safety. And that is an obvious advantage of Java over C. But C is a very low bar to compare to. There are dozens of other languages which are memory safe and some of them offer stronger guarantees than Java.
Your Java program may continue along silently, with corrupted application state, because it invoked a race condition, and you might never learn of the problem.
- kaba0 4y agoBut even race conditions are well-defined in Java: you can’t get so called out-of-thin-air values. Some updates may not be visible from another thread, and of course dead/live locks are on the table (but they are everywhere, even the actor model doesn’t solve those).
- pkolaczk 4y ago> you can’t get so called out-of-thin-air values You can't get out-of-thin-air primitive values (no word tearing). But you can still observe states that cannot be explained by any possible sequential interleaving of your program. E.g. your program can do: a = 0; b = 0; a = 1; b = 1; and another thread that does: print(b) print(a) may observe 4 different combinations of values, surprisingly including also this one: { a = 0, b = 1 } Why a corruption at a structure level should be considered less serious than tearing at a word level?
- mcculley 4y agoThe possibility of these very rare events does not change my mind about best practice for many kinds of deployed applications. I have production apps running right now using this pattern. The users would not be served better by stopping the whole app. We do capture the logs and fix the bugs encountered.