Think Big

March Madness: Java Tournament Championship (AudibleSmirk Blog)

Audible Smirk has done something amusing, intriguing, and possibly useful. They created a tournament for Java frameworks, similar to the NCAA Basketball Tournament.

It started off as follows:

Java web framework tournament

March 14, 2008

I had a need to compare Java web frameworks for my personal or professional purposes. How to compare? Here’s an idea. This tournament’s creation was inspired by the workings of “March Madness,” Thirty-three frameworks (The actual NCAA tournament has 65 teams) to go head to head in successive rounds until only one is left standing.

Criteria for selection

A “committee” (me) picked the frameworks to compete, in a way inspired by the way that the NCAA committee picks basketball teams (AKA schools).

They are “Traditional” Java web frameworks, involving a Client <-> Web Page <-> Server interaction, usually Model-View-Controller or Page/View – Controller in design. Pure AJAX frameworks such as GWT or Echo2 were not considered at this time.

They must be open source frameworks. I think pretty much all are anyway.

Like the NCAA tournament, the “powerhouse” teams are of course picked, then a selection of “mid-majors”, teams that don’t compete at the powerhouse level but are considered deserving, then there are the last teams to get in – the “small frameworks” are picked. These are obscure frameworks that will get their shot in a tournament. In the NCAA tournament, these small programs are chosen instead by an earlier round of multiple tournaments.

Of course, there will be frameworks, like NCAA tournament teams, that will get in because of buzz and past reputation.

There will be a “play in” match up, just like in the NCAA tournament. Teams that barely make it in or not make it are known as “bubble” teams. If you don’t make it in, then your bubble burst. There are always complaints that a team was “robbed,” didn’t get selected for the field. There are always controversies. Simple fact is, in a 33 team tournament, only 33 teams (frameworks) can be chosen to compete in the tournament. To help counter criticism, the NCAA allowed one more team to play (making 64 into 65) by adding a “Play-in game.” The two weakest teams in the tournament play two days before the actual First Round, to reduce the field back to 64.

There will be 32 total match ups, each decided by judgment according to criteria that follows.

How the match ups are to be decided?

Good question. I see possibly:

The two frameworks that match up in each round could be judged according to these criteria (of course they are all of the committee’s)

Ease of use / learning curve

Maintainability – Code base

Support available

“Subjective” factors

Doing a sample application for each match up would be a lot of work!


The Field of 33

The play-in

————————————————

8 Loom

vs 9 Chrysalis

East

————————————————-

1 JSF

2 Struts 2 / WebWork

3 Turbine

4 Stripes

5 Mentawai

6 VRaptor

7 Maverick

Winner of the 8 – 9 play in

South

————————————————-

1 J(Ruby on Rails)

2 Struts 1

3 RIFE

4 Lift

5 Phobos

6 Waffle

7 Click

8 XX

— Meet in finals

Midwest

————————————————–

1 Spring MVC

2 Wicket

3 Cocoon

4 Trails

5 RSF (Reasonable Server Faces)

6 jZeno

7 Verge

8 Parancoe

West

—————————————————

1 Tapestry

2 Grails

3 Shale

4 Expresso

5 Helma

6 Aranea

7 Jucas

8 Roma

Here’s how they decided to do the scoring:

Java tournament scoring

March 20, 2008

Usually you compare a framework against a fixed point of reference, not really against each other. Here, two frameworks are only compared to each other using the following criteria.

They are scored by distributing the points value for each criteria under “scoring” between the two frameworks. For example,
for a - Framework 1 could get 7 points, Framework 2 would then get 11 points, adding up to 18 points. If there’s no difference between the two frameworks for a criteria, each splits the points. One criteria has an odd numbered total of points, to avoid an overtime situation.

For the last two criteria, the frameworks either get 1 point or 4 points, on whether they meet the criteria or not.

The points are added up at the end, and the winner advances.

Criteria

View - templated preferred, DOM, XHTML,
JSPs not as preferred
score: 1 - 18

AJAX support - basic support on pages for
widgets and dynamic updates  of
sections
score: 1 - 7

Documentation - adequate reference, examples,
tutorials
score: 1 - 18

Backward compatibility - do new
versions cause upgrade woes?
score: 1 - 6

Support (maintenance of project,
forums), somewhat biased toward usage
score: 1 - 18

Database integration - full stack, ORM
capabilities built in, or
recommended 3rd party framework
score: 1 - 12

Integration with rest of app
stack - Spring or POJOs for biz logic
score: 1 - 12

Internationalization (I18N) support
- message bundles
score; 1 - 6

How complex is it (more subjective
than other criteria) how many "layers".
how easy does it seem to be to learn?
score: 1 - 18

Abstraction - how well does it "hide"
the HTTP request/response model
score: 1 - 6

Separation of concerns
(MVC, MC-V, Page/C)
score: 1 - 12

Can do file upload with framework
native capability
score: 1 or 4

Can plug in SSO
score: 1 or 4
Then the matches started:

Loom 85, Chrysalis 52

March 20, 2008

Chrysalis was hurt by its use of JSPs as the (sole) view technology, as well as lack of support (the project seems to have stopped being active in 2004)

View
L: 12  C: 6

AJAX support
L: 5   C: 2

Documentation
L: 11  C: 7

Backward compatibility
L: 3   C: 3

Support
L: 14  C: 4

Database integration
L: 6   C: 6

Integration
L: 9   C: 3

Internationalization
L: 5   C: 1

How complex is it
L: 10  C: 8

Abstraction
L: 4   C: 2

Separation of concerns
L: 4   C: 8

file upload
L: 1   C: 1

plug in SSO
L: 1   C: 1

final:
Loom 85  Chrysalis 52
A whole lot of matches in the first round…

Tournament 1st round

March 26, 2008

By request….

Waffle uses JSP, or template based views. Controllers can be written in java or jruby.
RIFE is a full stack framework. It uses HTML for its views.

View
W: 9 R: 9

AJAX support
W: 2 R: 4

Documentation
W: 8 R: 10

Backward compatibility
W: 3 R: 3

Support
W: 7 R: 11

Database integration
W: 5 R: 7

Integration
W: 5 R: 7

Internationalization
W: 3 R: 3

How complex is it
W: 10 R: 8

Abstraction
W: 3 R: 3

Separation of concerns
W: 6 R: 6

file upload
W: 4 R: 4

plug in SSO
W: 1 R: 1

final:
Waffle 66 RIFE 76
Helma is server side Javascript, so it requires JS knowledge. It appears to be fairly well supported. Good support for layout.
Expresso hasn’t had a new release in over two years, its original corporate sponsor may no longer support it.
Neither really has AJAX support.

<pre>
View
H: 10 E: 6

AJAX support
H: 4 E: 3

Documentation
H: 11 E: 7

Backward compatibility
H: 3 E: 3

Support
H: 12 E: 6

Database integration
H: 4 E: 8

Integration
H: 7 E: 5

Internationalization
H: 3 E: 3

How complex is it
H: 7 E: 11

Abstraction
H: 2 E: 4

Separation of concerns
H: 6 E: 6

file upload
H: 4 E: 4

plug in SSO
H: 4 E: 1

final:
Helma 79 Expresso 67

Cocoon is designed around having flexible views from transforming XML.
Jzeno doesn’t use view templates, all UI generated by java code.

<pre>
View
C: 12 J: 6

AJAX support
C: 3 J: 4

Documentation
C: 11 J: 7

Backward compatibility
C: 2 J: 4

Support
C: 13 J: 5

Database integration
C: 8 J: 4

Integration
C: 6 J: 6

Internationalization
C: 3 J: 3

How complex is it
C: 7 J: 11

Abstraction
C: 3 J: 3

Separation of concerns
C: 5 J: 7

file upload
C: 4 J: 1

plug in SSO
C: 1 J: 1

final:
Cocoon 78 Jzeno 62

Click
ORM integration out of the box with Cayenne (JPA)
Velocity as primary view technology
Simple to develop in
Limited out of the box Ajax support
Struts 1
Tied more to HTTP model
Strong support, documentation, usage in the wild
no native Ajax support

View
C: 11 S: 7

AJAX support
C: 5 S: 2

Documentation
C: 4 S: 14

Backward compatibility
C: 3 S: 3

Support
C: 4 S: 14

Database integration
C: 7 S: 5

Integration
C: 7 S: 5

Internationalization
C: 3 S: 3

How complex is it
C: 11 S: 7

Abstraction
C: 5 S: 1

Separation of concerns
C: 7 S: 5

file upload
C: 4 S: 4

plug in SSO
C: 1 S: 1

final:
Click 72 Struts1 71

Shale is built on top of JSF and provides more a traditional controller function to create an MVC architecture.
Aranea seems to require JSP for its view. Aranea allows different MVC frameworks to “plugin”, I suppose to maintain legacy applications with it, or to use Aranea as a glue framework. Only native Aranea facilities are considered here.

<pre>
View
A: 8 S: 10

AJAX support
A: 3 S: 4

Documentation
A: 7 S: 11

Backward compatibility
A: 3 S: 3

Support
A: 7 S: 11

Database integration
A: 5 S: 7

Integration
A: 7 S: 5

Internationalization
A: 3 S: 3

How complex is it
A: 12 S: 6

Abstraction
A: 3 S: 3

Separation of concerns
A: 6 S: 6

file upload
A: 4 S: 4

plug in SSO
A: 1 S: 4

final:
Aranea 69 Shale 77

VRaptor looks like a combo of Seam, Spring, JPA.
Turbine hasn’t been actively developed in several years.
View
V: 9 T: 9

AJAX support
V: 6 T: 1

Documentation
V: 6 T: 12

Backward compatibility
V: 3 T: 3

Support
V: 9 T: 9

Database integration
V: 8 T: 4

Integration
V: 8 T: 4

Internationalization
V: 3 T: 3

How complex is it
V: 11 T: 7

Abstraction
V: 3 T: 3

Separation of concerns
V: 7 T: 5

file upload
V: 4 T: 4

plug in SSO
V: 1 T: 1

final:
VRaptor 78 Turbine 65

Verge appears to be essentially unsupported, so releases since 2004. It is now called JCatapult?? I admit, this probably shouldn’t have made the field.

<pre>
View
V: 6 W: 12

AJAX support
V: 2 W: 5

Documentation
V: 3 W: 15

Backward compatibility
V: 2 W: 4

Support
V: 3 W: 15

Database integration
V: 4 W: 8

Integration
V: 4 W: 8

Internationalization
V: 2 W: 4

How complex is it
V: 7 W: 11

Abstraction
V: 2 W: 4

Separation of concerns
V: 6 W: 6

file upload
V: 1 W: 4

plug in SSO
V: 1 W: 4

final:
Verge 43 Wicket 100

Struts 2 is a clean break from Struts 1, really an upgrade of WebWork.
maverick has been widely used and touted, but hasn’t been maintained actively snce 2004.
View
St: 9 M: 9

AJAX support
St: 6 M: 1

Documentation
St: 12 M: 6

Backward compatibility
St: 3 M: 3

Support
St: 15 M: 3

Database integration
St: 9 M: 3

Integration
St: 8 M: 4

Internationalization
St: 4 M: 2

How complex is it
St: 8 M: 10

Abstraction
St: 3 M: 3

Separation of concerns
St: 7 M: 5

file upload
St: 4 M: 1

plug in SSO
St: 4 M: 1

final:
Struts2 92 Maverick 51

Spring MVC is a part of the Spring Framework. Ajax support is possible, but not baked in.
Parancoe is a full stack, perhaps ROR inspired framework based on Spring and JPA. Strong controller/DAO design. Appears to be slow development on it. Documentation is sparse, some nice tutorial docs. Parancoe integrates DWR for Ajax support. View technologies limited to the HTML generated by the framework?
Spring here is essentially then competing with itself, in that Parancoe makes certain integration choices (DAOs, Ajax). This makes for a metaframework? For example, to use Ajax with Spring, you have many choices (as long as one can be decided upon and is supportable).

<pre>
View
S: 11 P: 7

AJAX support
S: 3 P: 4

Documentation
S: 14 P: 4

Backward compatibility
S: 3 P: 3

Support
S: 14 P: 4

Database integration
S: 6 P: 6

Integration
S: 6 P: 6

Internationalization
S: 3 P: 3

How complex is it
S: 8 P: 10

Abstraction
S: 2 P: 4

Separation of concerns
S: 5 P: 7

file upload
S: 4 P: 1

plug in SSO
S: 4 P: 4

final:
Spring 80 Parancoe 66

RSF used plain HTML through its own templating engine. Has development slowed on it? (last update on website, Sept 07). Spring integration as well.
Trails - based on Tapestry, Spring. Uses Tapestry templates. Acegi integration
<pre>
View
R: 10 T: 8

AJAX support
R: 1 T: 6

Documentation
R: 11 T: 7

Backward compatibility
R: 4 T: 2

Support
R: 9 T: 9

Database integration
R: 7 T: 9

Integration
R: 6 T: 6

Internationalization
R: 3 T: 3

How complex is it
R: 8 T: 10

Abstraction
R: 3 T: 3

Separation of concerns
R: 10 T: 8

file upload
R: 4 T: 4

plug in SSO
R: 1 T: 4

final:
RSF 77 Trails 79

Phobos is a Sun Glassfish project. It uses server side Javascript for all coding, including views.
Lift uses the Scala language( means it has to be learned). Inspired by ROR. Uses plain XHTML for views.
View
P: 11 L: 7

AJAX support
P: 5 L: 2

Documentation
P: 10 L: 8

Backward compatibility
P: 3 L: 3

Support
P: 9 L: 9

Database integration
P: 6 L: 6

Integration
P: 7 L: 5

Internationalization
P: 3 L: 3

How complex is it
P: 11 L: 7

Abstraction
P: 3 L: 3

Separation of concerns
P: 6 L: 6

file upload
P: 1 L: 1

plug in SSO
P: 1 L: 1

final:
Phobos 76 Lift 61

Mentawai supports Velocity as well as JSP for the view.
Stripes is an improved Struts in a way, with Ajax support, and Spring integration. Leans toward JSP for views.

View
M: 10 S: 8

AJAX support
M: 4 S: 3

Documentation
M: 7 S: 11

Backward compatibility
M: 3 S: 3

Support
M: 8 S: 10

Database integration
M: 6 S: 6

Integration
M: 5 S: 7

Internationalization
M: 3 S: 3

How complex is it
M: 10 S: 8

Abstraction
M: 4 S: 2

Separation of concerns
M: 7 S: 5

file upload
M: 4 S: 4

plug in SSO
M: 1 S: 1

final:
Mentawai 72 Stripes 71

Jucas is hurt because it has not been actively maintained since 2003.

<pre>
View
G: 11 J: 7

AJAX support
G: 6 J: 1

Documentation
G: 14 J: 4

Backward compatibility
G: 3 J: 3

Support
G: 14 J: 4

Database integration
G: 8 J: 4

Integration
G: 7 J: 5

Internationalization
G: 3 J: 3

How complex is it
G: 10 J: 8

Abstraction
G: 4 J: 2

Separation of concerns
G: 6 J: 6

file upload
G: 4 J: 1

plug in SSO
G: 4 J: 1

final:
Grails 93 Jucas 49

JSF
Loom
View
JSF: 11 L: 7

AJAX support
JSF: 4 L: 3

Documentation
JSF: 14 L: 4

Backward compatibility
JSF: 2 L: 4

Support
JSF: 15 L: 3

Database integration
JSF: 8 L: 4

Integration
JSF: 7 L: 5

Internationalization
JSF: 3 L: 3

How complex is it
JSF: 6 L: 12

Abstraction
JSF: 3 L: 3

Separation of concerns
JSF: 7 L: 5

file upload
JSF: 4 L: 1

plug in SSO
JSF: 4 L: 1

final:
JSF 88 Loom 55

J(Ruby on Rails)
XX uses XSL / XML processing to create the view via JSPs.

View
ROR: 10 XX: 8

AJAX support
ROR: 6 XX: 1

Documentation
ROR: 14 XX: 4

Backward compatibility
ROR: 3 XX: 3

Support
ROR: 15 XX: 3

Database integration
ROR: 8 XX: 4

Integration
ROR: 7 XX: 5

Internationalization
ROR: 3 XX: 3

How complex is it
ROR: 8 XX: 10

Abstraction
ROR: 3 XX: 3

Separation of concerns
ROR: 7 XX: 5

file upload
ROR: 4 XX: 1

plug in SSO
ROR: 4 XX: 4

final:
JROR 92 XX 54

Results after the first round:

bracket

Posted in 1 | No Comments »

Tounament Round 2:

Tournament round 2

March 31, 2008

brackets

Click
ORM integration out of the box with Cayenne (JPA)
Velocity as primary view technology
Limited out of the box Ajax support
RIFE
uses HTML templating

View
C: 9 R: 9

AJAX support
C: 2 R: 5

Documentation
C: 8 R: 10

Backward compatibility
C: 3 R: 3

Support
C: 7 R: 11

Database integration
C: 7 R: 5

Integration
C: 6 R: 6

Internationalization
C: 3 R: 3

How complex is it
C: 11 R: 7

Abstraction
C: 3 R: 3

Separation of concerns
C: 7 R: 5

file upload
C: 4 R: 4

plug in SSO
C: 1 R: 1

final:
Click 71 RIFE 72

AJAX support
ROR: 5 Ph: 2

Documentation
ROR: 13 Ph: 5

Backward compatibility
ROR: 3 Ph: 3

Support
ROR: 13 Ph: 5

Database integration
ROR: 8 Ph: 4

Integration
ROR: 5 Ph: 7

Internationalization
ROR: 3 Ph: 3

How complex is it
ROR: 9 Ph: 9

Abstraction
ROR: 4 Ph: 2

Separation of concerns
ROR: 7 Ph: 5

file upload
ROR: 4 Ph: 1

plug in SSO
ROR: 4 Ph: 1

final:
JROR 86 Phobos 57

Spring MVC is a part of the Spring Framework. Ajax support is possible, but not baked in.

Trails uses Tapestry templates for the view, as it is based on the Tapestry project. Similar to Parancoe in the 1st round, Trails is a full stack
framework based on another popular framework. Spring MVC would be compared like it was against Parancoe, is it better to use an existing full stack, or to use
Spring MVC with additions to complete the stack, especially with regards to db access and integration with business logic. Spring MVC of course, is a part of
Spring, so that integration would actually be compared in large part to that of Tapestry and how well that is implemented within Trails.
Trails also integrates with Spring, Acegi and JPA.
View
S: 10 T: 8

AJAX support
S: 4 T: 3

Documentation
S: 14 T: 4

Backward compatibility
S: 3 T: 3

Support
S: 13 T: 5

Database integration
S: 6 T: 6

Integration
S: 6 T: 6

Internationalization
S: 3 T: 3

How complex is it
S: 9 T: 9

Abstraction
S: 3 T: 3

Separation of concerns
S: 5 T: 7

file upload
S: 4 T: 1

plug in SSO
S: 4 T: 4

final:
Spring 84 Trails 62

VRaptor looks like a combo of Seam, Spring, JPA.
Struts2 and VRaptor have similar flexibility in view. Struts 2 has good Spring integration, as well as VRaptor.
View
V: 9 S: 9

AJAX support
V: 3 S: 4

Documentation
V: 8 S: 10

Backward compatibility
V: 3 S: 3

Support
V: 6 S: 12

Database integration
V: 6 S: 6

Integration
V: 6 S: 6

Internationalization
V: 3 S: 3

How complex is it
V: 10 S: 8

Abstraction
V: 4 S: 2

Separation of concerns
V: 5 S: 7

file upload
V: 4 S: 4

plug in SSO
V: 1 S: 4

final:
VRaptor 68 Struts2 78

Shale uses JSF as its view technology. Shale’s dependency on JSF increased its complexity level. Use of JSPs as the ‘default’ view was also a disadvantage.
Grails was judged to be simpler to develop in, and its template view technology was compared to using JSF/JSP.

<pre>
View
G: 11 S: 7

AJAX support
G: 5 S: 2

Documentation
G: 9 S: 9

Backward compatibility
G: 3 S: 3

Support
G: 10 S: 8

Database integration
G: 6 S: 6

Integration
G: 7 S: 5

Internationalization
G: 3 S: 3

How complex is it
G: 12 S: 6

Abstraction
G: 3 S: 3

Separation of concerns
G: 6 S: 6

file upload
G: 4 S: 4

plug in SSO
G: 4 S: 4

final:
Grails 83 Shale 66
JSF
Mentawai
View
JSF: 8 M: 10

AJAX support
JSF: 4 M: 3

Documentation
JSF: 12 M: 6

Backward compatibility
JSF: 2 M: 4

Support
JSF: 12 M: 6

Database integration
JSF: 6 M: 6

Integration
JSF: 6 M: 6

Internationalization
JSF: 3 M: 3

How complex is it
JSF: 6 M: 12

Abstraction
JSF: 3 M: 3

Separation of concerns
JSF: 6 M: 6

file upload
JSF: 4 M: 4

plug in SSO
JSF: 4 M: 1

final:
JSF 76 Mentawai 70

Helma is server side Javascript, so it requires JS knowledge. It appears to be fairly well supported. Good support for layout.
Tapestry, as one would expect, has an advantage in published documentation and support.
View
H: 8 T: 10

AJAX support
H: 2 T: 5

Documentation
H: 6 T: 12

Backward compatibility
H: 3 T: 3

Support
H: 6 T: 12

Database integration
H: 6 T: 6

Integration
H: 5 T: 7

Internationalization
H: 3 T: 3

How complex is it
H: 11 T: 7

Abstraction
H: 3 T: 3

Separation of concerns
H: 6 T: 6

file upload
H: 4 T: 4

plug in SSO
H: 4 T: 4

final:
Helma 67 Tapestry 82

Cocoon is designed around having flexible views from transforming XML. On the other hand, that adds to its complexity and limits more dynamic support.

* View
C: 7 W: 11

AJAX support
C: 2 W: 5

Documentation
C: 11 W: 7

Backward compatibility
C: 3 W: 3

* Support
C: 8 W: 10

Database integration
C: 5 W: 7

Integration
C: 5 W: 7

Internationalization
C: 3 W: 3

* How complex is it
C: 7 W: 11

Abstraction
C: 3 W: 3

Separation of concerns
C: 5 W: 7

file upload
C: 4 W: 4

plug in SSO
C: 1 W: 4

final:
Cocoon 64 Wicket 82

The Semifinals:

Tournament semifinals

April 3, 2008

jft-brackets-4.jpg
J(Ruby on Rails) is a Ruby on Rails running on a java implementation of Ruby.
It is a complete stack framework, strongly MVC.
Documentation and support a real strength here.
Need to learn Ruby to use this.
Uses ActiveRecord for ORM integration.
Ruby templates for view.

RIFE
Full stack framework as well, uses more of a component model.
HTML templates for view.
Contains persistence layer.
Can use Spring for IoC support.

View
ROR: 8 RIFE: 10

AJAX support
ROR: 4 RIFE: 3

Documentation
ROR: 11 RIFE: 7

Backward compatibility
ROR: 3 RIFE: 3

Support
ROR: 12 RIFE: 6

Database integration
ROR: 7 RIFE: 5

Integration
ROR: 5 RIFE: 7

Internationalization
ROR: 3 RIFE: 3

How complex is it
ROR: 11 RIFE: 7

Abstraction
ROR: 3 RIFE: 3

Separation of concerns
ROR: 7 RIFE: 5

file upload
ROR: 4 RIFE: 4

plug in SSO
ROR: 4 RIFE: 1

final:
JROR 81 RIFE 65
Spring MVC is a part of the Spring Framework.
Ajax support needs to be added, hooks for this

Wicket
has Ajax support, support for Dojo
Wicket documentation suffers, not as many published books
Wicket almost a pure Java code, HTML template based framework, little XML or other configuration
View
S: 9 W: 9

AJAX support
S: 2 W: 5

Documentation
S: 11 W: 7

Backward compatibility
S: 3 W: 3

Support
S: 11 W: 7

Database integration
S: 5 W: 7

Integration
S: 6 W: 6

Internationalization
S: 3 W: 3

How complex is it
S: 7 W: 11

Abstraction
S: 3 W: 3

Separation of concerns
S: 5 W: 7

file upload
S: 4 W: 4

plug in SSO
S: 4 W: 4

final:
Spring 73 Wicket 76
Tapestry
component model, often compared to JSF
has bundled Dojo integration, supports JSON natively
backward compatibility of releases an issue
has its own templating view technology
has its own IOC integration with Hivemind (changed with upcoming release?)

Grails
MVC model, much based on ROR
has its own templating view technology (GSP)
based on Spring MVC and Spring, Hibernate for ORM
need to learn Groovy
GORM - built in ORM based on Hibernate

View
G: 9 T: 9

AJAX support
G: 2 T: 4

Documentation
G: 8 T: 10

Backward compatibility
G: 4 T: 2

Support
G: 9 T: 9

Database integration
G: 8 T: 4

Integration
G: 7 T: 5

Internationalization
G: 3 T: 3

How complex is it
G: 11 T: 7

Abstraction
G: 3 T: 3

Separation of concerns
G: 6 T: 6

file upload
G: 4 T: 4

plug in SSO
G: 4 T: 4

final:
Grails 78 Tapestry 70

JSF
Component based, page-component architecture
supports Ajax through 3rd party components such Ajax4JSF or other libraries.
View -use JSPs or other view implemetnations such as JSFTemplate or most commonly Facelets

Struts 2
MVC architecture, view/controller architecture
Ajax support via GWT integration (need to know GWT)
View - use JSP, velocity

Complexity hurts JSF.
Struts 2 can be used with JSF as the ‘view’, more limited documentation but can be done

View
JSF: 8 S2: 10

AJAX support
JSF: 4 S2: 3

Documentation
JSF: 9 S2: 9

Backward compatibility
JSF: 2 S2: 4

Support
JSF: 10 S2: 8

Database integration
JSF: 6 S2: 6

Integration
JSF: 7 S2: 5

Internationalization
JSF: 3 S2: 3

How complex is it
JSF: 7 S2: 11

Abstraction
JSF: 4 S2: 2

Separation of concerns
JSF: 6 S2: 6

file upload
JSF: 4 S2: 4

plug in SSO
JSF: 4 S2: 4

final:
JSF 74 Struts2 75

The Final Four:

Java Tournament Final Four

April 7, 2008 

Grails
MVC model, much based on ROR
has its own templating view technology (GSP)
based on Spring MVC and Spring, Hibernate for ORM
need to learn Groovy, discounting this though for the comparison.
GORM - built in ORM based on Hibernate

Wicket
has Ajax support, support for Dojo
Wicket documentation suffers, not as many published books
Wicket almost a pure Java code, HTML template based framework, little XML or other configuration
ORM not built in
View
G: 8  W: 10

AJAX support
G: 3   W: 4

Documentation
G: 10  W: 8

Backward compatibility
G: 3  W: 3

Support
G: 10  W: 8

Database integration
G: 8   W: 4

Integration
G: 6   W: 6

Internationalization
G: 3   W: 3

How complex is it
G: 11  W: 7

Abstraction
G: 3   W: 3

Separation of concerns
G: 6   W: 6

file upload
G: 4   W: 4

plug in SSO
G: 4   W: 4

final:
Grails 79  Wicket 70

Struts 2 is a clean break from Struts 1, really an upgrade of WebWork.
MVC architecture, view/controller architecture
Ajax support via GWT integration (need to know GWT)
View - can use JSP, velocity
J(Ruby on Rails) is a Ruby on Rails running on a java implementation of Ruby.
It is a complete stack framework, strongly MVC.
Documentation and support a real strength here.
Need to learn Ruby to use this.
Uses ActiveRecord for ORM integration.
Ruby templates for view.

View
St: 10  JROR: 8

AJAX support
St: 3   JROR: 4

Documentation
St: 9  JROR: 9

Backward compatibility
St: 3  JROR: 3

Support
St: 8   JROR: 10

Database integration
St: 5   JROR: 7

Integration
St: 6   JROR: 6

Internationalization
St: 3   JROR: 3

How complex is it
St: 8   JROR: 10

Abstraction
St: 2   JROR: 4

Separation of concerns
St: 7   JROR: 5

file upload
St: 4   JROR: 4

plug in SSO
St: 4   JROR: 4

final:
Struts2 72    JROR 77
And the Championship:

Java Tournament Championship

April 8, 2008

These two competitors are pretty much mirrors of the other.

Ruby on Rails, the highly regarded (and publicized) is a full stack framework
based on the Ruby language. It features an easy to use ORM implementation called ActiveRecord.
It is strongly MVC.
Documentation and support a real strength here.
Need to learn Ruby to use this. (both finalists are based on a scriptig language)
Uses ActiveRecord for ORM integration.
Ruby templates for view.

Grails is a relatively new framework based on Groovy, a Java implementation scripting language designed to be most
like Java itself while providing the advantages of a dynamically typed language.
MVC model, much based on ROR
has its own templating view technology (GSP)
based on Spring MVC and Spring, Hibernate for ORM
need to learn Groovy
GORM - built in ORM based on Hibernate

View
ROR: 9 G: 9

AJAX support
ROR: 4 G: 3

Documentation
ROR: 10 G: 8

Backward compatibility
ROR: 3 G: 3

Support
ROR: 10 G: 8

Database integration
ROR: 5 G: 7

Integration
ROR: 5 G: 7

Internationalization
ROR: 3 G: 3

How complex is it
ROR: 9 G: 9

Abstraction
ROR: 3 G: 3

Separation of concerns
ROR: 6 G: 6

file upload
ROR: 4 G: 4

plug in SSO
ROR: 4 G: 4

final:
JROR 75 Grails 74

Grails loses to JRuby on Rails by 1 (one) point! Aw!

Filed under: News, SpringSource.

Comments are closed.