Have Beans been holding us back?

I have been a Java developer for many years now and have always taken for granted some of the standards pushed on me from the beginning. Java standards such as basic Java Beans (aka POJOs) are supposed to make life easier by providing simple getters/setters that work with the private fields of your Object. For years I have neglected to challenge this as it seemed perfectly natural, and when I started to use Eclipse and could simply tell Eclipse to generate the getters and setters for my beans for me it made it that much easier to simply ignore all the extra code being created.

Unfortunately, over the years there have been some additional frustrations that have resulted from this approach as I wrote more code and attempted to do more complex things in my projects. As a developer trying to write more efficient and more elegant code these things have been a constant reminder that no language nor methodology is ever perfect.

The first frustration which I found myself struggling with as a new developer not using an IDE (that happily writes code for me) is the many lines of code to simply modify a variable. For example:

public class SimpleBean {
   private String name;

   public String getName() {
       return name;
   }

   public void setName(String name) {
       this.name = name;
   }
}

Notice that it takes up seven lines of actual code put a simple String into my bean and that’s not counting the whitespace added to “pretty it up”. Sure, as a noob coder it’s tempting to do something like this:

public class SimpleBean {
   public String name;
}

and be done with it. However, as a serious developer that’s really not practical as it creates additional problems down the road when you want to add validation, remove the setter so it’s a read-only field, notify something internally when the value changes, etc.

The next frustration I have with Java Beans is the fact absolutely EVERYTHING is a manual coding exercise. Take Java’s Observer/Observable pattern for example. When I was beginning to learn Java I ran into the problem that I wanted to be notified when a value changed in one of my beans and stumbled upon a Observer/Observable tutorial and at first glance I thought, “Wow, this is really great and exactly what I want”, until I realized in amazement they expect me to extend Observable and add an additional line of code to EVERY SINGLE setter call that I want to monitor. Come on, I was looking for abstraction to keep my beans dumb and simple, I don’t want to add a bunch of extra lines of code to every method. Also, what if I’m already extending another class that I can’t change? I’m sure many people might read this and think I’m just being nitpicky, and yes, I am, but I care a great deal about elegance in code and I was hoping for some sort of feature on my Field to “addChangeListener(…)” or something. Besides, every additional line of code is an added line that has to be filtered through when trying to read and debug and thus makes your code more error-prone and harder to manage.

Extending upon the previous frustration is bindings. There have been many a rant on the topic of bindings in Java and though there are many APIs and even a JSR set to solve the problem I have yet to see one do a good job. I myself tried to solve this with my MagicBeans project. There were many iterations of it, but the most elegant required AspectJ to monitor pointcuts on setter methods and notified listeners. It was a complete and elegant abstraction, but required your projects to be compiled with AspectJ which ultimately I abandoned as not worth the added pain.

Ultimately the Java Bean paradigm raises issues primarily in its requirement of the onus being on the developer to write any and all functionality. It disallows you to easily extend or reuse functionality in an Object-Oriented way because they are methods with statically typed fields they represent and though you can accomplish everything you might need to with beans they require a much greater commitment to custom code than should otherwise be expected of the developer in my opinion.

It is these things that have led me to believe there’s a better solution, and I’ve settled on what I believe is the better choice, to which I will explain in-depth in my next post. 🙂