There's a difference between something being possible vs supported. In C/C++ you can have a type, and a const version of that type. In Java you can't define a c

There's a difference between something being possible vs supported. In C/C++ you can have a type, and a const version of that type. In Java you can't define a class and automatically be able make a reference to a const object of that class. You can make a final reference, but that only means you're always referencing the same (mutable) object. You could you use final fields for the entire object, but then you have to make another type for the mutable kind, or builders to go from one to an other. Another example is Unmodifiable collections, which are only views on modifiable ones, so you can't be sure it's not modified. A language that supported immutability would come with some of these batteries included. There are places to use encapsulation with mutability, such as simulations, but having hidden mutable states is not desirable property when constructing rapidly changing applications. I do my best to keep things sane when working with a Java or Ruby or what have you codebase, but I don't pretend it's something it's not. Just do the best that the codebase and organization can tolerate.