JSPWiki logo
Main page
About

Getting Started

Documentation
Developers
Javadocs
Designers
Sample RSF Apps
Presentations
Acronyms

Downloads
Current Release
Trunk
Distributions
Old Versions

Community
Q&A
Forums
Mailing Lists
Issue Tracker
People

Design
Roadmap
Integrations
Concepts
Philosophy

Pages
Find
Recent Changes
Unused
Undefined
Index

Set your name in
UserPreferences

Edit this page


Referenced by
Main
RSF
UIComponent
WhyRSF




JSPWiki v2.2.33


FrameworkSize


On this page we compare the code sizes of various popular open source Java frameworks, some full web frameworks and some aimed at only part of the webapp pipeline. The point is to encourage people to get involved with living alongside the RSF source, since it is considerably more compact (and hopefully straightforward in design) than other frameworks. Part of this concision arises from the use of Spring, and other parts from the widespread use of generic (in the pre 1.5-sense) approaches based on reflective mapping rather than repeated boilerplate code. This genericism hopefully feeds through into RSF-written apps as well - the RSF Cookbook app, in contrast to most Java ORM apps contains no boring "DAO"-type code at all, only business logic (actually none in this case) and view-building logic.

RSF (0.7.2)JSF (1.1fcs)RIFE (1.2)Wicket 1.1.1Spring 1.2.7Hibernate 3.0Tapestry 4.0
Total LOC18,00060,000(API) + 80,000(RI)170,000(framework)76,000275,000157,000128,000(framework)
Servlet coupled56036,00023,00010,00019,000011,000
All of these measurements were done with the command line find . -name "*.java" | xargs cat | wc, trying to omit any test or sample code. Analysis of lines coupled to "javax.servlet" was done by counting the entirety of a file that imported it, using find . -name "*.java" | xargs grep -l "javax.servlet" | xargs cat | wc.

Clearly these measurements as with all LOC metrics are somewhat artificial. Neither RSF features nor documentation are yet fully complete - however it's worth noting what there *is* already inside RSF, which is peers for all HTML controls, both JSF and SWF-like navigation systems, a generic XML view renderer (IKAT), and an XML-driven template interpreter. I don't think bringing us to the 1.0 release point will close up the gap to the nearest frameworks considerably, on the LOC front.

Another aspect to look at is how 'little' integration code is required when RSF cooperates with another technology - here is an LOC count for the various integration libraries (the count for Servlets is included in the above):

TechnologyIntegration LOC
Java Servlets (full)560
Hibernate (full)740
Sakai (full)1765
Cocoon (partial)284
JSR-168 (full) 830
SWF 1977

The first is a figure well worth looking at - of RSF's 20k lines of code, only 560 of them have a dependence on HttpServlet. It's this sort of thing which accounts for RSF's easy mobility to other environments. The corresponding figure is 11,000 out of 128,000 for Tapestry, and 36,000/140,000 for JSF! With 36,000 lines of coupled code, it is no wonder that portlet applications of JSF struggle - note that this dependence is also *always* available to all JSF code simply through accessing the ExternalContext member of the "kitchen sink" object FacesContext. RSF selective delivery of dependencies, even at request scope, is one of its strongest architectural successes, resulting in enormously more testable and stable designs.

More discussion of code size, especially with regards to coupling, is on the UIComponent page. Code in component base classes is essentially delivered as a dependency to all the rendering code written by users - RSF is getting on for 2 orders of magnitude better than competitors in this area.


You can post comments and questions on this page using the following blog. Please set your name using UserPreferences before posting.
New entry


Go to top   Edit this page   More info...   Attach file...
This page last changed on 21-Jul-2007 02:30:30 UTC by AntranigBasman.