How important are scripting languages to our lives? Will we use them to develop large applications someday? You might say that "scripting languages are very slow on the JVM," but the MLVM may change that scenario. [Editor's note: the data doesn't actually validate scripting languages' lack of speed. In a lot of cases, JRuby is known to be faster than CRuby already.] Creating JSF applications with JRuby and ActiveRecord-JDBC sheds some light about how much effort is necessary to create a simple aplication that uses Spring as integration point between JSF and JRuby, and don't worry about the persistence layer, because part 2 shows how to use ActiveRecord-JDBC to save data.

We recently started using Groovy in our Flex/Java based client server product for test managment. Groovy gels very well with java and feels very much like java (while Jruby is more like ruby and feels foreign). I wonder what java experts think about this. Is there a clear winner in this? -Shailesh Now, Test Management is a breeze

I wonder what java experts think about this. Is there a clear winner in this?

http://softwaremaven.innerbrane.com/2008/02/our-dynamic-language-shootout.html

We recently started using Groovy in our Flex/Java based client server product for test managment. Groovy gels very well with java and feels very much like java (while Jruby is more like ruby and feels foreign).
I wonder what java experts think about this. Is there a clear winner in this?

-Shailesh
Now, Test Management is a breeze

Hi Shailesh, I'd be curious to learn more about your integration of Groovy in your product. Could you tell us a bit more?

Forget about JSF and JRuby, Try Grails with Groovy you will not regret. Grails is like Rails but very well integrated to the Java platform using well know frameworks as Spring and Hibernate behind the scene. I'm agree Groovy feels better for Java developers than JRuby.

The world is moving in the opposite direction of JSF, especially those that are part of the ruby community. JSF is the pinnacle of over-complicated Java frameworks that the ruby community (and at this point everyone else) is moving against. Rails is as popular as it is because people are looking for a simpler way. Also if you really need java and scripting integration, groovy really is a much better fit. For final proof - look at this: def setName(name) @name = name end def getName @name end Anyone who has ever done ruby would scream if they saw it. At least groovy does getters and setters for you.

The world is moving in the opposite direction of JSF, especially those that are part of the ruby community. JSF is the pinnacle of over-complicated Java frameworks that the ruby community (and at this point everyone else) is moving against.

I think this thread has been beaten to death elsewhere. Obviously I'm going to say that developing a JSF app isn't an overcomplicated process, and if you want Rails-like productivity and CRUD, use Seam. The other point that people miss is that since JSF provides component-based abstractions, it's not tied to pure HTML, AJAX, or anything else. JSF apps have a better chance of working when the next Big Thing arrives. People have written render kits for JSF that work with Swing, telnet, and cell phones.

Also if you really need java and scripting integration, groovy really is a much better fit.

You can use the same technique for Groovy integration, because Spring supports Groovy beans as well. I did a presentation last week at JSFDays covering this. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info

The world is moving in the opposite direction of JSF, especially those that are part of the ruby community. JSF is the pinnacle of over-complicated Java frameworks that the ruby community (and at this point everyone else) is moving against.

I think this thread has been beaten to death elsewhere. Obviously I'm going to say that developing a JSF app isn't an overcomplicated process, and if you want Rails-like productivity and CRUD, use Seam.

I know this point has been beaten to death already, but would you honestly be saying this if you weren't heavily invested in JSF?

The other point that people miss is that since JSF provides component-based abstractions, it's not tied to pure HTML, AJAX, or anything else. JSF apps have a better chance of working when the next Big Thing arrives. People have written render kits for JSF that work with Swing, telnet, and cell phones.

This has got to be the worst case of YAGNI I've ever come across. So just in case something new comes along which you don't know what it is yet, you are going to invest in JSF on the off chance that someone will write a JSF renderer for this new not yet known technology which may have a use for in the dim and distant future? Thats got to be the wildest bet in years. What's the chance of it paying off? :) One thing is for sure. The lost business opportunity costs due to delayed release induced by the use of JSF over something simpler is a financial certainty. We piloted JSF over a home-grown web framework and our projected time to release increased 3 fold. Paul.

One thing is for sure. The lost business opportunity costs due to delayed release induced by the use of JSF over something simpler is a financial certainty. We piloted JSF over a home-grown web framework and our projected time to release increased 3 fold.

Paul. Paul, excellent straw man argument. I presume you meant hand coding JSF was 3x more time instead of using something like Netbeans Visual Web JSF Application + Spring? We’ve had success rapidly building applications with Netbeans. Maybe it’s your development tools or process that’s really slowing you down and not the underlying technology. I’ve replaced CachedRowSets with a Spring service layer and ObjectListDataProvider, so the WYSIWYG design of Netbeans behaves as it would with CachedRowSets.

One thing is for sure. The lost business opportunity costs due to delayed release induced by the use of JSF over something simpler is a financial certainty. We piloted JSF over a home-grown web framework and our projected time to release increased 3 fold.

Paul.

Paul, excellent straw man argument. I presume you meant hand coding JSF was 3x more time instead of using something like Netbeans Visual Web JSF Application + Spring? We’ve had success rapidly building applications with Netbeans. Maybe it’s your development tools or process that’s really slowing you down and not the underlying technology. I’ve replaced CachedRowSets with a Spring service layer and ObjectListDataProvider, so the WYSIWYG design of Netbeans behaves as it would with CachedRowSets.

Fair point. We did not exhaust all our JSF tooling options (there are quite a few you know:)). The JSF tools we did try however were not worth bothering with. Hand coding using our home-grown framework was three times faster than JSF (ICEFaces/Facelets). Paul.

Obviously I'm going to say that developing a JSF app isn't an overcomplicated process

I agree. JSF is great. I love programming in XML

Also, JSF was designed by a committee, which makes it more flexible and open. You'd think with the success of design-by-committee products like JSF and EJB2.0 that other technology companies would design products using committees. I'm talking about you Apple!

Hi :) I agree that grails is a better choice for java developers as it is closer to java. I am a java developer who make my life from writing java code but in my last personal project I evaluated both rails and grails and I decided to use rails just because of better list of plugins and support for almost anything that I wanted to do there was already a plugin(handling and resizing image attachments and sending them to amazon s3, google geo coding, indexing model objects, pagination, support for paypal and captcha on the forms). The site took me two weeks of development the url is : http://www.fastgaragesales.com. The same stuff would have took me ages to develop in java or grails. So I think at this point rails is winner because of support, community and richness of plugins than anything else. But I think groovy and jruby should work with each other and provide a same underlying runtime and programmers be able to choose either ruby or groovy (or any other language that they want). Like what microsoft is doing with CLR and C# vs VB.NET. Behrang http://www.beyondng.com

3 times slower with Java Server faces ? I may be wrong, but I have seen this many times before. This is usually the result of not picking appropriate tools to work with the framework, and becoming proficient in those tools, before you attempt an aggressive project. JSF is a base specification, which was architected on top of the functionality of the Java Servlet API, and the Java Server pages API, which is why there is some amount of awkwardness in using the framework. This is what you expect when you have these types of layers that have history and a track record tied to their existence. Most importantly JSF, it was designed to be extended! yes the world is changing, Rails, Grails and another of technologies such as Google's GWT and AJAX are changing what we consider a Web application, but that is why JSF is important, because it bridges the gaps of applications built with older JSP and Servlet technologies with a bridge to a newer component based model Front Controller architecture, which can encapsulate enhanced features such as AJAX in packaged toolkits such as Ice Faces, Rich Faces, and a large number of other options. All of these Web Specifications are being discussed to improve the overall usage of the combined stack for the JEE6 Release. To mitigate the current awkwardness of these specifications, finding and using the right tools, will dramatically increase your productivity. This is a general statement with all of the Java Specifications.. finding ways of being productive. The Netbeans Visual Web Application is a great start (Check out the integration with the Ice Faces JSF AJAX based control suite), or Eclipse's /Redhats/JBoss Jboss Jboss Tool's with Seam. Both of which would dramatically improve your productivity, once you have become familiar with the toolset. Also consider Ruby/JRuby on Rails, and Groovy / Grails, and other script or other quick Web Toolkits. There is much that can be done quickly with these tools/languages and some of which can't easily be done any other way. If partitioned correctly it matters little if your application's display medium is JSF, JSP, Rails or Grails. Groovy is Groovy :) Best of luck, and I hope this little advise us useful to someone. Tony McClay Sun Certified Enterprise Architect JEE 5 (SCEA CS-310-052) Sun Certified Business Components Developer JEE5 (SCBCD CX-310-091) Sun Certified Web Components Developer (SCWCD CX-310-081) Sun Certified Java Programmer JEE5 (SCJP CX-310-056)

Let me give a little more background. Our home grown framework is component based. Our page is a DOM in memory which we initialise from an XML template and add to dynamically. Our DOM is then translated to HTML, incorporating CSS and JavaScript using an XSLT transform prior to sending our response back to the browser. HTML components in forms posted to the server are mapped to components in our DOM via unique ids. We then programatically access our DOM (each DOM component is actually a Swing like Java Component) to read user inputs. Similar to JSF in some ways, the main difference being that the ratio between our template file size and the generated HTML is less than 1 to 10. So we have a lot less XML to write (one tenth) then we do with JSF. Now this framework is home-grown, it doesn't have all the features of JSF and it won't solve everyones problems, but it does solve our problem. And this is the point I was trying to make. By trying to cover all the bases you can end up with a framework with a feature list as long as your arm that is over-engineered and adds little value to a specific use case. And I don't want to rely on tools to address complexity that I don't need. Tools are fine until you hit a bug in the tool and then you're stuffed. You are left debugging stack traces through other peoples code without the source. Been there done that. I am not for or against JSF. I am saying that the problem comes first and the solution should come second. JSF is no silver bullet, and the fact that it supports components or renderers or what ever doesn't necessarily make JSF the right solution. Use what you need and no more (YAGNI). We could have chosen to invest in building custom JSF components at the same level of abstraction as our home-grown XML, removing the need for HTML, CSS and JavaScript in our Facelets/Jsp templates, and we may still do this. But it still begs the question why? Which is where we started out a few posts ago. Paul.

Our page is a DOM in memory which we initialise from an XML template and add to dynamically. Our DOM is then translated to HTML, incorporating CSS and JavaScript using an XSLT transform prior to sending our response back to the browser. HTML components in forms posted to the server are mapped to components in our DOM via unique ids. We then programatically access our DOM (each DOM component is actually a Swing like Java Component) to read user inputs.

Hey Paul it seems similar to ItsNat :)