Home > API and Patterns, Reflection and Generics > Into the Void: Refining Java beans with rare weapons

Into the Void: Refining Java beans with rare weapons

Lately I’ve been experimenting with the Void class, because I asked myself what I could do with it that I haven’t yet thought about. I came across a use case that I’d like to share with you, because I think it is possible to beautify one’s code with it. In the process of slightly refactoring a Java bean in order to get a nicer, more refactoring-proof way of dealing with beans and reflection, I’m also using an inline-assignment in a way that you might already have come across, still I have hardly seen it anywhere in the wild, even though I find this particular use case for inline-assignments one of the best there is.

Proxies love the Void.class

You probably have asked yourself quite a long time: “What’s the class Void for?”, since you can’t create any object of it. You might be tempted to say that it’s just a placeholder to indicate that a generic method returns nothing, but it may serve you well beyond that, because these methods actually return something. As strange as it sounds they return something that is meant to be nothing: null.
In my previous blog “Reflection without Strings” I have constructed a “MethodFinder” class that enables you to get method objects from any interface without referencing the methods by its name. So you’d have a refactoring-proof way to use reflection on interfaces. The trick was to create a dynamic proxy for the interface, which will remember the last method call that it got, call it and then ask it what it has remembered. You could then pass the method object on to any object that can deal with it.
With some little syntax-trickery and a static import it was possible to get a nice and concise syntax that made it look like this:

import static de.plush.brix.tools.reflection.MethodFinder.*;
//…
 final Method getter = method(call(IArticle.class).getPrice());

The method “call(IArticle.class)” will return a proxy implementing the “IArticle” interface, this is where you call “getPrice()” on. Now the MethodFinder class will remember (per thread), the method you have just called and return the default for the method’s return type, which is either null, 0, (byte)0, (short)0, 0, 0L, 0d or 0f. That useless result of the proxy call becomes the parameter of the “MethodFinder.method(Object)” method and the parameter solely exists to make the expression a one-liner.
Mocking frameworks like Easymock work the same way. If you’re into unit tests, you might recognize this:

final IArticle mock = EasyMock.createMock(IArticle.class);
EasyMock.expect(mock.getPrice()).andReturn(testPrice).anyTimes();
//…
EasyMock.replay(mock);

Now the problem is, that for calling a setter, which is a void method, you cannot use the return value as parameter for “MethodFinder.method(Object)”, because void methods don’t return anything it won’t compile. So for void methods, the syntax looks like that:

import static de.plush.brix.tools.reflection.MethodFinder.*;
//…
 call(IArticle.class).setPrice(null);
 final Method setter = method();

At this point you should consider biting the bullet and refactoring your IArticle interface as follows:

public interface IArticle{
 Price getPrice(); 
 Void setPrice(final Price newPrice) ; //note the uppercase “V”
} 

This will make a setter look like this:

public class Article implements IArticle{
 //…
 public Void setPrice(final Price newPrice) {
  price = newPrice;
  return null; //works, as “null” has no type
 }; 
} 

As a result your reflection code can now look like this:

import static de.plush.brix.tools.reflection.MethodFinder.*;
//…
 final Method getter = method(call(IArticle.class).getPrice());
 final Method setter = method(call(IArticle.class).setPrice(null));
 final Binding<IArticle,Price> binding = new Binding<IArticle,Price>(getter, setter);
 binding.setModel(Article.none());
//..

The same happens with the EasyMock example:

final IArticle mock = EasyMock.createMock(IArticle.class);
EasyMock.expect(mock.setPrice(testPrice)).andReturn(null).anyTimes();
//…
EasyMock.replay(mock);

This looks a lot slicker, doesn’t it? The “return null” in Article.class sucks however, but since we’d probably like some event handling anyway, we can beef it up too. More on that follows.

Inline assignments beautify your setters

You have for sure seen something like this before, haven’t you?

public class Article implements IArticle{
 //…
 public Void setPrice(final Price newPrice) {
  final Price oldPrice = price;
  price = newPrice;
  firePropertyChange(“price“, oldPrice, newPrice);
  return null;
 }; 
} 

This method stinks in many ways: The property key is referenced by a String, we have a temporary variable for the old price and just because of our neat “Void” type, we have a “return null” here. Don’t worry; Salvation is near. Let’s tackle one problem after the other.
First we kill the temporary variable with a simple inline-assignment, which is discouraged by some style guides and is hardly used elsewhere than in loops to read streams, but it serves very well in this case:

public class Article implements IArticle{
 //…
 public Void setPrice(final Price newPrice) {
  firePropertyChange(“price“, price, (price = newPrice));
  return null;
 }; 
} 

To understand how this works is to understand how parameters are evaluated, which is from left to right: To call firePropertyChanged, the runtime must first push all 3 parameters on the Stack in order of appearance, which is the String “price”, the value of the price itself and finally the value of the bracketed statement. Now the statement in brackets not only results in the new price, it also assigns the new price to the price field.
Getting rid of the ugly “return null”, is as easy as it can get: Just change the “firePropertyChange” method to return the “Void” type instead of the “void” primitive and you can write it like that:

public class Article implements IArticle{
 //…
 public Void setPrice(final Price newPrice) {
  return firePropertyChange(“price“, price, (price = newPrice));
 }; 
} 

Its seems a little bit awkward to return anything after firing a property change, but I can live with it, can you?
The last thing that looks so incoherent is that even though we’ve now managed to access the method without referencing it by its name, we identify the property by the name. And there’s really no way around throwing a string around, when you need to stay compatible with the existing property change mechanism of the java beans framework, which you should. But then again we can get the string automagically by assuming the convention “setX”, “addX” and “removeX” for modifier methods. We just ask the stack trace which method we’re in and analyse the string and I’m using a little utility for that to not repeat myself. Alas, working with the stack trace is a bit of a mess, because call depths matter and these may change when refactoring, but that’s where testing getters and setters with unit tests pays off.
I like to have some sweet little methods in a utility class to get me the current property name:

public static String propertyName(){
 final StackTraceElement x = Thread.currentThread().getStackTrace()[2];
 return extractPropertyName(x.getMethodName());
}
public static String propertyName(Method method){
 return extractPropertyName(method.getName());
}
private static String extractPropertyName(String methodName){
 final String[] prefixes={"get","set","add","remove"};
 for (final String prefix : prefixes){
  if (methodName.startsWith(prefix)
   && methodName.length() > prefix.length()){
   return Character.toLowerCase(methodName.charAt(prefix.length()))
   + methodName.substring(prefix.length()+1);
  }
 }
 throw new IllegalStateException(methodName 
 +" is not a property get, set, add or remove method");
}

With this method in place and a static import to get it, my business object now looks as follows:

public class Article implements IArticle{
 //…
 public Price getPrice(){
  return price;
 }
 public Void setPrice(final Price newPrice) {
  return firePropertyChange(propertyName(), price, (price = newPrice));
 }; 
} 

Et Voilà! Here is your business object with property change support, Void return type and no need to keep any property name strings in sync, in other words “fully refactoring-proof”. Thanks to the “strange” Void class and a little utility, property change support looks pretty much like straightforward Java code without magic constants:

 String priceProperty = propertyName(method(call(IArticle.class).setPrice(null)));
 article.addPropertyChangeListener(priceProperty, updatePriceView);

So what is the take-home message of this blog? The Void.class is a quite useful replacement for the void primitive. Inline-assignments may seem like a black sheep in the Java language and are prone to be misread, in non-complex situations like these, they beautify the code considerably.
Mind you the Java bean was just an example to demonstrate possible uses of these rare tools – in the real world a setter that returns the old value is usually more beneficial.

About these ads
  1. July 24, 2011 at 18:16 | #1

    If you’re making bindings, you might look at bindgen (http://www.bindgen.org), which is an annotation processor that will generate bindings for your classes.

    E.g.:

    @Bindable
    class Employee {
       String getName() { ... }
       void setName(String name) { ... }
    }
    

    Then use it like:

    e = new Employee();
    eb = new EmployeeBinding(e)
    eb.name().get();
    eb.name().set("newName");
    

    Or, in a UI framework:

    new TextField(eb.name());
    

    For your property names, you may even be able to do that without the stack trace hack, e.g.:

    @Bindable
    class Employee {
      private static final EmployeeBinding b = new EmployeeBinding();
    
      public void setName(String name) {
        setAndFire(b.name(), name);
      }
    
      private  void setAndFire(BindingRoot binding, T newValue) {
        T oldValue = binding.getWithRoot(this);
        binding.setWithRoot(this, newValue);
        firePropertyChange(binding.getName(), oldValue, newValue);
      }
    }
    

    Interesting point about returning Void for better proxy-ability. I hadn’t thought of that. Will keep it in mind.

    • July 24, 2011 at 20:21 | #2

      I appreciate your comment Stephen. In my last project the binding the framework-designers had created was through a so-called “ValueProvider”-interface which was a simple interface with nothing but a getter and setter that you used to implement to bind the ui-adpater to a certain property (so most of the times the implementation was nothing but a get/set-call on the target bean), the other possibility there was handing over a string which was then transformed into a getter and setter-name and used with reflection on the bound object. I always thought that this was too verbose or not safe for refactoring, so I created a ValueProvider-Factory, that just got two methods as a parameter and returned a ValueProvider implementation that used those methods (as it was described in my previous blog). So binding was just the first example that came to mind, but I’m sure that’s not the end of the road,
      Bindgen looks very interesting, so many thanks for the pointer.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 40 other followers

%d bloggers like this: