4 ms·

> But not integrity of the program itself. You can still have data loss and garbage results. curious what do you mean here? Java has many utils for concurrent

• dwattttt 3y ago
  The distinction they might be going for is the difference between guarantees and helpful utilities; good utilities can provide guarantees, but there's a lot to be said for default-safe and a safety culture
• pornel 3y ago
  Java only promises to protect integrity of JVM itself, not your data. If you accidentally write to a non-concurrent collection from multiple threads, it's not a program-corrupting Undefined Behavior like in C/C++/golang, but it can still misbehave by corrupting the collection itself, causing it to mangle or lose data, or in the best case throw an exception. Either way you don't get the intended program behavior, and you may be unaware of using a wrong collection type until you create an invalid access at compile time. This is different from Rust, where thread-safety is part of the type system, so multi-threaded code that could write to a shared HashMap instead of a ConcurrentHashMap just won't compile with a type error.
  • nradov 3y ago
    This is quite trivial to avoid in Java. There are even static analysis tools which automatically detect most such defects.
• munksbeer 3y ago
  > curious what do you mean here? Java has many utils for concurrent programming Those are necessary but not sufficient to protect your program from data races or other multi-threaded issues. It is very easy to get them incorrect.