What now for Java ME? tagged: , , ,

What now for Java ME?

Posted by in J2ME

Java ME (or J2ME as it was called) used to be the way to provide cross platform apps on a huge variety of devices. Several factors are changing this situation:

  1. Some platforms don’t do Java ME
    Windows Mobile has always been bad with MIDlet support: most times you need to install your own MIDlet manager. Now iPhone and Android have done without it too. Samsung’s Bada is also Java ME free.
  2. Oracle ate Sun
    Oracle took over Sun, and a big question is how they will approach Java ME.
  3. Where are the updates?
    Since MIDP 2.1, there have been no updates to the platform. Developers have been begging for changes to allow them to keep up with user expectations, but actual change has been non-existent. MIDP3 has been on the horizon for a long time (see below), and JavaFX mobile is promising but
    notably absent from actual devices.

Point 1 continues to be a worry. iPhone will never use Java ME. Android use a flavour of Java, but it’s not Java ME. Thankfully BlackBerry still supports MIDP/CLDC, but with their own native Java API offering far greater features, Java ME is really only there to allow existing MIDlets to run on the platform.

Point 2 is still undecided, but it is promising that Oracles cares enough about Java ME that it’s suing Android for not using it (they don’t like the use of Dalvik on mobile devices). Personally, I don’t agree with Oracle’s approach, but at least it gives some indication that Java ME is not an orphan in the wilderness.

Point 3 may be the most worrisome. When are we going to get better APIs? There are two things to hope for: MIDP3 and JavaFX Mobile. JavaFX Mobile seems to be nowhere near devices at present, so I won’t comment at all. The MIDP 3 spec was finalized in Dec 2009, however, so it might actually appear sometime soon (if we’re lucky). It should add many desirable improvements.

Here are some highlights:

  • MIDlet application management
    • LIBlets: pre-packaged libraries referenced in JAD with a URL. Only downloaded if not already installed. Shared between apps.
    • Inter-MIDlet communication
    • New MIDlet types: Screen savers, Idle Screen MIDlets (placed on home screen), Auto Start MIDlets
    • Concurrent running of MIDlets
  • Several new JAD attributes, e.g.:
    • MIDlet-Splash-Screen-Image (shown immediately upon app start up)
    • MIDlet-Update-URL (for automatic update checks)
    • MIDlet-Scalable-Icon (probably SVG)
    • MIDlet-Persistent-Data-URL (used for downloading app data. Nice way of separating code and data: should allow easier provisioning of different variants)
  • Data
    • Standardized packaging of data within the MIDlet JAR. Can be loaded directly into record store.
    • App data can be specified by URL in JAD (above)
    • Data may be encrypted with AES
  • System properties
    • Easy way to obtain device IMEI and MSISDN, if manufacturer has allowed this.
  • Notifications
    • Application can post notification items to device home screen (e.g. for new message, app event,
      etc.)
    • Application can be notified of changes to system state (apps can also launch on an event), e.g.:
      • battery low
      • audio has been muted
      • a data network has become available (such as wifi)
      • flight mode enabled
      • voice call active
  • Graphics
    • OpenType font support: manufacturer installed or packaged with JAR
    • 8-bit alpha channel (4-bit for images) available for rendering: will allow new effects, overlays, etc.
    • SVG Tiny 1.1 support (will help to support multiple screen sizes with one app)

These are all very handy features which will lead to some great apps, but we need this to happen soon, else we’ll all be writing platform specific apps again. If Java ME can show its value again, maybe the manufacturers will continue to support it, and maybe a few others will bring it on board for the first time. Wouldn’t that be nice.