Without mutable objects you have no state. Admittedly, this is a good thing if you can manage it and if there is any chance an object might be referenced from more than one thread. But the program is going to be rather boring. A lot of software, particularly web servers, avoids taking responsibility for mutable objects by pushing mutability off on databases, operating systems, system libraries, etc. As a practical matter, this does free the programmer from mutability problems and makes web (and other) development affordable. But the mutability is still there.

In general, you have three types of classes: normal, non-thread-safe classes, that have to be carefully guarded and protected; immutable classes, which can be used freely; and mutable, thread-safe classes that can be used freely but which must be written with extreme care. The first type is the troublesome one, with the worst ones being those that are thought to be of the third type. Of course, the first type are the easy ones to write.

I usually end up with lots of normal, mutable classes that I have to watch very carefully. In a multi-thread situation, the synchronization necessary slows everything down even when I can avoid a deadly embrace. So I'm ususally making immutable copies of the mutable class and handing those off to whoever can use it. A new immutable copy is needed every time the orignal mutates, so I imagine at times I may have a hundred copies of the original out there. I'm utterly dependent on Garbage Collection.

In summary, non-thread-safe, mutable objects are fine if you are not using multiple threads. (But multithreading is inflitrating everywhere--be careful!) They can be used safely otherwise if you restrict them to local variables or rigorously synchronize them. If you can avoid them by using other people's proven code (DBs, system calls, etc.) do so. If you can use an immutable class, do so. And I think, in general, people are either unaware of multithreading problems or are (sensibly) terrified of them and using all kinds of tricks to avoid multithreading (or rather, pushing responsibility for it elsewhere).

As a P.S., I sense that Java getters and setters are getting out of hand. Check this out.

Without mutable objects you have no state. Admittedly, this is a good thing if you can manage it and if there is any chance an object might be referenced from more than one thread. But the program is going to be rather boring. A lot of software, particularly web servers, avoids taking responsibility for mutable objects by pushing mutability off on databases, operating systems, system libraries, etc. As a practical matter, this does free the programmer from mutability problems and makes web (and other) development affordable. But the mutability is still there.

In general, you have three types of classes: normal, non-thread-safe classes, that have to be carefully guarded and protected; immutable classes, which can be used freely; and mutable, thread-safe classes that can be used freely but which must be written with extreme care. The first type is the troublesome one, with the worst ones being those that are thought to be of the third type. Of course, the first type are the easy ones to write.

I usually end up with lots of normal, mutable classes that I have to watch very carefully. In a multi-thread situation, the synchronization necessary slows everything down even when I can avoid a deadly embrace. So I'm ususally making immutable copies of the mutable class and handing those off to whoever can use it. A new immutable copy is needed every time the orignal mutates, so I imagine at times I may have a hundred copies of the original out there. I'm utterly dependent on Garbage Collection.

In summary, non-thread-safe, mutable objects are fine if you are not using multiple threads. (But multithreading is inflitrating everywhere--be careful!) They can be used safely otherwise if you restrict them to local variables or rigorously synchronize them. If you can avoid them by using other people's proven code (DBs, system calls, etc.) do so. If you can use an immutable class, do so. And I think, in general, people are either unaware of multithreading problems or are (sensibly) terrified of them and using all kinds of tricks to avoid multithreading (or rather, pushing responsibility for it elsewhere).

As a P.S., I sense that Java getters and setters are getting out of hand. Check this out.