Which J2EE web development framework to choose for a simple, accessible application?

Question

I want to write a simple web application, on J2EE, with these characteristics:

1. I don't need any AJAX, and it should even work with JavaScript disabled on the browser.
2. It is a simple CRUD application
3. I would need full control on the way each element is laid out on the page - no compromise on the GUI's look and feel.
4. I can use plain old JDBC for data access - no o/r mappers necessary
5. Bookmarking of pages is necessary (wherever it makes sense to bookmark, that is).
6. Many of my users use tabbed browsing very much.

What I'd like the framework to do is:

1. Give me a nice abstraction to retrieve GET and POST parameters
2. Give me a nice facility to display validation errors and other errors to the user
3. Give a set of standard safety features - prevent cross-site scripting, prevent the user from setting a dropdown input to a value that isn't there in the dropdown, et.al
4. Be performant, scale well for over 200 concurrent users, on a not-so-powerful server. (no clusters - single node, a shared app server with multiple production applications)
5. Be stable; because I'd like to have that application running without a major refactor for at least 3-4 years

I looked at a few frameworks, and this is what I felt..

1. Plain Servlets/JSP - I need to code everything myself - this would take time, and probably have many bugs
2. Struts (1.x) - Doesn't provide too many advantages over the plain servlet approach; while it does map POST and GET parameters to form beans, the other features I'm looking for aren't there; and I need to invest a lot of time coding them myself
3. JSF - I'm scared of it because of the performance problem I've read about. It seems like the view construction and maintenance takes up too much memory. Also, JSF won't work well with bookmarks and tabbed browsers.
4. Tapestry - I took a look at Tapestry 5. While it looked good, it too seemed to be incompatible with tabbed browsing and bookmarking. While there is certainly support for "activation context", it is only a single string. It can't restore the state with GET parameters and hidden form fields (yet). Additionally, there seemed to be concern about the longevity of the framework - it appeared that it evolves without backward compatibility.
5. Apache Turbine - It looked good at first; but the fact that it's quite old and there's no much activity going on scares me.

Any suggestions on what would be good for me? Thank you!

PS: I'm constrained to use one that's licensed under Apache license (v2, preferably) or BSD license

Tallyho

Answer 1

Spring-MVC is another option to consider

Floatfeed

Thanks.. I didn't know that Spring had the MVC flavored version too.. seems like they have a good tutorial as well; will read it.. (found this -- static.springsource.org/docs/Spring-MVC-step-by-step) – Tallyho

Spring-MVC is relatively similar to Struts 2, of course with some differences. – Floatfeed

Answer 2

Stripes is an MVC java web framework that pioneered the 'Convention over Configuration' pattern for java web development. Spring MVC has adopted some of these patterns but I still prefer Stripes because it does one thing and does it well.

Militarize

I'm reading their "Guiding Principles", and I like this part: stripesframework.org/display/stripes/… "Stripes, at its core, is an action framework and action frameworks as a whole don't shy away from the fact that the entire web is implemented on top of a stateless protocol (HTTP). There are myriad shortcomings in HTTP, and in the various dialects of HTML that are in use. Trying to hide the fact that HTTP is stateless and provide a framework that hides this fact from the developer is fraught with issues, and nearly always leads to a leaky abstraction." – Tallyho

Answer 3

It is rather new java framework, but I think it looks pretty awesome

playframework

Gobi

Answer 4

Grails maybe? You don't have to use the o/r mapping (GORM) if you don't want to, you can use plain old JDBC

Floatfeed

I'm going through its website now.. on first look, it appears to use "Groovy" instead of the standard Java language.. Not sure if it will be a steep learning curve, play well with eclipse JDT etc.. But will check it out.. thanks.. – Tallyho

Learning Groovy is quite easy for a Java developer. Actually most Java code is valid Groovy code. But you should take some time to learn the basics so you can benefit from the power of Groovy. The Eclipse plugin is heavily developed right now. Still has some issues, but is getting better and better. Groovy support in IntelliJ is quite good. – Floatfeed

From another question here on SO, I became aware of the Play framework, playframework.org Haven't loked at it myself, but looks promising if you want don't want to go for Groovy. – Floatfeed

Actually, the web part of Grails leverages Spring MVC. – Floatfeed

Since Pradyumna is concerned with performance (re JSF), Groovy's probably not a good choice here. Barney Boisvert (a Groovy fan) writes about a case where Java took 110ms and Groovy 1.6 took 80,000ms: barneyb.com/barneyblog/2009/03/02/a-groovy-letdown – Karlise

Groovy is not a language for number crunching. The nice thing about Groovy is that it integrates so nicely with Java. If you need an algorithm to be really fast, then you can write just that algorithm in Java. For a web application, the extra 1 ms or so to handle a request shouldn't be noticeable. Groovy 1.7, which is right around the corner, has quite some performance optimizations. – Floatfeed

Answer 5

How about wicket?

http://wicket.apache.org

• Component-based framework, with complete separate of markup and code. Each "panel" component is bound to a more or less plain HTML markup file, which lets you customize the appearance as precisely as you want.
• Encourages OOP, easy custom component-building and code reuse.
• Validation framework with feedback.
• AJAX support with built-in "fallback" behavior for javascript-less browsers
• Supports bookmarkable pages

Starryeyed

Oh, and it's stricltly a GUI framework. You can implement custom models to wire up JDBC or whatever kind of back-end you like. (My project uses Databinder, which is a thin glue framework that wires wicket up to Hibernate). – Starryeyed

It looks good.. Just worried about this one paragraph in the Introduction that I just read.. From wicket.apache.org/introduction.html "For many applications, it will be worth trading off the increased server load of extra server-side state for decreased development costs, lower maintenance costs, quicker time-to-market and generally higher quality software. The basic observation here is that software is expensive and complex while servers from companies like E-machines and Dell are relatively dirt cheap." – Tallyho

I realize that it is premature to worry about performance issues without having done any background.. but if anyone has seen that Wicket needs powerful servers to handle reasonable loads, it would be a good info to know – Tallyho

Wicket itself is pretty lightweight, if you don't hang onto too much of your own information in a page object. Models are detachable, which gives you a clear mechanism to clean up state associated with the page at the end of a request, to minimize the amount of state that's stored. It also has support for stateless pages, which reduce the load on the server. – Starryeyed

Answer 6

JSF - I'm scared of it because of the performance problem I've read about. It seems like the view construction and maintenance takes up too much memory. Also, JSF won't work well with bookmarks and tabbed browsers.

Try Seam framework

• improved performance (added conversation scope)
• fixed JSF to work well with bookmars and tabbed browsers
• many others pros :)

Seam is good for two reasons:

1. It let you quickly create application (basic CRUD like RoR or Grails style)
2. It will be a good foundation for further development.

I want to write a simple web application, on J2EE, with these characteristics: 1. I don't need any AJAX, and it should even work with JavaScript disabled on the browser.

With JSF good library (Richfaces or Icefaces) writing JavaScript code is reduced to minimal. Why JavaScript will be disabled on the browser?

2. It is a simple CRUD application

Seam is great for generating CRUD application via seam-gen tool.

3. I would need full control on the way each element is laid out on the page - no compromise on the GUI's look and feel.

This is work for CSS code. With facelets as templates you'll have less work to do.

4. I can use plain old JDBC for data access - no o/r mappers necessary For simple CRUD application ORM is really cool feature, with Seam you'll have it for free. But ORM isn't mandatory.

5. Bookmarking of pages is necessary (wherever it makes sense to bookmark, that is).

As mentioned with Seam isn't a problem anymore. In "plain" JSF thre are only POST requests and that is a problem.

6. Many of my users use tabbed browsing very much.

Seam introduce new scopes (conversation and buissines process) so now there is possible to open few tabs and simultanously do more than one task/flow.

What I'd like the framework to do is: 1. Give me a nice abstraction to retrieve GET and POST parameters

That's the feature of JSF.

2. Give me a nice facility to display validation errors and other errors to the user

Seam integrates with Hibernate Validator and have really good support for messages and i18n.

3. Give a set of standard safety features - prevent cross-site scripting, prevent the user from setting a dropdown input to a value that isn't there in the dropdown, et.al

IMO JSF libraries are good in this field.

4. Be performant, scale well for over 200 concurrent users, on a not-so-powerful server. (no clusters - single node, a shared app server with multiple production applications)

Perfomant- yes. Seam fix brokes statless application design pattern promotes statefull application. With using POJO in state from performance view is similar to other frameworks like Struts or Spring. For real world use cases see seam in production page.

5. Be stable; because I'd like to have that application running without a major refactor for at least 3-4 years

Seam and JSF are stable technologies.

Zaller

Thanks for you detailed response. The reason I want to avoid JavaScript is that the application must work for users who are visually impaired. They use JAWS (a screen reader), but perform a good deal of data entry and verification work. – Tallyho

Just noticed that Seam is LGPL licensed - BSD or Apache 2 would have been better.. – Tallyho

This link might help you - theserverside.com/news/thread.tss?thread_id=49650 – Zaller

@Tallyho Seam is JBoss/RedHat product. I presume that almost all theirs opensource projects share LGPL licence. – Zaller

Answer 7

Thanks everyone. I'll build some sample apps tomorrow using Spring MVC, Stripes (and probably Wicket), and see them in action :)

I'll update this answer with what I find..

Thank you! -Pradyumna

PS: It's disappointing that I can't mark multiple answers as "ANSWERED" in stackoverflow.. :( I'll have to wait and see what I finally decide on..

Tallyho

Answer 8

When you're trying out Stripes, you can get started quickly with either Rayures (with Maven) or Stripes-Quickstart (with Ant).

Uhland