Devoxx 2011

Once again, more than 3200 passionate developers gathered for one week in Metropolis, Antwerp. The Devoxx event is split in two parts: the “University Days” on Monday and Tuesday (long conferences, tools, trainings and hands-on labs), and the “Conference Days” from Wednesday till Friday noon (keynotes, conferences, quickies and “BOFs” (round tables)).

Devoxx rocks!

What is unique in Devoxx, is that it is made by and for the developers (the real ones: those that are actually writing code!). You will see almost no commercial presentation there. On the contrary, speakers don't hesitate to display code, or even to write it live! You come back from Devoxx with tons of practical information and lots "things to try at home by myself".

It's also giant live Twitter walls all over the venue; 29 companies presenting their products and distributing their goodies at heir booth; 59 JUGs (Java User Groups), many whiteboards, and hundred of places to sit and start coding.

There is of course free WiFi, with this year a 1Gb/s internet pipe! Enough to give easy access to any participants (easy, except maybe for the few unlucky ones that are still using Windows instead of OSX ;-)).

Wednesday was the day of free French fries, Thursday of free movie ("Tintin" this year). There was also free beer and after parties every night... and countless occasions to meet members of the Java community, from all over the world. Devoxx is the place where any lambda developer can talk with the Chief Architect for Java at Oracle, for example.

To celebrate the 10th anniversary of Devoxx, each participant received a nice free mug (I chosen the HTML5 collector!), and was invited to a memorable free clubbing party at the Noxx.

Content, content, content

This year, Devoxx was 167 speakers giving about 174 sessions happening in 7 theatre rooms in parallel: 3 Keynotes, 1 discussion panel, 86 Conferences, 16 University, 10 Labs, 19 “Tools in Action”, 14 Quickies, and 25 “BOFs” (informal discussions)! These sessions cover 9 tracks: Java SE, Java EE, Web, Mobile, New Languages on the JVM, Methodology, Architecture, Security, and "Partner slots". There were up to 8 talks running in parallel.

Devoxx is initially focused on the Java ecosystem, i.e. not only the Java language, but also other languages based on the Java Virtual Machine, and all Java related frameworks in general. Also, more and more pure Web and mobile technologies are gaining importance in this conference. This year, HTML5 and Android talks were amongst the more attended ones (btw, let's highlight here the big presence of Google at this conference, and the quality of speakers they sent). Beside these, there are also a number of talks about the job of developer (or, should we say about the software craftsmanship).

Highlights

As usual, one of the big theme was the evolution of the Java language, especially with the long awaited release of Java 7, but also Java 8 profiling in the near future, and Java 9 added to the roadmap.

Probably the second most popular track was HTML5. The Web platform has evolved very rapidly since two years and it provides now a complete stack for developing client side rich application. Bye bye Flash...

Mobile platforms were also very present, especially the Android platform (whose programming language is Java) and mobile web technologies.

Several new JVM languages (non-Java languages running on the JVM) were present in the talk: Scala (lots of hype), Groovy, JRuby, Fantom, Ceylon. Some of these languages have now went past the experimental status and are used in critical enterprise context. "Web languages" were also present: JavaScript (and jQuery), Dart.

Let's also mention the iconoclastic talk from Martijn Verburg, the "Diabolical Developer", full of refreshing behavioral (anti-)patterns for the developer.

Sogeti

This year was also marked by the return of the presence of Sogeti. More than 10 consultants attended the conference, but also Sogeti was a Medium partner of the event and had a nice stand in front of the Google one. This was made possible thanks to a collaboration between Sogeti France, Netherlands, and Belux. Kudos for all the people who spent their time answering questions at the stand! And, last but not least, Laurent Guerin from Sogeti France made a well attended presentation about the Telosys web framework.

GWT and Flex, a comparison

One of my customers recently asked me to help them choosing a framework for developing rich web applications, i.e. desktop-like web applications (see also my previous article [1]). After some internal discussion, it was decided to short list Google Web Toolkit (or GWT) and Adobe Flex. Microsoft Silverlight was not included for a number of specific reasons, like market share and coding culture. Moreover, the customer also asked to include jQuery in the study, even though it's not a complete framework (jQuery was already used by the customer, and the department had to justify the introduction of a new technology).

Note that the comparison that follows was done taking into account some specificities of the customer. A different context might lead to different conclusions. (There is no one-size-fit-all in the landscape of RIA frameworks.)

I took into account the latest versions of the frameworks at the time of this writing, i.e. GWT 2.2.0, WindowBuilder Pro / GWT Designer 0.9.0/2.2.0, Flex 4, Flash Builder 4 Premium Edition, (?BlazeDS 4?).

Criteria

Based on the typology I had established previously ([1]), I prepared the following list of criteria:

• Staffing
• Availability of programming skills
• Learning curve
• Documentation and Tutorials, Books
• Productivity
• GUI Builder
• Object Mapping
• Validation
• I18n and L10n
• Industrialisation (automatic builds, tests...)
• Maintainability
• Design patterns (MVC or MVP, IoC/DI...)
• Testability
• Programming language (static typed vs. dynamic typed, e.g. Java vs. JavaScript)
• Risk (durability of the vendor)

After reading a number of references ([2]...[6]), I completed with a few additional criteria:

• Staffing and Support
• Community
• Productivity
• Data Binding
• Widgets/components library
• IDE support
• Communication protocols and formats (REST, SOAP)
  (Communication formats (JSON, XML...) are discussed in the "Object mapping" criterion.)
• Maintainability
• Declarative UI design
• Style sheet
• Scalability (avoid server-side session)
• Browsers versions coverage
• Security
• User experience
• Mobile platforms support
• Client side drawing
• Printing
• Drag and drop
• DOM (browser) integration
• Stability

jQuery

While GWT or Flex are complete frameworks, jQuery is only a Javascript library providing additional widgets and functions (events, interactions, effects) to the developer. It does not solve the maintainability issues of Javascript based web page design (no, or weak, design patterns, dynamically typed language, no declarative UI design, poor testability, no IDE support...). The productivity is also questionable, since there is no support for mapping objects to server resources, validating object attributes, or for internationalisation. For these reasons, we must consider jQuery more as a tool for improving the interactivity of a web page, not as an appropriate tool for building desktop like applications in an enterprise context (see [1] for the differences between a rich web application and a set of interactive web pages).

Comparisons

We here compare GWT and Flex through each set of criteria: staffing, productivity, maintainability, user experience.

Each criteria receives a mark between -- and ++ (- and -- for bad performance, + and ++ for good performance).

Since there are a lot of add-ons available in the respective communities, we've indicated with the special mark "opt." the criteria where there is support which is not native.

A "!" mark indicates a compatibility issue between some criteria.

Staffing and Support

The staffing and support criteria compare as follows:

Criteria	GWT	Flex
Availability of programming skills	++	+
Learning curve	++	+
Documentation and Tutorials, Books	++	++
Community	++	++

Skills. Being 100% Java based, GWT has an advantage over Flex, where the client side application is built using a dedicated language (ActionScript), unique to Flash. Even though Flex skills are relatively common, ActionScript developers are clearly outnumbered by Java developers. This is even more significant for a company that is already using Java as his prime technology, since it already has inside resources that do not need to learn a new language.

Learning. Developing GWT based application is very similar to developing actual Java based applications, and the programming model is very similar to the one of Swing based applications. Hence, traditional Java developers won't be disoriented. Flex is reported as being quite easy to learn for web developers (partly because ActionScript is based on JavaScript), but won't be on par with GWT for existing Java developers.

Documentation, Communities. Both solutions have very large communities communicating on-line, one can easily find numerous tutorials on the web, and there are plenty of books available. The online communities also provide plenty of add-ons for both framework. (This is particularly useful for GWT, for complementing lack of native capabilities.)

Productivity

The productivity criteria compare as follows:

Criteria	GWT	Flex
GUI Builder	+!	++
Object Mapping (JSON, XML...)	-/opt.	++
Data Binding	+!	++
Validation	-	+
I18n and L10n	+	+
Industrialisation (automatic builds, tests...)	++	++
Widgets/components library	opt.	++
IDE support	++	++
Communication protocols and formats (REST, SOAP...)	-, opt.	++

GUI Builder. Google recently acquired the company "Instantiations" and is now delivering one of their product, "GWT Designer", together with the GWT framework. This is a full fledged GUI builder. However, since the acquisition is quite recent, both technologies are not yet fully integrated. Noticeably, it's difficult (if possible!) to use the "GWT Designer" with a declarative UI approach (see "UIBinder" further).

Object mapping. Object mapping is automatic when using GWR RPC for communicating with the server. When using other protocols, it will depend on the data format. For JSON, the mapping is obviously automatic to JavaScript, but one has to manually map the JavaScript to Java. When using XML, the mapping and the parsing must be completely done manually (or you'll have to rely to a third party module). For Flex, mapping is trivial since JSON and XML are native data types.

Data binding. In GWT, the "Editor" framework makes possible to do data binding. It must be configured programmatically (Java code) and relies on the declarative UI mechanism (UIBinder) (see further for impact of using UIBinder). In Flex, the data binding mechanism is available both in the declarative UI (MSXML) and programmatically (ActionScript).

Data validation. In GWT validation must be programmed manually, or through a third-party add-on providing JSR 303 validation (though there is immature (partial, unstable) JSR 303 support in native GWT). Advantage of JSR 303 would be that you could reuse the same code on the server. Client side data validation is done in Flex using "Validators". They are available both in the the declarative UI (MSXML) and programmatically (ActionScript). A number of predefined validators are provided and custom validators can also be defined.

I18n and L10n. GWT manages localisation with resource files. There is also a specific mechanism helping generating these files from the declarative UI (UIBinder) files. Flex does support localised strings through ResourceManager.

Industrialisation. A GWT app can also be compiled from command line, or even through a 3rd party Maven plugin. Only the premium edition of Flash Builder provides Ant based build and unit tests (hence also command line) capability for Flex. Maven support is only possible through third party plugin.

Widgets library. Standard GWT widgets are quite basic, though lots of third party add-ons provide very rich libraries. Standard Flex widgets library is already very complete.

IDE support. GWT comes with a plugin for Eclipse (free), providing a.o. a unit test framework, an emulation mode to simulate the behavior of the browser, text completion for JavaScript and UI design file... Flex has its own commercial IDE, Flash Builder (either as an Eclipse plugin, or as a standalone Eclipse based application) providing also text completion, refactoring... The premium version of Flash Builder comes with "testing tools such as profilers, network monitoring, an automated testing framework, integration with Flex unit testing, and command-line build support (...)".

Communication. REST communication is possible from GWT by constructing HTTP requests. The framework provide no facility to automatically bind a data object to a REST service. SOAP is not possible without third-party add-on. Hopefully, GWT also provides a proprietary protocol (GTW RPC) that provides automatic binding. Flex provides support for both SOAP and REST-like protocols, as well as a proprietary protocol (AMF). All can be used either from the declarative UI or from the code. There is also a mechanism for managing remote data objects.

Maintainability

The maintainability criteria compare as follows:

Criteria	GWT	Flex
Design patterns (MVC or MVP, IoC/DI...)	++, opt.	+(+), +
Testability	++	++
Programming language (static typed vs. dynamic typed, e.g. Java vs. JavaScript)	++	+
Risk (durability of the vendor)	++	+
Declarative UI design	+!	++
Style sheet	+	++
Scalability (avoid server-side session)	++	++
Browsers versions coverage	+	++
Security	-	-

Design patterns. GWT recommends using the MVP design pattern. The GIN Google add-on brings to GWT dependency injection based on JSR330. Flex uses the MVC design pattern and it uses a dependency injection mechanism in the declarative UI files. [?Event bus?]

Tests. GWT can be tested using JUnit. There is a test container making possible to run unit tests  without starting the whole UI. There is also a "development" mode in the Eclipse plugin that makes possible to run the whole UI in the browser without compiling the code (which is very slow!). GWT can also benefit from all existing Java libraries (like Hamcrest, FEST, jMockit, Mockito...) for writing unit tests. Adobe provides FlexUnit 4, a framework similar to JUnit. It also provides a UI test container (UIImpersonator).

Language. GWT is based on (a subset of) Java, which is statically typed .Flex uses ActionScript (see [10]), based on JavaScript, which is not statically typed, but there is an option of the compiler that enables strict type checking. Besides this, ActionScript has more OO features than standard JavaScript.

Vendors. Both vendors (Google and Adobe) are well established. Though Adobe, being a smaller player, is more subject to buyout. Another hand, Google is not a software house, and nothing guarantees it will keep the focus on GWT, though it is a strategic product for Google.

Declarative UI. GWT: UIBinder (compatibility with GWt Designer?). For Flex, the MSXML UI declarative language is at the base of the framework and is directly edited by the WYSIWYG editor in Flash Builder.
Styling. Both frameworks support CSS. The version of CSS supported by GWT will depend on the target browser and this can be tedious in case you target a multi-browser environment. Flex not only has support for CSS at various levels in the UI, but also for themes (packaged style sheets and assets).

Scalability. Both frameworks enable building a RIA where the whole UI context is maintained on the client side, hence enabling session-less server-side code.

Coverage. GWT supports all major browsers. It does this without performance impact because it generate separate sets of resource for each "kind" of client (a "kind" of client being a permutation of browser family and language). Note that there is always a risk of having to recompile an application when a new browser appears, in case it's not fully compatible with older browsers. Flex is completely independent from the browser, since it runs in a separate plugin.

Security. The level of protection of an application built with GWT cannot be better than what is provided by the web browser. In that respect, a GWT application is neither worse nor better than a traditional web application, being subject to all traditional web exploits (like cross-site scripting...) The Flash player has a SandBox mechanism to isolate an application and avoid malicious attacks to the client side code, however it has not proven to be very robust. (Most recently known exploit have been patched last month only!)

(Has an illustration, in 2010, for Windows, the site secuser.com reported 10 critical vulnerabilities for Internet Explorer and 7 for Flash (+ 1 medium). During the same period, only 3 critical vulnerabilities were reported for Java.)

User experience

The user experience criteria compare as follows:

Criteria	GWT	Flex
Mobile platforms support	++	+
Client side drawing	exp./opt.	++
Printing	-	+
Drag and drop	opt.	++
DOM (browser) integration	++	++
Stability	++	-

Mobile platforms. Since a GWT application runs in a web browser, it can target any platform with a web browser (provided that it supports JavaScript). This is the case for all modern smartphones. Moreover, with the advent of HTML5 in Android, iOS, and RIM phones, the capabilities of applications running in the browser will be even closer to native apps. On the other hand, Flex is now supported by most smartphones manufacturers except one, but which is not the least since it's Apple.

Drawing. Client side drawing is only an experimental feature in GWT (at least until 2.2) and it uses HTML5 Canvas (hence requires a compatible browser). There are also third-party libraries providing drawing capabilities for any browser. Drawing capability is native in Flex, and is very powerful, being the Flash inheritance.

Printing. GWT provides access to the browser "Print" command. Printing a specific item requires to render it first in a separate window or frame. Flex has a built-in API for controlling a printer. This API enables printing any "Sprite" (a displayable component).

Drag and drop. Drag and drop support is provided has a third party library in GWT. It is native in Flex.

Browser integration. Integration of GWT in the browser is de facto. For Flex, communication with the browser is possible through JavaScript code. Both GWT and Flex have support for deep linking (linking directly on a specific view of the application) and browser history mechanism (Back and Forward). GWT does this through "History Tokens" mechanism, and Flex through javascript ("history" resources) and BrowserManager class.

Stability. Flash has sometimes be reported to present stability issues due to memory management. Moreover, since it requires a plug-in, Flex has a negative impact on memory per se. It is also to be noted that some Flash implementations (typically on Mac OS) had known dramatic CPU performance impact in some situations. This has only be fixed in recent versions of the Flash player.

Other considerations

BlazeDS... an open source server side framework from Adobe to ease integration of Flex with the application server, data, and other web services.

HTML5... likely the platform of the future. Will be natively supported by GWT. On another hand, Adobe has recently shown effort to support it also transparently from Flex projects.

Multimedia (video, web cam...)... are supported by Flex. GWT support is limited to web enablement (cf. also recent HTML5 progresses).

Summary

GWT: There are more skilled people, ad there is a better browser integration. Lot's of missing capabilities are possible only through third-party add-on, for which there is no guarantee of longevity.

Flex: It's more complete, has better productivity and better user experience. Capabilities for communication, object mapping, and data validation are very good. There might be a performance impact.

Both share the low security profile of any web based application.

Recommendation Given the specificities and needs of my customer, based on the above advantages, and on the opinion of both developers and customer architect, I recommended the selection of Flex.

References

• [1]^{^1 2 3} Rich Web Apps: RIA, AJAX... - An overview. Pendragon Blog. 11-Feb-2011
• [2]^{^} Flex vs GWT: Comparison Part 1. Memory Leak. 03-Mar-2010
• [3] GWT vs Flex vs ? Asked on StackOverflow on 08-Jan-2009
• [4] Comparing JVM Web Frameworks -TSSJS 2011. Matt Raible. Mar-2011
• [5] Flex vs. GWT Smackdown. Matt Raible. ~2009
• [6]^{^} Flex vs GWT vs Echo2. blog.pursuit.be. 23-Oct-2007
• [7] MarketScope for Ajax Technologies and Rich Internet Application Platforms. Gartner report. Revised 14-Jan-2010
• [8] Using Adbove Flex 4. Last updated 11-May-2010
• [9] Using Adobe Flash Builder 4. Last updated 29-Jun-2010
• [10]^{^} ActionScript 3: The Language of Flex. Frank Sommers, James Ward. 26-Apr-2007
• [11] The Flex Programming Model. Franks Sommers, James Ward. 03-May-2007
• [12] Using Flex in the Enterprise. Frank Sommers, Bill Venners. 28-Feb-2011

Rich Web Apps: RIA, AJAX... - An overview

I've already been several times confronted with the task of explaining what Rich Internet Applications (RIA) are, and why they are different from classical web applications. This is the reason why I wrote this article. It is not meant to be exhaustive and it might contain some approximations but I hope it can help the reader to get an insight and build his own idea.

Web applications typology and RIA

Since advent of the Web era, web sites have evolved by becoming more and more dynamic, then more and more interactive, and more and more complex...

We can schematically distinguish the following successive phases:

• static web sites (pure HTML)
• light dynamic web sites (CGI processes on the server side)
• dynamic pages (JavaScript + DOM + CSS)
• interactive pages (+ AJAX)
• rich web applications (RIA...)

« A RIA is a web-based application that is designed to provide functionality similar to a desktop applications. Some RIAs run completely inside a web browser while others are browser-independent. » [1] This definition implies, notably, that just adding a few AJAX interactions to web pages is not sufficient to turn these pages into an RIA. Sometimes authors insist on this difference by distinguishing "thick RIA" from "light RIA". Though, in our understanding, an RIA is always of the "thick" kind and we won't consider "light" RIA as true RIA.

Note that there is a controversy in the literature on the usage of the term RIA. For some, like Gartner, RIA designate only applications running independently from the browser (like Java VM, Flex, or Silverlight). For others, like Kristen Waters, the term RIA also covers applications running inside the browser. In this article we target all cases and, to avoid confusion, we will use the broader expression "rich web applications" (or RWA).

Typical characteristics of rich web applications, compared to traditional web sites, are:

• richer user experience thanks to more user controls (not limited to basic HTML controls), in-line editing, drag and drop...
• UI logic running on the client side / session less server side
• reduced reliance on network/server communications, by transferring only data or partial pages instead of refreshing full page
• better performances, lower load on the network and on the servers
• better scalability
• largely browser and OS independent
• difficult to index by search engines

Compared to traditional desktop applications:

• better security, "sandbox" isolation
• easy distribution, deployment and maintenance
• application accessible on any host, instantly
• OS independent

Typical use cases for RWA are:

• office application (word processor, spreadsheets, presentation tools...) (e.g. Google Docs)
• personal information and communication (mail, contacts, calendar, tasks, chat, feed aggregation...) (e.g. GMail-GCalendar, Outlook Webmail)
• cartography (e.g. Google Maps)
• CRM (E.g. Salesforce.com)
• Business Intelligence (E.g. BimeAnalytics.com)
• Development tools (E.g. App Inventor)
• Software-as-a-Service (SaaS) in general

Frameworks

As already said, one can distinguish two kinds of rich web applications. Those based on a framework running in a specific virtual machine (like Java VM, Flex, or Silverlight) on one hand, and those using the browser itself as a virtual machine on the other hand.

Frameworks using the browser as a virtual machine capitalize on the capabilities of HTML, DOM, CSS, and JavaScript. They also usually enable development to be independent from the target browser with seamless degraded mode for old-dated versions.

These are a few well known browser based frameworks:

• GWT (Google Web Toolkit)
• Cappuccino

But there are also plenty of vendor specific frameworks, usually little known and used mainly in enterprise environments, like for example General Interface (from TIBCO). Though, most developers available on the market would likely not know these vendor specific frameworks.

Frameworks using a specific virtual machine have the disadvantage of requiring a specific prior install, typical in the form of a browser plug-in. (Though this inconvenient is insignificant in the case of Flex, since the Flash Player is deployed in 96% of internet enabled desktops. For Java the figure is 79% and for Silverlight, 61%. [2]) Advantages are better performances and even richer experience.

Here follows an indicative list of choice factors:

• Staffing
• Availability of programming skills
• Learning curve
• Documentation and Tutorials, Books
• Productivity
• GUI Builder
• Object Mapping
• Validation
• i18n and l10n
• Industrialisation (automatic builds, tests...)
• Maintainability
• Design patterns (MVC, MVP...)
• Testability
• Programming language (static typed vs. dynamic typed, e.g. Java vs. JavaScript)
• Risk (durability of the vendor)

Links

[1] "What is RIA?", by Kristen Waters

[2] Rich Internet Application Market Share, Stat OWL

Mobile Apps Development: Native vs. Web

When it comes to start developing apps for mobile devices, a difficult question is immediately raised: which platform should we select? Indeed, the mobile landscape is the scene a fierce fight between major players (like Microsoft, RIM, Apple, and Google) or challengers (like HP and Nokia). Each of these platforms comes with its own way of developing apps; they often use different languages and SDKs, and always have different APIs.

There is obviously no unique answer to the question. It depends on a lot of factors.

The way you interpret those factors depends on your intent. Are you an individual who wants to invest time on its spare time to build skills in a new technology? Are you a software architect who must make a technical choice for a specific project? Are you an enterprise that must set architecture principles impacting all developments for the coming years?

An individual will take into account its personal taste; the software architect will consider the specific requirements of the project; while an enterprise will have more strategic considerations.

Choice factors

There are factors that are typical when you make a technology choice, like cost, performance, availability of technical resources (it might be easier to find Java developers than Objective-C developers), integration with the existing architecture, etc.

Then, there are factors that are typical to the mobile apps development landscape. Mobile appshave very specific characteristics that traditional applications don’t have:

• Limited resources
• Limited or varying connectivity
• Specific hardware: touch screen, camera, GPS, accelerometer, NFC…
• Specific services: contacts, calendar, SMS…

These bring additional constraints you have to take into account when choosing a technology.

Mobile platforms diversity [Max Katz]

Two alternatives

When it comes to make a decision there are two main tracks you can take, either you go for native development, or you go for web based development. Each track comes with its own advantages and drawbacks, but the gap becomes smaller, especially since the raise of HTML5 techniques opens the door to web apps that can compete with native ones.

Both solutions share the following advantages: easy deployment, fast time to market, good user experience, local storage, off-line mode…

Advantages of native development (and drawbacks of web development) are: integration with device services and hardware (though some services might be available through HTML5, like location); and best performances.

Advantages of web development (and drawbacks of native development) are: only one set of skills to address all platforms (no fragmentation: pretty much all mobile platforms now (will) support HTML5), re-use of existing enterprise connectivity infrastructure, no overload of device apps collection.

So, it will depend on the kind of requirements your application will have. You will choose the native track for: games, access to device features, high performance, rich graphics, single platform target, and – in some cases – off-line mode. You will choose the web track for everything else, especially if supporting multiple platforms or enterprise connectivity is important.

This section is based on a presentation by Max Katz at Devoxx 2010:
“Mobile Development Choices: Native Apps vs. Web Apps” http://goo.gl/mc0Gl

The third way

Since very recently, a third way is taking shape in the form of the Adobe Flex SDK. It provides a common stack for all platforms. Three alternatives can be chosen for the distribution: either Flash web applications, similar if not identical to applications running on personal computers; or Flash applications deployed locally; or by cross-compiling to a native app. Note however that, for iOS, only the latter is possible, due to Apple boycott of Flash.

Mobile applications based on Flex might gather the advantages of both native and web based development, but this technology is very recent in the mobile landscape, and not yet finalized for all platforms. Future will tell us if it’s a viable alternative.