After almost 7 years I’m blogging again. It feels great.
And it is good to be back in the thick of open-source action, founding a brand new project, and actively spreading the word and building a community from scratch. And the best part is the support I’m getting from my employer – Intuit.
For me personally, this is some of the best hacking I have ever done. There were times when it seemed like things magically came together. After programming for what feels like decades, the 10,000 Hour Rule feels Very Real to me now.
For those following this blog, I’m likely to be blogging over on Medium from now on.
Do have a look at my first blog post over there, and please do help spread the word !
For the last few minutes I’ve been trying to post a comment on this blog post http://raibledesigns.com/rd/entry/my_everything_you_ever_wanted and the blog engine there (Roller) throws an exception. Matt links to one of my tweets as an example of the “anger” he has inspired. Here is my response, hopefully at least the blog pingback will register.
Matt, you’ve linked to one of my tweets as an example of the “anger” you have inspired, so I’ll comment.
I have no problem with the web-frameworks comparison presentation you have been making for a while, sure, it is probably highly entertaining in a conference setting, audience participation and all. For the record, I have never agreed with some of your conclusions, having followed your legendary presentation for the last four years or so, but that is another story altogether. Just one example is the fact that you gave Apache Wicket negative marks (was that 2007 or 2008?) because you couldn’t integrate Sitemesh (of all things), and you were trying to do this the night before your presentation. Many in the Wicket community remember this incident well.
What troubles me (and many others in the community) is that you give the impression that your ratings are based on objective information, but that is not true, see this tweet from you: http://twitter.com/mraible/status/9819312227352576. What you are doing is adjusting ratings based on who in the community shouts the loudest. I can’t help saying that this approach comes across as highly arrogant and condescending, you seem to expect framework developers and proponents to rush over and fawn over you to get better ratings, like waiters in a restaurant trying to impress a food-critic for Michelin stars. If you are truly someone who is qualified to evaluate the framework relative strengths and weaknesses, you should be able to come out with your conclusions and stick to them, instead of relying on “community feedback”.
So please, by all means continue to do your web-framework comparison song and dance at conferences and the like, but please stop this charade of serving as an objective source of information on web-framework comparison. You certainly do have a reputation and level of respect in the Java EE community, and I guess there are still many development teams and stakeholders who would blindly follow your advice and recommendations, which I find highly unfortunate (for example, don’t get me started on your recent SOFEA obsession ;).
It looks like you had a great time at the Rich Web Experience, I just hope you don’t add “conference ambience” as a rating factor, because in that case other frameworks don’t stand a chance against Spring MVC and Grails. Just saying.
Anyway, for those wondering if I am anywhere near qualified to comment as Matt Raible, please have a look at some of the work I have done here for example: http://code.google.com/p/perfbench/
Here are the relative performance test results (page response time in milliseconds):
Heap-dump comparison for 20 concurrent user / sessions:
I’ll save detailed framework impressions and comparison for a later blog post, and I may need to make updates to the code based on feedback. Here are some overall observations:
Grails was far more productive than Tapestry 5. This was mainly due to the documentation quality of Grails compared to the scattered and not very well organized Tapestry documentation.
Ease of writing custom tag-libraries is IMO one of the best things about Grails.
The two missing rows in the Tapestry performance test results are because I gave up trying to implement form field validation over Ajax when the user “tabs out”. Actually I didn’t implement form-field validation at all because I could not figure out how to integrate Hibernate Validator. Maybe I missed something obvious, do let me know.
Grails still has some way to go in terms of performance. I am told that significant performance optimizations for GSP will make it into 1.2
Overall, Wicket is fastest, with Tapestry coming a close second.
Wicket also takes up the least amount of heap. 31 MB of the Grails heap alone is taken up by instances of the “groovy.lang.ExpandoMetaClass”.
Session usage of the Seam + JSF combination is significantly higher compared to all the rest, around 760 KB per session.
Thoughts on Tapestry 5
I was very interested in seeing if Tapestry 5 lived up to its promise of significantly better performance and scalability – which is known to come at a cost: a programming model that treats web-pages as static structures that can be “pooled”. One example of what this means is that you can’t rely on constructors anymore so you now have to figure out other ways of re-initializing your server-state (if applicable) after you are handed an instance from the pool. The “magic” of getting a page from the pool or getting hold of request or session scoped variables is all achieved predictably – using annotations.
Another example: due to the way Tapestry does byte-code manipulation – the annotation approach works only for “private” fields and not “protected” ones. I found this out the hard way, encountering an exception when I tried to extend from an abstract base class and re-use code the “old-fashioned” object-oriented way.
There’s a lot more I can go into, but for now, to summarize my experience as a long-time Wicket user trying out Tapestry 5 – the top few differences I found are:
Having to work around the implications of Tapestry pages being static and “annotation driven” programming like I described above.
Tapestry does not have the equivalent of Wicket Model-s which give you fine-grained control over the data you need to render (and bind) within a page and how much of it you decide to persist in the session. Model-s are certainly the aspect of Wicket that takes the most getting-used-to, but I have a new-found respect for them now after trying Tapestry.
I would rate the Ajax infrastructure of Wicket higher: for example Wicket Behavior-s are cleaner compared to Tapestry Mixin-s, and calling / handling Ajax requests (especially when you depend on server-side state) is far easier.
Tapestry 5 does not have built-in support for web-flow or “conversation scope” so I had to write some code to maintain a map of bookings in the session. BTW I did not have to do this for Grails as I could use WebFlow.
So coming back to the question, does the “Tapestry way” have a distinct advantage and are the quirks of the programming model worth it? The opinion of the Tapestry team on this is pretty clear. Take this quote from the Tapestry home page for example:
In some Tapestry-like frameworks, such as Faces and Wicket, the page structure is more dynamic, at the cost of storing much, much more data in the HttpSession.
Well, looking at the performance comparison results, my personal conclusion is that statements like the above are incorrect. In fact Tapestry seems to take up more heap space than Wicket for the same functionality. Also worth noting are the results of running the Wicket application using the HttpSessionStore instead of the default SecondLevelCacheSessionStore + DiskPageStore:
Because this time, Wicket is faster now even for the “post confirm booking” page. This particular action actually ends up displaying 200 items in an HTML table by the end of the test run for 20 concurrent users, since pagination is not being used.
The benchmark has been designed to be easy for you to run once you check-out the code, refer the end of this blog post for details. The details of the environment I used for the results posted here are as follows:
java.runtime.version : 1.6.0_16-b01
java.vm.name : Java HotSpot(TM) Server VM
java.vendor : Sun Microsystems Inc.
os.name : Windows XP
os.version : 5.1
sun.os.patch.level : Service Pack 3
Intel Core 2 Duo 3.01GHz
3 GB RAM
Feel free to post your results or suggest changes to the code.
Getting an AutoComplete JavaScript widget to work with a server-side framework involves a few more steps and integration points than what it would take for e.g. a simple date-picker widget. It makes for an interesting example that shows off the strengths of Apache Wicket when it comes to creating custom components – especially when Ajax and integrating third-party JavaScript and CSS is involved.
This tutorial covers the following topics:
Creating a re-usable Wicket custom component
How to use a Wicket Ajax “Behavior”
Integrating a third party JavaScript widget into a Wicket application
Packaging CSS and JS resources needed for the custom component
How the required CSS and JS can be contributed to the HTML <HEAD> on demand
Hooking into the Wicket Ajax life cycle
Returning custom JSON data from the Wicket server-side component
The Yahoo! User Interface Library (YUI) AutoComplete control is our target. Our example uses YUI version 2.7.0b which you can download from the YUI home page. We’ll be using Wicket 1.4 but this particular example should work unchanged in Wicket 1.3.X as well.
Note: The Wicket Extensions project includes an AutoComplete component (see it in action here) which should suffice for most of your AutoComplete needs. The YUI version arguably looks and feels richer (animation and all) and has a whole host of customizable options that are worth looking at.
You can leave the archetype parameters unchanged, and go with the default “com.mycompany” and “myproject”. Run the Maven command to generate the project structure including quick-start Java code. In the resulting “pom.xml” add the following dependency (within the <dependencies> section) so that we can use the Jackson JSON processor library for converting Java data into JSON.
Using something like Jackson means that you don’t have to worry about forming JSON by hand and dealing with things such as nesting, escaping characters etc.
Now you can import the project into your IDE. Instructions pertaining to your IDE of choice are available at the Wicket quick-start page itself. Our AutoComplete use case is to load a list of country names matching the user’s input. We’ll use the java.util.Locale class as a quick and easy data source. Create a new Java class in a “com.mycompany.util” package as follows:
public class LocaleUtils {
private static final Set<String> countries;
static {
final Locale[] locales = Locale.getAvailableLocales();
countries = new TreeSet<String>();
for(final Locale locale : locales) {
countries.add(locale.getDisplayCountry());
}
}
public static String[] getCountryNamesMatching(String query) {
List<String> list = new ArrayList<String>();
for (final String country : countries) {
if (country.toUpperCase().startsWith(query.toUpperCase())) {
list.add(country);
}
}
return list.toArray(new String[list.size()]);
}
}
And let’s also get this other utility class out of the way before we get to the really interesting stuff. Here’s the listing of “com.mycompany.util.JsonUtils” which uses Jackson to convert Java data into JSON:
public class JsonUtils {
private static final JsonFactory jf = new JsonFactory();
public static String marshal(Object o) {
StringWriter sw = new StringWriter();
try {
JsonGenerator gen = jf.createJsonGenerator(sw);
new ObjectMapper().writeValue(gen, o);
return sw.toString();
} catch(Exception e) {
throw new RuntimeException(e);
}
}
}
By looking at the simple “Basic Local Data” YUI AutoComplete sample, we can figure that the following YUI modules are needed as dependencies for the AutoComplete control:
yahoo-dom-event
animation
datasource
autocomplete
We need to copy these modules containing JS and CSS resources from the YUI downloaded distribution into our project structure. First create a “com.mycompany.yui” package where our YUI Wicket components will live. Under the “yui” folder on the file system, create a new folder called “res” (resources). Copy the folders listed above from the “yui/build” folder into the “res” folder. You should end up with something like this:
The JavaScript API documentation of the YAHOO.widget.AutoComplete component says that it requires a YAHOO.util.DataSource instance to work. For example, a LocalDataSource can be used when the data is available as an in-memory JavaScript array or JSON object. We will create a new JavaScript component that extends LocalDataSource and override the “makeConnection” method to get the data from a Wicket component over Ajax. Details of how to go about implementing “makeConnection” can be figured out by looking at the base method in “res/datasource/datasource-debug.js” – which is excerpted below for completeness:
// begin excerpt from YUI code
makeConnection : function(oRequest, oCallback, oCaller) {
var tId = DS._nTransactionId++;
this.fireEvent("requestEvent", {tId: tId, request: oRequest, callback: oCallback, caller: oCaller});
var oRawResponse = this.liveData;
this.handleResponse(oRequest, oRawResponse, oCallback, oCaller, tId);
return tId;
},
// end excerpt
In the code taken from YUI above, “oRequest” is the string the user has typed into the input text field. So it looks like after fetching the corresponding data, we need to call the “handleResponse” method to complete the flow, and the data is passed on as the “oRawResponse” method argument.
Here is the code we end up with for “WicketDataSource” which extends “LocalDataSource” the JavaScript “prototype” way and all. We re-use the “YAHOO.widget” namespace to keep things clean and reduce the risk of JavaScript name collisions:
Our implementation (override) of the “makeConnection” method uses the Wicket Ajax engine to GET data from a given URL and we pass a callback function that will call “handleResponse” once the response from the server is received. The value typed by the user is passed as as a query-string parameter “q” which will be read on the server-side.
Update: for more details on the lightweight Ajax engine and JavaScript utilities that come along with Wicket, refer this article by Nino Martinez: Wicket Javascript Internals dissected. The script.aculo.us “Drag & Drop ListEditor” example by Al Maw is another useful resource and you can get the slides and code from this page.
We could have used YUI itself to make the XMLHttpRequest but the nice thing about using the Wicket Ajax engine is that you can spy on all the action using the very nifty Ajax Debug Window in “development mode” like this:
You may be now wondering how “_this.responseArray” gets initialized once the server request completes. The “YAHOO.widget.WicketAutoComplete” (below) is a JavaScript convenience object we define to represent and wrap a single AutoComplete instance (along with the DataSource):
So if an instance of “WicketAutoComplete” has been assigned to a JavaScript variable “foo”, the responseArray can be initialized by assigning something to “foo. dataSource. responseArray”. We will take care of this in the Java code of the Wicket component, coming up shortly.
The YUI AutoComplete expects data received from the DataSource to be a JavaScript array of items. The customized “formatResult” method override above just displays each item as-is. You could implement more sophisticated routines such as bold-ing the part that matches the user input, and you can refer the YUI examples for more details. For now, we are keeping it simple, but in the future you may want to consider things like returning a multi-dimensional array or an array of JSON objects etc. from the server.
Our “WicketAutoComplete” JavaScript object constructor takes the following arguments:
inputId: HTML id of the input text field (needed by the YUI AutoComplete control)
callbackUrl: URL where the Wicket component will listen for Ajax requests, used by our custom WicketDataSource
containerId: HTML id of the <DIV> where the autocomplete results will be rendered (needed by the YUI AutoComplete control)
Take the two javascript listings above (“WicketDataSource” and “WicketAutoComplete”) and combine them into a single file called “YuiAutoComplete.js” within the “src/main/java/com/mycompany/yui” folder (or rather the “com.mycompany.yui” package). In the same folder, create “YuiAutoComplete.html” and “YuiAutoComplete.css” as follows:
The HTML and CSS files are pretty straightforward. Setting the CSS “width” of an enclosing <DIV> is the recommended way of controlling the rendered size of a YUI AutoComplete control. The YUI CSS “skin” reference “yui-skin-sam” can be even kept at the <BODY> tag level (like in the YUI examples) but here we chose to have it self contained within our component.
And finally here is the code of “com.mycompany.yui.YuiAutoComplete” that ties everything together. A description of what is going on appears below the code listing:
#33 – 39: we ensure that the required JS and CSS files are contributed to the HTML <HEAD> of any page that contains our custom component. Tip: use “debug” versions of the JS files for e.g. “autocomplete-debug.js” instead of “autocomplete-min.js” to make debugging using FireBug easier. You probably don’t need the “debug” versions for a “production” version of this component. The good thing about loading resources like this from the package / classpath is that you can simply JAR it all up for use by other teams.
#40: we output a variable declaration (global to the page) to hold a reference to our “WicketAutoComplete” JavaScript object – which can be referenced later during the Ajax request for passing data to the web page, we derive the name from the HTML id of the input TextField (#23)
#41: ensure that an instance of our WicketAutoComplete JavaScript object is instantiated (and assigned to the variable described above) when the page loads, note how the HTML id-s and Ajax “callback” URL are determined
#47: get the value of the parameter “q” in the incoming Ajax request
#50: ask Wicket to execute some JavaScript when the request completes which will (pass) assign a JSON array value back via our “WicketAutoComplete” object reference
Now the project within your IDE should look like this:
Edit the “HomePage.html” and “HomePage.java” files to use an instance of our Wicketized AutoComplete component as follows:
<html>
<head>
<title>YUI Autocomplete Demo</title>
</head>
<body>
Enter Country Name: <span wicket:id="autocomplete"></span>
</body>
</html>
public class HomePage extends WebPage {
public HomePage() {
add(new YuiAutoComplete("autocomplete", new Model("")) {
@Override
protected String[] getChoices(String query) {
return LocaleUtils.getCountryNamesMatching(query);
}
});
}
}
Note how we have implemented the “getChoices()” method to return a list of country names in this case. That should be it! Start Jetty by using the “com.mycompany.Start” class that should be under the “test” source folder structure. Browse to http://localhost:8080/ and try out your shiny new Wicket + YUI AutoComplete component.
I’ve uploaded the source code here: myproject.pdf – just rename this to a *.zip after downloading. Do comment if you spot any mistakes or stuff that can be improved.
This post is intended to be a reference for those evaluating or contemplating using JSF. Once in a while, I find myself having to convince people that there are far, far, better alternatives to JSF. With this blog post finally in place, from now on I will probably just refer people here. Please pass this link on to those you feel will benefit from this fairly large selection of links and real-life experiences collected from across the interwebs. And if you have any more such links, do let me know in the comments.
Update: [2010-01-23] – Ed Burns, co-spec lead for JSF has just posted a detailed response to this blog post here:
Readers are encouraged to also read the other side of the argument there and form their own conclusions.
My 2c:
Clearly, many architects recommend JSF as a “safe choice” for new projects just because it is a “standard”. All I’ll say is that there is more than enough evidence to prove that JSF is flawed in some significant and fundamental ways – especially compared to available alternatives.
We all know what happened to EJB 1.X / 2.X. Will JSF go the same way?
The Java Community Process (JCP) has approved a standard for building Web applications at the presentation layer, but the reaction of some programmers so far is that it adds another layer of complexity while delivering nothing they can use.
What I see in JSF is overengineering. Let’s think of every possible usage pattern for Web pages and address them, not necessarily a bad thing. The resulting standard is one in which there are several layers of abstraction, many, many moving parts, and ultimate flexibility.
[2004-06-09] Improving JSF by Dumping JSP – O’Reilly / OnJava.com article on one of the problems that has plagued JSF for a long time and many unfortunate teams (who don’t use Facelets) face even today. Keep in mind that this article is from 2004. Quote:
Don’t get me wrong: I like JSP and I like JSF. I wouldn’t have spent so much time contributing to the specifications and writing books about these technologies if I didn’t think they had value. It’s the combination of these two technologies that I don’t like, because they don’t complement each other in a natural way.
[2004-08-06] My JSF Experience – blog post by Matt Raible. Some follow up discussion here where David Geary (JSF EG member) admits that JSF is not perfect. Quote from Matt’s blog post:
Whatever you do, don’t use JSF. Not yet anyway.
[2004-09-20] Boycott JSF – blog post by Hani Suleiman (who currently happens to be a JCP Executive Committee member). Quote:
So I beg of you all, don’t use JSF, boycott it, avoid it all you can. Do not let it thrive or prosper. We don’t want it improved or tweaked, we want it to die the horrible painful death it so richly deserves.
[2005-07-??] Gradebook – Taming JSF 1.1 – an article / wiki page by Ray Davis detailing the problems faced by the Sakai project and how they had to work around some of the issues faced. The content here can be considered somewhat outdated (relates to JSF 1.1) but serves to highlight the elementary problems that JSF has had in initial versions of the spec itself. Some commentary also on other blogs here and here.
[2006-01-20] JSF Burrito: More Complete List – commentary and a list of JSF pain points by Tim Shadel. Part of a series of blog posts – read the others here, here and here. Quote:
Ultimately, JSF provides a Leaky Abstraction that (in spite of its promise) still requires all developers to understand Request-Response in addition to the 6-layer lifecycle. (”Response already committed” error, anyone?)
I’m a complete JSF newbie, and I’ve been trying to hack together a small demo app. I’ll spare you all the gory details but long story short I _hate_ JSF. Hate it, hate it, hate it. I honestly can’t imagine how anyone at Sun could ever imagine this as a competitor to ASP .NET.
A second category of annoyances in JSF consist of “nothing happened” problems. For example, if a validation error stops you from going on to Invoke Application, but you’ve forgotten to add an tag or something similar to your page, all that you see is – nothing.
[2006-05-03] Where JSF and Portlets went wrong… – blog post by Jevgeni Kabanov, founder of the company that makes JavaRebelJRebel. Some follow up discussion on JavaLobby here. Quote:
What’s worse, JSF have imposed on us a highly complex and clumsy API, that one needs to follow to achieve even a little reusability and broke the familiar way of capturing logic in custom JSP tags.
[2006-05-19] JavaOne: Google Web Toolkit vs. JSF – blog post by Bob Lee, creator of Google Guice. You can’t help thinking – if JSF is so great as the vendors / authors / evangelists would have you believe – why are there so many competing Java web-frameworks? Quote:
For the majority of intents and purposes, GWT invalidates JSF. Both frameworks seek to isolate web developers from HTTP, but due to the fact that Google built GWT from the ground up with AJAX in mind, GWT offers a cleaner abstraction, better type safety, and a lower learning curve. When it comes to AJAX and JSF, you’re at the mercy of which functionality your JSF components offer.
[2006-06-19] JSF Rough Spots – blog post by Don Brown compares JSF and Struts 2, talks about how JSF is more verbose and cumbersome to use.
JSF continues to be the most over-hyped under-used framework in Javaland. If you read the blogs of first-time users, you’ll find many complaints and issues on how things work.
[2006-09-08] JSF and RSFHistory – wiki page detailing some of the issues with JSF that led to the creation of RSF (Reasonable Server Faces). Quote:
I could go on about JSF’s other architectural deficiencies (firstly the existence of FacesContext, and secondly the global access to it which is the most utter destroyer of testability, thirdly the crazy table rendering model, fourthly the fragile and untrustable PhaseListener system, fifthly the lack of any coherent policy wrt. exceptions &c), at some length, but I will move on :P
[2006-09-13] Geebis Blog: Wicket – blog post by Caleb(?) that discusses experiences with Seam / JSF and how Wicket appears to be better. Quote:
The biggest reason is that creating custom components in JSF can be difficult, especially if you want your components to have lots of javascript/css that it contributes to the page. JSF requires that you use a writer to send your component’s HTML to the browser. With this system you end up with spaghetti code that’s hard to debug, and hard to test. Add ajax functionality to the mix and you have a featureset that JSF just can’t handle in the current version.
[2006-09-16] Tinman and the Scarecrow – blog post by Dhanji Prasanna, Google Wave Core Engineer and creator of the Google Sitebricks web-framework. Quote:
It is no secret that JSF is made for tool vendors. However, it is somewhat possible to get away with working with JSF by hand only (in fact Ive done a fairly large project this way), though this is neither on par with using tools nor easy as many proponents claim. Principally, it is not fun and doesnt offer as much reward to a developer for effort spent hitting keys.
[2006-10-19] MyFaces: The emperor has no clothes – a detailed blog post by Ignacio Coloma. Of all the many rants against JSF out there, I would pick this as my favorite. It deals with the author’s experiences with JSF on a real-life project and goes into the technical details of various issues. A must read. It looks like Ignacio Coloma was so disgusted with JSF that he later decided to create a new Java web-framework called Loom. Quote:
I do not have enough space here to explain the hell that developing a custom component is, so will leave a short summary: you will be fine if you are doing a simple stupid component that is shown as a single textfield, and there are big, red, horny demons in your way if you try anything more sophisticated.
If you keep in mind that Sun started in 2003 to talk about the JSF specification in the public, we hear and talk about JSF for three years now. If I have a look at the results, I’m a bit disappointed. This is comparable to the Swing development and the missing practical GUI designers (for years).
I liked [JSF’s] form handling and navigation support but I did not like all the javascript and extra markup that was inserted into every page without me asking for it.
[2006-12-26] not enamored by JSF 1.1 – great rant by Timothy Stone on the JavaRanch forums. The whole thread is worth reading. Quote:
The RI of JSF v1.1 hijacks and pollutes the id attribute of HTML for its own use, thus rendering CSS stylesheets almost useless and making work with the DOM in Javascript a PITA. This is probably the single greatest problem I’m staring down the barrel at.
[2007-01-01] JSF in 2007 – O’Reilly.net / ONJava article by Shashank Tiwari. This promptly triggered a lively debate on TheServerSide here.
I’m very tired, I spend the double of the time to develop this because of the problems I had to check out on the net, maybe I will wait for JSF to become better and for now use other technologies.
This article covers anti-patterns and pitfalls of day to day JSF development. Most of these issues have kept the author up at night; some of these are the same old challenges with a new face, pun intended. These challenges include performance, tight coupling, thread safety, security, interoperability and just plain ugliness.
The end impression is that it is a horribly convoluted, over-engineered framework that goes to great lengths to replace existing, well functioning technologies without addressing any of the pain-points at all.
Conclusion: don’t use JSF simply because it’s a “standard”. Use other frameworks that are more actively developed and designed for the web. For component-based frameworks, the most popular are Tapestry and Wicket. Less popular ones are RIFE and Click.
[2007-04-26] Creating a jsf div component – blog post by Andrej Koelewijn. The amount of code and effort that is required for just creating an HTML DIV is to be seen to be believed. Discussion on TheServerSide here.
[2007-05-14] A Wicket user tries JSF – a side by side comparison of JSF (MyFaces) with Wicket by Peter Thomas. Lots of discussion in the comments. Quote:
JSF is supposed to be a component oriented framework but I wouldn’t call them Java components and definitely not Object Oriented.
[2007-05-22] Rethinking JSF – The Real Problem – after a flurry of JSF-bashing blog posts appearing in early 2007, Joseph Ottinger (then editor of TSS) attempts to do some damage control. But the ensuing discussion thread is a good read with some gems in it like this one comment by Leo Lipelis that does a great job of listing and explaining a bunch of JSF issues. More discussion can be found here on the Artima forums. Quote (Leo Lipelis):
JSF multi-rendering capability — it’s an API bloat the weight of which you feel when designing custom components. Whether a project will benefit from multi-rendering or not is questionable. Why should I pay the price in terms of conceptual complexity of an API when I may not even need to use it in 99.9% of the use cases?
This is certainly no small list of challenges! JSF was built in a time when fewer client-side technologies were available, but it also seems to be targeted to projects that require less client-side interaction. If you are developing the next great web 2.0 application, you may want to consider a framework that intrudes less into the markup of the page, such as Struts or Spring.
[2007-05-25] JSF and real stuff – yet another laundry list of JSF problems outlined in this JavaLobby thread.
I still haven’t made up my mind about JSF, but we have people in our community who want to use Spring (and Spring Web Flow) and JSF, and it’s important that we accommodate that.
To put that quote in context, note that three years prior, Rod Johnson and Juergen Hoeller (Spring Framework #1 and #2) had this to say about JSF on page 408 of the book “Expert One-on-One J2EE Development without EJB” [2004, Wiley]:
Java Server Faces has been hyped as the next big thing in J2EE web development for more than two years and is now taking shape. In its current incarnation, JSF is a JSP centric affair that is heavily targeted toward GUI builder tools, resulting in code that gathers all sorts of concerns in the web page. There is no notion of view-agnostic controller and model, and no concept of pluggable views. With this programming model, JSF is well-suited for attracting .NET and other RAD developers, but not for becoming the de-facto standard web MVC framework in the Java world.
We expect to see a massive vendor marketing push behind JSF. However, we are not convinced that JSF will represent a real advance on existing open source solutions such as Tapestry, WebWork, and Spring web MVC.
[2007-06-07] c:forEach vs ui:repeat in Facelets – blog post by Roger Keays. Facelets is supposed to rescue JSF from JSP but it is not without its share of quirks !
[2007-06-11] the death of reason, professional addition – yet another blog post that suggests JSF is guilty of driving a fair number of developers away from Java. Quote:
i’ve been in a JSF class this week that has only reinforced my opinion that java web development sucks. it’s an over-engineered amalgam of crud. what i’m noticing, too, is that JSF is way behind the curve on annotations-is-the-new-xml java craze. this class has more than doubled my appreciation of ASP.NET.
I recently worked on a professional project with JSF and ran into several problems. Don’t think I didn’t try “extras”: Facelets, Seam, … In the end it just piles on complexity without solving the problems, or solving them but introducing new ones.
While I can appreciate the design ideals of component based development on the web, each of these technologies, and especially stacked, represent an abstraction above and beyond what HTTP really is that makes me sick to my stomach to think about.
JSF 1.2 (JSR 252) is targeted for JavaEE 5.0. And I don’t even see JEE 4 in every customer I go, just like JSE 5, so try to imagine when JSF 1.2 will be world wide deployed. Again, standards are cool, but they lose speed. This spec was delivered at December, 19, 2006 and alternatives like Tapestry, Echo and others, including Wicket, are improving faster than JSF since that time.
[…] with JSF — you’re farther away from the final HTML. Its the components you include on the page that generate DIV tags and so forth. Having accrued 10+ years experience working with HTML, I find this the most frustrating aspect of JSF.
[2007-10-30] Xebia Web Framework Contest – a contest where different teams had to develop the same application using different Java web-frameworks. The team using JSF really suffered. Some follow up discussion here on Matt Raible’s blog. Quote: (‘Google translated’ from French):
JSF is clearly not the most productive framework, at least not on a day because the entry cost is heavy. And even once used to the framework, one may wonder how to be productive without error recovery and ask what limits the buffer management in the framework of a real project?
The problem with all that is that the JSF Ajax implementations suck. And the learning curve for JSF (much less components) sucks. It’s just too quirky. Hopefully JSF 2.0 will make component creation easy, enable RESTful services, and will make it easier for newbies and old hands to just get things done. I’d like to hope all of that, but the only positive things I tend to hear about 2.0 are from Ed Burns, who seems like a very nice guy, but whose rhetoric reeks of corporate “gotta toe the line/I think my company is the best ever […]”
[2007-12-26] JSF 2.0 Faces Disjointed Components – SD Times article on how the “next version of JavaServer Faces aims to reduce configuration headaches”. Quote:
Sometimes, the cure for one’s woes is a hard look in the mirror. JavaServer Faces is facing up to its own configuration problems with JSR 314, the specification for JSF 2.0
The bottom line is I’ve done a lot of web applications in my career, and I would *never in a million years* choose JSF to build a web app. It’s nearly unusable. Don’t get me wrong. I am getting the project done, but that’s a testimony to my own development skills, not how great the technology is. JSF stinks.
[2008-01-11] A Year of Wicket – blog post by Julian Sinai who evaluated web technologies and chose Wicket over JSF and other contenders like Tapestry. Quote:
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.
Considerable ramp up time and tool support is a requirement to be productive. Instead of just working with standard Java and HTML, you end up locking into a particular toolset. The tools get you up and running very quickly, but you pay for the convenience since you can only build what the tool supports and they restrict how much you can do with the internal framework.
I’ve said this before that I feel that JSF is an incarnation of EJB 1.x which is overengineered and too focused on “enterprise patterns” making the simple things not so simple to implement.
[2008-04-10] JSF: A Wish List – Java Developer Journal article by Shay Shmeltzer. Quote:
Since the JSF specification doesn’t include a definition of how AJAX should be incorporated into the JSF lifecycle, each vendor/framework has its own approach to handling AJAX events, usually involving extending the JSF lifecycle. The result is that developers end up with one set of components that collides with the architecture of another set because they have different lifecycles. This must be addressed in the next release of JSF.
[2008-04-28] JSF2 – wiki page maintained at the Seam web-site on all the stuff in JSF 1.X that needs fixing in 2.0. It is painfully clear from this list how much of a raw deal JSF 1.X is. And *another* page of things to be fixed in JSF2.1 exists! Look for it somewhere below.
[2008-05-03] Game Over Java Server Faces – this was a great rant that suddenly does not seem to exist on the web anymore – so I’ve linked to the DZone entry for now. If anyone knows where this blog post can be found now – do let me know!
JSF is still a relatively new technology. JSF is undergoing a major revision for the next round of specifications with an expected integration between JSF managed beans and Enterprise JavaBeans™. The risk of changes affecting existing applications will be higher here than with other presentation technologies. IBM does have representation on the JSF expert group and will keep a watchful eye out for problems.
One area of future concern is be how well Ajax support in JSF will follow the specifications for the OpenAjax Alliance. Through its participation, IBM will try to ensure that compatibility is maintained as the standards move forward. Ajax support in JSF will be new (when it appears) and use of that feature will be at a somewhat higher risk than other parts of JSF. More details will be known in early 2009.
[2008-05-14] JSF Issues – blog post by Phill. Quote:
Although JSF does make some development quicker, the amount of time you lose to stupid problems like this probably negates any gains you made originally.
Ever since I’ve had the experience of using ASP.Net and comparing it to JSF, I’ve been hoping that someone would come up with a way to improve the sorry state of affairs that is JSF component creation. Far too much time is spent on complex components and supporting a billion renderkits, when most of the time, I just want to be able to composite a couple of preexisting controls.
I actually forgot how much JSF sucked (I remember it was hard to test). The biggest problem is that it’s been developed by someone who doesn’t use it to write real applications. It’s full of crappy implementations of concepts that seem like a good idea from an ivory tower.
No, you aren’t missing anything. JSF sucks huge monkey balls. The worst part is the convoluted, and heavy-weight response life-cycle. When it works, everything is wonderful and magic. When it doesn’t work, good luck figuring out why.
[2008-07-25] Wonderful Wicket – blog post by Sergey Grigoriev. Quote:
After I had read a book on JSF, I had impression that JSF is overcomplicated technology. Nevertheless I downloaded the latest release of ICEFaces and tried to write a simple “hello world” application with a singe button and a message area. I’ve spent two hours configuring it and six hours figuring out how to eliminate an exception.
In the most recent JSF tour, we were doing a wizard and had to bind to checkboxes. That turned into a nightmare, and for all the typical JSF reasons. JSF gets a low grade for heuristics (intuition is rarely the road to figuring things out).
How can something like JSF be promoted to be the standard? A component framework that lacks even one interesting component! That relies on third party libraries (many OSS) that are, of course, incompatible between them. Each one with a different AJAX approach (as the specification says nothing on the topic). And, worst of all, incompatible with JSP/JSTL and portlet development.
I have not read the latest JSF 2.0 draft thoroughly, but upon a quick reading of all the changes, I don’t see anything to address the basic web usage. Unless there are more changes coming that will magically fix the core without an overhaul, JSF should the follow JAX-RPC into the JSR-graveyard.
[2008-11-03] “Simple” JSF 2.0 Component vs. Tapestry – article by Howard Lewis Ship. Yes, even in the not-yet-final JSF 2.0 custom component creation leaves much to be desired. Hope this answers JSF apologists who would complain about the above list of links claiming that it is outdated and that JSF 2.0 fixes everything etc.
We’ve done only the first page of our application, and I’m really wondering if we took the right library. I believe now that in case you have a web designer in your team, you shouldn’t use libraries that generate HTML for you, like JSF or gwt, but instead use a framework allowing to generate the precise HTML the designer wants
Do you understand the JSF request phases? On a first look they look simple but in fact it is a nightmare of things happening and being dependent on each other. It is not at all easily to hook in and change the behavior.
You like JSF and you are not convinced? Then try to write a library which caches a part of your component tree to render the page faster and make sure that it works with GET and PUT requests. You will have fun, believe me.
[2009-02-25] JSF 2.1 – similar to the “JSF 2” page mentioned earlier, another page on the Seam wiki details stuff that needs to be fixed in JSF 2.1 – perhaps these are things that did not make it into 2.0 ?
[2009-04-29] Shale in the Attic – the project that Craig McClanahan (spec lead of JSF 1) started as a supplement to JSF goes “where other projects go to die”. Also see the link dated 2008-05-29 for more background. Quote:
What happened? The answer is quite simple: Craig lost interest and left the community.
[2009-05-11] JSF Nonsenses – Matthias Hryniszak starts an entire blog at http://ihatejsf.com dedicated to documenting his struggles with JSF. In his first post, he says:
Welcome to this new place in virtual space where you can express your darkest feelings about the sole nature of JSF (Java Server Faces) and other technologies that are connected to it (Facelets, JSF libraries and the like).
This blog has arose from the need to express my personal dislike for that glorious set of utilities that have made my life a misery.
[2009-05-12] JSF 2 fu, Part 1: Streamline Web application development – IBM developerworks article on the spanking new JSF 2.0. In the beginning of the article, David Geary (JSF EG member) admits that JSF 1.0 wasn’t that great. It is worth mentioning that JSF 2.0 is still not yet approved at the time of this blog post! Quote:
JSF 1 was developed in an ivory tower, and the results, arguably, were less than spectacular.
[2009-05-15] JSF Sucks (Compendium of JSF rants/reviews) – link to this blog post on DZone where there is some active discussion and also do consider voting up this link! The number and ratio of upvotes speaks for itself.
[2009-05-15] Reasons why not use JSF – someone posted a link to this blog post on the Seam forums, some discussion there. Look out for the comments from Francisco Peredo, for example this one.
[2009-05-16] “JSF sucks” on Reddit – wow, that brought a lot of traffic! Some good discussion there as well.
[..] it is not a proper component framework, let alone a complete one. It is intrinsically over engineered, yet critically underspecified. As such, it can serve as a powerful basis for a real component framework. Because of the critical parts missing it is essentially impossible to mix JSF components from various providers without including a lot of overhead and loosing a lot of consistency. Frameworks like JSF should essentially make easy things easy and hard things possible. Yet JSF’s standard components, even in JSF 2.0, fail to deliver basic One-O-One web application features from 10 years ago. It is a remarkably complex specification that delivers pretty much nothing out of the box.
[2009-11-10] JSF 2 – evaluation and test – very detailed evaluation of the brand new JSF 2.0 reference implementation (Mojarra) by Sebastian Hennebrueder and Holger Brade. Sebastian’s conclusion:
JSF looks like an old castle, where every generation added pieces, towers and buildings. I don’t blame the developers for this, as the code shows, that they know how to do a proper job. I believe that the reason for the current status of JSF is that the features are defined by a specification. The specification is industry driven with a focus on being backward compatible instead of being technology driven. Everything works somehow but always rather complex than simple. Every release makes it worse as nothing is dropped. I am sorry, but I can only see a bad ending for such a strategy.
Pages are extremely verbose. Using it make you feel being unproductive most of the time. JSF 2 brings some innovation but in a lot of areas it doesn’t even catch up with the current status of other frameworks. It is likely to be outdated before it is actually stable.
I wouldn’t use it for new projects and especially not for large enterprise projects.
Alfresco has been fairly open with the fact that their ‘Explorer’ client which is based on JSF technology is no longer being actively developed. While JSF is still around and actively used at a lot of places, it is a ‘heavier’ technology compared to a lot of whiz-bang Web 2.0 stuff. Alfresco is now investing development cycles in Alfresco Share.
Update 2:
[2010-09-09] RichFaces 4.0.0 Release Plan Updated – the long awaited release of RichFaces 4.0 final (which is supposed to support JSF 2.0) is further delayed to Feb 2011 because of “issues in the JSF specification”. Note that as of September 2010, only ONE production ready JSF 2.0 component library exists. The JSF 2.0 spec was approved well over a year back (May 2009) and was available in a draft form much earlier as is typical in the JCP.
We had hoped to get the final release of 4.0 out before the end of the year, but as mentioned previously we have run into various hurdles: These include identifying issues in the JSF 2 specification, and implementations (JSF RI, MyFaces).
Another reason I don’t like JSF: there’s very few developers in the wild happy with it. The major promoters of JSF are book authors, trainers, Java EE Vendors and MyFaces developers. Whenever I speak at conferences, I ask folks to raise their hands for the various web frameworks they’re using. I always ask the JSF users to keep their hands up if they like it. Rarely do they stay up.
Take a look at JSF. JSF is obligatory part of a full stack application server, but JSF gives you nothing. Again, you have a component model, and each vendor will provide the required runtime API. But you won‘t be happy with that, you will need a JSF library like RichFaces, ICEFaces, PrimeFaces, MyFaces, etc.
Take a good look at those. You will realize that, once you start using JSF, you are not standard anymore, you are bound to the JSF library vendor. The programming models for the components are different, the tags have different name. Switching or mixing JSF library ranges from very hard to impossible. So what good is the JSF standard for? Why is RichFaces for JSF 2.0 taking so long and how many people are developing it? Will it be there tomorrow? Will it be continued? JSF surely, but RichFaces, ICEFaces? Who can assure that?
[2010-10-26] JSF Expert Group Disbanded With No Successor JSR – pretty damning when folks outside of Sun / Oracle who have been trying heroically to fix JSF and rally the community – say that they have almost given up. If you thought that the JSF spec would get any better in terms of reducing the need for vendor-specific and proprietary extensions, think again.
According to Balunas, the expert group was still very active in their communication and development, and he doesn’t believe that dissolution of the group was necessary. He says that it will now be “very difficult” to continue supporting the Java Server Faces specification without an official JSF and EG in the JCP, mainly because there are no longer intellectual property and governance guarantees involved in JSF development if there is no current or successor JSR for JSF.
I hate JSF with a passion. And JSF was done, you know, there are a few things that were done for, I don’t know whether they were stupid reasons, they’re just, it’s just the way the world is, so, Microsoft had this thing called ASF which was angle brackets and percent signs with BASIC code there, then they are [gestures] “in-between”, right, and they go on a marketing campaign saying, “this is the greatest thing since sliced bread”, they get all the journalists to go, “ohh, that’s the greatest thing since sliced bread”, they come to us and they say, “ooh, angle brackets and percent signs and code in between, isn’t that the greatest thing since sliced bread?” What’s your answer to that? And if your answer is “that’s stupid – you know, there’s a better way to do that”, the press by and large can’t parse your sentences. And so we did do JSF as basically a clone to ASF just because it was easier to explain to the press. And then it wouldn’t die.
Update 5:
[2016-06-01] ThoughtWorks on JSF: “We […] are recommending that you avoid this technology”
ThoughtWorks on #JSF: "We continue to see teams run into trouble [..] and are recommending you avoid this technology" pic.twitter.com/hzW6PYSzVZ
A quick post to announce my new open-source project: http://flazr.com
I had done most of the coding early this year and was really feeling bad about sitting on the code and not having time to package and release as open source. Judging by the number of hits I keep getting on this blog entry I made previously on “how to download RTMP streams with Red5” – there appears to be a lot of demand for this.
Flazr is a Java implementation of the RTMP protocol using the excellent Apache Mina project. I think I was able to come up with a far more concise and readable implementation than what the Red5 project uses – which is not that surprising – because the scope of Red5 is much bigger and Flazr focuses only on the client side. I do feel that Flazr will be useful as an additional reference for those interested in understanding the details of the RTMP protocol.
One of the highlights of Flazr (especially from a Java perspective) is the usage of Groovy for scripting. Groovy allows the end-user to script things such as scraping the HTML from a given URL, parsing it and then invoking the RTMP client routine with the right parameters. All this in a platform-independent manner, without the need to compile anything and using a normal text-editor. I expect Flazr’s Groovy approach to be much easier to use (and arguably more powerful) than the PERL-driven approach that projects like “get_iplayer” and “rtmpdump” use.
Flazr has been designed so that end-users can extend the capabilities far beyond what the core supports – using just some plain-text Groovy scripts. This means that end-users won’t need to depend on the project team (*ahem* just me for now :) to pitch in and make changes. I’m quite interested to see how this turns out in practice.
All in all I’m quite positive about Groovy’s useful-ness, the example scripts that come with the Flazr distribution demonstrate usage of the nifty XmlSlurper and implementing a Java interface on-the-fly. End users should be able to even plug in third-party libraries if they so desire and make use of all that the JVM offers.
Like manyothers I really like Ant and I intend to keep using it until something better comes along. And I strongly feel that when you try to use *only* Maven for everything, you give up control over a few things.
Are there things that Ant does better than Maven? Oh yes, IMHO. Here are a few examples of typical Java web-app build related stuff that turn out to be “edge cases” in Maven meaning that you have to struggle, read up on obscure plugins or resort to ugly hacks in order to get things to work.
Replacing text in files only for development mode
<target name="jetty-setup-dev" unless="production.mode">
<echo>making webapp changes for development mode...</echo>
<replace file="target/${war.name}/WEB-INF/web.xml"
token="org.apache.wicket.protocol.http.WicketFilter"
value="info.jtrac.wicket.devmode.ReloadingWicketFilter"/>
</target>
The example above shows how I switch to a custom Wicket filter in web.xml that supports hot-class-reloading and debug logging – but only in development mode. The Ant replaceregexp task can give you even more regex driven find-and-replace goodness.
Maven apologists will promptly point you to the great Maven Assembly Plugin. Sorry, no thanks. I sincerely tried to understand how to use *that* piece of work a few times in the past but gave up in despair.
Execute an arbitrary Java class with control over everything (args, classpath, etc.)
This is a target I keep around to forward-engineer the DDL from my Hibernate entities on demand, for any database of the user’s choosing – just enter the dialect at the prompt.
There are times when even Ant may not have all the answers and a technique I use (or misuse) effectively is to use a custom Java class to extend Ant. So I don’t even need to learn how to create custom Ant tasks and mess around with the Ant classpath ensuring that the build remains “xcopy” friendly. Now, the “Maven way” to handle custom stuff is to write a custom plugin. Which is the easiest thing in the world right? Heh – don’t get me started.
There are quite a few more examples I can think of but that’s not the main point of this blog post. Hopefully I have made a case for “why Ant” above. A deal-clincher for me is the fact that all popular IDE-s have excellent support for Ant. NetBeans (which I use) takes it to a whole different level of tight integration – for e.g. you can map Ant targets to toolbars, shortcuts and things like that. Yes, IDE support for Maven is getting there but not as good as Ant IMO.
But am I saying that you shouldn’t use Maven at all? Not really. Let me explain.
For Java projects, the essential one thing that Maven does well and Ant cannot – is dependency management. So IMO the way to go is to use *both* Maven and Ant. The problem is that Maven obviously goes out of the way to *not* use Ant.
Fortunately, there *is* a way to get the information about dependencies from your Maven “pom.xml” project file across to your Ant “build.xml” file. I am referring to the Maven Ant Tasks. The thing is – there is very little documentation out there on how to use this. My conspiracy theory is that the Maven guys don’t want you to know about the existence of the Maven Ant Tasks. This is backed up by the fact that the two options for using Ant mentioned here in the official Maven FAQ cunningly avoid linking to the actual Maven Ant Tasks! (update: more than half a year after this blog post was published, the Maven FAQ was updated with a new entry “How can I use Maven features in an Ant build?” :)
I’ve explored custom plugin based approaches for bridging Maven and Ant with some success, and I’ve gotten some good feedback and even patches for the NetBeans specific integration that I tried for. I wasn’t aware of the Maven Ant Tasks until recently because as I said, the Maven guys have done a good job of making it hard to find. So I hope this post helps improve things on this front.
You need just the maven-ant-tasks JAR in “lib” as per line #03, if you are picky about that, you can even consider downloading it automatically as part of the build. You can find details on how to do that in this blog post on how to use the Maven Ant Tasks instead of Ivy by Josh Suereth (who deserves credit for some of the ideas in this post).
I prefer bootstrapping the Maven integration within a target instead of globally for the build so that targets that don’t depend on Maven can run faster. Also, I don’t have to “pollute” the entire build.xml with the XML namespace stuff, it is isolated to just within this one target.
The unless=”compile.classpath” in line #01 is a nice way to ensure that the bootstrapping happens only once even when Ant executes multiple targets that depend on each other.
Lines #04 – 06 allows the user to override the default local repository location by having a “maven.repo.local” property entry set for e.g. in “build.properties”. You can even use relative paths here – so all your dreams of having Maven builds that work even when you copy the project folders across to some other machine – can come true ;)
The rest intializes classpath and fileset variables for compile, test and runtime scopes – which should be sufficient for most WAR projects.
Something that really surprised the heck out of me is that you don’t need Maven installed for all this to work! You are getting all the benefits from a single teeny tiny JAR file. Spread the word, people!
Now you can write your compile target like this, note the ‘classpathref” on line #03:
I normally use Jetty for development (like this) so I don’t need to assemble a WAR most of the time. People who haven’t tried this really don’t know what they are missing, huge time saver – not to mention tight IDE integration for things like debugging. But when the time comes to build a WAR this is how you could do it (note the reference to the Maven fileset at line #11):
Note that I don’t even use the Ant “war” task, I just ZIP ;) Maven evangelists would have you believe that Ant leads to un-maintainable, verbose build scripts that are hard to re-use across projects. I call bullsh*t. Look at the Ant “macrodef” usage above which means that I can reuse the WAR routine and do something like this for Tomcat later:
What about Ivy?
Whoa, I never thought that this would turn out to be such a long post, let me end by addressing the question: should projects use Ivy instead?
My opinion is NO. Actually, the trigger for this blog post is that I recently joined a project-team already using Ivy and I’m having a hard time adjusting. Anyway, trying to be objective, here are my reasons:
One of the good things about Maven is that it enforces the closest thing we have in the Java world to a standard directory layout structure. I find it hilarious that Ivy falls into the same trap as Maven in that they can’t say good things about Maven just like the Maven guys avoid saying good things about Ant. So you won’t find any recommendations to use a standard project structure in the Ivy “best practices” documentation ;) Ivy projects tend to use ad-hoc directory structures, this is what I have observed.
Maven obviously has been around longer than Ivy, this translates into more documentation, more users who are used to working (and struggling ;) with it etc.
IDE project descriptor creation support: For example, Ivy has no official way to create your Eclipse project descriptor files for you. This itself would be a reason for me to avoid Ivy. There are some ways to manage your Eclipse classpath like IvyDE which honestly doesn’t have much documentation and something like this and this Google code project which don’t look too stable. If you have a Maven pom.xml and Maven installed, just do “mvn eclipse:eclipse” and you can even add “-DdownloadSources=true” – and you can ensure that even things like the “output folders” like “target/classes” and “target/test-classes” – are standard across your team.
Needless to say, using the Maven Ant Tasks approach gives you a smooth migration path to Maven. If you do it right, nothing prevents Maven die-hards on your project team from using only the pom.xml and avoiding Ant completely. This is how I have set up the JTrac build for the last 3 years.
Maven is positioned as a “project management and comprehension” tool (whatever that means ;) and there is certainly a good ecosystem of plugins that for e.g. can generate your project web-site, run Checkstyle reports, etc.
As someone already using Maven for a while, I found it really unsettling that having to use Ivy for another project was resulting in a ton of JAR duplication on my hard disk. And why on earth did the Ivy guys decide to re-invent the structure in which JAR files are stored in the local repo? So you can’t reuse your Maven repo or copy stuff around.
Something that the Ivy guys would hate to admit is that ultimately you end up downloading JARs from the Maven public repositories only. So all that talk of doing a better job than Maven kind of sounds flat. People are quick to blame Maven when resolving of dependencies fails to work as expected but this is usually the fault of whoever setup the metadata in the repositories. There’s not much that Ivy can do to solve that problem.
I think Maven multi-project support where you keep common stuff in a parent POM and have projects depend on each other is better than how you would do it in Ivy (although I haven’t explored this fully yet).
The only thing that appears to be compelling about Ivy is that doing “exclusions” is far less verbose than how you would have it in Maven. But if the Maven guys just fix this one issue …
As an example of the kind of thinking that Ivy encourages which I don’t agree with is this quote from a blog post by Dan Allen (Seam committer and author of “Seam In Action”):
But the most absolutely vital feature of Ivy, and what makes it infinitely more useful than Maven 2, is the fact that you can disable transitive dependencies.
I’m outspoken about my position on transitive dependencies. I see them as both evil and a silly device designed for novices (and people with way too much time on their hands). It makes your build non-reproducible and unstable and in the end causes you more work than the work you were attempting to eliminate by moving to Maven 2. This “feature” really is Maven’s boat anchor. Trust me on this one, it’s trivial to define which libraries your application depends on. There really aren’t that many! And you can put all the worrying aside about exclusions.
All I’ll say is that if you disable transitive dependencies, then what is the point. You might as well write a script that downloads a bunch of JAR files listed in a properties file. And about the statement that “there really aren’t that many!” – I really don’t agree. Take Seam itself as an example of a framework that has so many dependencies (and sub dependencies) and expecting developers to keep track of the sub-dependencies (instead of the project-owners who should be updating the Maven repository metadata correctly) – just seems wrong to me.
Did I miss any reasons for not using Ivy? Do let me know in the comments!
I mentioned in my previous post that I would blog about some of the things I learnt while putting together the Seam / JSF versus Wicket “perfbench“.
A while back I posted about how to start and stop Jetty from Ant – useful for those using the Jetty downloaded distribution. In this post I show how to cleanly shutdown a Jetty instance started in “embedded” mode. This tip may be useful for those using Jetty in a continuous integration build – for e.g. when Selenium tests are involved.
Update 2009-04-07: just found a blog post by Stephen Haberman that has a detailed explanation of WAR-less Development with Jetty
Here’s the code to start Jetty. The trick is to spawn a thread with a socket listening on another port (8079 in this case) that we can connect to later:
package mypackage;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.InetAddress;
import java.net.ServerSocket;
import java.net.Socket;
import org.mortbay.jetty.Connector;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.bio.SocketConnector;
import org.mortbay.jetty.webapp.WebAppContext;
public class Start {
private static Server server;
public static void main(String[] args) throws Exception {
server = new Server();
SocketConnector connector = new SocketConnector();
connector.setPort(8080);
server.setConnectors(new Connector[] { connector });
WebAppContext context = new WebAppContext();
context.setServer(server);
context.setContextPath("/wicket-jpa");
context.setWar("src/main/webapp");
server.addHandler(context);
Thread monitor = new MonitorThread();
monitor.start();
server.start();
server.join();
}
private static class MonitorThread extends Thread {
private ServerSocket socket;
public MonitorThread() {
setDaemon(true);
setName("StopMonitor");
try {
socket = new ServerSocket(8079, 1, InetAddress.getByName("127.0.0.1"));
} catch(Exception e) {
throw new RuntimeException(e);
}
}
@Override
public void run() {
System.out.println("*** running jetty 'stop' thread");
Socket accept;
try {
accept = socket.accept();
BufferedReader reader = new BufferedReader(new InputStreamReader(accept.getInputStream()));
reader.readLine();
System.out.println("*** stopping jetty embedded server");
server.stop();
accept.close();
socket.close();
} catch(Exception e) {
throw new RuntimeException(e);
}
}
}
}
The “MonitorThread” in the inner class above stops the embedded Jetty server if a line feed is received. So the code to stop Jetty is pretty simple. Here we duly send “\r\n” to port 8079:
package mypackage;
import java.io.OutputStream;
import java.net.InetAddress;
import java.net.Socket;
public class Stop {
public static void main(String[] args) throws Exception {
Socket s = new Socket(InetAddress.getByName("127.0.0.1"), 8079);
OutputStream out = s.getOutputStream();
System.out.println("*** sending jetty stop request");
out.write(("\r\n").getBytes());
out.flush();
s.close();
}
}
A while after Seam support for Apache Wicket was announced, I downloaded Seam and took a look at the Wicket example. Then an idea struck – how about doing a performance comparison – I mean, here was the very same application implemented in JSF and Wicket – right? So I decided to write a JMeter script for both the JSF and Wicket versions of the Seam “hotel booking” example and compare results. I started right away but very soon got tired of waiting for app-server re-starts on my trusty laptop (Jetty has really spoiled me) – and it kind of bothered me that the Seam examples were not in Maven 2 layout. Anyway, at some point I decided to re-write an “EJB-free” version of the Seam booking example using just Wicket and JPA. And use Maven and Jetty. And… one thing led to another – and what I ended up doing is this:
Adapted the Seam JPA example (the one that does not use EJB) as the baseline application. Converted it into a Maven 2 WAR project which can run on Jetty.
Implemented what I hope is the exact equivalent of the above using only Wicket and JPA, also Maven-ized and Jetty-fied. Decided to also experiment with some of the ideas in this blog post.
Wrote a JMeter script for both applications taking care to exercise identical functionality.
Used an Ant script to run the JMeter scripts in batch mode (passing number of concurrent users as a parameter) and start / stop Jetty in sync.
Automated the entire cycle of running the load test for 1, 5, 10, 15 and 20 concurrent users including some code to parse the JMeter logs and generate a CSV file of tabular results.
Also included an Ant target that takes a JVM heap dump at the end of the load test – just before the users are logged out and the HTTP sessions killed.
I was able to re-use the official Seam Wicket example to some extent, mainly the HTML files – but the Java side is almost completely re-written. The Seam booking example covers quite a bit of ground from the framework comparison point of view – for example:
Security – some pages are secured and redirect to a login page
Templating – some pages inherit from a common layout with a header / footer defined
Ajax –
hotel search results refresh as you type and a “busy” image is shown during the Ajax request
form field validations occur as soon as the field loses focus
Session scope – some state is stored and retrieved in the session
Page navigation / state –
user navigation state transparently managed by the framework
user should be able to work in multiple concurrent conversations (browser tabs)
the browser back button should work as expected
JPA – getting access to the entity manager and transaction management
Forms – binding, validation and displaying error / info feedback to the user
Hibernate Validator – annotations on the JPA entity classes are re-used for form-validation
Both sides use the exact same entities, persistence.xml and initial HSQLDB import. I’m using the latest Seam 2.1.1-GA and Wicket 1.3.5. Disclaimer: my Wicket code may not be ideal, and I’ve also experimented with a custom RequestCycle for JPA and tried to use inherited models as far as possible. Instructions on how you can download the source and run the scripts on your local machine are at the end of this blog post.
I may do some follow up blog posts on how the code compares between the Seam / JSF and Wicket implementations, and also share some tips on writing JMeter scripts and automation using Jetty, Ant etc. I’m also expecting to have to make corrections and changes to the code based on feedback. For now, I’ll summarize my observations on performance and memory usage.
Performance:
In the JMeter script, except for the login and logout (first two rows and last row), the actions are executed in a loop ten times for each concurrent user. So if the number of concurrent users is 20, the login and logout actions happen 20 times and the rest 20 x 10 times. The numbers below are average page response time in milliseconds.
Wicket appears to be faster by a wide margin. For two pages (“ajax post search” and “post confirm booking”) the results are a bit closer. This can possibly be explained by the fact that these particular actions display the results from a relatively expensive database query. My amateur profiling attempts suggest that the database query is taking most of the time here.
One thing I have to mention: the “cc number” and “cc name” requests are simulations of the Ajax validations of the credit card number and name fields on the booking form. For these particular requests on the JSF side, the entire form is being POST-ed instead of just the value of the form field being validated when the user tabs out (onblur). So the difference here is quite dramatic. I did try adding ajaxSingle=”true” in the JSF view but it did not appear to work (I used HttpFox while building the JMeter scripts). I can re-post the updated results if someone lets me know what changes need to be made to “book.xhtml” to get the Ajax validation to work as expected.
Memory Usage:
The JMeter script can be told to skip the logout page and I wired up one of the Ant targets to take a JVM heap dump / snapshot as soon as the JMeter script completes. So I can compare what the heap looks like just after a load test when all the concurrent HTTP sessions are alive.
I’m very much a NetBeans user but I have to say that the Eclipse Memory Analyzer is far better than what the built-in NetBeans Profiler offers for looking at JVM heap dumps. Here are some side-by-side screenshots of the heap analysis after running the JMeter script for 20 concurrent users.
“Top Consumers” report below showing the classes that dominate memory usage:
The “dominator tree” report below is very useful to see which objects hold on to the most memory directly as well as indirectly. The column headings after “Class name” are Shallow Heap, Retained Heap and Percentage. Shallow Heap means the memory consumed by a single object and Retained Heap is the sum of shallow sizes of all objects that will be garbage collected if the given object is garbage collected.
Looking at the above two reports we can infer that on the Seam / JSF side, the 20 sessions each take up about 800 KB adding up to around 16 MB total. On the Wicket side the 20 sessions add up to around 1.5 MB. On the Wicket side it is the DiskPageStore that appears to hold the most memory and we can see what is going on here after drilling down a little:
The Wicket DiskPageStore uses SoftReference-s to serialized pages so the memory will be reclaimed by the JVM if needed. And the SerializedPageWithSession holds a WeakReference to the actual page instance (MainPage). You can also spot the byte-array which is the result of page serialization. If a serialized page is requested (perhaps the user hit the browser back-button) and the page is no longer in memory because the SoftReference has been GC-ed – it will be restored from the temp file that the DiskPageStore has been saving pages to.
I’m totally impressed by the Eclipse Memory Analyzer. Here we can see the break-up of the contents of the largest HTTP session on both sides. I think we can safely blame JSF for the lion’s share of memory usage on the left:
Finally, a summary of the heap-dump comparison (for 20 users) collated from the various reports:
Create a perfbench/build.properties file that points to your JMeter installation. You can look at the comment in perfbench/build.xml for an example.
Open a command prompt, change directory to perfbench/seam-jpa
If running for the first time, use the command “ant jmeter-cycle”. The build script would prompt for the number of threads, so enter “1”. It may take time for all the required JAR files to get downloaded. Once you see Jetty start and stop successfully, you should be all set to run the actual benchmark.
To start the benchmark run “ant jmeter-cycle-full”. This should take 2 – 3 minutes to run a series of tests for 1, 5, 10, 15 and 20 concurrent users. Results will be dumped into perfbench/target. You can look at the *.csv file at the end for the results.
You can also run a load test which saves a snapshot of the heap dump towards the end by running “ant jmeter-cycle-heapdump”.
Repeat the previous 3 steps after changing working directory to perfbench/wicket-jpa
Update: perfbench/build.xml starts Jetty with JVM options “-Xms64m -Xmx64m” and you may need to change this if you want to experiment with more concurrent users.
Simplifying JavaServerFaces Development with Spring Faces – Jeremy Grelle
I was running quite late, by the time I was in for this session, Jeremy was out of the slides and busy switching between Eclipse code and the demo web-app. He was covering the “Spring centric” JSF integration approach where you use JSF backed by Spring MVC. And you can use Spring WebFlow to control stateful conversations and navigation rules.
I have used Spring WebFlow 1.0 in the distant past and I it certainly looks like the WebFlow 2.0 syntax is much simpler. It is very much a comprehensive DSL for all kinds of things though and I would guess there is a bit of learning curve. I could spot flashes of the upcoming Spring 3.0 EL++ within the on-screen webflow XML samples, e.g. “bookingService.findHotels(searchCriteria)”. Spring WebFlow appears to encourage doing as much as possible declaratively in the config. Jeremy was recommending that for e.g. instead of implementing action listeners in java code (which is nothing but “glue” code) – just do this directly in the flow definition. This is optional of course, and existing action listeners would continue to participate in the JSF life cycle as normal.
There were a couple of hiccups during the demo which Jeremy recovered from, at one point he wondered out loud if the view did not refresh as expected because of JSF quirks – keeping the whole UI component tree in memory etc.
The Spring Faces tags demos were impressive, for e.g. the rich form input validation messages that gracefully degrade. I especially liked the pop-up demo, which must have been Spring / JavaScript / Dojo behind the scenes. If getting pop-up windows to work with stateful flows, JSF and Ajax is made easier by Spring, that is indeed a Good Thing.
Client / Server Application Development using JSON SOA/REST – Kris Zyp
In this session I realized how much I did not know about what’s going on in the world of cutting edge REST / JSON / Ajax / Dojo / Comet etc. And really, aren’t these the buzzwords of the moment!! So I was glad I picked this session although at times I felt that my head would asplode from JavaScript overload. I had to Google a few unfamiliar things during the course of the session and consistently turned up blog posts written by Kris himself, he is evidently at the forefront of getting a lot of this stuff standardized. I include the relevant links below:
JsonRestStore – Dojo has a “Data Store” concept that standardizes an interface or set of APIs to read, write and even scroll through data. JsonRestStore is a data store implementation that can automatically use a given RESTful JSON service, provided it conforms to some conventions.
JSON Referencing – avoids cyclic references by using only id values with a special key to represent referenced objects – and dojo can even lazy load the whole object from the server, think of this as the JavaScript equivalent of Hibernate proxies.
JSON Schema – like XML schema but without teh suck
Bayeux – like JMS for the web – or asynchronous messages over HTTP
REST Channels – like eventing and pub-sub for the web
Spring Cleaning: Tips for Reducing XML in Spring Configuration – Craig Walls
One of the rare sessions at SpringOne coming from an experienced user rather than a Spring committer. The author of “Spring in Action“, Craig has obviously lots of experience with Spring and I did pick up a few tips. I actually attended two of his sessions back to back hoping to be cured of my allergy to annotations :) This first one covered some basics like using attributes instead of <value>, the “p” namespace, bean inheritance, property editors etc – but it appeared to be quite relevant for the audience. For e.g. I was surprised by the show of hands that not many people had seen the transaction proxy factory bean. Looks like everyone is onto namespaces and annotations nowadays.
The before and after effects for simplifying declarative transaction management were quite convincing and even more convincing was the effect of the Acegi to Spring Security makeover. Spring Security has come a long way indeed :) Craig was pretty emphatic that this is the “best security framework around, period”.
Session ended with how AOP becomes simpler using annotations instead of XML and finally a quick look at JavaConfig. One nice tip I got out of the session is that Jasypt could be used to encrypt externalized config properties like the database connection password.
Spring for the Angle-Bracket Averse: Developing Spring Applications with Absolutely No XML – Craig Walls
That was the last session in SpringOne 2008 (for me) and that’s a long title for a session :) Craig started with a quick look at some alternative contenders like Springy – I had never heard of this (but it is dead now) and the Groovy based Bean Builder. Then he dived into a sample application all done in JavaConfig with zero XML. And no, web.xml doesn’t count. Craig spent time in the IDE, making it clear how this way of configuration could appeal to a Java programmer, you get the benefits of IDE navigation, auto-complete, syntax coloring, type safety, OO, etc. Of course, there are a few annotations to remember and lots of @@@@ symbols in your code. But I guess many people would prefer this to angle brackets and this is just configuration anyway. Session ended with Craig strongly recommending that one should just try JavaConfig once, quite likely you will get hooked. The message was clear that people who used to say Spring sucks because of so much XML just can’t complain anymore.
Incremental Operations 
recent comments