Java ME (Java Micro Edition) software programming language was originally created in 2001 to enable the development of Java games & applications for mobile devices and mobile telephones particularly. In its early days it seemed to be a promising solution. The variety of mobile telephones models was very small, most of them were black & white, the basic capabilities J2ME offered were more than enough and the simplicity involved with developing in J2ME created huge expectations.
During the last years it seems that Java ME has failed to adjust itself to the changing world and as a result of that has become less attractive. The new emerging Java ME JSRs certainly do indicate about an excellent work and especially an excellent integration between the industry leaders and the Java ME evolvement. Yet, concurrently with the evolvement of those rich capabilities many of the difficulties the market faced were ignored. Especially those the smaller companies, who have less influence on the Java ME evolvement, had to cope with.
Java ME hasn’t disappeared and will defiantly continue to evolve. Yet, I find it hard to believe it will ever be capable to meet the expectations me and many of my colleagues had during its early days.
In this blog entry I overview the main reasons for the Java ME failure to meet the expectations shared by many companies involved with developing Java ME games and applications. These reasons are also the ones who led and continue to lead to the evolvement of other alternative technologies. One of the most promising alternatives is Flash, which is the world “de facto” standard for web client side multimedia development. Another promising alternative is the combination of web 2.0 technologies, that seem to repeat their success with desktop rich client web based solutions, with the evolvement of better mobile web browsers.
I am writing this blog entry from a technical business perspective based on my experience running Zindell Technologies. I will be more than happy to get your feedback.
Java ME Games & Applications Problematic Deployment
Distributing content for mobile telephones involves with handling a huge number of versions for each title (e.g. when distributing a wallpaper there is a need to provide each mobile telephone with an image its dimension fits the mobile telephone screen). Developing server side solutions that identify the handset and provide it with the exact version based on the user-agent HTTP header is rather simple. Nearly all content types for mobile telephones are easy to handle. For many of them there are automated solutions that create on the fly the exact required version (e.g. an automated server side that cuts the image according to the mobile telephone screen dimension). Trying to do the same when dealing with Java ME games & applications for mobile telephones is nearly impossible. Though it is possible to identify each mobile telephone according to its screen dimension, CLDC supported version, MIDP supported version and even few more detailed spec, there are still many other difficulties that hold us from implementing distribution & deployment solutions similar to those used with other content types. Comparing two mobile telephones models with the same screen size dimension, the same spec (CLDC & MIDP versions) and even the same manufacturer doesn’t mean that if a given Java ME application runs perfect on one of them it will run on the other as well. There can be many reasons for such cases. The one that is the most difficult to cope with is a case in which the two models are exactly the same except for the fact that their manufacturer software version is different. The difference can be very small (e.g. bug fix). Yet, cases like that are enough to have us releasing two separated versions for each one of these two models. In addition, those cases make it necessary to test each Java ME application on each mobile telephone model. Given the huge number of today mobile telephone models, the lack of a better and a more efficient deployment model causes many of today content distributors to avoid the distribution of Java ME games & applications.
Java ME Implementation Differentiation
Each mobile telephone has a Java ME implementation, which is another small software that sets on top of the mobile telephone internal computer and is capable of running the Java ME code. That small software implements the public specifications we can all find at www.jcp.org. The implementation must be the same in order to enable the developers to develop the same application for all phone models. Small differences between those implementations eventually lead us to create different versions for the same title. Those small differences are not relevant when developing low quality titles. Those small differences become relevant especially when trying to exploit the handset and develop high quality titles. One of the best examples is the image type supported by Java ME when using images within the J2ME code. According to the specification the format that must be supported is PNG only. Yet, when trying to develop high quality title that includes a big number of images, sometimes there is no other choice but to use the JPG format instead (takes less space). Most of the handsets support using JPG. However, some of them still don’t. Another example is the transparency type between images used within the Java ME code. Different phones support different transparency types. That yield the need to create separated versions of the same title.
Lack of Reliable Emulators
Today market includes thousands of different mobile telephones models. Developing a Java ME application that fits most market’s phone models should be carefully tested before it is released. Unlike server based applications we can fix at any time, when you release a Java ME game or application and it is already out there in the market it is nearly impossible to go after all of those thousands of people that already have the Java ME application on their mobile telephone and send each one of them the new fixed version. The lack of reliable emulators for nearly all mobile telephones models turns the testing phase of the Java ME application into an impossible mission. Having the need to test on each phone model separately is a slow, tedious and expensive process. Installing a Java ME application on a mobile telephone is a very slow process. In addition, buying a huge number of phone models is not simple.
Complex Development Process
Developing a Java ME game can be done very fast. Few lines of code and you get an up and running Java ME game for your mobile telephone. Yet, if you want to adhere today “market standards” and deliver an high quality Java ME game you can’t use any of the standard GUI components Java ME offers and you need to create graphically each one of the GUI components the Java ME game includes. You can find a good sample for this need taking a look at Jacado SuDoKu. Checking this game you will find that each one of the GUI components it includes is composed of small images the Java ME code puts together. This complex development process is very expensive. Especially given the need to develop different versions for different handsets that have different screen size dimensions. Being familiar with Flash, I can testify the simplicity Flash offers is far more attractive.
There are many other reasons for the Java ME failure to deliver its promises. Yet, I believe the four I have mentioned above are the most important ones.
I have no doubt Java ME will continue to evolve and at some point will merge into Java SE allowing the various JSRs to add the required specific functionality when developing specifically for mobile telephones. I also tend to believe that at some point the possibility to integrate between Flash and Java ME will emerge. Such possibility will allow us to enjoy both worlds. Easy standardize multimedia developed using Flash together with a back end logic developed using Java ME. Such possibility might solve many of the problems listed in this blog entry.
I hope that sharing my view with you via this blog entry will some how have some impact on future technologies development ensuring their highest possible success.
Java ME is certainly a success. Yet, it could be a much bigger one.
