4 ms·

The pattern evolved from early Java’s lack of reflection. In order to give tools the ability to set/get data, we got the JavaBean. The culture internalized the

by jt2190 9y ago

The pattern evolved from early Java’s lack of reflection. In order to give tools the ability to set/get data, we got the JavaBean. The culture internalized the pattern, and we’ve been mindlessly doing it ever since.

dboreham 9y ago
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...
- pjmlp 9y ago
  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.
cultvoid 9y ago
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.
- jt2190 9y ago
  > I only quibble on the "mindlessly" part. I'll grant that you're mindful ;-)
  - cultvoid 9y ago
    You overestimate my abilities! I mindfully create a horribly coupled mass of Spaghetti. But it's not anaemic spaghetti ;-)
cmrdporcupine 9y ago
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.

by jt2190 9y ago

dboreham 9y ago

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...

pjmlp 9y ago
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.

cultvoid 9y ago

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.

jt2190 9y ago
> I only quibble on the "mindlessly" part. I'll grant that you're mindful ;-)
- cultvoid 9y ago
  You overestimate my abilities! I mindfully create a horribly coupled mass of Spaghetti. But it's not anaemic spaghetti ;-)

cmrdporcupine 9y ago

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.