Beans Considered Harmful

JeffBay thinks Java Beans suck. He has eventually explained why in this forum. Read on!

Everybody knows what a bean is, but why does everybody put up with code like this:

  private String foo;
  public void setFoo(Object foo) { this.foo = foo; }
  public Object getFoo() { return foo; }

  private String bar;
  public void setBar(Object bar) { this.bar = bar; }
  public Object getBar() { return bar; }

or this:

  private String bar;
  private String foo;

  public Object getBar() { return bar; }
  public Object getFoo() { return foo; }

  public void setBar(Object bar) { this.bar = bar; }
  public void setFoo(Object foo) { this.foo = foo; }

Either way, when you have bar, foo, baz, biff, blag, blarg, and bloog, it seems a bit ugly to me. How about:

public class something implements FOO

  private Map fields;
  public Object get(Name name) { return fields.get(name); }
  public void set(Name name, Object value) { fields.put(name, value); }

(JSTL will accept this as a valid bean. Not that JSTL is the language of the future, but at least this is useful)

  public List names() { 
    Object[] names = { FOO.bar, FOO.foo, FOO.baz, FOO.biff, FOO.blag, FOO.blarg, FOO.bloog };
    return Arrays.asList(names);
  }

  public List names() { 
    Object[] names = { "bar", "foo", "baz", "biff", "blag", "blarg", "bloog" };
    return Arrays.asList(names);
  }

although I'd prefer that each of the strings was actually an object accessible by an interface as above, because then you have the same type safety you have with compilation of getFoo/setFoo methods, but the added ability to loop over columns without reflection. -- JeffBay

I agree with the above sentiment. Furthermore, I think the basic JavaBean component model is not dynamic enough. The component model best supports composition before compilation rather than at run time. Composing beans at runtime (e.g. by AutomatedAssembly) is awkward and excessively verbose.

If it's all that typing that annoys you, then, perhaps, you should check out the GroovyLanguage. Groovy has a bean generation syntax that makes it trivially easy to create beans without all of that typing. The ScalaLanguage makes it even easier. An entire bean (your first example plus class definition) can be done in one line. -- MarkCrocker

The goal is not to avoid typing, but violation of encapsulation and eschewing duplication. -- JeffBay

"Bean" is a stupid term. It's meaningless. It doesn't reveal any kind of intention. The more it is applied, the more meaningless it becomes. -- RandyStafford

"Bean" is a marketing term. Like all software marketing terms, it means "nothing novel from a technological viewpoint, but you can use it as inspiration for a memorable logo and thereby encourage a SnowballEffect that will help everyone who wants to sell beans." -- AnonymousDonor

It is interesting to note that while "Bean" was devoid of meaning, it has spawned an untold number of interesting metaphors, as JumpingBean?, BagOfJumpingBeans, BagOfBeans?, BeanCounter?, etc... -- JeffBay

What are we bemoaning here? The JavaBeans protocol? EnterpriseJavaBeans? The way people (over-)use one or the other of these? -- GeorgePaci

Hi George. I'm not sure what caused JeffBay to (apparently) start this page, but what I bemoan is the tendency to include "bean" in the name of something, as if doing so will make that something more meaningful or legitimate. Some of the most recent examples: MessageDriven?Bean, "form beans" in JakartaStruts, Bean Scripting Framework from Jakarta, NetBeans, etc. What meaning does "bean" contribute in the names of those things? RebeccaWirfsBrock writes in ObjectDesign that "We judge an object by how well its name fits its role, and how well its role fits its situation." Calling something a "bean" doesn't do very much to reveal intent, because it's not at all clear what the hell "bean" is supposed to mean in the first place. -- RandyStafford

I humbly disagree. What is a JavaBean is very clear, you can download the specification here http://java.sun.com/products/javabeans/docs/spec.html. Simply put, if you call some of your Java classes a bean, I expect it to contain attribute getter/setters and methods and useful events where applicable. IOW, I expect your bean can easily integrate with other beans. Now whether those beans you listed above actually provide one is another matter. -- OliverChung

But an EnterpriseJavaBean is not a JavaBean. So the term "bean" has become meaningless. EJBs are called "beans" for marketing, not technical, reasons.

I understand that it has been changed in the later EJB specs but I don't track EJB very closely thus do not know the details. However, keep in mind that EJB is an architecture more than a Java class, so saying a EJB is a JavaBean is like saying CORBA is COM object, which doesn't make much sense. My limited understanding is that in the later specs, the remote object (guaranteed to implement your EJB's remote interface) returned to the EJB client (from the EJB container) can (must?) be a JavaBean. -- OliverChung

An EJB is an object that implements one or more of the interfaces defined by the EJB framework. It does not have to be a Java Bean in the sense that is used by the java.beans package. Therefore, EJB misuses the term "bean" and renders it meaningless.

I understand that the original term "JavaBean" connoted a certain set of conventions and therefore had a reasonably precise definition (I was gung-ho enough to buy and read ISBN 1565922891 when it first came out :-)). So let's say that everything that has "bean" in its name these days actually does adhere to those conventions, which is not the case. My complaint is that including "bean" in the name still does not add much value. My humble observation is that just because an object adheres to a set of (trivial) conventions, that does not reveal anything about what that object is intended to model, and that does not guarantee ease of integration (semantic integration is not guaranteed by mechanical integration).

At least in the case of EJBs (if not also JavaBeans), I think what JavaSoft intended, for better or worse, is that an EJB be a "component". What if they had just used the word "component" instead? Then instead of being puzzled by the definition and application of "bean", we could instead argue over whether the things make reasonable "components" or not (I say "not"), according to definitions in the literature of the profession. -- RandyStafford

Why is the term "bean" any worse than "COM object", "ActiveX Control", "OCX" or any of the other half dozen or so different names Microsoft has given to the Windows programming components over time? -- StevenNewton

I would say that apart from "COM Object", "beans" is as bad a term. The term "COM Object" has a specific technical meaning. Microsoft's OLE/Ole/OCX/ActiveX/OLE Automation/ActiveX Scripting/etc./etc. MarkeTecture are just different names for the same thing and introduce nothing but confusion. An example: when ActiveX was being hyped I went to buy an introductory book on ActiveX programming published by Microsoft Press. Luckily I flicked through the book before buying it and noticed that all the code was using the Ole interfaces. ActiveX was just a new name for Ole and I already knew how to use it. The book was just a scam to extract another 40 pounds from existing Ole programmers.

I don't know who wrote the above paragraph, Steven, but I would tend to agree. With the possible exception of "COM Object", I think all of the terms you listed (including "bean") are equally bad examples of meaningless marketing terms that waste developers time trying to figure out what they mean. At least "COM Object" gives you some idea that the thing to which it applies is ostensibly an object that participates in Microsoft's "Component Object Model". In response to Falk, below, if a bean is supposed to be a "Java component", then I guess it's fair to ask WhatAreComponentsAnyway. But I have another question: what does "bean" mean? Suppose I want to use the word "bean" in the name of something. What responsibilities go along with that? Are there BeanityTests? for beans, like PatternityTests for patterns? -- RandyStafford

There is a specification for what makes a class a JavaBean, at http://java.sun.com/products/javabeans/. There are still a lot of things out there that have the word "bean" in their name that have nothing to do with the JavaBean specification.

The main component of coffee is coffee beans. Thus, I find the name "bean" for Java components both fitting and funny, and well in line with the name "Java" itself, or the fact that you can put beans in a JAR, or the magic number for class files. Still trying to figure out what "enterprise coffee" is supposed to be, though... -- FalkBruegmann

Actually, the main component of coffee is water :)

Maybe the way you make it! ;) ;)

But EJB programmers have to put beans in their EARs. What is the Java equivalent to a trip to the hospital and a nurse with a pair of tweezers?

To say nothing of servlet programmers. To misquote WinstonChurchill, "To JAR-JAR is always better than to WAR-WAR."

You may be the first person in history to profess an affinity for Jar Jar ;)

The main component of coffee is coffee beans. Thus, I find the name "bean" for Java components both fitting and funny

It's not such a good fit if components can be composed of other components. And to the extent that the abuse and overuse of "bean" engenders confusion and questionable design, I find that more unfortunate than funny. -- RandyStafford

He looks innocent enough to me:

http://www.imdb.com/title/tt0118689/

Coffee beans aren't really beans, they're actually seeds. And for that matter, if you use beans do you go on to produce vaporware?

Personally, I think the real problems with JavaBeans is that they encourage exposure of attributes. In a sense, each getter and setter violates encapsulation and makes your class one step closer to a C struct. Methods on classes should be about behaviour, not about shoving data in and out -- CeesDeGroot