This is correct. JavaBeans were a bad solution to a problem. It was Swing (or was it AWT then?) that needed it first, so that tool builders could allow widgets to have their properties customised. So the vile JavaBean conventions took hold.

I only quibble on the "mindlessly" part. I will never add a get/set in a class if it isn't needed. But invariably, in a Java project, some library somewhere insists that I have them. So eventually I find I've reluctantly added them.

Sometimes you can get away with leaving them private, sometimes not. It's a pain in the neck and like many things in Java, it should have been sorted out years ago.

> I only quibble on the "mindlessly" part.

I'll grant that you're mindful ;-)

You overestimate my abilities! I mindfully create a horribly coupled mass of Spaghetti. But it's not anaemic spaghetti ;-)

Appreciate you posting the actual history.

One thing I've noticed more and more over the years is this tendency for folks to do things that under analysis make no sense and have no benefit.

Even worse, I have a bad feeling that 20 years ago I was one of those people...

You this a lot with C and C with Classes devs, micro-optimizing every single line of code as they write them, based on urban myths or past legends without touching a profiler a single time.

I won't disagee with the mindlessly or the JavaBean origins part, but reflection was present in Java from very early days from what I recall.

It definitely is the case that reflection in the JDK would be a very slow and ungainly way to do data access so I can see the 'bean' convention being a way around that.