JavaPolis 2005: what's hot and what's not?

As a first recap of my five days at Javapolis, here are my thoughts on trends, past, present and future of the Java platform. Expect to see more in-depth articles soon.

JSP’s are so passé now

There was a time when scripting embedded inside text templates seemed like a good way to produce HTML. It was certainly an improvement over writing lines of Java code printing to a ServletOutputStream. But nowadays this approach doesn’t seem like such a good idea anymore. JSP’s can be hard to maintain, and seem to live outside of the world of Java objects. Their plain-text approach doesn’t do justice to the nature of HTML and HTTP, and there is no clear separation between graphical design and logic. It just seems much more natural to think of web-pages as a collection of components, and AJAX fits nicely in this model as well.

Enter component based frameworks. There are lot of web frameworks out there, but it’s the component based ones that ran the show at Javapolis: Tapestry, Wicket, JSF and JSF-leveraging frameworks (Shale and Seam). They all boast AJAX support with ease of development, and a better programming model for web front-ends. Components are hot, plain old JSP’s are not.

The battle of the web-frameworks

Let’s face it: Struts is dead, and who could be in a better position to say so than Struts committer David Geary in his weblog:
"Let’s get something straight right off the bat: Struts is old-school and is no longer the best Java-based web application framework. IMO, it’s not even in the top 3. As a Struts committer, I will always have a soft spot for Struts, but let’s face it: over the past 4 years many advances have been made in WAF technology and, mostly due to backward compatibility considerations, Struts has not kept up."

Interestingly enough, the Struts project has recently announced to merge with Webworks, a move that’s probably unprecedented in the open source world. But frankly, I don’t think this is going to save the framework from rapid decline in the near future. Better start looking for a component-base framework!

Java Server Faces

It has taken two years, but JSF finally has the momentum by now, and all the industry support that one could hope for. Tool support is in the works for most popular IDE’s. A large number of good components is readily available, in particular from Apache MyFaces and Oracles recent donation of ADF Faces, together soon to be renamed to Apache Faces. There were many stories from early JSF adopters at Javapolis, very encouraging in general, but a few weak spots were identified as well. Firstly, JSF provides a great foundation for AJAX but there’s no standard way to implement it. Secondly, JSF doesn’t mix with the JSTL expression language. (The next release, JSF 1.2 will address this to some extent). Thirdly it lacks support for state management and variable scoping appropriate for dialogs and processes that span multiple requests. The term process scope was coined, as opposed to request scope (to short) and session scope (too long). Remarkably enough, almost every session on JSF presented some custom solution, so this must be one of the more obvious shortcomings of the original spec.

Tapestry and Wicket

Arguably the greatest contribution of Tapestry to innovation is the concept of weaving pure HTML files with Java components. This provides an ideal separation of concerns between graphical design and UI logic, leaving it up to the framework to weave the two together. New kid on the block Wicket copied the idea, resulting in a view framework that resembles a Swing-like model. Definitely very interesting and usable, but my major concern with these frameworks is they don’t allow me to leverage and reuse the growing arsenal of readily available JSF components.

Seam

JBoss Seam addresses some issues, mainly targeted at EJB 3.0 integration. They provide process statemanagement (see above), tighter integration between the JSF managed bean and the EJB session- and entity beans, and move the validation from the view higher up into the model.

Shale

Authored by Craig McClanahan and David Geary, both deeply involved with both Struts and the initial JSF spec, it should come as no surprise that Shale (a.k.a. Struts Shale, according to David just a branding name Craig insisted on), is a very strong contender for the big prize. Instead of reinventing the wheel, they have bundled best of breed solutions from the open-source domain in a framework that sits on top of JSF:

• Jakarta Commons Chain implements the command pattern. Command catalogs and hierarchical chains (chain of command pattern) provide an appealing way to organize the logic that drives the view components.
• Jakarta Commons Validator provides components for unified server- and client-side validation.
• Tapestry-like views provide complete separation of concerns between graphical design and UI logic (see above).
• Shale Webflow was modeled after Spring Webflow, and addresses the state management issues that I mentioned.
• AJAX and remoting support is supported, and leverages the command infrastructure.

And the winner is…

As of now, I’m convinced that Shale, oops, Struts Shale has the best package on offer. Time will tell, but it’s currently my best bet.

AOP is here to stay

AOP (aspect oriented programming) has been around for a long time already, but adoption is slow. Nevertheless, it finally has gained enough momentum for it to be no longer considered exotic, but an advanced technology instead. For many people, the proxy-based AOP implementation offered by Spring may have been the first introduction to AOP at large. But there’s more to it. I attended an extensive session by Ramnivas Laddad on AspectJ, the leading, open-source, AOP framework. AspectJ provides compile-time (and load-time) AOP. The extensive coding demo’s convinced me that this AOP implementation is actually really easy to adopt. The basic concepts (aspects, pointcuts and advice) are simple enough to grasp. The pointcut expression language is powerful, yet easy to get started on. The tool support is extensive and excellent, plugins are provided for all popular OS ide’s and build tools like Eclipse, Netbeans, Ant and Maven2. I tried the Eclipse plugin, trust me, it can’t get any easier than that. In addition there are tools that visualize the weaving of aspects into classes. There is AJdoc, a javadoc extension that supplements the documentation for each method with a list of cross-references to the aspects that affect the method.

Several speakers agreed that it usually takes one or two years to learn to fully think AOP. Adoption typically starts with development aspects (logging, debugging, profiling). Over time, as one becomes more comfortable with it, the application of AOP will extend into the area of business logic as well. Sounds a bit like the adoption of OO in the C/C++ world ten years ago…

Annotations to the rescue

Annotations are arguably the most powerful new language feature in Tiger, but have been the slowest to deliver. With the advent of Java EE 5, that’s going to change big-time. In many places annotations are going to make our work a lot easier, and more fun. Expect to see more annotations coming soon to an API near you.

A second chance for XML

XML, once the popular new rave, seems to have acquired an image-problem as of lately. There are two reasons for this. Firstly, people have come to hate the abundant use of XML for all sorts of deployment desciptors in J2EE and webservices. In JEE 5, it seems we can ditch most of these in favor of annotations. But, as Mike Keith pointed out in his EJB3 sessions, we’ll still need XML descriptors, albeit less verbose. The real gain is that we’ll be able to make an informed decision about what metadata we provide at compile-time, using annotations, and what at deployment-time, using XML.
Secondly, the two standard XML-processing API’s (DOM and SAX) are definitely low-level, clumsy and elaborate. In his Java Roadmap keynote, Sun VP Graham Hamilton announced integration of XML support in the Java language for Java 7, codenamed Dolphin. Hopefully, this will finally addres the issue and make XML a first-class citizen in Java. It might even use annotations.

Java EE 5: lessons learned

Redefining the EJB spec for greater ease of development: it was a titanic task the EJB 3 spec team set out on, and its amazing how well they did. A large part of this succes must be due to the adoption of winning concepts from the open-source arena: pojo’s, dependency injection, introspection-based collaboration, AOP-like concepts and configuration by exception (a.k.a. the principle of least surprise). Plus the power of annotations. Tie it all together in an industry-strength reference implementation, let early adopters play with it and use their feedback to make final adjustments. Compared to previous major J2EE specs, this is a different beast altogether. It sets a new and vastly improved standard for specs to come.

Webservices everywhere

Webservices were everywhere at Javapolis, especially when you consider that AJAX is really a lightweight webservice technology. Sun VP Graham Hamilton announced that with the advent of Dolphin, JSE 7, webservices will become part of the standard edition as well. Even desktop applications will be able to both consume and provide these services in order to better interoperate with non-Java environments. Webservices with or without web, so to speak.

New languages

Java 6, codenamed Mustang, will include the Rhino scripting engine for Javascript support. This will set the stage for a whole new development, i.e. support for alternative languages that run natively on the Java platform. My favorite announcement was that Dolphin will take this even a step further by improving support for dynamic languages. To this end, according to Graham Hamilton, Dolphin will incorporate modifications to the JVM spec that will never be used by Java itself! More evidence to the rumors that the platform, the JVM, might eventually outlive the language. Exciting times are coming…