Making bean properties a little easier – upgrading beanutils


If you read the last post, you’ll know that I’m losing patience with get/set methods for bean properties. Well, I did something about it this weekend, and experimented with a newer version of commons beanutils.

Here’s the idea, you should be able to create a bean without writing getter/setter methods, like this AnnotatedPerson.java. Then you should be able to use something like PropertyUtils to get and set bean properties. If you take a look at the code I just linked to, you’ll see a quick unit test in a forked version of Commons Beanutils. I took some time this weekend to experiment with the ideas I talked about in the last post, and I made a little bit of progress.

You can see it for yourself here: http://brahe.discursive.com/viewcvs/commons-beanutils5/, and if you want to check it out of Subversion just use http://brahe.discursive.com/svn/commons-beanutils5. I’m doing this outside of the ASF to begin with because I’m just experimenting with some ideas about how this Property annotation could be refined. If you have ASF commit rights, and if you care to commit, send me an email from your apache address, and I’ll gladly give you rw access to the repo. Anyway, from my initial findings, it looks like the @Property annotaiton is going to require a security workaround ala ReflectionToStringBuilder in Commons Lang…..me? I’m totally fine with that, but I’m imagine someone’s going to have a cow about adding sometihng insecure into code that is so widely used. I guess my preresponse to the security argument is, that if someone is using the @Property annotation, they are already going to be aware of the tradeoff.