Editor's Desk

Tuesday Apr 23, 2013

JSF 2.2 Final Draft Approved; Java EE 7 Coming Soon

JavaServer Faces 2.2 (JSR 344) was officially approved on April 18th last week. The results were unanimous, with the exception of a couple of members whose voting rights were suspended (such as Google), and a couple that didn't vote (such as Nokia). JSF 2.2 is part of the Java EE 7 release train, which includes a bunch of other JSRs:

  • Java Persistence API (JPA) 
  • Java API for RESTful Web Services (JAX-RS) 
  • Servlets 
  • Enterprise JavaBeans (EJB)
  • JavaServer Pages 
  • Expression Language 
  • Java Messaging Service (JMS) 
  • Java API for XML-based Web Services (JAX-WS) 
  • Contexts and Dependency Injection for Java EE (CDI) 
  • Bean Validation 
  • Common Annotations (JSR-250)
  • Java Connector Architecture 

There are also a few new JSRs in Java EE 7:

Personally, I'm particularly excited about having a standard API for JSON processing and WebSocket. All of these JSRs have either been approved, or are in the final review stages. According to the Java EE 7 schedule, all of the JSRs are expected to be approved by the end of the month, and the reference implementation (Glassfish 4.0) should be out in the middle of May.

So, what about JSF 2.2? First, keep in mind that even though it's part of Java EE 7, you can still use it without the rest of the release train, although it now requires a minimum of Servlet 3.0 (which ships with Java EE 6 containers). That being said, some new features require CDI. This means that Spring shops will have to roll their own integration with Spring for these features, much like they must do today in order to support JSF's view scope with Spring.

Even though JSF 2.2 is a point release, it includes a few major features, plus several other enhancements and bug fixes. Even though HTML5 has always been supported, it's easier than ever with HTML5-friendly markup (you can now build JSF pages using HTML syntax instead of component tags). Faces flows allow you to package up navigation, pages, and code into easy-to-manage modules. Enhanced Cross-Site Request Forgery (CSRF) protection makes your applications more secure, and finally there is a standard File Upload component. Resource library contracts allow you to swap sets of templates, images, stylesheets, and JavaScript files across your application, simplifying customization for different clients or deployments. Other features include loading Facelets via the ResourceHandler, view actions, and window scope.

We'll be covering more of JSF 2.2 here at JSFCentral.com, but if you want to play with it, you can always check out the most recent Mojarra (reference implementation) snapshot (download it, or specify the Maven dependency). MyFaces isn't too far behind with their support either.


Wednesday Sep 09, 2009

JSF Summit Early Bird Discount ends Sept 21st

In case you haven't heard, JSFCentral and No Fluff Just Stuff have teamed up once again to launch the second annual JSF Summit this December 1st-4th in Sunny Orlando, FL. There's less than two weeks left before the $400 Early Bird discount ends.

[Read More]

Tuesday May 26, 2009

JSF Job Trends

Every once in a while, I run some Indeed job trend searches and post them on a blog somewhere. My last entry was about a year ago. Of course I'm not the only person doing this, but usually that's not a good reason to avoid doing something. Everybody does things differently, even queries.

So, this year, I did the obligatory JSF vs Struts comparison:

struts, (java and jsf) or "javserver faces" or "java server faces"

As you can see, JSF is eating into the Struts market share, but has quite a way to go. The query doesn't differentiate between Struts 1.0 and 2.0, though. What about Struts 2.0?

This isn't a lot of adoption, but some companies have definitely begun or augmented projects in the past few months.

What about Grails, Rails, Flex, and Wicket?

Flex is obviously doing quite well, and JSF is holding it's own. However, despite all of its hype, Ruby on Rails still doesn't employ as many people as JSF or Flex. Grails and Wicket have devoted followers, but far fewer job postings. In fact, their percentage is closer to Struts 2.0.

In terms of predicting the future, relative trends are more useful because they show how quickly the job market is growing for a particular search term. Let's look at the same graph, relative style:

So, it looks like there's reason for all of the Ruby on Rails hype after all. Let's zoom in and look at the frameworks with slower growth:

Clearly, buzz is related to growth, not overall adoption. Grails and Wicket are doing quite well in this area, while Flex and JSF grow at a slower pace.

Is JSF demand decreasing? Doubtful. With JSF 2.0, you can expect demand to grow this year (also, remember these stats are already a few months old). Traditionally, JSF has been good at eating away Struts' market share, and I see that trend continuing (especially based on my own experience training and consulting). And, as people begin experimenting with JSF and Groovy or other dynamic languages, you'll see more interest from the scripting world. 2009 should be an interesting year.

P.S. Yes, I realize I forgot Spring MVC this time around. There's always next time :-).

Thursday May 07, 2009

Are you coming to JSFOne?

Last year, in conjunction with Big Sky Technology (creators of the No Fluff Just Stuff conferences), we ran the first annual JSFOne conference in the Washington, DC area. This was the first and only US conference devoted to JavaServer Faces technology. With four tracks, it covered everything related to JSF and Seam, and brought industry experts from all over the world.

This year, we'd like to do it again. Only this time, the target time frame is early December, and we're considering hosting it in the New York City area so that it's convenient to people up and down the Northeast corridor, as well as those overseas. (If you're on the West coast or in the Midwest, we still want you to come!)

If you'd like to attend the show this year let us know -- respond to the poll below.

Tuesday May 05, 2009

Where are the Conversations?

First, I want to say I'm extremely excited about JSF 2.0, and I think it's a major leap forward for the framework.

That being said, there's one thing that's been bugging me for a while: no built-in support for conversation scope. (For those who don't know, "conversation" scope is shorter than a servlet session and longer than a request, and is popular in frameworks like Seam, Spring Web Flow, MyFaces Orchestra, etc.).

By default, JSF 2.0 will leverage the controversial JSR 299 (Java Contexts and Dependency Injection, or JCDI) specification (formerly WebBeans). JCDI provides, among other things, support for conversations in a JSF environment. Both JSF 2.0 and JCDI will be part of Java EE 6, but users of existing containers will have to download a JCDI implementation, such as WebBeans, just to use conversations.

Good luck if you only want to use conversations -- JCDI adds quite a few other features which, although powerful, add conceptual complexity.

On the bright side, JSF 2.0 supports custom scopes, so adding conversation support is something frameworks like MyFaces Orchestra can add (developers can easily add their own scopes, too). But, then again, why do frameworks need to add support for something as common as a conversation scope? To me, and many people I've talked to such as Matthias Wessendorf, this seems like a natural fit for the Servlet spec. And, for all of the useful features in Servlet 3.0, this one is sorely lacking.

So, here's the bottom line:

Conversations should be part of the Servlet spec.

And remember, I'm saying this as a member of both the JSF 2.0 and JCDI expert groups. Once again, a key part of the Java platform is not implemented consistently across different layers of the stack...

Wednesday Apr 29, 2009

Shale in the Attic

In case you hadn't heard, Apache Shale is moving to the Apache Attic. What is the Apache Attic? It's a new project, started last year. It's where other projects go to die.

According to the Apache Attic site:

It is intended to:

* Be non-impacting to users
* Provide restricted oversight for these codebases
* Provide oversight for active user lists with no Project Management Committee (PMC)

It is not intended to:

* Rebuild community
* Make bugfixes
* Make releases

Basically, if your community is dead or dying, your project is a good fit:

Projects whose PMC are unable to muster 3 votes for a release, who have no active committers or are unable to fulfill their reporting duties to the board are all good candidates for the Attic.

So, it looks like the Apache Shale developer community wasn't even strong enough to put out a release. I noticed things were quiet last year when I did a talk on the Shale Test framework at JSFOne -- the latest release was available, but no one had bothered updating the site.

If you're using Shale, don't worry too much -- as the above quotes state, the purpose of the Attic is to be "non-impacting" to users. Unfortunately, even though you'll still be able to get the bits, you can kiss any hopes of bug fixes goodbye.

What is Apache Shale?

If you're not familiar with Shale, it was one of the first projects that filled in holes in the JSF spec and added additional features such as an alternative templating mechanism, annotations, and a dialog framework. It was started by Craig McClanahan, the father of Struts and a member of the JSF 1.0 Expert Group, and originally intended to be a successor to Struts 1.0. As a matter of fact, originally it was a Struts sub project. However, the Struts community decided to merge with WebWork to form Struts 2, Shale became a top level Apache project, ant and the rest is history.

Shale includes several individual modules that could be used separately or together:

  • View Controller - Convenient mechanism to associate a "backing" Java class with each JavaServer Faces view in an application, with predefined event handlers for events significant to an application developer.

  • Dialog Manager - Mechanism to define a "conversation" with a user that requires multiple HTTP requests to implement, modeled as a state diagram.

  • Application Manager - Traditional application wide front controller features that should be applied to every request.
  • Validation - Integration with the Apache Commons Validator Framework, supporting both client side and server side validations based on a single set of configured validation rules.

  • Remoting - Server side support for applications that employ AJAX-style interactions.
  • Spring Integration - Integration with the Spring Framework, allowing the use of Spring's dependency injection framework to create JavaServer Faces managed beans.

  • Clay - An alternative to JSP where you define views in pure HTML, in a fashion similar to Tapestry and Facelets. An innovative sub-framework for supporting the configuration of reusable subtrees of JavaServer Faces components for customizable reuse.
  • Test Framework - Set of mock objects and JUnit test case base classes suitable for testing both the framework classes themselves, as well as application components built on top of the framework.

  • Tiger Extensions - Optional add-on library that adds additional ease-of-use features for Shale applications that run on Java Standard Edition 5 (popularly known by its code name during development, "tiger").

To learn more about Craig's perspective on Shale (among other things), check out this interview with Craig McClanahan.

What Happened?

The answer is quite simple: Craig lost interest and left the community.

Or, maybe it's a little more complicated: JBoss released Seam. Seam covers quite a bit of the same ground as Shale -- pretty much everything except Clay and the Application Manager. Facelets is a reasonable replacement for Clay (and more popular), and the Application Manager seemed pretty out of place from the beginning. Seam doesn't do Spring integration, but that has since been rolled into the main Spring distribution. It doesn't do client-side validation, but Ajax has diminished the demand for such a feature. Moreover, Seam is a cohesive product with the backing of JBoss and frequent releases and extensive tooling.

Seam is a full-stack framework (in other words, combined with EJB or JPA, it's all you need). However, MyFaces Orchestra provides conversation scope and view controller functionality similar to Shale, and other libraries such as MyFaces Trinidad offer some of these features as well.

So, without a driving force and facing a powerful alternatives, Shale lost its way. The most useful remaining portion, the Shale Test module, will find a happy home with the vibrant MyFaces community. Personally, I'm glad to see this -- I've spent a good deal of time, as have others, trying to move that project somewhere with a more active community.

I don't necessarily see this as a failure of Shale as a concept, though. Craig said the primary goal was to prototype new features for JSF 2.0. Perhaps it's fitting that JSF 2.0 will be out in just a couple months. And yes, many of the core features of Shale, such as annotations, resource resolution, additional scopes, and view controller functionality, and an alternative to JSP, will be in JSF 2.0. So, in some ways, Shale was a success after all.

Monday Apr 20, 2009

Oracle and Sun: JSF Comes Full Circle

So, the big news today is that Oracle is buying Sun. This is definitely the biggest thing to happen to Java since it's original release (not to mention the rest of Sun's portfolio). Overall, I believe Java is in pretty good hands. Oracle has bet their entire non-database business on Java. It's their lingua franca, the basis of the Oracle Fusion Middleware stack, which includes the entire BEA portfolio (WebLogic, Tuxedo, JRockit, etc.), JDeveloper, Coherence, and tons of other development and server products. More importantly, Fusion Middleware is the technical foundation of Oracle's next-generation Fusion product line, which includes their original business applications, plus PeopleSoft, Siebel, and JD Edwards applications.

The Fusion applications are built using Oracle ADF Faces Rich Client, and run on Fusion Middleware. So, not only is Java central to their application stack, but so is JavaServer Faces --- ADF Faces Rich Client is a suite of JSF components, built on top of the open source Apache MyFaces Trinidad component suite. ADF Faces Rich Client is so important for Oracle's strategy, they even have a site to explain how these new "Rich Enterpise Applications (REAs)" work.

So, I think we can all rest assured that JSF is in good hands -- it's a core piece of Oracle's strategic foundation. IBM, on the other hand, has less incentive to care. However, they've been making quite a few improvements to Rational Application Developer's JSF tooling over the past few releases, and they have also been contributing to MyFaces 2.0. So, given the fact that they already have quite a few JSF customers, and it's gaining market share, I don't expect that to change too much. I don't think things will change too much for JBoss/Red Hat, either, except they may no longer enjoy such a close relationship with Sun.

What's funny about the JSF RI becoming part of Oracle is that in many ways, the framework is coming full circle. JSF 1.0 was heaving influenced by Oracle UIX. ADF Faces Rich Client is, in essence, a very advanced version of UIX.

Time will tell how well this merger works out, which product lines will survive, and so on. No doubt, the landscape has changed. Let's just hope that Oracle improves the Java Community Process instead of ditching it, and that the platform remains as open and prevalent as it is today (or even more so).

Monday Sep 08, 2008

Looking back at JSFOne 2008

I had intended to write about JSFOne 2008 several times during the show, but helping with the show, working on my sessions, chatting with our excellent speakers and attendees, and plain fatigue, got in the way of that plan :-).

So, I'm sitting here in my hotel room the Monday after the conference (my last day in town), trying to figure out what to say.

When Jay Zimmerman and I setup the schedule, I thought having my Exploring the JSF Ecosystem keynote at the beginning was a good way to provide a context for the topics throughout the next couple of days. Not everyone knows about all of the UI component suites, IDE tools, and dozens of libraries and extensions available for JSF. Fortunately, my hunch turned out to be correct -- I was able to refer people to sessions that delved deeper into specific topics, and several people told me they enjoyed having my keynote first.

This was my first experience organizing a conference, and I had a funny sensation later on day one. After running around constantly all day (and the day before), I had the chance to sit in on the last few minutes of Ian Hlavats' Designing JSF user interfaces with Adobe Dreamweaver presentation. Suddenly it hit me: I invited Ian and suggested that talk. As a matter of fact, I either invited or approved all of the JSFOne speakers. And the conference was actually happening. There were three other JSFOne talks going on at that moment. Weird.

Of course, my enjoyment of the 40+ sessions was short-lived. I spent most of my "free" time recording podcasts for JSFCentral.com with several speakers, including Stan Silvert, Daniel Hinojosa, Scott O'Bryan, Martin Marinschek, Neil Griffin, and Ian Hlavatz. A few speakers slipped through the cracks, such as Keith Donald and Ed Burns, but such is life.

It's interesting interviewing several people in succession, because the personality differences jump out. Some people are very terse, others are quite the opposite; with some it's easy to establish a conversational rapport; with others, you have to pull information out of them. I know one thing's for sure: all of the interviews are interesting. And, since I upgraded my podcast recording equipment, they'll sound better too. You can expect to see them posted on JSFCentral.com over the next several months.

Even though I didn't see many sessions, I was able to bounce between the BOFs on the first night. We had four of them: MyFaces, Seam, Testing, and If I Were the Spec Lead, I Would... The latter BOF, run by JSF co-spec lead Ed Burns, drew the largest crowd. Ed asked people to get up on a pedestal and declare what they would change about JSF; he got a lot of good feedback. I emphasized the need for better error-handling for 'magic strings', such as matching action outcomes with navigation rules. Stan Silvert led up the testing BOF, where he provided some detailed info on his JSFUnit project. The Seam BOF was lead by Dan Allen, Emmanuel Berhnard, and others. Dan pointed out the differences between the Seam and Spring philosophies, while Emmanuel provided some insight on Hibernate Search and Compass (summary: competition is good). By the time I made it to the MyFaces BOF, Matthias Wessendorf, Martin Marinschek, and the attendees were already talking about beer, so I don't have too much to say about their session...

The party on Friday night was lots of fun -- it was one of several events that combined both the JSFOne and Rich Web Experience crowds. I got a chance to talk to some people about real-world deployments, which is always a good thing. Everything was going fine until Ian Hlavats bought me a strange blue drink, which I intelligently asked to be extra strong. It was all down hill after that. I vaguely remember talking about music (Ian plays flamenco guitar, I dabble in keyboards, Ed Burns plays piano, etc.) drinking tequila, and ordering more drinks. It was a fun night, but I wasn't having as much fun Saturday morning...

On Saturday, there were couple of sessions, plus a keynote from Jared Richardson on Career 2.0 and a bonus keynote from Ed Burns on Rockstar Programmers. After two-and-half days of intense UI development sessions, it was good to end on a completely different tune.

So, what else is there to say? I can talk about how bright and knowledgeable the attendees were. I can say it was great meeting the speakers I didn't know in-person, and hanging out with old friends. I can say that Jay Zimmerman and the NFJS crew did a phenomenal job pulling off the show. One thing's for sure: the show was a great success, and we're doing it again next year. Stay tuned.