The Practicality of J2ME Applications | Hacker News Reader

The Practicality of J2ME Applications

ecc-comp.blogspot.com

33 pointswolfgke41 comments

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...

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.

What I wish Android had

- up to date Java language version

- official tooling support for the major alternative JVM languages

- a proper simulator that does not require alternative solutions like Genymotion

- proper tooling support for editing Renderscript and OpenGL shaders

- OpenCL support instead of NIH Renderscript

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.

Sun and later Oracle were kind of crap at leading J2ME into the future, so basically nothing worthwhile happened after MIDP 2 in 2002 (besides vendor-specific API:s from like Nokia and Sony Ericsson). So yeah, you had to build your own UI, pixel by pixel. To me, that was the charming aspect of the platform, like with the Amiga, or with DOS stuff. :)

Oh yeah, it was fun building our own UI that we had complete control over, so that part wasn't so bad. It was just at times, it seemed like they (carriers) didn't want you using the phone for something other than voice. What!? you want to actually send your own data, over our network? And tag it with GPS?

Which app(s) did you work on? Surely it's okay disclose this nearly a decade later? :)

I made two apps, and sadly, not many people have heard of them, since I was working for a small company at the time and we really didn't have the clout to deal with carriers or a sales force to sell. Both apps were agricultural related.

The first app was a general purpose data collection app. It was purely data driven. I could define a template on our server which defined what fields you wanted information for, the type of field (text, number, list selection, etc) and if it was geo enabled. This would be sent out to the phone, and a user could enter the information, send it up to our server and view it on a map. Doesn't sound to exciting, but you could pretty much create a template for anything, This was before google maps, so we also had to manage the shapefiles and handle displaying and rendering them on our website.

The other app was a payroll app for harvesting crews. We could set up the crew members on the server, they would get downloaded to the phone where we used a bluetooth card reader to scan them in/out. Also added some bluetooth printing.

Overall, you could be productive using J2ME. It was just all the stuff that went with getting it out to users.

Only if you are looking into mobile handsets.

J2ME is used a lot in embedded systems for factory control, automotive systems, network aware measure equipment, copiers, ...

Edit: forgot to mention that in the mobile area it is actually sad, specially with Oracle pushing ADF Mobile instead. So back to C++ for multi-platform code.

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.

I found LCDUI practically unusable (in order to build a compelling app). Pretty much like anything else coming out of Sun after 2002.

It is awful, you want to use an alternative.

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/

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.

Its still around and became Codename One http://www.codenameone.com/ and its way better as such.

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.

> 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.

> 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.

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.

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...

I don't mean apple was the first. Getjar.com was an App Store long before any. Facebook opened their platform for 3rd party apps before apple as well. But Apple, like with most things it does, popularised the idea of apps for your phone. Nobody quite got the power of apps or understood just what a stranglehold mobile carriers had on app distribution and monetization. Apple with its credit card integration, singular SDK, single point of deployment changed all of that.

Hehehe. I'm thinking of writing "The non-practicality of J2ME applications" after, since so far it has even been difficult even setting up the development environment.

I've written android applications so it'll be something to compare this experience to.

Yes I am naive in J2ME development X) But everyone's stories have been interesting to read!

Yes, I predict you're about to discover a lot of hard truths about J2ME but in this process, you'll understand better why Android appeared and how much better it is than J2ME.

I predict that in a few months from now, you'll be coding on Android exclusively and you'll never try J2ME ever again.

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/

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.

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.

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

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.

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

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.

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).

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).

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.

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.

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.

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.

Awesome. Do you have link to code or some references?

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

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

"Opera Mini: Best Mobile Web Browser Bar None

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

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.

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.)

Opera mini is a great browser and very very lightweight in ram.

I really think that if the goal of firefox os was to create smartphones affordable to everyone , they should have gone with opera mini - they've would've got better performance at lower costs.

Reply on news.ycombinator.com