Skip to main content

Developing mobility apps on Mac OS X and Solaris

Posted by terrencebarr on September 21, 2008 at 6:39 AM PDT

1212841574138_solaris.jpg The Sun WTK (Wireless Toolkit) for years has been the de-facto standard for mobile development on the Java platform (together with the "Mobility" plug-in for NetBeans which is itself built on the WTK and hooks it into the NetBeans IDE).

However, the original architecture and implementation of the WTK was quite OS specific and had a number of hooks into the underlying platform features and so the WTK has been only available for Windows and, lately, for Linux. Developers on Mac OS X (and Solaris, for that matter) were left out in the cold. But due to the numbers and Windows being the vastly predominant platform developers were using it just didn't make sense to create (and support!) a whole new port of WTK to the Mac platform.

So what can Mac users do (and I am one myself) to develop mobility apps on OS X? The recommended method currently really is to run Windows (or Linux) in virtualization (via VirtualBox, VMWare Fusion, or Parallels) and then the WTK on top of that virtualized OS. Not exactly elegant but it is generally pretty painless and works very well if your goal is to be productive and just get the job done.

However, increasingly, people are also going the route of using Java ME emulators written in Java SE to provide mobility functionality on platforms that otherwise lack WTK support, such as OS X and Solaris. Some examples are mpowerplayer and microemulator. While this approach is not perfect (in particular, Java SE-based emulators tend to lack tight platform integration, some advanced tools such as monitoring, and some of the latest JSRs features) it does allow the Mac OS user to run and develop Java ME applications directly on OS X.

Karol Harezlak from the NetBeans team has built a plug-in for microemulator that allows Java ME application development within NetBeans 6 in a fashion similar to the original Mobility plug-in under Windows and Linux. Currently there are still a couple of limitations with this in respect to the microemulator functionality (MIDP CustomItem is not completely implemented and there are a couple of issues with some JSR implementations). But it's a great start and since microemulator is an open source project I expect the community to continue to address the remaining issues over time.

Found out more on the NetBeans wiki.

Cheers,

-- Terrence

Comments

Given attitudes such as this there is a strong possibility of the Java ME platform drifting into obscurity. Rightly or wrongly the pace of mobile development is being driven by Apple and there are legions of developers with a fantastic range of skills and knowledge of mobile development writing fantastic applications ON MACS! Many of these, myself included, are now branching out and applying our skills to other platforms and have high expectations of a seamless and high quality experience. It is clear that Google recognise this and are actively courting these developers. In addition to their SDK they have released an Eclipse plugin that makes it EASY to start Android programming ON MACS! I have also now started learning how to develop applications for WebOS on the Pre since they have also simplified the development process. My day job is running a degree in Mobile Development in a University faculty that uses Apple Macs and as a result students are being taught three platforms: iPhone, Android and from September WebOS. We are producing dozens of skilled Mobile Developers ready to contribute to a growing marketplace and NONE OF THEM will be using JavaME. Is that not rather worrying? It would worry me. The lame excuses given in the previous post will have to give way to a motivation to make it as easy to develop JavaME applications on ANY PLATFORM as it is to develop Android apps. Unless this happens the platform will continue its drift into obscurity. And the worrying thing is it does not have much further to go... M

robdaemon,

WTK fundamentally needs three things: A UI that the user can interact with, a virtual machine with special hooks for tools and monitoring, and finally implementations of all the JSRs such as graphics, media, location, 3D graphics, and more.

Most of this can be built on a pure Java SE platform today but when WTK was developed 10 years ago Java SE was not up to the task. Therefore, using a special version of KVM (which mostly C-based) and leveraging the existing features of the underlying Windows platform was a much more direct approach.

Since then, WTK has involved and has added many features and supported JSRs. As with any software project it becomes increasingly difficult to throw away existing work and rearchitect the product and make it more portable and flexible. There has to be a business case to do so.

On the upside, WTK 3.0 will have major architectural improvements that improve portability, including using the phoneME code base as the underlying Java stack which is more feature-rich, modular, and portable than KVM.

I'm the first one to love to have full Java ME support on the Mac but the history of the WTK product can't be ignored.

-- Terrence

I'm sorry, I have to find fault with the argument that it doesn't make sense to support Mac OS X developers. Had the underlying architecture of the WTK been 100% Java, this would never have been a problem. What is lacking in the Java SE platform that makes it unappealing for producing the WTK and the emulator? I'd love to develop J2ME applications, but my two platforms of choice are Mac OS X and OpenSolaris. I've managed to follow some blog posts online to get NetBeans and MicroEmu to play together nicely, but why must it be this hard?