Diff b/w JSF 1.x and JSF 2.x

• You have more debugging help during project development. To get started with JSF 2.0, at the very least you need a web.xml with a url-pattern for *.jsf or something similar, and a faces-config.xml with valid start and end tags, just as in JSF 1.x. However, in JSF 2.0, you can optionally add a PROJECT_STAGE setting of Development to web.xml. By doing this, many errors that would silently fail in JSF 1.x now result in explicit error messages.
• Facelets, not JSP, is the standard technology for all your JSF pages. Name the pages blah.xhtml, but use the URL blah.jsf (assuming a url-pattern of *.jsf in web.xml). Use xhtml format for the pages themselves. Don't use @taglib, but instead use xmlns:h="http://java.sun.com/jsf/html". Then, use h:head, h:body, and h:form (but not usually f:view) in the page. You can find a representative sample here.
• You can use default bean names. Instead of declaring beans with managed-bean in faces-config.xml, you can put @ManagedBean above the class definition. Then, take the bean classname, change the first letter to lower case, and use that as the managed bean name. For example, if the class is package1.package2.MyBean, you would use #{myBean.whatever} in your code. You can also do @ManagedBean(name="someName"). Beans are request scoped by default, but there are annotations like @SessionScoped to change the default. This sample bean and the sample .xhtml page from above illustrate this.
• You can use default mappings of outcomes to results pages. In the absence of explicit navigation rules, the return values of the action controller method correspond to the file names that should be used. Suppose that your form (file form.xhtml, URL form.jsf) says <h:commandButton ... action="#{someBean.someMethod}"/>. When the button is pressed, the bean named someBean is instantiated (assuming request scope), setter methods corresponding to the h:inputBlah elements are run, validation occurs, and then someMethod is executed. This is the same as in JSF 1.x, except that the managed bean name (someBean) can be derived from the bean class name (SomeBean). But now, if someMethod returns "foo" and "bar", and there are no explicit navigation rules in faces-config.xml for those outcomes, then JSF will assume that they correspond to foo.xhtml and bar.xhtml (from the same folder as form.xhtml), respectively. For example, in the this sample bean, the outcomes correspond to accepted.xhtml and rejected.xhtml. In a later section on page navigation, I will argue that explicit navigation rules are probably what you will use in real projects, but the implicit navigation lets you get your app up and running more quickly, and is particularly convenient for test apps where you just want to experiment with some particular JSF 2 feature.
• You can usually use #{myBean.myProperty} instead of <h:outputText value="#{myBean.myProperty}"/>. If you don't need any fancy options, the first form is much more concise. Both forms escape HTML characters, and thus can be used for properties containing user input. You only need h:outputText when you need escape="false" or want to compute the render property or need to assign an id or want use another less-common feature of h:outputText.
• You can easily Ajaxify your application. Add xmlns:f="http://java.sun.com/jsf/core" to the page header. Inside the start and end tags for h:commandButton, put <f:ajax execute="@form" render="resultId"/>. Then, also have <h:outputText value="#{myBean.myProperty}" id="resultId"/>. This means that when the button is pressed, all the form elements are sent to the server and executed normally. Then the action controller method is executed normally. Then, the value of getMyProperty is computed and sent back to the server. JavaScript receives the value and inserts it into the current page in the place where the h:outputText element initially was. A later section covers the Ajax support in detail.
• Mere mortals can build custom components. In JSF 1.x, the existence of an API for custom components was a real boon. Because of it, a whole market for third-party component libraries developed, with PrimeFaces, RichFaces, IceFaces, Tomahawk, ADF, and Web Galileo being notable libraries. However, the API was so complex that it was more trouble than it was worth for most ordinary JSF programmers. Now, there is a very easy-to-use facelets-based (rather than Java-based) method for building simple and medium-complex components. This is somewhat analogous to the tag-file way of building JSP custom tag libraries, but even simpler and even more powerful. A later section covers composite components in detail.
• There is a powerful and relatively easy to use page templating library (better than Tiles!). JSP always had jsp:include, but it lacked a serious library for building page templates, sub-templates, and concrete pages built upon templates. However, most modern Web apps have many similar-looking pages, so templating is a must. JSF 2 has a well-thought-out, extensible, and moderately easy-to-use templating framework that is arguably even better than Apache Tiles on which it was loosely based. A later section covers page templating in detail.