I have a love/hate relationship with J2EE. I love the idea of standards that we can all use in our development to improve interoperability, ease integration issues, create a pool of skilled developers, etc. I hate the idea that I have to wait years for the standards to evolve and become usable. And I hate having specs that seem to work well in theory but have no practical implementation behind them. This brings me to the JSF specification.

How long have we heard about JSF (JavaServer Faces) and how it will make it easier to build Web pages? Why did it take more than two and a half years to come up with JSF, which is essentially an event model for Web pages? And it happened at a time when Microsoft was coming out with major innovations (a debatable point, I concede) and huge pushes targeted at providing ease of development for the corporate developer. Visual Studio/.NET developers look at the J2EE community and basically say "these guys don't get it."

Let's take a look back at JSPs. Isn't one of J2EE's goals to encourage encapsulation and object-orientation? If so, why create a standard that encourages a mixture of presentation logic, application logic, business logic, and data access into one page class? The answer is Microsoft. It was a reaction to what Microsoft had: "Hmm, we need something to compete with ASP. Hey, let's make JSP. We'll have tag libraries so we can easily embed components on a page and call it encapsulated." Obviously things have evolved a bit since then and we can now separate the flow of the application from the pages with frameworks like Struts. Well, last time I looked, Struts isn't part of J2EE - which means you're doing nonstandard development - but it is open and has an ecosystem of developers so it's a pretty safe choice. Of course, if you like editing XML, Struts is for you. There are Struts editors out there to help you, but in the end you're still dealing with a lot of complexity.

Now we have JSF, which promises to apply the "ease" of Swing to page development.

My expertise is in building corporate business applications and the needs of the business application developer. What I see in JSF is overengineering. Let's think of every possible usage pattern for Web pages and address them, not necessarily a bad thing. The resulting standard is one in which there are several layers of abstraction, many, many moving parts, and ultimate flexibility.

The problem is that ultimate flexibility comes at a cost - it's called ultimate complexity. From what I can tell, JSF won't actually reduce the complexity of creating Web applications. In fact, it greatly adds to the complexity. Just as JSPs did too little to provide granularity in building pages, JSF goes too far and makes things too granular. Do I really need a separate event to be called for each piece of data that has changed on a form? And possibly separate handlers for each? Be prepared for the framework that will sit in front of JSF to simplify its complexity.

In defense of JSF, it does follow many of the object-oriented Web page design concepts that we had at SilverStream in, oh, 1998. And it does have some appeal to the PowerBuilder developer that I used to be in the mid-'90s. However, experience has shown that building page-based applications with the level of object granularity shown in JSF doesn't make life easier; it makes it more complicated. I've architected and used many frameworks in my career and the trick is to perfect the balance between the ultimate flexibility that the architect wants and the ultimate usability by nonengineer developers.

I just joined ClearNova, and for several years our product, ThinkCAP, has provided a rapid way to build applications and presentations, one thing that attracted me to the company. We're doing the R&D needed to move parts of the platform toward JSF, but I'm concerned we'll lose a lot of the productivity that our current product has by implementing a spec that only object-oriented theorists could love. If we don't allow developers to have complete control over everything that JSF can do, we'll take flak from the purists, even if doing so makes the tool so hard to use that it appeals only to experienced J2EE developers.

Ultimately, my fear is that JSF will once again play into the hands of Microsoft's "complexity attack" and tempt business developers to run for the J2EE exit.

• Java Opinions: Geary vs Raible on JavaServer Faces (JSF)