This years JavaOne was filled with JSF, Ajax and even more the combination of the two. On the Pavilion several commmercial vendors were selling their ajax enriched jsf components. The blueprint team showed us the petstore. Oracle showed us how to build custom ajax enabled jsf components. And so on.
In my previous post I noted the Google Web Toolkit hadn’t landed yet completely in my java wasted brain. After four days of conference my brain is still completely wasted with java (two very positive exceptions, I saw the Ruby on Rails framework running on a java VM using JRuby! and I saw some really Groovy things a java programmer can only dream about) but I found some spare time to play with google’s new toy. While the conference only had one presentation about GWT (compare it with all those ajax and jsf sessions) the rumours/facts (find out yourself) on the internet are spreading. And somehow nobody seems to write something really interesting about JSF.
Is there a reason. Yes ofcourse. First it is the hype. GWT is new so GWT should be cool! Second, al the Ajax/JSF things are actually well known already (otherwise it would be impossible to have such a huge coverage on the conference). But between the rumours/facts I could not find out when to use JSF and when to use GWT?
Using GWT you will run into two major drawbacks. The amount of javascript that need to be downloaded will increase (lineair?) with the complexity of the interface. The KitchenSink example application is relative simple but already needs a 100kb of (compiled/generated) code. The other drawback is that your UI is fully (and I really mean fully) decoupled from your server logic. It’s like a Swing or Flash app making RPC calls. And altough very beautiful (designwise) not always as handy and productive as wanted.
GWT also has a lot of advantages. And they are obvious. No more javascript hackery. No more browser problems. All is taken care of by the toolkit. Another major advantage will be the usage of bandwidth after the application has been loaded. It will be minimized to the necessary RPC calls in order to add business functionality to the application. Which at the end will increase user experience. Using this approach state can be managed on the client (and/or in the database). And finally, the support for browser history works wonderful well.
But the biggest advantage is the fact it is a one stop shop. And here the biggest disadvantage of JSF had been mentioned. JSF is just like GWT (and Echo2 and several others) a component oriented approach for building rich web applications but it will allow you to combine several techniques together. It gives you the possibility to mix javascript library x with library y. It’s like combining Swing and SWT on the desktop. Javascript libraries are becoming the assembly languages of the web. And combining assembly languages does not feel right. (By the way, using Tapestry or Wicket this same problem can occur)
So when to use JSF and when to use GWT? I can’t answer this question. When all those beautiful JSF components provided by one and the same component vendor are being used and nothing more (not even self written ones!) JSF still seems a good choice. But if you can accept the drawbacks of GWT, I probably would recommend to at least investigate the possibilities GWT is opening up. (Or take a serious look at Echo2!)
The blueprints are back, The Petstore is back and Google smashes them exactly one hour later. What I’m talking about? This morning Sun did a presentation of their new Blueprints for Web 2.0 (sorry, it is not my choice of words) Applications. And to support their technical vision (what else is a generic blueprint) they reincarnated their Petshop. A lot of Dojo based bling bling, a lot of not easy to understand javascript and of course JSF. I also attended a session by Bruce Johnson and Joel Webber, both from Google, who presented their vision and their tool support for AJAX applications. Two complete different visions, two complete different worlds. Sun’s vision is all about their standards (JSF, EJB3), Google’s vision is focused on the regular web developer who do not understand the hairy javascript constructions needed to get a fancy interface. Sun’s vision does not look at the end-user experience at all (that is up to the developer). Google instead gives the developer the right instruments to support seamless end-user practice.
Google’s web toolkit has shown the light only one day ago and the blog-o-sphere is already filled with articles explaining what it is and what it does. So I’m not going into details (yet again standing behind a conference terminal and my back starts hurting) but I was pretty impressed by their innovative approach (They compile Java code into javascript!), their support for browser history aware ajax applications and their support for RPC (not only java based, in theory you can define the UI using Java, compile it to javascript and provide a PHP backend for service calls). The only practical problem I found after a quick scan through their website is the way they licenced the stuff. The javascript widget libraries are open source (apache based) but the actual compiler is as closed as an unlockable safe deposit box.
Of course, I’m writing this down just a few minutes after their marvelous act so the presented material still needs to land down smoothly in my java wasted brain but I’m already under the impression Sun’s blueprints might need a complete refresh.
Yesterday I visited a session by Jetbrains Dmitry Jemerov about IntelliJs’ new product called teamServer (TS-5033 : IntelliJ IDEA: Integrated Team Environment) and I really was flabbergasted by the presented material. 
Everybody knows Continous Integration is a must have in your projects and everybody also knows Continuous Integration does not work or at least does not work the way we really want it to work. TeamServer might change this. They developed it to support their own development. In other words, the developed it from the perspective of the developer (they eat their own dogfood), not the perspective of a company whos only core activity is building A continuous integration product. And just as their famous IDE(A), this product is stuffed with a lot of intelligent features that make life as easy as possible. And these features are making the difference.
One of the most remarkable features is the way they treat the check-in process. Instead of just checking-in code into the underlaying revision system, the tool is performing a build and test cycle first. So only changes that pass this phase will be added to the shared code repository. It is impossible to break the build. (Question, how many times did you do a check out of the code base and figured out the build was broken and the person responsible for this has left the building?)
Other interesting features are the way Team Server integrates with your IDE. No more bloats of email messages you never are going to read but instead nice taskbar indicators and direct pointers from (your own, not someone else’s!) build problems to actual source code. As expected the integration works for their own IDE only but there are plans to make it available as Netbeans and Eclipse plugins.
Besides the continuous integration aspects, the tool is featuring collaboration between developers also. For example, It is possible to do a diff action between your code and your coworkers code who’s sitting at the other side of the room (or worse, at the other side of the world) without using cumbersome mechanisms like e-mail or even worse, check-in/check-out.
Of course I need the proof of the pudding first but I think its worth to take a look at the the Team Server early access program site and try it.
So what if you want to develop a rich portal application, let’s use the standards!
Standards are their to make live easy for you, right…..? 
I want to create a Portal application with a rich and easy to build interface, this leads me to the following standards JSR168, the portal standard and JSR127 the JavaServer Faces specification. First of all I want to find a portal that supports this standard and does not provide to much overhead. This lead me to the JSR168 Portal Jetspeed (http://portals.apache.org/jetspeed-1/). Jetspeed 1 also provides support for JSR168 under the codename Jetspeed Fusion.
Yes there are other alternatives like Exo and Liferay that do the job but these provide to much overhead for my “simple” requirementSo the most important step is done I found myself a suitable OpenSource Portal with JSR168 support. Now we need to install it and as always Apache provides a out of the box solution including Jetspeed and Tomcat 5.0.3. The next step should be easy we need to create a rich JSR168 portlet application using JSF technology. In my opinion this should be as simple as 1.2.3. We just need to include the JSF jar into your project and start developing the portlet following the JSR168 API. After that we can just create a war-file which will be automatically deployed by Jetspeed.How wrong can one be, standards are not their to work with each other out of the box one must create a bridge for these two standards to work together. In this case I need to use the Apache Portals Bridges project ( http://portals.apache.org/bridges/ ) for these two standards to work together. The bridge consists of a generic Portlet-class which forwards your actions according to your configuration in the portlet.xml. All in all it’s not the work that triggers me but the bridging method, is this also based on any standards?? Or will we have to build bridges to support bridges?? So why do we need a non-standard bridge, which by the way impacts your flexibility to code portlets, to couple two standards? Aren’t both standards all about presentation? And why isn’t the JSF standard not supported by JSR-168 (or the other way around)? JSR-286 seems to make some promises about a tighter integration but besides to late, it is still a long way to go.So, until then we’re struck with bridges and our history has learnt us how dangerous bridges can be 
I’m currently standing behind a Sun terminal at the conference and due to the position one has to take to use the keyboard and see the screen, it is impossible to make this a lengthy entry describing everything I’ve seen and heard today.
The conference was opened by the General Session aka keynote of Sun themselves. And the message was pretty clear: Please join the JCP (we only have 1052 members) and please download and use Netbeans. Nothing more, nothing less except for some minor details like the birth of JEE 5 and the incredible impact it will have and the announcement that Java once will become really open source (quote : the question is not whether, but how). Openness matters but its clear Sun is still struggling with their other marketing exclamation: Compatibility matters.
About netbeans, two major statements were made. The first was coming from JBoss founding father Mark Fleury who declared that JBoss will support (and donate to?) the netbeans platform (Hey, is JBoss IDE not eclipse based?). The second was coming from Sun themselves declaring they will bring their Studio Creator to the open source community by donating it to Netbeans. It seems the IDE war has entered a new phase.
One other very small thing that caught my attention was about certification. Since we’re not talking J2EE anymore but JEE 5 (Still having problems pronouncing it fluently), we all need to recertificate to become JEE certified developers or architects. So for all who are planning to do their exams, please wait for the new certification program. And for those who already are certified, start reading books again!
Who doensn’t know the JavaOne Conference:) You have to be there!
May 16 - 19, 2006 Moscone Center - San Francisco, CA
My goodness, 691 speakers and 380 session all packed in 4 conference days. It’s huge, it’s massive and it’s almost impossible to pick out sessions to visit. It’s simply too much! Way too much. And even Sun’s schedule builder, an online session scheduler, won’t help. Just like a little kid in a toy store I want to play with everything!
Mission impossible. So to get organized I gave myself a theme to fill in: productivity. And within that theme I picked to major hotspots: tooling and scripting. In my very humble opinion tools can manage the overwhelming complex world we’re programming in and scripting will make the actual programming task more comfortable. Beside this theme I picked a couple of sessions that sounded just fun or had a speaker who attracted me.
So, here’s my list (exluding the general sessions and the evening Birth of Feather sessions) in order of appearance. Upfront I have no idea if I’m actually able to follow the schedule but at least it is a good intention.
- TS-4311, Inside Eclipse calisto
- TS-4386, Twelve reasons to use Sun Java Studio Creator IDE
- TS-5033, IntelliJ IDEA: Integrated Team Environment
- TS-3361, Java EE 5 Platform: Even easier with tools
- TS-1615, Java EE 5 Blueprints for AJAX-Enabled Web 2.0 Applications
- TS-3376, Java technology techniques for developing AJAX applications
- TS-3273, Groovy = Java Technology + Ruby + Python for the JVM
- TS-3059, jRuby, Bringing Ruby to the JVM Software
- TS-3886, Dynamically typed languages on the Java Platform
- TS-3187, Advanced JSF Custom components development
- TS-1660, Twelve Java Technology security traps and how to avoid them
- TS-5397, The top-10 ways to botch a J2EE based application
- TS-1382, Scripting in Java SE 6 (Codename Mustang)
- TS-3987, Crazy Talk: Examining why Agile software development works
The only session I really would have liked to attend but didn’t fit into my schedule was the session about writing a Sony Playstation emulator in Java. And the session about the building of a highly dynamic battlefield infrastructure. And the session about the robotic dune buddy called Tommy. And the session about ……
No U turn on top of the golden gate bridge ?!
