Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

I don't hate JSF

I'm still amazed by all the traffic and comments received by my experience with JSF. In some cases it feels like I insulted some of these guys wives or something. Here's some good quotes from the comments:

The less than positive experience is because Matt wants to write an app while asking a million questions all over mailing lists and not investing the time to learn.

I think you're too in love with struts to have a clear sight on what's going on.

Pick your poison and stop bad-mouthing others because you don't get.

I admit that I was a bit harsh on JSF in my post. Here's why. I developed 5 simple apps this summer, all doing the same thing with different frameworks: Struts, Spring MVC, WebWork, Tapestry and JSF. All of them hooked into the same backend, which was Spring+Hibernate. I had a learning curve to overcome with WebWork, Tapestry and JSF. I already knew Struts and Spring MVC, so those versions where easy to develop with. Of the three (WebWork, Tapestry and JSF), I was able to complete the JSF version the fastest. It took me a 1 1/2 days for WebWork, 3 days for Tapestry and 1 day for JSF. Or so I thought.

The JSF app was pretty close to being finished, but I was missing one thing - a sortable/pageable table. And I hadn't written the test for my page classes yet. This was Wednesday. I made a post late that night on how much I liked the JSF-Spring integration library. If you'll notice in this post, I mentioned that I got the displaytag to work too (almost). I found that I had to use an empty tag to pull the list of users from my page bean into the request, and then the displaytag could render the list. This was almost perfect, but the <h:commandLink> didn't work, so I had no way of editing a record from the table.

At this point, it all started to break down - and my frustration began. I was sooo close to completing this application and so far (even with the minor snags I'd hit) it was the easiest one to develop. Juergen left a comment stating that Spring's core now had a DelegatingVariableResolver in its core. So I figured I'd make my application more "pure" and use that instead of the JSF-Spring integration library. This was my first mistake. The DelegatingVariableResolver from Spring didn't work with Sun's RI and only worked with MyFaces. I figured it wouldn't be hard to switch (JSF is a standard, right?) - so I went to it the next day. I'd also heard that MyFaces had a sortable/pageable dataGrid - so the switch seemed like a good idea.

The first bump in the road was that while the DelegateVariableResolver worked, MyFaces reported an error. The Spring guys blamed MyFaces and MyFaces blamed Spring. Result: it's a bug that no one will fix. I spent a couple hours being a good open-source citizen by 1) trying to fix it and 2) reporting it. The second bumb in the road was that I had to change a few things that worked in the RI but didn't work in MyFaces (I forget what now). However, this wasn't so bad since it also fixed a couple of issues.

Next I tried to use MyFace's <x:dataTable> to replace the display tag. Since it had a sortHeader component, I figured this would be easy. It turns out this component requires you to implement custom logic in your page bean. Things might've changed since July, but I doubt it. Lastly, aftering getting everything to work, I went to work on writing a jWebUnit test to test it all. While doing so, I found that it was almost impossible to test my edit screen. With other frameworks, I could specify a URL with a record id and then proceed to change form fields and push buttons. With JSF, there was no easy way to determine the URL. The rendered UI used heavy JavaScript and when you clicked on a link in the dataTable, this called a JavaScript function. I have no problems with JavaScript and I think it's a great technology. However, the current UI testing frameworks I use (jWebUnit and Canoo WebTest) use the Rhino JavaScript library (js.jar) and it sucks at JavaScript. It reports errors where there are no errors - and hence, I tend to exclude the JAR and disable JavaScript support in my tests. If there was better JavaScript support in these testing frameworks - I'd likely have to problems with JSF's "I post for every link" mantra.

In most of my development life, I've most often been a framework user rather than a developer. This means that if I find problems, I don't extend the framework - I look for other solutions. Call me whatever you like, but I'm just trying to get my job done and the project completed. I don't want to mess with the internals of a framework to make that happen. With JSF (and Tapestry too), you have to be more of a framework developer. You have to be willing to create your own components. These frameworks are designed as component frameworks and they want you to extend them. That's one of the major points of their architecture.

So here I am again, posting about JSF - which will undoubtably get an incredible amount of hits just because it has "JSF" in the title. Why? Because you can't ignore JSF. Even if you don't want to develop with it - there's going to be tons of jobs that require JSF in the near future. In fact, there are already quite a few. Surprisingly enough, in my job search last month, I has a more opportunities for JSF (and WebWork suprisingly enough) than Struts. Finding a Tapestry gig - good luck. Of course, I'm a consultant, not an employee - so I don't often don't get to choose frameworks for companies.

I think JSF is an immature technology that will rapidly mature. I hope it does b/c it was fairly easy to develop with - there were merely some minor bugs in the two implementations. These can be fixed. In reality, I think we should all quit bashing on JSF and jump in to try and make it better. Rather than complaining, let's try to help.

I've done my part and applied to be on the JSF Expert Group. They probably won't let me in though - everyone seems to link I hate JSF. If I had my way, I'd scrap the sucker and make Tapestry the JSF standard. ;-)

Posted in Java at Oct 15 2004, 09:04:03 AM MDT 12 Comments
Comments:

You never mentioned anything about JSF enabled IDE's. That IMO is the real driver behind JSF. I know you and many others will say that you don't need a JSF enabled IDE to do JSF and you're right however JSF is being targeted at what I have heard is the "4 million VB programmers out there". Having done dotNet with Visual Studio I can understand that the only way to pull them over is with a slick IDE. I myself can' t wait to see a good JSF enabled IDE because again, having used Visual Studio and can truely see the value in RAD development with a tool like that. So do I hate JSF.... no, I just don't think it is ready to be taken out of the oven for mass consumption. Sure skilled fellows like you can develop with it with no problem but how common are developers like you out there... really... I would bet very very small. JSF will succeed, that I don't doubt the real question is when and IMO the when depends on successful JSF enabled IDE's to be produced.

Posted by Kris Thompson on October 15, 2004 at 10:33 AM MDT #

I heard a good quote the other night. JSF (and it's IDEs) are targeted at the "corporate developer", right? However, it's also a part of J2EE, right? The quote was - "Should corporate developers be developing Enterprise applications?" Kinda funny. While I think the tools support is important, I'd like to see tools support like Tapestry's Spindle - where it helps the programmer who likes to look at code, rather than just the drag and drop developer. I'd like Java Studio Creator a lot better if they'd replace it's internal server with something fast like Tomcat. Waiting for Sun's appserver to startup can be painful.

Posted by Matt Raible on October 15, 2004 at 10:39 AM MDT #

I started used Oracle ADF framework and i've got great results with a low learning curve. I know that JSF is only starting to get stable.

Posted by Flavio Leite on October 15, 2004 at 02:03 PM MDT #

No reason to be a Leming. If that is what you expereince and reaserch show you, as a consultant, you owe it to your profesion to tell the truth. What if bridge arcitects lied ? Brige would fall down.
.V

Posted by Vic on October 15, 2004 at 02:42 PM MDT #

I never understood what is so special about Visual Studio .NET. IMO it's just a normal development environment like many others. E. g. Delphi was always miles above Visual Basic (both the language and the IDE).

Posted by Lars Fischer on October 16, 2004 at 03:42 AM MDT #

I don't think it's time to hate JSF anyway... Whatever you like, JSF (even young, it's as good as struts IMHO) is now the standard way to deal with with web application providing consistent GUI. The error handling is good, and tool like Java Studio Creator help a lot. It's just (far) more productive ! I can't see a value in knowing the XML tags for Tomcat, struts, or whatever. The work is to get the job done. Moreover, I tested Java Studio Creator a little, and so far I love it.

Posted by vachor on October 16, 2004 at 05:10 PM MDT #

Matt - You are right on. It is EVEN BETTER that you didn't know the frameworks, as that is what EVERY NEW DEVELOPER has to put up with if they pick up Tapestry, WebWork, or JSF. It is better to read about your experience than someone from the expert group who ported something :) Dion

Posted by Dion Almaer on October 16, 2004 at 09:41 PM MDT #

I would second the suggestion to check out the Oracle ADF components. While it may mean you need to work on some page redesign, they already have a number of very useful, functional components and a very easy method of laying out a page in a 'standard' format. Until they make the UI more customizable, this could be a limitation, but while learning JSF is brought the frustration level down greatly having working components on hand.

Posted by sjg on October 18, 2004 at 02:03 PM MDT #

I love JSF, so far. I got my hands really dirty with JSF-Spring in the last few days trying to port the JPetStore demo app in the Spring distribution. Everything went really smooth until I decided to use the Acegi security framework to replace the security mechanism. It took me 2 days to have them integrated, because the Acegi stuff is out of faces domain and I needed to explicitly use the http session quite a bit to exchange information. All I can say is Sun RI 1.1.01 is quite stable and does almost everything by the textbook. The DI style of defining managed beans work really well with Spring, with the help of JSF-Spring library. I have never liked Struts and Tapestry's separation of web components from the HTML just adds one more layer of indirection that makes reading the "code" quite a bit of neuron activity. I have found I could read my JSF jsp pages faster than reading plain HTML or JSPs with with all those JSTL tags scatterd around. The lession is: don't mix JSF with other tag libs. JSF way is quite adequate for my little experiment. The Creator thing as of this stage is good for learning JSF, and only for that purpose. Hand coding JSF is not any worse than coding JSP. Coding and debugging JSF in Tomcat with IDEA is as smooth as anything. I still want to see how IBM Websphere Studio supports Drag'n Drop JSF development. Reading the redbook from IBM gave me the impression that IBM's implementation could be a lot advanced than Sun's Creator. From now on I'll recommend JSF to my clients.

Posted by bran on October 25, 2004 at 09:40 PM MDT #

Matt, Did you ever get the display tag to work with the commandLink? We are also experiencing this... As for myfaces, we seem to have an issue with commandLinks inside dataTables not working either,,, I hope you can lick this...If I figure it out, yu'll be the first to know. Mike

Posted by Mike Park on October 27, 2004 at 09:25 PM MDT #

Your comment that Rhino sucks is not correct. Rhino is probably the best Java implementation of a JavaScript interpreter that can be found, it has a commercially friendly license, it supports an interpreted (no bytecode generation) mode as well as a bytecode-generated mode (unlike Jython, last I checked) which can be helpful in secure environments.

JavaScript is also an international standard. When allowing users to script JavaObjects via a scripting language of your choice, future versions of your app must not break any of the assumptions that have been exposed via scripting languages, as otherwise your users' scripts may not work. This means that the language and implementation should be stable. Rhino satisfies those requirements.

Posted by Jimmy Bigknuckles on August 20, 2007 at 08:52 AM MDT #

You have to take a look at my blog at http://ihatejsf.com!!! I've been in pain from the moment I started using JSF/MyFaces and other frameworks that are connected to it. Maybe we can share some experience in this area...

Posted by Matthias Hryniszak on May 12, 2009 at 11:08 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed