Java Locks and Atomicity

It's important not to confuse people by using words that are imprecise or ambiguous. This annoys many experts because this world is confusing enough. I will point my fingers to the "misuse" of the word atomic. I have to be careful here because I had the idea for this post when I was reading the bible of concurrency: Java Concurrency in Practice. However, in this book, just for instance, the word atomic is used in a way, which can confuse people that spent five years of their career building transactional database systems. In short:

In Java, only single, discrete language operations are ever going to be atomic. There is no such concept in Java that inherently creates atomicity.

Assigning a value to a variable is an atomic operation in Java. Calling a method (the call itself) or creating an object may be atomic, but the atomic data types like AtomicInteger  provide atomic actions. There are more examples. However, if one tries to explain the notion of Java locks by giving the impression they make compound language operations atomic, then this is not 100 percent correct. Locks can make sure that the sequence of language operations are going to be performed in isolation to other concurrent threads working with that same resource. That's exactly what locks like  ReentrantLock and ReentrantReadWriteLock add to the language features.