
The Practicality of J2ME Applications - wolfgke
http://ecc-comp.blogspot.com/2014/09/the-practicality-of-j2me-applications.html
======
cedricbeust2
I created the Gmail application running on J2ME, which we shipped in 2006 [1].

When we shipped, this application ran on about 300 different devices which,
for those of you who ever wrote J2ME code, is pretty impressive. J2ME
development was an absolute nightmare. There was no debugging on device,
pretty much no tooling, even doing a println to find out what was going on in
your code was not supported (I had to write entire libraries that would
display debug messages in the window titles).

The default J2ME widgets were absolutely horrendous (and they all looked
different on various phones) so we had to write our own widget library. This
came at a price but it was invaluable in being able to make the app work on
hundreds of devices.

Looking back, I honestly don't know how we did it, but the team was absolutely
brilliant.

Shortly thereafter, I joined Android where I was asked to create the Gmail
application and help build up the operating system. With my experience on
J2ME, I knew exactly what I wanted Android to have:

\- Seamless on device debugging

\- IDE support

\- Powerful view system

\- Java API's that look familiar to Java developers

In short, everything we never had on J2ME.

Needless to say, my subsequent work on Android was infinitely more pleasant
than the year I spent on J2ME, which I don't miss one bit :-)

[1] [http://googleblog.blogspot.com/2006/11/gmail-mobile-
client-i...](http://googleblog.blogspot.com/2006/11/gmail-mobile-client-is-
live.html)

~~~
kumarm
Having worked on Java ME(J2ME) since 2002, When Android first came out I
thought Android is Java ME Fixed. One thing missing in your list is
distribution. Lack of Single Java ME store made it practically impossible to
distribute apps unless you are Google or some other big name company. Every
Carrier had different Store with different rev share model, different
certification process etc.

BTW Huge fan of your work since BEA Days.

------
joverholt
I worked on some J2ME applications around 2004. While we built usable apps, it
seems if you want any kind of user interface that doesn't look like crap, you
need to implement it yourself. The default text fields and labels did not look
nice.

Another problem was that each carrier pretty much determined what you could
do, such as using GPS or network access. So one some phones it works, others
it doesn't. Of course, that's assuming you can get it onto a customers phone
in the first place. There were app stores, but they sucked. We used Nextel's
"store", and it was not fun.

I hope the situation is better today for J2ME, since when the iPhone and
Android came out, it showed the carriers that people actually do want to use
their phone's full capabilities. And have an easy way to get apps onto the
phone.

~~~
Zigurd
There is a built-in UI framework in J2ME/MIDP: LCDUI. It's possible to make a
very compact UI implementation using LCDUI. The problem is that, on some
platforms, it WILL look like crap. On some, with decent fonts and a good LCDUI
implementation it will look pretty good for menu/button/list UIs. But
designers used to designing Web pages find it rudimentary and a design
straitjacket.

I also found that among the handful of J2ME/LCDUI implementations required to
cover a broad range of handset models, they all had different bugs, and I had
to make a compatibility layer to smooth over these differences and bugs. BUT,
nevertheless, it is possible to make a UI in single digit KBs that is portable
across multiple J2ME implementations.

~~~
ak1394
There was/is a great UI library for J2ME called LWUIT. It arrived pretty late,
but it was very good at abstracting the differences of various J2ME platforms
(i.e. differences key codes/keyboard layouts, screen sizes and such).
[https://lwuit.java.net/](https://lwuit.java.net/)

Back then, I wrote a Twitter client app for them J2ME phones with some
processing offloaded to the server, which was done in Erlang :) Ah, the times.

~~~
invalidname
Its still around and became Codename One
[http://www.codenameone.com/](http://www.codenameone.com/) and its way better
as such.

------
nashadelic
It's incredible just how naive the author is. If you've ever worked on j2me or
even Symbian vs Android or iOS you never want to go back. There's a reason why
the apps have blown up thanks to Apple: making apps in the j2me era was a
nightmare with each handset having a different implementation of j2me and same
functions returning different behaviours.

I do not ever want to go back to that time and any developer romanticising
horrible tech needs to develop an actual real world app or two on a number of
handsets before going all gooey eyed.

~~~
zak_mc_kracken
> There's a reason why the apps have blown up thanks to Apple

It makes me sad to read this.

The first iPhone had no third party applications, no API, no SDK, nothing. It
was impossible to write apps for the iPhone then, Steve Jobs thought that HTML
5 should be good enough.

He changed his mind only after Android shipped with a full SDK.

~~~
tzs
> He changed his mind only after Android shipped with a full SDK

There may have been an Android SDK before there was an iPhone SDK, but iPhone
was the first whose apps actually ended up in the hands of the general public.
Apple had their App Store up and open to developers and the public by July
2008. The first shipping Android phone was still three months away.

~~~
zak_mc_kracken
What does this have to do with the (incorrect) claim that Apple kickstarted
the "App on a phone" market?

I was just debunking this claim.

Android 1.0 went to market with a full blown SDK and the vision that the
future belongs to third party apps.

Steve Jobs completely disagreed with this vision and he only changed his mind
after Android shipped.

~~~
tzs
Android 1.0 went to market in September 2008, two months AFTER Apple's App
Store opened to the public, so it is clear Android 1.0 going to market did not
have anything to do with Jobs changing his mind.

Jobs changed his mind sometime before October 17, 2007. We know this because
it was on that date that Apple published a note in his name announcing that
they were going to allow third party apps and that the SDK would be available
by February 2008 [1].

At that date in the Android world, Android only existed as an alpha within
Google, and had not yet even been officially announced. It wasn't announced
until the first beta, November 5, 2007. The first Android SDK was released
November 12, 2007.

By the end of the first weekend that the Apple App Store was available, they
had 10 million downloads from real customers. By that weekend in the Android
world, there were 0 apps in the hands of real customers. So yeah, it was
indeed the Apple App Store that kickstarted the "App on a phone" market.

[1]
[http://web.archive.org/web/20071020040652/http://www.apple.c...](http://web.archive.org/web/20071020040652/http://www.apple.com/hotnews)

------
sehugg
J2ME programming is actually kinda fun, because the concepts make sense, and
there aren't many of them. Canvas/Screen is pretty straightforward. Android's
Context/Activity/Fragment/Intent/Bundle/etc/etc are a cognitive nightmare by
comparison.

Unfortunately JRE 1.3 is almost 15 years old, and it's just annoying to e.g.
not even be able to use java.util.List. And MIDP just isn't very rich in
support for ... anything.

But FWIW you can compile C to J2ME, and it kinda works:
[https://code.google.com/p/cibyl/](https://code.google.com/p/cibyl/)

~~~
fallat
That's why J2ME is appealing to me right now. The simplicity is something to
die for in other environments.

Hopefully it's as simple as it appears.

------
stuaxo
ex j2me dev here: I could not go back... it was great developing on a limited
platform, (boundries spur creativity). But the bugs were show stoppingly
terrible l, also completely unnessary platform differences, I would never go
back.

------
Goopplesoft
There was a prior article attributing J2ME to Whatapp's success:
[http://blog.textit.in/your-path-to-a-$16b-exit-build-
a-j2me-...](http://blog.textit.in/your-path-to-a-$16b-exit-build-a-j2me-app),
discussion here:
[https://news.ycombinator.com/item?id=7269258](https://news.ycombinator.com/item?id=7269258)

------
wtracy
What was most frustrating to me about J2ME was how few device
manufacturers/service providers were willing to open up to third-party app
developers. In the U.S., I found these phones to be about as open as video
game consoles: You have to get the carrier's blessing before you can even
start development on your app.

~~~
johansch
This was actually a US-only thing. Outside of the US, stuff eventually worked
(especially in emerging markets).

------
octorian
One J2ME platform often forgotten about, or outright ignored by the J2ME
community, is the old BlackBerry OS. They took a J2ME base, and added a ton of
BB-specific APIs on top of it to make the platform actually useful.

Early on, this led developers to having to make a choice... Code to pure (or
mostly pure) J2ME and run everywhere, or fully embrace the BB-specific APIs.
The former was attractive in theory, but the latter was a necessity to make
your app actually look-and-feel correct and actually integrate with the
platform.

As time dragged on, however, it felt like the BB SDK got all of its
limitations from the J2ME base without actually deriving any benefits.
Meanwhile, Android showed that you could actually do modern Java on a mobile
device.

------
imperialWicket
Another huge challenge with J2ME application development is the marketplace
options. Most of these are carrier controlled, and you must pass certification
tests per carrier, per device in order to make your application available.
While some devices/carriers will allow easy J2ME 'side-loading' (never called
that in the J2ME world), almost no one does it.

Additionally, most developers are aware that mobile app purchases most often
happen immediately after the purchase of a device, and lots of users never buy
another app again. This is even more stark a scenario in the J2ME world
(particularly in the US - though we make up a small amount of the J2ME devices
in use).

~~~
johansch
With Opera Mini, we got like 95% of the installs the first five years via our
own wap(!)/web site (mini.opera.com/m.opera.com).

~~~
imperialWicket
That's a meaningful data point, and impressive! Nonetheless, I think Opera is
exceptional for a few reasons and for a smaller dev, there's little
practicality to J2ME. It's much more difficult to charge for or in your apps,
and without a known brand, having your own wap or download site isn't
productive because you still won't get much traffic.

I'm really just highlighting that while some of the aspects have allure, many
of the challenges that are present in the current 'mobile' (android|iOS)
landscape are simply heightened in the j2me world.

~~~
johansch
Yeah, this is clearly something that only applies before the advent of in
phone app stores. Back then word of mouth was the thing. This worked
particularly well in developing economies for us with Opera Mini.

------
pkulak
Have you seen the cheap Android phones out there? The Android One phones are
about 100 bucks. The Moto G is $180. Still not $50, I know, but it's getting
close enough the really start squeezing those phones (and JSME) right out of
their niche. And Android development is Java (for all intents and purposes)
too.

------
magoghm
In 2008 I was working as a contractor for somebody who needed many J2ME
MIDlets. Some of those MIDLets had to get information from a server, in most
cases the MIDlet did an HTTP GET and the server would respond with some simple
data (usually a number or a string).

But one day I had to write a MIDlet that would need to receive a more
complicated data structure. As I was the one person in charge of writing both
the MIDLet and the server side servlet I could choose any format I wanted for
the data.

I decided that XML was too verbose, and I decided to use lisp-like
S-expressions to encode the data. Writing the parser, which took a string and
converted it to a list of cons cells and atoms, took me about 2 hours. Then I
decided that the best way to debug it was to write another routine to
translate those cons cells and atoms back into a string, then to write a loop
that read a string parsed it and then took the data structure, converted it
back to a string and printed it. About half an hour later, I had a program
that could read S-expressions and print them back (running it on my computer
using the subset of Java that could run on a mobile phone).

Then I realized that I had a read-print-loop, and if I added an eval to that
loop then I would have a lisp interpreter. Nine hours later, I had a simple
Lisp interpreter that could run on J2ME devices!

I was so happy about my J2ME lisp interpreter that I decided to add support
for lisp macros. That turned out to be harder, it took me three days to have a
version with a working defmacro.

Then I added a way to open a bluetooth connection to my computer, where I had
a small program that would send anything it read from standard input to the
mobile phone and then print out on standard output the response it got from
the phone. I now had an interactive REPL to execute Lisp code on my phone.
With this I could write and debug MIDlets much faster than before.

All the MIDlets I wrote in the following weeks were written in Lisp.

I then decided that my Lisp interpreter was too slow for some applications and
decided to write a compiler that turned Lisp code into bytecodes I could
efficiently interpret in a J2ME lisp virtual machine. I took the scheme
compiler described in Norvig's "Paradigms of Artificial Intelligence
Programming" and translated it into my version of Lisp (which was very similar
to scheme). Then I used my Lisp interpreter to compile the compiler itself
into bytecodes. This part turned out to be much harder than I expected, it
took one month of hard work to make the transition from interpreted Lisp to
compiled Lisp.

The result was a very compact J2ME Lisp environment. A MIDLet with the Lisp
virtual machine, Lisp compiler and basic runtime libraries was about 32 KB
(and a full MIDlet with application specific code was usually less than 50
KB). It could connect to a server over bluetooth or TCP/IP to give me an
interactive REPL, and it could also dynamically download new code to extend
its functionality without requiring the user to install a new version of the
MIDlet.

~~~
phatak-dev
Awesome. Do you have link to code or some references?

~~~
magoghm
Unfortunately, I do not own the rights to the code. If I did I would have
released it as open source.

------
johansch
I managed the tech/product aspect of Opera Mini and its direction for most of
its first decade (we started in late 2004). There's 250+ million monthly
active users of it now (most in places like SEA, Russia, India, Africa, South
America). Reading stuff like this is quite rewarding.

This post somehow made me think of the first English language blog post from
early 2006 that really appreciated what we (me and my team) accomplished:

[http://www.russellbeattie.com/blog/1008770](http://www.russellbeattie.com/blog/1008770)

"Opera Mini: Best Mobile Web Browser Bar None

Posted Tuesday, January 24, 2006 12:41 pm"

~~~
wcummings
Correct me if I'm wrong, but rendering is done on a server farm, at least
partially, so J2ME itself is not entirely responsible for a good UX.

~~~
johansch
We run the Opera web browser core on the server side, in many, many instances.
The J2ME client paints stuff like it would paint a PDF or Flash document.
Obviously we paid extreme amounts of attention to compressibility/amount of
bytes transferred. (Most of our work on this aspect happened while we were
using GPRS (and later EDGE) ourselves.)

