It was designed when UML and tools like Rational Rose was being pushed hard by the big consulting firms on their clients as the One True Way to build Serious Business Software. JavaBeans was designed as a way to have a conventional interface that allows code components to be snapped into GUI applications. But someone thought it would be a great idea to use it everywhere else, too.

Can we all agree that the bean spec was not a good idea? No matter how old, or what other stupid ideas were fashionable back then. I cannot see how making things "beans" actually solves anything (besides maybe a slight reduction in boilerplate when (de)serializing bean-classes).

Java now has sum types (sealed types) with exhaustiveness checking, pattern matching for records, and more general destructuring in the works for classes.

Java has been around for a longish time. Around the early 2000's there was at least a perception that you should avoid creating too many objects as that carried performance overhead for construction and garbage collection.

https://softwareengineering.stackexchange.com/questions/1495...

Immutable objects often require you to construct a new object to store an updated value and garbage collect the now unused previous object. So a lot of early Java code was written with mutable objects to avoid performance issues.

The Java Bean spec was written in 1997:

https://blog.joda.org/2014/11/the-javabeans-specification.ht...

I didn't say make everything immutable. I just mean that if you want an object to be mutable, you need to say so.

Bean spec is in no way mandatory. Plenty of existing code doesn't follow the bean spec. Immutable Java classes have been in vogue for many, many years.