Perusing javablogs, I discovered that a friend from college, Rich Unger, has a journal on java.net and recently mused on the proliferation of J2EE frameworks. I decided this was as good an opportunity as any to geek out in my blog, given that I’ve been neglecting it of late.
Despite the fact that he lists things like “Hibernate” (an Object/Relational mapping tool), “Velocity” (a text templating language agnostic to J2ee or web frameworks), “SiteMesh” (a Servlet filter for decorating pages with common layout components like headers and sidebars), and “EJB” (component-based framework for creating distributed enterprise Java apps), I believe Rich’s real astonishment is at the number of Java web frameworks available to webapp developers. Indeed, this can’t really be argued against; Java web frameworks are legion. New ones pop up all the time, each created seemingly to meet the whims of another development style. As a wise man once said, that’s the beauty of standards: there’s so many to choose from.
I think, though, it’s a common mistake (especially among webapp development newcomers) to confuse web frameworks with application frameworks. I would guess there aren’t many experienced J2EE developers who didn’t, at one time or another, work on a project that failed to make this distinction. A web framework, if done well, only provides a solution for one tier of a typical J2EE application: the UI. This is also the reason, as Rich puts it, that “the folks at Spring seem to take it for granted that Tapestry is something best relegated to the UI layer.” They do that because that’s what Tapestry and other such web frameworks are built to solve: organizing code and content in the UI tier of a J2EE application. Once you start using a web framework for more than that, though, you’re really asking for headaches. Placing business logic and persistence code directly into your Struts actions or JSP pages, for example, invites a host of problems into your application.
That’s why frameworks like Spring are so compelling. Spring is an application framework. In fact, while it is incredibly well suited for J2EE development, it works beautifully in environments that wouldn’t normally be considered under the J2EE umbrella, such as in the Spring Rich Client Project.
Part of Spring’s charm is that it (typically) doesn’t attempt to reinvent the wheel. It provides a clean and consistent interface (both through its API and its IoC configuration model) for many, if not all, of the technologies you would use in a typical J2EE application. Spring’s effectiveness in this regard can’t be understated. Rich complained about a proliferation of web frameworks, but have you seen a list of the “core” set of J2EE technologies? They include, but are not limited to, JTA, JMS, JDBC, JMX, EJB, JavaMail, JSP , and servlets. Note that only those last two are specific to the web tier. Yet all of these technologies have different APIs, different exception hierarchies, different configuration mechanisms, different programming models. The beauty of Spring is that it provides a unified front for these technologies, allowing for easier coding, testing, and configuration.
This is why there’s no contradiction when coupling Struts and Spring. While Spring does provide an MVC library for implementing the view tier of a web application, it doesn’t mandate its use, and provides direct support for a number of other view technologies, including the ever-popular Struts. Thus, Struts is not a direct competitor of Spring, just Spring’s MVC layer.
I could discuss this at length, but I’ve already exceeded the point where anyone would find this post worth reading. For more information about what goes into writing J2EE applications, I really recommend Rod Johnson’s books “Expert One-on-One J2EE Design and Development” and “Expert One-on-One J2EE Development without EJB“. While the second one is certainly Spring-friendly, the first was written prior to Spring, and is the tome that inspired the development of Spring in the first place. It provides a really powerful overview into the technologies and architectures available when creating J2EE applications.
It’s true that I was a bit cavalier about distinguishing between web UI frameworks as application frameworks. You can hardly blame me, considering the confusion out there. After all, Spring’s own reference guide lists Velocity and Freemarker under “view technologies”, and Tapestry under “web frameworks”, and considers them integrations on 2 different levels.
One thing’s for sure. From now on, whenever I hear someone say there’s no room for both Eclipse RCP and the NetBeans Platform, I’ll have a good response
I wasn’t aware that JavaMail was considered a “core J2EE technology”. After all, it predates J2EE. Remember when Jason Ginchereau and I coded up an email client as a school project? That used JavaMail. By the way, I haven’t used it since and never intend to. That’s a classic example of an API that was designed to make it easy on the API writer instead of the API user.
Besides, most webapps are concerned only with sending email, and for that we have the much better jakarta commons email library.
I would completely agree with Spring in its assessment of Velocity, Freemarker, and Tapestry. Velocity and Freemarker are “merely” templating languages. They are not specific to webapps. In this way, they are superior to JSP (another “view” technology), in that they can easily live outside an HTTP request/response cycle. For example, there’s a project called FMPP that uses Freemarker as a suped-up preprocessor, usable from the command-line or ant. If desired, Velocity and Freemarker can used to render an HTML page (very easily, if you’re using Spring MVC), but they can be used most anywhere a templating language is needed. We use Freemarker in our app for rendering emails, and it works really well for this.
Tapestry, on the other hand, is most definitely a “web framework”. It also happens to define its own “templating” engine as part of this, which is tied closely to (X)HTML. But it is specifically designed for organizing and rendering HTML content in response to an HTTP request. As such, it is a “competitor” to Struts, Spring MVC, and the like. These tools serve a very different need than Velocity and Freemarker.
J2EE, as far as I can tell, is really just an umbrella for Java libraries. If you use JDBC in a Swing app to access a database, does that make your client a J2EE app? I don’t know. Mostly, it’s just marketing, and another one of those buzzwords that has implied association, even if it’s not rigorously defined.
I agree, JavaMail is truly a horrendous beast. It is my least favorite of the “core J2EE technologies”. I haven’t played with commons email. I’ll have to investigate.
Ah, so Velocity and Freemarker play in the same niche as XSLT. Makes sense.
I see the distinction, and how Tapestry is tied to an HTTP request. However, I’m pretty sure the core library is not tied to xHTML (though many of the standard components certainly are). I’m fairly certain I could write a VoiceXML Tapestry app, for example. It would probably be a bad design decision, given the way conversation flows are represented in VoiceXML, but it could do a few useful things like concatenation strategies.
I have done serious work with JavaMail and it was not that bad. At least the object hierarchy sounded like the MIME hierarchy and I found it easy to work with it even considering I had to handle SSL both on the SMTP side and the POP side and navigate the attachment structure heavily.
At least, I did not find more complexity in the library than in what it models, like the protocols and the structure of messages. This means that after dealing with the RFCs the rest looks simple
Turning on traces for debugging is also simple.
The worst part is configuring TLS.