J2ME/MIDP was a fun platform to really cut your teeth on, and performed far better than many like to claim. For example, an old colleague of mine had written a Java emulator of a Game Gear, and it ran very well on J2ME, yet Android was horrific. Curiously the MIDP implementations out of Sun were also awful, and it was Nokia and some other European VM providers that did way better.
By far the most annoying aspect of J2ME were the jar size limits at the lower end, meaning to squeeze every byte (and this was real) you had to reduce the number of classes in the jar. Around 4-5 was typical. For many of the games on that page you'd be looking at 1 class of about 30000 lines, and a few others for device type specific abstractions, for example, maybe Sprite routines using Nokia DirectGraphics. This made teamwork on these games an absolute nightmare, especially in a pre-Git source code management era. (CVS/SVN/P4 were not exactly designed for working like that).
Later on there were some incredibly good studio specific optimization tools that handled transformations automatically, and outperformed humans, but these came into play exactly as iOS absolutely exploded.
They mention Mascot Capsule, which was a reasonably successful proprietary 3D engine pre-bundled on some devices. The other was the "standard" JSR 184, and I worked with at least two separate dev studios that had each implemented that in OpenGLES/C++ so that porting their 3D titles from J2ME to iOS/Brew could be reduced to an almost copy/paste business. This lasted maybe about two years before bothering with J2ME output was abandoned, but a side effect is the scene graphs for a lot of old iOS "premium" games look a lot like the one in JSR 184.
At least on Nokia's S60, the J2ME implementation was so good that it made Opera Mini feel almost native, and definitely more snappy than the actually native Opera Mobile (arguably mostly due to the server-side rendering).
It definitely took Android a while to get to that level of performance; the first few versions didn't even have JIT for Dalvik, while I think even Sun's MIDP implementation had it.
OpenGL also only became available on Android 1.6, while J2ME devices usually had either Mascot Capsule or JSR 184 as you say (sometimes backed by software rendering, but some S60 devices had a mobile GPU backing it, I believe).
> OpenGL also only became available on Android 1.6
I believe opengles 1.0 was available from the first public release of android - though some sources claim 1.6 added opengles 1.1 support.
Though I think there were sometimes difference in what was exposed between the NDK and in java - e.g. opengles2.0 was supported in the NDK at android 2.0, but not in java until android 2.2
No, they were proprietary, and their exact details remain trade secrets.
The best I knew of performed several tricks that the public research community assumes to be impossible. The big problem we had was making it totally deterministic as part of ensuring we had reproducible builds.
Of the public obfuscators in that era the most useful came from a company called dasho.
> meaning to squeeze every byte (and this was real) you had to reduce the number of classes in the jar
I suppose Google did something right with Dalvik (other than improving their "It's not Java!" stance for copyright reasons), i.e. introduce a bytecode file format that can share constants across Java classes :)
Ugh, really all the device specific fiddling with memory constraints or bugs always made me wonder why people complained about CSS incompabilties,etc :P
Really not missing doing J2ME development (even though at the time I heard that straight up Symbian was far-far worse).
J2ME is an unprecise term. I'd guess they mean J2ME/MIDP. The other profiles did even fly less probably.
I remember from the early 2000s you could get railway time tables from the German railways for your selected pair of stations as a midlet. That was truly useful.
I also used a mobile browser frontend. The data was rendered by the backend and transferred in compressed form. That was very usable at 2G speeds. Of course JavaScript was rare at the time. But I don't think the product was any commercial success.
Of cause their were (mostly toy) games. But in general the technology was probably 10+ years too early for the market.
I vaguely remember PP (Personal Profile IIRC). That was probably CDC/PP. Nokia either put it into one of the communicators or at least intended to so. 9210 I'd guess. But apps were extremely rare.
I think Opera Mini did much more than compression.
I seem to remember them actually rewriting (rendering?) the web page server side, and then sending an optimized mobile friendly version to make it more readable for pages that were originally designed for desktop.
It worked great on my phone and I even used it when the phones were more cabable, because web pages looked better and it saved a lot of bandwidth.
No, it was another company, I don't think a well-known name.
Opera Mini still works today on S60 phones from 2006ish. I regularly see web server log entries from a relative on my private server. But I believe it's a native Symbian app (.sis) not a Midlet. (I have working phones, but I don't have Opera Mini, so I cannot verify)
IIRC, other browsers (the chinese UC browser and Nokia's OVI browser) had compression too. But opera was most popular (and perhaps most mature as well).
IIRC for WAP the only way to use form elements was JavaScript as there was no equivalent of HTML <form> that would just submit the request automatically.
I got super interested with these in high school, because I finally got a Nokia N73 and that phone had the best and most complete J2ME implementation.
But I only had a netbook (atom cpu, 1gb ram, rotational hard disk) so I ended up coding J2ME using Emacs, a poorly written ant buildfile (due to my poor understanding of Ant) and the J2ME javadoc in a browser.
Woah, macOS support? Amazing, thank you! I've been using an old Android phone for J2ME emulation so far.
I'd love to see a J2ME emulator for iOS, now that they're tolerated by Apple on the App Store, but that would probably be tricky due to the lack of JIT compilation (presumably yours just leans on standard Hotspot for Java execution?)
I'm not sure what you meant by that standard hotspot - it can run on java 8 (in my case I use openjdk) albeit it uses the ASM library to modify class bytecode (a custom classloader, used for things like loading resources) and importantly, there are JNI native parts.
I'm not an iOS developer, so I can't help here, but my ultimate plan was to make it run.. on the web!
Unfortunately this is not feasible since it'd require a custom webgl-based m3g and mascot capsule v3 implementation.. also CheerpJ is said to be too slow. But technically you can run the "freej2me-plus" fork (no natives but no 3d support) on the web via CheerpJ (I hope that works on iOS)
J2ME was my first experience with mobile app development. It was very direct and easy to program for! But it definitely needed testing on the different devices. We had an array of different phones to test on. And some definitely had a nicer implementation than others.
The Java it supported was very old fashioned, with no generics. Which was a pain at times.
The most infuriating thing was extreme fragmentation when it came to support of various APIs in devices, even devices from the same vendor. Nokia was prominently culpable of this. The Finnish giant vomited out an enormous stream of S40 and S60 phones whose support for APIs was all over the map, which meant producing a shitload of JARs depending of what you needed, and the code was cluttered with constant checks of what is supported and what not. What an irony given Java's official motto of "Write once, run anywhere". Just freaking no.
Being a developer for Nokia was its own kind of hell. They never understood what API standardization is for and didn't care about your time and effort.
Hey, here are 12 different devices for this year with different hardware, screen size and other equipment, and you'd better get your hands on all of them to make sure that your app really works and looks acceptably, because an emulator only gets you half way. Also, any firmware update from us can kick your house of cards apart, and there will be like three of them coming in the next year. Happy programming!
> whose support for APIs was all over the map, which meant producing a shitload of JARs depending of what you needed
I wouldn't be surprised if this was actually one of the reasons why Sun fought MS and Google when they tried to make their own "Java" versions (embrace+extend). They didn't want a repeat of the J2ME situation.
There are a few models from Nokia running KaiOS (based in Boot2Gecko from FirefoxOS). Lower end devices had MediaTek MRE running and even some sort of dubious SDK available. Most recent Nokia devices switched to Unisoc chips and there seems to be no developer tools available.
I actually made money from selling a midlet via the Singtel marketplace. Not a lot but it was a good experience actually getting something to production outside of normal work.
It's been installed on my phone for years, for a single purpose: show the obscure mobile version of Sid Meier's Civilization V to my friends. Seriously, this existing still blows my mind to this day.
Readit News
By far the most annoying aspect of J2ME were the jar size limits at the lower end, meaning to squeeze every byte (and this was real) you had to reduce the number of classes in the jar. Around 4-5 was typical. For many of the games on that page you'd be looking at 1 class of about 30000 lines, and a few others for device type specific abstractions, for example, maybe Sprite routines using Nokia DirectGraphics. This made teamwork on these games an absolute nightmare, especially in a pre-Git source code management era. (CVS/SVN/P4 were not exactly designed for working like that).
Later on there were some incredibly good studio specific optimization tools that handled transformations automatically, and outperformed humans, but these came into play exactly as iOS absolutely exploded.
They mention Mascot Capsule, which was a reasonably successful proprietary 3D engine pre-bundled on some devices. The other was the "standard" JSR 184, and I worked with at least two separate dev studios that had each implemented that in OpenGLES/C++ so that porting their 3D titles from J2ME to iOS/Brew could be reduced to an almost copy/paste business. This lasted maybe about two years before bothering with J2ME output was abandoned, but a side effect is the scene graphs for a lot of old iOS "premium" games look a lot like the one in JSR 184.
It definitely took Android a while to get to that level of performance; the first few versions didn't even have JIT for Dalvik, while I think even Sun's MIDP implementation had it.
OpenGL also only became available on Android 1.6, while J2ME devices usually had either Mascot Capsule or JSR 184 as you say (sometimes backed by software rendering, but some S60 devices had a mobile GPU backing it, I believe).
I believe opengles 1.0 was available from the first public release of android - though some sources claim 1.6 added opengles 1.1 support.
Though I think there were sometimes difference in what was exposed between the NDK and in java - e.g. opengles2.0 was supported in the NDK at android 2.0, but not in java until android 2.2
Also I only moved away from Symbian when it was clear the war was lost.
N95 was the first Symbian with hardware rendering.
Do you know of any of those tools that are available? ProGuard Obfuscator is the only tool I know of to optimize your jar.
The best I knew of performed several tricks that the public research community assumes to be impossible. The big problem we had was making it totally deterministic as part of ensuring we had reproducible builds.
Of the public obfuscators in that era the most useful came from a company called dasho.
Now I can’t remember the name of that company from Switzerland…
They did some early work on dalvik but it didn’t fly commercially iirc…
I think they've pivoted into microcontroller stuff.
I suppose Google did something right with Dalvik (other than improving their "It's not Java!" stance for copyright reasons), i.e. introduce a bytecode file format that can share constants across Java classes :)
An example was IBM's Websphere Real Time JVM.
Really not missing doing J2ME development (even though at the time I heard that straight up Symbian was far-far worse).
I remember from the early 2000s you could get railway time tables from the German railways for your selected pair of stations as a midlet. That was truly useful.
I also used a mobile browser frontend. The data was rendered by the backend and transferred in compressed form. That was very usable at 2G speeds. Of course JavaScript was rare at the time. But I don't think the product was any commercial success.
Of cause their were (mostly toy) games. But in general the technology was probably 10+ years too early for the market.
Java’s attempt to make the GNU/Linux terminology nitpicking portable? ;)
Wasn’t there also CLDC, CDC etc.? I could never figure out what the hierarchy there was – was MIDP above or below C(L)DC?
All devices I ever encountered were of the MIDP and CLDC type, in any case.
I think bottom up it's Java, J2ME, CLDC, MIDP.
So the programmer really works with MIDP.
I vaguely remember PP (Personal Profile IIRC). That was probably CDC/PP. Nokia either put it into one of the communicators or at least intended to so. 9210 I'd guess. But apps were extremely rare.
I seem to remember them actually rewriting (rendering?) the web page server side, and then sending an optimized mobile friendly version to make it more readable for pages that were originally designed for desktop.
It worked great on my phone and I even used it when the phones were more cabable, because web pages looked better and it saved a lot of bandwidth.
Opera Mini still works today on S60 phones from 2006ish. I regularly see web server log entries from a relative on my private server. But I believe it's a native Symbian app (.sis) not a Midlet. (I have working phones, but I don't have Opera Mini, so I cannot verify)
IIRC for WAP the only way to use form elements was JavaScript as there was no equivalent of HTML <form> that would just submit the request automatically.
Deleted Comment
I got super interested with these in high school, because I finally got a Nokia N73 and that phone had the best and most complete J2ME implementation.
But I only had a netbook (atom cpu, 1gb ram, rotational hard disk) so I ended up coding J2ME using Emacs, a poorly written ant buildfile (due to my poor understanding of Ant) and the J2ME javadoc in a browser.
Those were the times, for me.
Oh to be young again...
This wasn't meant to start a competition on who's older. I was just meaning to express the fondness of my memories about J2ME and those times.
I remember being so hopeless staring into the decompiled java code for my favorite games trying to learn something from it and spin into my own game.
I'm now an (aspiring) android dev, and looking back at the past I can only say "Damn, it has gotten so much better since then"
I'd love to see a J2ME emulator for iOS, now that they're tolerated by Apple on the App Store, but that would probably be tricky due to the lack of JIT compilation (presumably yours just leans on standard Hotspot for Java execution?)
I'm not sure what you meant by that standard hotspot - it can run on java 8 (in my case I use openjdk) albeit it uses the ASM library to modify class bytecode (a custom classloader, used for things like loading resources) and importantly, there are JNI native parts.
I'm not an iOS developer, so I can't help here, but my ultimate plan was to make it run.. on the web! Unfortunately this is not feasible since it'd require a custom webgl-based m3g and mascot capsule v3 implementation.. also CheerpJ is said to be too slow. But technically you can run the "freej2me-plus" fork (no natives but no 3d support) on the web via CheerpJ (I hope that works on iOS)
The Java it supported was very old fashioned, with no generics. Which was a pain at times.
https://engineering.fb.com/2016/07/13/android/the-mobile-dev...
I think it is fair to say that no serious developer will publish an app without testing on at least 2-3 physical devices.
The most infuriating thing was extreme fragmentation when it came to support of various APIs in devices, even devices from the same vendor. Nokia was prominently culpable of this. The Finnish giant vomited out an enormous stream of S40 and S60 phones whose support for APIs was all over the map, which meant producing a shitload of JARs depending of what you needed, and the code was cluttered with constant checks of what is supported and what not. What an irony given Java's official motto of "Write once, run anywhere". Just freaking no.
Being a developer for Nokia was its own kind of hell. They never understood what API standardization is for and didn't care about your time and effort.
Hey, here are 12 different devices for this year with different hardware, screen size and other equipment, and you'd better get your hands on all of them to make sure that your app really works and looks acceptably, because an emulator only gets you half way. Also, any firmware update from us can kick your house of cards apart, and there will be like three of them coming in the next year. Happy programming!
I wouldn't be surprised if this was actually one of the reasons why Sun fought MS and Google when they tried to make their own "Java" versions (embrace+extend). They didn't want a repeat of the J2ME situation.
Also, they don't have wifi, and they only do GSM 900/1800, have fun testing in the US.
The unofficial motto was "Write once, debug everywhere"
Of course, doing things equivalent to what J2ME did on kilobytes of RAM and storage requires hundreds of megabytes for webapps now...
https://www.youtube.com/watch?v=IsD6irFkY_0