JAX India 2007 – Bangalore day 3

Below is the coverage of todays sessions and my takeaways. The slides for all presentations are available here.

JSF and AJAX : Best of Friends (by Craig McClanahan, SUN Microsystems)

• The motive was to convey various means of achieving AJAX while using JSF. Though all means are workarounds in my opinion. JSF specification should have built-in support for AJAX. It lost out in this front because of the delay in finalizing the specification and AJAX peaking up during the same time.
• The means are : (a) DIY (Do It Yourself) (b) Use JSF components with native AJAX (c) Wrap client side JS libraries (d) Make non-JSF calls to the web server.
• DIY – Most JSF components have JS event methods. Leverage that along with own JS methods and XMLHttpRequest or other client side JS toolkit like Dojo, Prototype or Scriptaculus. Involves lot of work. Implementing page refresh might be tricky.
• JSF with native AJAX – Components take care of making async calls and updating DOM. Simpler to use. Loads of OSS and commercial ajaxified JSF components available. e.g ADFFaces, MyFaces, etc
• Wrap JS libs – Strongly suggested Jmaki which wraps different client side AJAX libraries like dojo, prototype etc.
• Make non-JSF calls – You can choose to use any of the AJAX libraries and make them talk to a servlet directly instead of going thru the JSF life cycle. Handling the component tree update will be tricky.
• choose any of the above options based on whether you need to keep the component tree in sync with the DOM updates.

Should you adopt/migrate to Struts 2.0? (by Harshad Oak, Rightrix Solutions)

• Provides an overview of new features of Struts in 2.0 release. Its basically like Struts 1 + WebWork = Struts 2.
• Features include annotation support, interceptors through servlet filters, convention over configuration, derive method name from URL, concept of value stack, new tag libraries, a Guice based minimal DI container to integration with Spring, no form beans etc
• Integration points for Spring, AJAX frameworks like dojo, GWT etc.
• Package names now contain com.opensymphony.*.
• Migration from Struts 1 to Struts 2 is difficult because of such drastic changes but migration from Webwork is lot easier.

My opinion – its a mess now, it is dieing. The code code sample he shown looked lot messier, a result of merging two frameworks. The author himself seemed directionless like the framework and mostly tried to highlight that the framework supports all the buzz words in web framework market these days. Guess Webwork is banking on Strut’s image now to sell itself. Pity for both of them. Good for us (developers) since we have two frameworks less to worry about now.

Can tools improve even a power geeks productivity? (by Craig McClanahan, SUN Microsystems)

• Brings out the point that geeks who like playing with their good old editors using the combination of hot keys and the keyboard, can be more productive if the IDE has appropriate features.
• Few features that makes a java IDE good are – documentation lookup, refactoring, real time debugging, unit testing support, version control support, database administration, deployment, generate boiler plate and plumbing code, allow maven / ant structuring, integrate runtime dependencies, heterogeneous programming language support, generate skeleton OR mapping and support for popular frameworks etc.
• Demonstrated Netbeans IDE supporting these features, though he named Eclipse in the context. So i would not say that we was solely pushing the SUN product by throwing a catchy session title.

You can’t just buy an Open Source community (by Neelan Choksi, COO Interface21)

• This talk was to highlight that all the commercial vendors taking the open source route to stay in business will not succeed. They can not buy the community by open sourcing their products e.g OpenJDK, OpenJPA, JBuilder etc etc.
• The only sensible thing he talked about – Community is the most important factor in success of open source projects. You need to build community and their are few approaches to do that.

Otherwise the talk was complete waste of time. More focused on picking up failures from rivals and quoting Interface21 as the rightest thing to ever happen. The less you write about his presentation skills, on stage persona and language command the better it is for Interface21. An instance of catchy title but patchy content.

Why is everyone so excited about Ruby-on-Rails (by Neal Ford, Thoughtworks)

• Title says it all – marketing of RoR. However i still wanted to attend to see whats inside RoR. And to be honest, i was taken aback, throughly surprised with zillions of questions shooting here n there in my mind.
• Few features – RAD development (they mean it, needs to be seen if it works in enterprise apps), agility, instant feedback, OR mapping via ActiveRecord, no compile/deploy etc, scaffolding, testing generation, web 2.o support etc.
• Follows standard folder structure which helps in getting rid of configuration files, making safe assumptions. Generates method code at runtime based on need.
• Recommends Streamlines, a 3rd party scaffolding library.
• Admits it slowness now but expects drastic improvements in next release.

my thoughts – this is a completely different way of developing web apps. Given the productivity features and all the buzz around it, i feel the time has come for a try on it for an agile development project.

SOA: The future of distributed computing? (by Neal Ford, Thoughtworks)

• I am not a SOA fanboy but attended it since none other parallel session were any better. Not sure if i followed him properly but i guess he started with bashing SOA and ended with the note that it has the best chance to work this time for distributed computing.
• One should download the slides from his website and go thru it. Its pretty humorous and informative at the same time.

Overall, one key point to note is that the audience is much more patient and lenient while listening to the established speakers as against the local ones. I had expected more skilled and professional audience since most of them are at architect or designer level. But few basic ethics like allowing the speaker to cover the topic before asking ahead or out of context questions, things like limiting conversations to certain iterations etc were clearly missing and thus few of the sessions were reduced to mere show-off events than for knowledge exchange.

SUN Technology summit 07 – Bangalore

It started with a keynote address by Scott McNealy. Few points that he brought out were,

> Moore’s Law is not good enough. We are progressing even faster.

> Focus on social networking and community building. He is seeing huge opportunity there. Mentioned about Curriki, the one of its kind online curriculum and other related stuff, free and open source.

> Showcases UltraSparc T2, slated to be released in few months time. Requested developers to write multi threaded applications to make real use of the processing power offered by these advanced chips.

> Requests greater participation by Indian IT professionals in java communities. According to him, 25% of the members of SUN developer network are Indian, so at least 25% of the source code contribution should be from them.

> Showcases grid computing platform Network.com. First 100 hrs CPU time free, 1 USD for each subsequent hour. Suggests moving of data centers to its super computer grid.

> Talked about JavaFX accepting competition from Apollo while failing to remember the M$ offering in this area (Silverlite). Tried to justify “yet another scripting language” in JavaFX from SUN. Says, 90% of cellphones already run java. JavaFX mobile technologies to leverage on it while providing a fully integrated java stack in cellphones.

> All the while he did stress on the point that almost all offerings from SUN is now FREE and Open Source. He didn’t forget to name Java SE, Netbeans, GlassFish, OpenSolaris and others as OSS products at every opportunity.

> Speaks about Derby and PostgreSQL.

Overall his speech was more of SUN marketing and Microsoft bashing with occasional statistics. I was expecting few lines on future plans on technologies but i was disappointed.

Sessions:

There were a good numbers of sessions squeezed in a short time span of 4 hours. Topics were in expected lines, like Java EE 5, GlassFish, OpenSolaris, Java DB, Dtrace, AJAX and Web 2.0 (not sure how much SUN contributes in this area) and Netbeans etc. Except for a couple of sessions all others were a mere slide rush-thru. The sessions were more of a platform to throw jargons than to discuss anything serious about the subjects. Surprisingly there was no session on JavaFX neither a single mention of Groovy anywhere.

Speakers:

None worth taking note except for the session on Dtrace. Most of them were IT kids, may be with just couple of years of experience in industry. They obviously lacked presentation skills, thus killing the interest in the subject. The most disappointing of all was the session from “Suresh Narayanan” on AJAX and Web 2.0. He was clearly not knowledgable enough on the topics to present them in front of such a huge crowd. Many of the things that he spoke outside-of-slides were wrong. At one point i got so annoyed that i had to correct him by saying that “building AJAX applications in GWT involves coding using GWT APIs and not using Swing APIs”.

Conclusion:

I hope SUN does some due diligence in future while choosing speakers for conferences. The crowd in conferences in India are no more IT kids. Its a mix of experience and youth. The telecom and IT boom in India has resulted in increased skill level of average IT mass. So you can not just get away with some random blabbering any more.

I would not say it was complete waste because i missed two good sessions (mistake in choosing tracks). There were a couple of new jargons i picked up which i am going to look into further and the speech from Scott was good barring the marketing stuff. Oh, one more thing – the venue and the food were absolutely wonderful!!!

GWT – what to expect…

About a couple of months back a news posting caught our eyes. We were fed by a few aggregators and ofcourse Google alerts – mentioning that Google has just released the beta (i am fed up of seeing beta for all google products) version of GWT (Google Web Toolkit). We were already into evaluating a couple of web frameworks including JSF and Wicket.

GWT was just another announcement among those recent spurt of web framework offerings. But knowing the brand value of Google we decided to give it a go. We put together a team developing a full fledged application on GWT to start with. And then add on the complexity of having a Spring + Hibernate backend. I am posting our observations out of this excercise.

Positives:

1. The team didnt have to know a thing about JSP and Servlets to develop a web application.
2. Knowledge of core java is good enough to get started, though a little idea of event driven programming and Swing/AWT will be added advantage.
3. The embedded shell provides an easyway to test and see the application in action during development.
4. Discussion forums on GWT site is already rich enough to have information on almost all issues that we faced.
5. There is a huge community building and contributing UI widgets.
6. Developers didnt know JavaScript but built the AJAX interface. Though you need to know JS for complex tasks.

There are a lot more positives. You can always get them from GWT site. But what you wouldnt get is – the negatives. So the below text is more important and needs to be exhaustive. So dont decide on GWTs fate by the number of items below, but use the information below to your aid.

Negatives:-

1. Its not completely open source. Its java to javascript compiler is still proprietery.
2. It only supports async communication. We didnt find a way to do sync communication.
3. Its documentation is not very friendly. Not based on standard javadoc. Sometimes it becomes difficult to navigate. We posted in the forum but no luck.
4. Limited set of GUI widgets. Dialog box doesn’t have minimize, close buttons out of the box.
5. Documentation doesn’t have pictures of all the widgets. You really need to use the widget to know how it looks like.
6. It needs a tooling support for drag-n-drop GUI design. As of writing this there is no open source IDE or plugin to other IDEs. Desiging the UI manually was painful and reminded us of those granny’s days of Swing coding.
7. Browser incompatibility, looks different in Firefox and IE. Didnt try with Safari or Opera.
8. No support for JSE 5.0 yet.
9. GWT UI will not load at all if a browser doesn’t support JS.
10. No direct support for internationalization. There is a complex workaround only.
11. It provides an abstraction over JS, HTTP and HTML using Java. The obfuscated (compiler generated) JS is very hard to debug while detecting and fixing bugs.
12. The web application will be dependant on GWT’s code generator being error free.
13. You can only unit test the java code and assume that the generated JS will work properly.
14. GWT does a good job of abstracting away some of the low-level aspects of Ajax application development, such as cross-browser incompatibilities, the DOM event model, and making Ajax calls. But modern JavaScript toolkits such as the Yahoo! UI Library, Dojo, and MochiKit all provide a similar level of abstraction without needing to resort to code generation. Moreover, all of these toolkits are open source, so you can customize them to suit your needs or fix bugs that arise. This isn’t possible with the black box of GWT.
15. GWT supports only a subset of java classes and interfaces.
16. Serializable is not recognised by GWT compiler and it forces objects that are passed between cleint and server to implement GWT’s IsSerialisable interface. This puts design constraint when GWT is integrated with a backend. We had to resort to object to object mapping toolkits (like Dozer) to solve the problem.
17. List Box does not have ‘value’ feature.
18. gwt-user jar cannot be used for deployment in Tomcat, the javax.servlet packages have to be stripped from the jar before deployment.
19. If you need to integrate your UI with any existing application, the source code of existing app will be required if any of the classes from it needs to be used in UI code. If it uses any ‘non-supported’ java class then you are in a soup.
20. All your GWT code runs on client. So the bigger your application is, the heavier the JS that gets downloded to client browser and hence the slower your initial page load beomes.
21. Application code is sent to the client though in the form of obfuscated JS.
22. Few utility packages in java like, reflection, text and regular expression are frequently used in user interface code. GWT doesnt support them.

Our impression from this small excercise is that, if there is open source (we support OSS) IDE support to build the UI quick and fast then building the web application using a bunch of java developers will not be a tough task. If the API documentation can be improved and the widget libarary can be made little more rich then the UIs can be made amazingly beautiful in small time.

We reserve our comments for its suitabilty for enterprise application development. Its definitely an issue if you have to integrate with existing applications.

ps: Thanks to the team who worked on developing the prototype and helped compiling these points.