Comparing Mobile Platforms: Java ME and Adobe Flash Lite

By Bruce Hopkins

If you’re a mobile developer, you may have noticed that more devices these days are supporting Adobe Flash Lite. According to the latest figures, approximately 300 million devices in the market support some form of the Flash Lite specification. Of course that’s nothing compared to the 1.2 billion (yes, that’s with a “b”) Java ME devices that are currently available, but I thought that it would be worthwhile to see the strengths and weaknesses of each platform side by side. In the tables that follow, I’ll compare the latest and greatest specifications for both platforms in the following categories:

Local Device Accessibility
Network Connectivity

Our first category for comparison is graphics. As you can see in the table below, the Flash Lite 3 platform supports all the standard rasterized graphic formats and supports FLA (Flash format) and SVG formats for vector graphics. In my opinion, FLA is a superior vector graphics format compared to SVG, and the tools required to create sophisticated applications are easier (and more widely available) to use for FLA compared to SVG. So, the Flash Lite 3 platform is a worthy competitor in the graphics department for mobile applications, and it is easy to see why many Flash Lite applications are games. One downside, however, is that Flash Lite 3 has no support for 3D graphics.


When it comes to multimedia (the playback of various formats and codecs of audio and video). The Flash Lite 3 platform is a clear winner. It not only supports the Flash 8 video specification but also Sorensen video, which is an industry standard for compressed video. Both platforms support streaming audio and video, which is crucial when your mobile device needs to communicate with a media server.


How do the two platforms compare when you want to gain access to local resources on the mobile device? As you can see in the table below, the Java ME MSA specification gives the developer an unprecedented amount of access to local resources such as the GPS radio, camera, and microphone.

This may be a little known fact: both platforms support the capability to initiate a request to the handset to dial a phone number. However, since the Java ME MSA platform can also read phonebook entries on the local device, it’s more suited for creating powerful business applications. Note that there are Java ME and Flash Lite implementations that do have access to sensor data from accelerometers, but such functionality is not a part of the Java ME MSA spec or Flash Lite 3.


In the security realm, both platforms support HTTPS, so you can use either platform to securely communicate with a SSL-enabled web server. However, applications that use the Java ME MSA platform can also use digital certificates for secure identification. MSA devices have the added ability to use various encryption algorithms to secure data at rest (that is, on the filesystem).


Which platform provides more options for connectivity when your mobile application needs to communicate with external resources? The following table gives you a good idea of what you can expect when you create a mobile application that needs to communicate to a networked or local device. As you can see, both platforms support the capability for mobile applications to initiate requests using raw TCP sockets or with the HTTP protocol. However, mobile devices that support the Java ME MSA standard have the additional capability to act as servers, and wait for incoming requests on various protocols on both TCP and UDP transports. This allows the mobile device to communicate in a peer-to-peer mode without the necessity of server-to-proxy requests between them. If you’re in server mode, your application doesn’t even need to be running in order to receive its data. The PushRegistry allows Java ME application to “wake up” upon an incoming network request.

Mobile devices that adhere to the Java ME MSA standard also have the ability to use the local serial and infrared ports on the mobile device.


The following capabilities really didn’t fit in any of the categories discussed earlier in this article. For those of you who have never developed Flash Lite applications, you may be surprised to learn that it supports floating point math, XML parsing, and even TCP/IP networking without necessitating the use of a threading framework for its developers.



Each platform has its own strengths and weaknesses when it comes to mobile application development. Flash Lite-enabled devices are really good at displaying graphics and multimedia, which lends itself to several gaming applications. On the other hand, devices that support the Java ME MSA platform are the obvious choice when you need to communicate with Bluetooth devices, use location based services, capture audio/video, render 3D graphics, or perform any form of asynchronous communication.

I’m really glad to see that one of the Java ME licensees, Sony Ericsson, has made significant progress on bridging the gap between both platforms with its Capuchin technology, which was announced in late April: "...a Java ME API that defines a bridge between the Java ME and Adobe Flash Lite programming environments. This API makes it possible to use Flash Lite as the front end and Java ME as the back end of applications, meaning that Flash tools can be used for UI design while still having access to all the phone services available to Java ME." Both platforms have made significant advances from their initial 1.0 versions. I can’t wait to see what’s on the horizon for both platforms as the standards evolve.

Bruce Hopkins is the author of the book, Bluetooth for Java (Apress Publishers), and is the creator of the JB-22 developer kit.


I need more information about this topic.

Posted by Sachin Upadhye on May 29, 2008 at 03:25 PM PDT #


What exactly are you looking for? More info on JavaME MSA? FlashLite 3.0? Both? Source code on how to do stuff using both technologies? Let me know what you're looking for in particular.



Posted by Bruce Hopkins on May 30, 2008 at 06:22 AM PDT #


Please, don't forget to mention Jarpa Framework. Jarpa is an open source software, released under Apache 2.0 license, that extends Flash Lite capabilities with the true power of Java ME.

Posted by Felipe Andrade on June 03, 2008 at 09:44 PM PDT #

Thanks Bruce for taking the time to capture all of this information. You've done a good job of articulating the differences between Java ME and Flash Lite and it should benefit mobile developers and web developers looking to get into mobile application development. If you could add a table talking about porting and the versions of the client run-times that would be helpful as well. Also the number of devices that have shipped with Flash technology is over 500 million as of Q1 2008. You can also find the latest shipping devices with Flash Lite here:

Posted by Bill Perry on June 04, 2008 at 04:16 AM PDT #

Hey Felipe,

Thanks for the info on Jarpa! That looks really cool.


Posted by Bruce Hopkins on June 04, 2008 at 06:36 AM PDT #

Hey Bill,

I'm glad that one of the Adobe folks had the time to stop by and validate the comparison charts presented in this article. I got the 300M figure from the widely-spread press release that had that number in it.

Regarding the porting issue, I couldn't find a good way in this article to articulate that Flash Lite development has Adobe Device Central, which is the brainlessly simple way to test your Flash Lite app on multiple device platforms (without buying actual hardware). There is absolutely no equivalent to that for JavaME developers.

By the way, I have your book, "Flash Enabled" ( is there any chance that you might write another soon?


Posted by Bruce Hopkins on June 04, 2008 at 06:59 AM PDT #

Hi Bruce,

If I can find some free time I'd consider writing another book - it's about finding the time ;o)


Posted by Bill Perry on June 04, 2008 at 04:12 PM PDT #

My personal opinion is that J2ME and FlashLite are definitely (at least, currently) suited for different needs.

FlashLite limits are yet big and well-defined, and this is maybe the first reason why there are a lot of rumors and works around its merging with other technologies: from Felipe's Jarpa and SonyEricsson Capuchin for Java itself, to KuneriLite for Symbian S60, to FlyerFramework for Phyton and, dulcis in fundo, the future access to Brew APIs. But, at the moment, if you want to target a large audience/set of phones, FlashLite limits are still there, and you have to forget all the goodies and whistles that J2ME can give.

Of course, if you use Java, you also have to forget something: that is all the immediateness of Flash development and something more, like FLV support, that is widespreading these days... (and that is one of the main FL3.0 success reasons, in my opinion).

Also, they have totally different development paradigms: FlashLite (like Flash itself) is way more suited to develop interactive/multimedia applications, while enterprise/more classical ones are still best approached by plain-old-good Java (isn't this the main point behind Flex?).

FlashLite has totally a desruptive potential in comparison to any other technology (the desktop lesson should mean something?), but it's still too young (and still too differently oriented) to be compared to a mature technology like J2ME.


Posted by Jappit on June 06, 2008 at 06:00 AM PDT #

Hi Bruce,

Thanks for this excellent comparison between Java ME MSA and Flash Lite 3. I think the MSA is a great step forward for Java ME and it will certainly make the lives of developers much easier.

Project Capuchin is a great natural progression for Sony Ericsson to open their platform further for Flash content while using tried and tested Java packaging and security.

Adobe are great fans of Java, in fact our Adobe Mobile Server and Flash Cast servers are built on it :-)

Adobe Systems EMEA

Posted by Mark Doherty on June 06, 2008 at 07:00 AM PDT #


Thanks for stopping by and providing kind remarks. It looks like Adobe has really put some thought into the distribution of mobile Flash applications. Honestly, I can't wait until MIDP 3.0 starts to surface in the coming months. That should take mobile Java application development to the next level!

Posted by Bruce Hopkins on June 09, 2008 at 05:08 AM PDT #

which particular feature of MIDP 3 would bring "mobile Java to the next level" in your opinion ? Problem of JME, including MSA and MIDP 3 is there are way too many optional features and Tck enforcement by Sun is too benevolent to extent that some non-optional behave rather odd on certain platforms or are unusable at all thanks to bugs in implementation. Mobile operators typically won't permit distribution of application if it is not supported on vast majority of phones in their portfolio, which makes many MIDP "features" in your tables unavailable.

I hope in the future we can see a reference emulator and if you get your application running there, you're safe and any problems in actual devices would be considered bugs of the implementation that will get addressed by the future patch to JME runtime on the particular device. Until this happen, IMO it would be rather Android or Sun bringing Java to the iPhone that will push mobile Java further.

Posted by Pavel Lahoda on June 09, 2008 at 07:41 AM PDT #

Thanks for giving me information..

Posted by Sachin Upadhye on June 12, 2008 at 07:00 PM PDT #


Thanks for the article. And it's great it's attracting a bunch of comments from Adobe folks and others.

I'd like to echo the sentiment that Flash is really geared towards a very different application and developer space compared to Java - you can see that from the history and features/limitations of each platform. The space Flash addresses is very important and becoming increasingly so: graphics/media-heavy content created by non-programmers.

Let me add a few things to the picture from a Java perspective. First, the installed based of devices with Java ME is more on the order of 2.5 billion (not 1.2) - and that doesn't count smart cards or Blu-ray. Next, the strength of Java is really its flexibility and ubiquity. In my opinion you can only create truly compelling applications if you can integrate tightly with the platform capabilities. And this is where Java has a \*huge\* lead.

On the media front, Sun is very serious in addressing media in Java - note the broad licensing agreement on media codecs announced at JavaOne. All this will come down to mobile devices as well.

Finally, I think the ultimate platform would be one that comes with and leverages the power of Java but allows you to do all the cool stuff (graphics, media, scripting, etc) easily and quickly on top. Project Capuchin is one possibility but a more comprehensive and integrated approach is Java FX Script. At JavaOne, Stephan Janssen (owner of did a talk where he reported his experiences with implementing with different Web 2.0/RIA platforms such as DHTML, Flash/Flex, and FX Script. One of his conclusions was that while FX Script is playing a bit of catch-up the combination of Java and FX Script is clearly a very powerful and compelling technology.

FX Script for Java ME will be available in spring of 2009. And in the meantime here is some cool graphics and UI technology you can use for today's mass market devices:


-- Terrence

Posted by Terrence Barr on June 16, 2008 at 10:31 PM PDT #

Typo in the URL. Should be:

Posted by Terrence Barr on June 16, 2008 at 10:37 PM PDT #

Over a billion JavaME-enabled devices? That's a very good opportunity for anyone interested in doing mobile development. Thanks a lot for the information Bruce.

Posted by Babatunde Adeyemi on June 22, 2008 at 04:45 AM PDT #

Nice comparison, Bruce. Thanks for posting.

Couple things to mention: 1.) .FLA is not a graphics format, it's the SWF that you are referring to. Need to correct the graphics table and content to reflect this. The .FLA format is the binary source file for Flash content, .SWF file is the runtime format. 2.) on2 should be on2 VP6 in the multimedia chart.

Posted by Scott Janousek on July 17, 2008 at 11:13 AM PDT #


What interests me the most about MIDP 3.0 is the support for OSGi.

Posted by Bruce Hopkins on July 18, 2008 at 07:02 AM PDT #


Technically, you're exactly correct. Much in the same way that no one every runs .java programs (since it's nothing more than an ASCII document) they actually run .class files. However, some people use the terms synonymously. The same thing applies to .fla and .swf; people tend to use the terms synonymously.

Posted by Bruce Hopkins on July 18, 2008 at 07:08 AM PDT #

Nice comparison but a few things are not correct in my opinion:

1) People generally refers to FLA when they have to edit content with the Flash IDE, not when they have to play it (SWF), so the two are not used in the same context. In fact there a few implmentation made in J2ME of Flash-compatible player that can read and process the SWF format, while there is no application in FlashLite capoable of reading and processing .CLASS files
2) Even if it has been hinted by Adobe many times, actually there is not a single handset manufacturer that has opted-in for the SVG-Tiny play back capability of Flash
3) More over, it is not true that every FL3.0 has the same capabilities, for example all the Japanese operators have removed the FLV playback capability and capped the heap at a maximum of 100KB.
4) Quite a few new handsets coming in the market in these days still sports the FlashLite 2.0 version rather than 3.0, would be nice to know the reason

Posted by Emanuele Cipolloni on July 23, 2008 at 08:33 PM PDT #

Hi Emanuele,

In relations to some of your points:
1. I don't see why you would want Flash to read .class files, Flash has it's own interpreted language called Actionscript.

2. It has become apparent that most developers and their customers (OEMs, operators) would prefer to use Flash.

3. The Max heap size for handsets in Japan is 2.99MB, this is consistent with our Device Central tool info. Some devices can support Flash Lite 3.0 content but cannot support video playback, combinations of VGA screens and slow processors/data buses are largely the problem. In some cases the platform is simply not capable of compositing video using Flash.

4. The reason for different manufacturers shipping different versions of Flash Lite is down to their production and testing cycles. Adobe have announced the Open Screen Project wherein OEMs have agreed to work towards shipping Flash players that are updated during the device lifetime.

Posted by Mark Doherty on July 23, 2008 at 09:36 PM PDT #

Hi Mark,
thanks for your clarification, but:

1) In the first table (Graphics) looks like FlashLite can process FLA while J2ME can't. While not even FlashLite can process FLA but only SWF, I don't see why it should be accounted against J2ME. As I noted, it is almost trivial to build a parser for the SWF formnat while certainly you can't do that in FlashLite and being able to process .CLASS files. It should not have been a point of comparison, that's all.

2) Ok, but then why it should be a considered a feature of FlashLite while it is not supported anywhere? Not even in the releaess made by Adobe itself for developers, there is simply no trace of SVG support. Many handsets manufacturers prefer Flash to play just Flash beacuse they already had licensed SVG engines like Ikivo

3) That's the heap size for the standard device reported by Device Central, I have a few FOMA devices whose heap cap is 100 KB even with FL3 and FLV video is unsupported, while the perfectly play 3GP full screen videos without a hitch. Whether it is limited by the operator (NTT Docomo in my case) or the device manufacturer, honestly I don't know, I only know that these are severe limitations.

4) Yes, but this will end up in a big mess, keep saying "500 million device sold with Flash" where there are a bunch of versions trown in, incompatible implementations (when they are not buggy, like the N95 8GB) is just non sense. Open Screen is still a concept I see, as it talks about the NEXT major versions of Flash and FlashLite, whenever they will come. By the way, the companies that agreed to it are exactly the same ones that currently ships FlashLite, so I don't see the news here especially considering that companies like RIM or Apple didn't care at all.

Posted by Emanuele Cipolloni on July 23, 2008 at 10:41 PM PDT #


Thanks for taking the time to provide feedback and clarification for this tech tip. Hopefully, sometime next week, we'll be able to remove all references to FLA since, technically, no virtual machine on earth can run or interpret .FLA files.

Now, let's all sit back and get the big picture here. The point of the tech tip is for developers who are choosing between platforms before they develop their next mobile application. Specifically, in the graphics category, the Flash Lite 3.0 platform supports vector graphics in a way that Java ME devices are currently unable to do. For Flash Lite applications using Flash's own vector graphics capabilities, the individual instructions that tell the virtual machine how to render the vector graphics is embedded within the Flash Lite runtime file itself (the SWF file). However, the analogous instructions for SVG content are conversely encapsulated within an external file (the .SVG file, which is xml) and \*NOT\* within the application runtime itself. The main point is that the Flash Lite Platform supports Flash vector graphics.

We'll also ensure that the number for Flash devices is at 500M, and Java ME devices at 2B.



Posted by Bruce Hopkins on July 24, 2008 at 02:50 AM PDT #

Thank you so much for these useful information.

I prefer Flash Lite ,because it give me the ability to develop wonderful multimedia applications.

Posted by http:/ on June 18, 2009 at 12:55 AM PDT #

I am new to flashlite. I want to develop a few application for mobile, Can u please tell me if there is a away to call native C/C++ libraries from flash lite.
Also I am wondering if there is a turn around to access device capabilities, say GPS and Camera from flash app,


Posted by Ganesh on June 23, 2010 at 06:12 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Tips for developers who use Java technologies (Java SE, Java ME, JavaFX) for mobile and embedded devices.


« August 2016