13 Reasons for Java Programmers to Learn Flex and BlazeDS

This article outlines the 13 reasons why Java programmers should learn Flex and BlazeDS. It talks about why Flex with BlazeDS is one of the best choices for developing rich Internet applications (RIAs)—from highly interactive websites to enterprise applications with Java back ends. Most importantly, it shows the high return on investment (ROI) that this combination provides, both for developers and for enterprises.

In outlining the 13 reasons why Java programmers should learn BlazeDS, I use a fictitious soda dispenser to show how to morph an existing Java program into an RIA. Through the example, I explain the different ways you can use BlazeDS, either with your existing Java applications or with new Java applications.

Reason 1: It's open source

The core Flex software development kit (SDK) is an open source framework used for building and maintaining RIAs that look and feel the same across different browsers and operating systems. Flex is released under the Mozilla Public License. Compiled Flex applications run in the proprietary Adobe Flash platform.

For connecting Flex to Java, BlazeDS is an open source technology for remoting and messaging. It runs on Java application servers as a servlet, allowing you to use it in any standard Java web application. BlazeDS is licensed under the Lesser GNU Public License (LGPL). Along with the release of BlazeDS, Adobe published the ActionScript Message Format (AMF) specification, which allows BlazeDS and Java to communicate with the Flex client using a compact binary format.

Reason 2: It has great community support

Flex has a very active community, with a lot of community-contributed projects. Flex.org, an Adobe site with community news, sees almost daily community contributions, and the Flex users group on Yahoo! has over 11,000 members.

For example, the FlexLib project on Google Code has contributed a large amount of open source user interface (UI) components. The Swiz and Mate projects have contribute a framework to help handle events. And Gorilla Logic has contributed Flex Monkey for automated UI testing.

Reason 3: You can have a job in another six months

According to James Ward, a Flex evangelist for Adobe, there is still a large need for senior Flex developers. Learning Flex gives you marketable skills that will put you ahead of the competition.

Reason 4: Higher business ROI

In general, developing enterprise web applications has been notoriously difficult. Flex and BlazeDS provide not only higher-powered tools but are also easier to develop with. The increase in developer productivity allows organizations to get to market more quickly. Flex and Flash also create a more engaging user experience, which can increase traffic and conversion rates.

An ideal example of this is the Borders book store chain, which recently introduced a new website with a "Magic Shelf." This site uses a Flash interface to simulate the experience of browsing books. Borders found that this greatly increased conversion rates: "Customers who use this Flash-driven interface—which allows visitors to view the covers of books, DVDs, and CDs—convert at about 62 percent higher than those who do not".

Reason 5: Flex was the first language designed for creating UIs

Most languages add support for building UIs as an afterthought. This was particularly true for Java with Swing. As a result, simple things in Swing—like wiring data—can be painful and require using Swing-specific data models. The largest problem with Swing is that you have to dig very deep into the application programming interface (API) to be productive.

Flex is the exact opposite: It was designed from the ground up for building web UIs. As Bruce Eckel likes to say, Flex is the first domain-specific language (DSL) for UI development. So, it's much easier to create UIs in Flex than in other technologies, such as JavaServer Pages (JSP), JavaServer Faces (JSF), and Swing. Data binding, event handling, component layout, and other, common UI development techniques are built into the language, which allows you to be productive even when you know very little about the language.

Reason 6: It has a programming model similar to Java

You can develop with the existing tools used to develop Java. You can also develop Flex applications with the free command-line tools included in the SDK, with Adobe Flex Builder (an Eclipse plug-in), or most recently, with IntelliJ IDEA 8.

Flex provides a stateful environment in which data is loaded from the client. The programming model is more like developing a desktop client than Hypertext Markup Language (HTML) programming, which makes the programming model feel familiar to anyone who has done Java Swing programming.

Flex is programmed using a combination of MXML, a UI markup language similar to Extensible Markup Language (XML), and Adobe ActionScript, an object-oriented scripting language. This combination makes programming Flex similar to programming with Java, because you can use the familiar object-oriented concepts.

An ideal way to set up your development environment is to have the Flex application built right in your web deployment directory. That way, you do not need to re-deploy your application after every build: A simple browser refresh reflects the latest changes. Developing with Flex and BlazeDS is fairly productive as a result.

Reason 7: BlazeDS runs in any Java application server

Multiple versions of BlazeDS are available, including a turnkey version that includes a version of Apache Tomcat configured with BlazeDS. For this article, I used the binary distribution, which comes as a web archive (WAR), to show how you can deploy to any application server. Otherwise, you can extract the Java archive (JAR) files and use them in your project. Visit the BlazeDS wiki for information about the various options for installing BlazeDS.

This example uses BlazeDS with an existing project—a simple soda dispenser. You just need to add the JAR files to your project, then you can use BlazeDS from within the application, which allows you to deploy it anywhere you can deploy the application.

Reason 8: You can use it with existing Java applications

For the soda example, assume that you want to expose your existing soda service so that remote Flex applications can connect to it. The basic steps to set up BlazeDS with an existing application are:

Edit the BlazeDS configuration files in the WEB-INF/flex directory.

Define MessageBrokerServlet and a session listener in the application web.xml.

After you set up BlazeDS, you need to add your soda service to the BlazeDS remoting configuration file, which allows the soda service to be called from a Flex client. You make this addition by defining a destination and one or more channels to transport the data. The basic AMF Channel is defined in the services.xml file. Use this definition to identify your destination in remoting-config.xml:

This code tells Flex that when the results from a remote service call return your Java SodaModel, map it to your Flex SodaModel. The Flex client in the sample shows how to call this Java service. The call returns a SodaModel, filled with your order:

Flex returns your results in the generic result variable, which you map into your SodaModel. I won't go into the details here, but one tip is to specify services-config.xml in the compiler configuration, like so:

If not, your Flex client will not be able to find the Java services. In the same manner, you can pass an object from the client back to the server. For example, you could pass the empty soda model back to the client.

Reason 9: You can extend BlazeDS and modify it with Java

Suppose you decide that you want to add special logging anytime the soda service is called. You can extend the standard Java adaptor to add logging.

By default, all the remote procedure calls (RPCs) in use employ the AMF Binary Protocol. An open standard, AMF is extremely fast. James Ward put together a sample that shows a comparison with other remoting solutions. Although other Asynchronous JavaScript and XML (Ajax) solutions like Dojo struggle with a couple of hundred rows, Flex with BlazeDS can easily handle thousands of rows. (See James Ward's census for a benchmark of different RIA data loading technologies.)

Reason 12: You can call BlazeDS directly from Java clients

The latest release of BlazeDS includes a Java AMF class that you can use to make a Java client call the BlazeDS server. Being able to call BlazeDS this way is extremely useful for unit testing and load testing.

Reason 13: It works with Spring

Adobe and Spring have teamed up to bring closer integration between the two projects, and the initial release of the Spring–BlazeDS integration shows a lot of promise. By allowing a Spring Bean to become a remote service, duplicate configuration files will be eliminated. For more information, visit the project's home page.

Conclusion

With BlazeDS being open source and based in Java, it is an ideal choice for new and existing Java server projects. With high-performance remote communication and object mapping between Flex and Java, the Flex and BlazeDS technologies are an ideal choice for RIA development. Java developers new to Flex and BlazeDS will find the development process highly productive and easy to learn.

Flex with BlazeDS is also an ideal choice for large-scale Java enterprise applications. In a previous project, my team wrote an application that contained over 50 different screens and would regularly transfer several thousand rows of data between the server and client. This type of application would have been nearly impossible using traditional Ajax technologies. With Flex and BlazeDS, we where able to release an initial version in under a year. See what this dynamic duo can do for your application-development projects.

I don't think people should learn Flex because it works with Spring, that is quite biased statement. Not everybody love Spring! What about people that use Rails, PHP or Seam since Flex also works with these technology.

From the Java community audience perspective, Spring project-level support is a valid argument for promoting the use of a technology. You don't have to love Spring to appreciate its importance and ubiquity. I further doubt the Spring brand needs advertising on this forum:)

The Spring support will be the most important argument for projects that have a Spring backend today and will port the frontend to Flex tomorrow without re-implementing the business logic again. Spring support additionally allows to have a mixed client environment. That's pretty cool even today. So, you can add client functionality that delivers a better user experience without the need to skip your existing markup-based client stuff (JSF, ...). You can have separate client implementations or you add small Flex components to your existing client environment for a smoother migration. Best of all: all these Flex components can be reused if you change to a full-blown Flex implementation without any effort.

BTW: it is really crazy how fast you can implement complex presentations that AJAX is not able to delivers at all. And the user experience is really fantastic. From the user interface developers point-of-view that's the killer tool for the next years. It is faster, better, cheaper.

See reason 1 - 'runs in the Proprietary Adobe flash player. You still need Flash, so you ultimately need an Adobe runtime somewhere, and sometime in the future it may no longer be available at no cost - after all, Adobe has plans for Flash that extend into mobile devices, televisions, and... who knows? It's a bit disingenuous to sell Flash as open source. Show me a Flex 'compiler' that produces javascript or some other open source language, and I'll buy the argument. And this is coming from someone who, in spite of this text, likes Adobe and it's ethics.

Surely you have to factor the probablility of this happening into your technology decisions? I think the chance of Adobe charging for the Flash Player is approaching zero. Why? Well, firstly, the SWF spec is open so anyone could build a competing free Flash Player and secondly, with strong competition from Silverlight, JavaFX and good old AJAX, it would be commercial suicide.

Binding support in Flex is fairly superficial. As soon as you want to do anything out of the ordinary, you have to do it yourself. Binding in MXML is trivial; binding in code is not.

Flex doesn't support bi-directional binding.

Don't get me wrong: as a Java developer, I've been working with Flex for the last 18 months. It's not a horrible environment, but is designed for fairly simple applicactions.

Also: Reason 6: It has a programming model similar to Java

Again complete rubbish. Yes, Flex Builder is based on Eclipse, but the static code analysis for Java is much better than anything you get in Flex Builder. Also, the way Flex builds is very different from Java. If a class is not directly referenceable from the main application, it won't get compiled in. This can lead to all sorts of problems if you instantiate classes dynamically.

There are a lot of pitfalls in Flex for a Java programmer.

Reason 3: You can have a job in another six months

Yeah, right! (as my 4-year-old daughter says). Flex doesn't give you the opportunities that Java does. With Java, you can code a UI, do some network programming, manipulate the database, parse some HTML and mash it all up to do something funky, all without leaving the language. Try doing that in Flex! Flex alone is a dead-end: you'll just do boring GUIs for the rest of your life!

Hi Komal,Yes I have attended the training by www.FlexOnWeb.com and many of my other friends too. Also just to add to someone who posted that: "Flex alone is a dead-end"; Yes, you obviously need something like Java to get the best of this world-class RIA called Flex from Adobe. The end product that gets churned out is a web-based application yet gives you possibly all that you ever wanted as a Rich Client windows application!

Use Flex what it is meant for: Building great UI's. Leave back end integration issues and database connectivity/operations to a platform like Java.Spring also helps creating solutions which can be easily connected to other frameworks/platforms.