Tag Archives: google

Live from TSSJS – Web Frameworks with Matt

Posted on by
3

Live blogging from TheServerSide Java Symposium again, this time with Matt Raible, who is giving a presentation entitled “Comparing JVM Web Frameworks”.  He began his talk taking feedback from the audience on what frameworks people are using, with one humerous dialogue that proceeded as follows:

“How many people are using Struts 1?”.
One gentleman raises his hand.
“Poor bastard.  Are you using Struts with WebSphere?”
The gentleman nodded.
“Why haven’t you quit your job yet?”

1.  Web Frameworks – Too many?
In the non-Java market, jQuery has risen to the top but this hasn’t happened in the Java world.  Some people have criticized Java as having too many frameworks to choose from.

Matt is personally very much against Struts 1, as well as JSF.  He talks about how the founder of both, Craig McClanahan has essentially ditched Struts/JSF for Rails in around 2007.  He also quotes James Gosling as saying he hates JSF with a link to the YouTube video, although indicates he may have been referring to JSP.

2. Choosing a framework
Matt often talks about being asked which framework to use.  He has constructed a list of 20 criteria to determine which framework to use such as:

  1. Developer Productivity
  2. Developer Perception
  3. Learning Curve – Should be able to learn in under a week
  4. Project Health
  5. Developer Availability – Will you be able to find developers to hire who know the material?
  6. Job Trends
  7. Templating
  8. Components
  9. Ajax
  10. Plugins or Add-Ons
  11. Scalability
  12. Testing Support
  13. i18n and testing
  14. Validation
  15. Multi-language Support
  16. Quality of Documentation/Tutorials
  17. Books Published
  18. REST Support (client and server)
  19. Mobile / iPhone Support
  20. Degree of Risk

Matt reviewed a number of platforms and posted the resulting matrix online.  The top 5 ones based on these scores are Grails, Tapestry, Lift, Spring, and Struts2.  Often the 5, 6, and 7 providers change every few months.

3.  Business Decisions
Often companies hire consultants to reinforce web framework decisions that they have already made.  A lot of companies have a proprietary web framework that can be successful for their product.

4.  Controversary
Matt has been criticized for his scoring by members of the community.  He has posted a detailed explanation of how he calculated these ratings online.  As a well-read GWT developer, I disagree with some of his scores for GWT, especially templating which only scored a 0.5.

5. Matt’s favorite web frameworks

  1. Grails and Groovy:  Eeasy transition for Java developers.  It is also a gateway to Groovy.  He mentions some companies and developers resist Groovy because it is targeted only for Java developers and there isn’t a high availability of jobs.
  2. GWT:Great for Java developers who hate JavaScript.  The community is open and Google has done a good job growing a vibrant developer base.  The down sides, though, are that it is slow to test and requires Java knowledge to use.
  3. Ruby on Rails: Good for web developers, rather than hard-core Java developers.  The community is excellent.  The down sides is performance, testing, and type safety are limited.
  4. Spring MVC:  Easy configuration and usage
  5. VAADIN:  Excellent theme and layout support.  Uses the GWT API for developing view.
  6. WICKET:  Great for Java Developers.  Active community with creators providing a lot of support.  One downside is very little jobs available for WICKET developers.

Active Mailing Lists
One good measure of the health of a web framework is the number of developers asking questions and involved in the community, such as mailing lists and forum websites.  Some frameworks have hundreds of questions posted a month while others have 1-2 and are clearly not being used much.

Conclusion
Matt finished asking the question “What if there is no ‘best’ web framework?”, to which he spent time presenting competing argument about how people ‘shop’ for frameworks.  He compared shopping for frameworks with shopping for food and discussed an article with a researcher who did trending for how people choose food products.  “When we pursue universal principles in food, aka web services, we are doing ourselves a massive disservice”.  In other words, pick the frameworks that work for you, not neccesssarily the “best” framework.

Matt gave one of the best presentations I’ve attended at TheServerSide Java Symposium, and covered a large variety of web frameworks, while demonstrating expertise in each.  As a fellow consultant, I appreciate that he emphasized how quickly it is to pick up these frameworks as well as how easy it is to find a job with these skills.  At one point, he was one of only 3 active GWT developers in the Denver area and would get a call anytime there was a GWT job available.

Side note:  Matt recommends all Java developers learn about and know JRebel given its power, saying if you take away only one thing from this presentation it is that you should know JRebel.

Live from TSS-JS – Mobile Development with Mark

Posted on by
3

Currently attending “Comparing, Contrasting, and Differentiating Between Mobile Platforms” by Mark Spritzler, a fellow CodeRanch moderator.  The presentation is in part an open discussion with the audience of what people have tried and works well in the Mobile environment.

1.  What is out there?

  • Android OS (Java)
  • Apple iOS for iPhone/iPod/iPad
  • Web applications with custom UI for mobile applications.  CodeRanch currently offers a mobile web version of the website
  • J2ME (not common)
  • BlackBerry (custom Java)
  • SymbianOS (C)

2.  Android OS Review
Built by Google and uses Java and can run Flash.  UI built with declarative UIs using XML primarily and supports visual tools such as Droid Draw and/or Interface Builder.  MVC-like architecture with view as XML, and control/model as Java classes.  The API is quite open so there’s a lot of ability to customize for developers.

There is currently a large variety of Android devices so splintering of the code base could be in the future.  Some devices cannot upgrade the Android OS, leading to permanent branching of code base.

Also, Android requires a lot of manual work to integrate with a database, such as SQL Lite, whereas Apple iOS has this built in.

3.  Apple iOS Review
Built by Apple and uses Objective-C, and cannot run Flash.  Developers must manage memory manually.  The API is completely proprietary and there are limit tools for developers.  For example, the developer must have a Mac and use an xCode.  Closed APIs but Apple promises stability (although it did change in iPad with split/view feature).

Dicussion on Apple’s strigent application approval process followed.  One participant commented that they waited 1-2 months for Apple to approve it.  Apple has also stopped approving ‘pointless’ apps.  I asked Mark if he thinks the delays are worth the improvement in quality, to which he replied that it does lead to better applications.  He also informed the audience that Apple wants you to use certain visual controls in particular manners to help build a consistent UI, and may reject applications based on improper usage.  Apple sometimes comments on why applications are rejected but not always.

4.  J2ME Failure Review
Idea was to develop using Java and runs on a variety of devices.  One of the major problems is Sun certified J2ME mobile phones that didn’t properly or fully implement the spec.  Also, lead to splintering of code base and very inconsistent results across devices.

5.  Native vs Web applications
Web applications have greater reach since they can run on many devices, but have weaker performance and require the developer to self-promote them.

6.  App Generating Frameworks
Build mobile applications from predefined templates using a CMS system often entered in a web browser, such as MobileRoadie, but it is a paid service.  Builder frameworks (often open source) that generate mobile applications based on existing code including Appcelector, Rhomobile, PhoneGap.

Write once and run on many devices through generation.  They may have limited functionality since they use a subset of features available in the language.  Multi-touch is also very limited in Android over iOS.  HTML5 does support location-aware so it can help in application generation.

Conclusion
Mark ended the presentation with an open discussion asking people to share their own mobile development experience.  He pointed out that there a lot of pros and cons to using different mobile platforms and mobile devices, and you should consider the resources on hand when deciding how to proceed in development.

GWT 2.2 Breaks Most Plug-ins

Posted on by
3
Google Web Toolkit I often comment that the GWT API is extremely unstable, more so than most other open source projects, due to the vast number of changes in each release. When Google released GWT 2.2 a few weeks ago, the release notes implied this was a relatively minor release. After attempted to update a fairly large GWT project to 2.2, I discovered a major issue: all of the referenced GWT plugins broke and required a new version that was GWT 2.2-compatible.

The API Change – Small and Subtle

In GWT 2.2, Google changed the class library JClassType from an abstract class to an interface. On the surface, this may seem like a minor change that would not affect most developers. Java compiler experts may be aware, though, that changing the class type alters the byte code of classes that compile against this class. In other words, any JAR or library compiled prior to GWT 2.2 that references this class will be unable to be used in GWT 2.2.

The error often manifests during a GWT Production mode compilation as:

[ERROR]  Internal compiler error
java.lang.IncompatibleClassChangeError: Found interface com.google.gwt.core.ext.typeinfo.JClassType, but class was expected

The Fallout

Because of this API change, most GWT plug-in libraries must be recompiled to GWT 2.2, and the resulting JAR will not be compatible with versions of GWT older than 2.2. In my case, this affected all the plug-ins I was using.

On the plus side, many GWT plug-in developers have already noticed the issue and begun issuing new versions. For example, if you are using Ext GWT, Sencha just released a new version this morning that is compatible with GWT 2.2. Bst-player, a plug-in I have contributed to, has also been updated for GWT 2.2.

Unfortunately, Google Maps, one of the most commonly used plug-ins, has not yet been updated and is therefore not currently compatible with GWT 2.2, as described in this bug report (please “Star” this issue if you have a G-mail/Google account!). If you rely on Google Maps in your GWT application, I strongly recommend you hold off upgrading to GWT 2.2. If you refer to the ticket, a user has posted their own GWT 2.2-compiled JAR, but this is not an official release.

All or Nothing

The major problem with this update is that it forces developers to update GWT and all plug-ins at the same time. If you upgrade to GWT 2.2, you are required to update all of your plug-in libraries and if, as in the case of Google Maps, there is no such update available, then you cannot upgrade at this time. Alternatively, if you keep the older version of GWT, then you cannot upgrade any of your plug-ins since the new versions will not be compatible with versions of GWT older than 2.2.

Conclusion

When I upgraded from GWT 1 to 2.0, a much more significant process, most plug-ins still worked, albeit with some issues. The fact that the GWT 2.2 upgrade completely breaks existing plug-ins is a serious issue, one I hope Google does not repeat in the future. With any luck, this is not a sign of things to come, and Google will consider supporting existing software in the future.

I'm Speaking at TheServerSide Java Symposium Reminder: Jeanne and I are both presenting at TheServerSide Java Symposium next week. My lecture is entitled “GWT Roundup: An Overview of Google’s Web Toolkit and Hybrid Integration” and Jeanne’s presentation is called “Throw Away All The Rules. Now What Process Do You Follow?.” The conference is being held in Las Vegas and it’s not too late to register to attend.