Raible Designs

All Java web frameworks should support hot deploy of a single class

In Anyone else using Groovy?, Tim Fennell (inventor of Stripes) raves at how much he likes Groovy now that it supports Java 5 features. He writes that Groovy might offer a solution to make development with Stripes faster:

The other thing I've been wondering about is that if there were enough demand for it we could try adding "improved" groovy support. E.g. throw your groovy actions under WEB-INF and we'll use groovy's built in stuff to do auto-reloading etc.

Gregg Bolinger responds with an excellent idea:

It would be really cool if Stripes could automatically discover and load changes to action beans (including new ones) without the entire app restarting, regardless of what the action bean is written in. But I realize that is a pretty tall order. :)

I agree that it might be a tall order, but I don't think it's impossible. In fact, I think all Java-based web frameworks should support hot deploy of a single class. We shouldn't have to buy JavaRebel to do this. It should be mandatory.

When an application reaches a certain size, the startup time can get pretty lengthy. This is lost development time. Furthermore, if any part of the development cycle takes longer than 15 seconds, there's a good chance developers will do something else (check their e-mail, move onto another task, etc.). Multi-tasking may be a good skill to have, but it's a horrible way to be productive.

Of the frameworks I'm familiar with, only Tapestry 5 and Seam support reloading single classes without restarting the whole application. Why can't the other frameworks "borrow" Tapestry 5's code? Maybe someone should just buy ZeroTurnaround and give away JavaRebel for free.

If I had one wish for 2008, it would be for all Java web frameworks to support this feature. Pretty Please?

How long does it take to build a modern web framework?

Dear Java Web Framework Authors,

I hope you're doing well and continue to enjoy working on the web framework you created years ago. I'm curious to know something:

    How long would it take you to build your web framework from scratch?

If all the code from your framework magically disappeared tomorrow and you had to write it from the ground up - how long would it take? What if you had a group of 3-5 developers (of your choosing) to help you do it?

Furthermore, would you write the whole thing line-by-line, or could you borrow code from other open source projects to streamline the process?

Thanks in advance for your response,

Matt

Migrating a Rails app to Grails

There's an interesting trend I've seen happening at companies over the last year. More and more, they're experimenting with Rails and/or Grails for both prototyping and real applications. I think this is an excellent use for these frameworks as they both are very productive. The reasons for their productivity is simple: zero turnaround and less code.

For a Java-based company that's built their bread and butter applications on Java and been successful with it, both frameworks can be disruptive. Bread and butter applications tend to be large and somewhat difficult to maintain. In my experience, the biggest maintenance headache is not writing code or fixing bugs, it's the turnaround time required to make changes, run tests and build the application to test in your browser. Since Rails and Grails eliminate the turnaround, it's only natural for developers at companies with a lengthy build process to love their increased productivity.

Over the next couple weeks, I'm going to do some experimenting with porting a Rails application to Grails. Why? Because I think companies are going to have a difficult time choosing between these two frameworks for rapid prototyping and (possible) production deployments. While both frameworks are great for prototyping, the last thing most developers want to do is throw away the prototype and develop it with something else. They want to continue to enhance the prototype and eventually put it into production. With Rails and Grails (and many others), it's possible to build the real application in a matter of weeks, so why shouldn't it be put into production?

For most Java-based companies, putting a Rails application into production is unfamiliar territory. However, a Grails application is just a WAR, so they can continue to use all the Java infrastructure they know and love. So for companies with an established, tuned and successful JVM infrastructure, does it really make sense to use Rails over Grails? The only thing I can think of is language reasons - there's a lot of Ruby fanatics out there.

So again, the purpose of my experiment is simple: to see if a Grails app can do everything a Rails app can. As for language features and scalability, I'm not really concerned with that right now. I'm not looking to prove that either framework should be used for all web applications - just certain types.

Has anyone out there ported a Rails application to Grails? If so, are there any gotchas I should watch out for?

NOTE: I realize that Rails can be deployed on the JVM with JRuby. However, I think many companies have existing Java-based tools (logging, JMX, Spring backends, etc.) that more easily integrate with Grails than Rails. I could be wrong.

A Positive Wicket Experience

Julian Sinai recently released the first version of his company's product based on Wicket. In A Year of Wicket, he describes the experience (emphasis mine).

I've been working with Wicket for almost a year. We've just released our first product that uses Wicket for the user interface, and so it seems like a good time to take stock. Unfortunately, it's not a public site, it's an installable enterprise product, so I can't show it to you. If you don't want to read further, here's the executive summary: Wicket rocks!

I was hired as the GUI Architect for this project. I came to it with many years of GUI experience, mostly using Swing, but without a lot of web development experience.

Because of my Java and Swing background, I was drawn to Wicket. It maps fairly closely to the Swing model of development. So does GWT, but when I evaluated it, it seemed so different from other J2EE frameworks that I felt it was a step too far. No HTML, and no WAR files, for example. This made my colleagues nervous, who were used to Struts and PHP. Me too, as a matter of fact.

I had done some pretty serious prototyping for another project with Tapestry, and there were certain things I liked, like runtime bytecode generation. But the learning curve was pretty steep. At one point I needed to create a custom component, and to do so I needed to learn about engine services and other arcane things that I felt made the process too hard. By contrast, custom components are Wicket's bread and butter, and they are very easy to build.

I also took a close look at JSF. It seemed overly complex to me, and not much of a departure from the Struts era. It came across as a technology designed by committee, with the combination of several complementary libraries required to get the job done, and there are still too many configuration files.

So we decided to use Wicket.

...

One of Wicket's advantages is the strict separation of design from behavior, that is, HTML from code. While we did not have a web designer on the team who built the HTML (the developers did this), and therefore didn't get any mileage from the separation in that sense, we definitely gained from having all the behavior in Java code, because it gave us all the power of refactoring, compile-time error checking, and maximum reusability. [Read More]

I really like how Julian talks about reasons they didn't choose other frameworks. Beyond that, I think it's important to note that Wicket was a perfect fit for someone with heavy Java and Swing experience. I still think Wicket is a little verbose for Web developers that program in Java (me), but it's unlikely there's very many of those. Building a form in Java seems so much more cumbersome than building it with HTML - but that's probably just me.

FreeMarker vs. JSP 2

I've been doing quite a bit of prototyping with Spring MVC and Struts 2 with both JSP and FreeMarker in the last few months. I'm trying to migrate a proprietary servlet-based framework with a proprietary JSP compiler to something that's open source. There's a couple of important features that the proprietary view framework has:

1. It's expression language allows methods to be called with arguments.
2. Templates can be loaded from a JAR on a remote server.
3. XML in variables is escaped by default.

For #1, I've found this to be impossible with JSP EL or JSTL. I've created JSP functions that allow argument passing, but they don't allow overloading of functions. FreeMarker solves #1.

For #2, JSPs again fail because the templates have to be on the file system or in a WAR. FreeMarker solves this problem as well.

For #3, neither JSP or FreeMarker solve this problem. I realize it can be fixed in FreeMarker by hacking the code - I've done the same with Tomcat and solved it for JSP as well.

So based on the requirements in this project, FreeMarker is the clear winner. Here's some problems that I see with using it:

• No XML escaping of expressions by default
• No compile-time checking of expressions
• IDE support is limited to Eclipse (meaning very little in the way of code-completion)

FreeMarker users - are there other problems you've experienced when using FreeMarker in your applications?

Java Web Framework Smackdown at TSSJS in Vegas

This year's TSSJS is starting to look like an excellent conference. I'm particularly excited to be moderating the following Expert Panel.

Java Web Framework Smackdown: Struts 2, Spring MVC, Grails, Seam/JSF and Wicket
The leading advocates of today's popular Web frameworks will duel under the Vegas Lights. Come and learn when to use your favorite framework and to see if it can live up to its hype.

We're talking about productivity, scalability and maintainability of Java-based Web applications. The emerging trend is that simplicity is better and productivity matters. Furthermore, if maintainability is the most costly part of any application -- how do these frameworks perform?

Attend if you're a Java Web developer, or if you simply like good entertainment. A working knowledge of the popular Java Web framework options will make this session more fun. If you haven't worked with any framework, come and learn who has the best spokesman.

I plan on bringing the boxing bell from OSCON 2005 to make this session one of the best in the show. I'll be coming up with a list of questions for these experts in the next couple of months. In the meantime, if you have any suggestions, please let me know.

With a venue like The Venetian, why wouldn't you go?

Comparing Java Web Frameworks Presentation on Parleys.com

The good folks from JavaZone have published a video of the Comparing Java Web Frameworks presentation I did in Oslo in September. Enjoy!

Update: In this presentation, I say we've chosen Struts 2 at LinkedIn. Even though it solved most of our problems, I'm also now prototyping with Spring MVC. I wish JSP/JSTL had a way to call methods with arguments like Struts' OGNL supports.

Comparing JVM Web Frameworks Presentation

Early this morning, I assembled a Comparing JVM Web Frameworks presentation in preparation for my talk tomorrow at ApacheCon. As mentioned on Monday, this presentation compares Flex, Grails, GWT, Seam, Struts 2 and Wicket. While I think this presentation would be fun to deliver, I don't believe it has as much meat as the original talk I was planning to give. My original talk compares JSF, Spring MVC, Stripes, Struts 2, Tapestry and Wicket. Since I've used all these frameworks, I'm able to compare them more on their technical features. Since I haven't used Flex, GWT or Seam, there was no way for me to 1) try them all before tomorrow and 2) do a thorough analysis of how well they each handle my desired features.

Since the abstract on ApacheCon's website mentions my original presentation, I don't want to yank out the carpet and present the second without asking. So my plan is to ask the audience which one they'd rather hear and continue from there. I've updated both presentations with the latest statistics and uploaded them for your review. For those of you who've used these frameworks, I'd be interested to hear how accurate you think my Pros and Cons section is. If you know of better pros or cons, please let me know and I'll adjust as needed.

• Comparing JSF, Spring MVC, Stripes, Struts 2, Tapestry and Wicket
• Comparing Flex, Grails, GWT, Seam, Struts 2 and Wicket

While creating the 2nd presentation, I found a couple things that surprised me. The first is how popular Flex is - not only in job listings, but also in skilled developers and mailing list traffic. Below is a graph that shows how there aren't many jobs for most of the frameworks, but there's lots for Flex.

The following graph illustrates while I chose to use Flex instead of OpenLaszlo as the Flash framework. OpenLaszlo has a much smaller community than Flex.

The second thing that was surprising is Seam doesn't have a logo! How does it ever expect to become a popular open source project without a logo?! It's amazing they've made it this far without having this essential feature. To motivate the creation of a Seam logo, I'm using the following butt-ugly logo in my presentation (found here). Hopefully something better comes along before I deliver my talk tomorrow.

Update: Monday's post started an interesting thread on Stripes' mailing list. Also, I really like Spring MVC's new annotation support. It'd be nice to see it go a step further and use defaults (like ControllerClassNameHandlerMapping + subpackage support) and only require annotations to override the defaults. IMO, Stripes, Spring MVC and Struts 2 are all excellent choices if a request-based framework provides the best architecture for your application.

Update 2: Comparing Flex, Grails, GWT, Seam, Struts 2 and Wicket seems to gave gained a lot of interest (and support) in the blogosphere. Because of this, I'm considering submitting it as a JavaOne talk. If I were to do this, how would you like to see this presentation changed and improved?

Update 3: I received the following Seam logo via e-mail. Thanks Christian!

Update 4: I've updated the Dice.com graph to include "Java" with every search term. To understand the comments on this entry, you might want to view the previous graph.

Update 5: This presentation was posted to the Wicket User mailing list. I followed up asking users to post the pros and cons of Wicket. Now there's a lengthy thread on Wicket's Pros and Cons. Good stuff.

Comparing Web Frameworks: Time for a Change?

I first came up with the idea to do a "Comparing Web Frameworks" talk in 2004. I submitted a talk to ApacheCon and it got accepted. From there, I outlined, created sample apps and practiced this talk before ApacheCon. Believe it or not, that was my first time speaking in front of a large audience.

Historical note: October 2004 was a pretty cool month - I discovered Rails and Roller had a 1.0 release candidate.

When I created the presentation, it was in large part due to all the WebWork and Tapestry folks harassing me on this very blog. I started using Struts in June 2001 (the same month 1.0 was released) and had used it successfully on many projects. Part of the reason this blog became so popular was I posted lots of tips and tricks that I learned about Struts (and its related project) while using it. After a while, the noise became too heavy to ignore it - especially after I'd tried Spring MVC. So in an effort to learn more about the the other frameworks, I submitted a talk and forced myself to learn them. It seems to have worked out pretty well.

With that being said, I think it's time for a change. The reason I originally wrote this was to educate developers on how the top Java web frameworks differed and encourage developers to try more than one. A while later, I realized there's different tools for different jobs and it's not a one-size-fits-all web framework world. It's not a component vs. request-based framework world either. There's lots of options now. When I've delivered this talk earlier this year, I've always felt like I've left quite a few frameworks out. The solution could be to add more and more frameworks. However, I don't think that's a good idea. The talk is already difficult to squeeze into 90 minutes and it's unlikely that adding more frameworks is going to help.

The change I'd like to do is to reduce the number of frameworks down to (what I consider) the top web frameworks for deploying to the JVM. What are those frameworks? IMHO, they are as follows, in no particular order:

• GWT-Ext
• Wicket
• Grails
• Flex/OpenLaszlo
• Seam
• Struts 2

The RIFE, Tapestry and ZK folks can start bitching now. Sorry - less frameworks make for a more interesting talk. Maybe I'll add you in the future and I can ask the audience which ones they want compared then we can choose four and go from there. Why don't I mention Spring MVC? Because I think Struts 2 is easier to learn and be productive with and I also like it's more open and active community. I've written applications with both and I like Struts 2 better. As for Flex vs. OpenLaszlo, I'm somewhat torn. It seems like learning Flex is going to be better for your career, but it's likely useless without the Flex Builder - which is not open source. However, at $250, it's likely worth its price. I know the Picnik folks used Flex for their UI - I wonder how much they used Flex Builder in the process?

What do you think? Are these the top web frameworks for JVM deployment today? The next time I give this talk is this Thursday at ApacheCon. I may try to re-write my talk and then give the audience a choice of old vs. new. The downside of doing the new talk is I won't have time to write apps with GWT, Flex or Seam. Anyone care to post their top three pros and cons for any of these frameworks?

SOFEA: Also known as SOUI

InfoQ asks Does the rise of Service Oriented UI (SOUI) means the death of server-assisted MVC? A similar thread was started on JavaLobby last week: Web frameworks peaking toward obsolescence. A month ago, TSS posted a whitepaper titled Life above the Service Tier.

As far as I can tell, Nolan Wright and Jeff Haynie haven't read the Life above the Service Tier article - where the very same architecture is called SOFEA. Nolan and Jeff are calling it SOUI. Is there a difference that you can see? I don't think there is. However, I do think there's a better acronym out there that could spark more interest in this type of architecture. After all, isn't the tipping point often triggered by good timing and clever marketing?

As I mentioned previously, I really like the ideas behind SOFEA/SOUI. However, I don't think it will replace the existing frameworks we use to develop web applications. Those have been very successful and will continue to be. The internet is growing - there's lots of room for new applications developed with new architectures. As long as this new architecture is scalable and maintainable, I can't think of a good reason why it won't succeed.