WORA: Really?

Hi all,

I believe most Java developers know that Java's slogan is "Write once, run anywhere", right? - I believed so! This slogan comes from the portability provided by Java platform, since any Java application is compiled to a intermediary code (platform independent), which is interpreted by a virtual machine specifically built for the underlying platform, i.e., JVM.

I also believe that most of developers have already witnessed situations where a certain Java application, which runs perfectly on Windows, for instance, does not go that well on Linux or Mac, right? - I bet so! It is always necessary, in some applications, some small adjustments to get them up and running properly. Most of times, those adjustments are necessary on applications that somehow use APIs that work with any resource from operation system (e.g. I/O, threads, etc.).

In mobile world the things are not different from any other platform. Actually, those incompatibilities are much more common. If you develop just for a certain line of devices, you are so lucky! Otherwise, be prepared (if you are not already), because even in devices from the same manufacturer, differences among devices can require many adjustments.

Today a witnessed an issue in a application that we are working on, that fortifies what I am writing about. The team was struggling to play a sound on Java ME application that already works perfectly on others devices from our client. However, for a specific device, the sound persisted in not working at all.

The team had attempted many imaginable ways to get a sound playing using JSR 135 - Mobile Media API. We also thought that it could be a platform's issue. But, when we were about to give up, We figured out something as a last resort: to play the sound is recommended to spawn a new thread to manage the player, so the application's main thread does not get blocked, right? We were doing that. What we did not know is that we should not spawn a thread, in order to play a sound, from a thread that was not the application's main thread. In our case, the parent thread was the accelerometer sensor's one (JSR-256). To sum up, to play a sound we had to spawn the player's thread from the application's main thread, instead of sensor's one. That's it! For some reason, the underlying implementation hanged the application.

Now, you tell me: where the heck could we imagine that? Even though on others platforms everything was working really fine. In the end, the most important, our client got very glad because we got the feature working and now he has the application ready to go. For us, that was one more lesson learned to be shared with our fellows.

Write once, run anywhere... tell me about it!!! Write once, adapt forever. :-)

How about you? Do you have any "freak" workaround to get a code working? Tell us!

See you in the next post...