When Will We Come Full Circle?

Kirill Grouchnikov recently blogged about his distaste for AOP, and I have to completely agree with the guy. Not to my surprise, a few disagreed with him, retorting that, "you don't understand AOP." What aren't we understanding, and more importantly, when will the Java developer community come full circle?

I look at things like Groovy and AOP, what are we gaining? What purpose does it serve that can't already be accomplished in Java? Is it appealing to some developers because it's simply something new and more interesting to try? Or, is it appealing because developers are trying to solve problems they've created for themselves?

Really, we can't blame developers for thinking AOP is the greatest thing next to sliced bread, or blame those developers who have developed their entire application in Groovy. I say we blame the specification groups and framework developers. Ask yourself, "Why is AOP so appealing here?" Is it because the API is so horridly complex that developers seek to jump completely out of the "box" into byte code manipulation, just to better understand what they are doing?

Simon Brown also blogged about a new Web Services Tag library. What's the goal? To simplify the use of web services. I find this funny since we can generate a JSR for an easy to use tag library, yet we must still jump through hoops on the Java side to deploy and use web services. I realize that open source projects have made web services easier, but for pete's sake, why isn't this standardized in an easy to use API?

Some may argue that most specifications generated are for vendors, giving them grace for being so complex and yet so flexible. An example is JavaServerFaces, a framework geared at working directly with your plain old Java Objects-- beautiful, but I wouldn't use it without a development tool.

But then I look at some other specifications that have come out and for the every day developer, it's like choosing a contractor to build your house, and then they just dump all the materials on site and leave you with a few instructions. Maybe this is why .Net is so appealing? There, I said it. Developer friendly APIs, not vendor friendly APIs.

At the ServerSide.com, they just posted an interview with the EJB 3.0 spec where a question was asked, "POJO programing is definitely one of the hottest things going. How is the POJO programing model on EJB3 going to affect developers?" To which he replied, "I think it is going to have a big impact on developers, in particular, because it simplifies what developers are required to do to write an EJB. So the bean class much more like regular java beans class now. It's not required to implement a particular call back interface or extend EJB classes like it was in the past. So it has made EJB development a lot more like regular java development."

What's wrong with this--? POJO programming is definitely one of the hottest things going... the POJO programming model? You mean developers are actually using plain old java objects again-- or as he put it, "regular java beans"?! Taboo I tell you. Basically, this is a perfect example of why Java went wrong.

In any case, I'm still waiting for the day when developers will feel comfortable actually new'ing an instance of something in their code again-- instead of using some factory with byte code weaving under a proxy layer which is an object with twenty 'setters' and no concept of encapsulation, referenced by some key name *cough*.