Comment by fidotron

Comment by fidotron 18 hours ago

14 replies

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.

lxgr 15 hours ago

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

  • kimixa 10 hours ago

    > 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

  • pjmlp 11 hours ago

    Hence why as Nokia alumni the whole Google's marketing regarding Dalvik never convinced me.

    Also I only moved away from Symbian when it was clear the war was lost.

    N95 was the first Symbian with hardware rendering.

baumschubser 17 hours ago

> Later on there were some incredibly good studio specific optimization tools that handled transformations automatically

Do you know of any of those tools that are available? ProGuard Obfuscator is the only tool I know of to optimize your jar.

  • fidotron 17 hours ago

    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.

lxgr 12 hours ago

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

  • pjmlp 11 hours ago

    That was a path already trailed by JVM implementations for embedded systems, which already translated JVM bytecodes to their internal formats.

    An example was IBM's Websphere Real Time JVM.

    • lxgr 10 hours ago

      Websphere sounds familiar – do you know if that was the one used for Palm OS (ARM only, I believe) by any chance?

      • pjmlp 10 hours ago

        I think not, this was for embedded stuff, soft real time.

        Same domain as Aonix, PTC, Aicas, microEJ, and such.

auselen 16 hours ago

> European VM providers

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…

  • fidotron 16 hours ago

    Esmertec?

    I think they've pivoted into microcontroller stuff.

whizzter 17 hours ago

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

  • pjmlp 11 hours ago

    Not having Symbian C++ love, with build scripts being a mix of batch files and Perl scripts? :)

    • [removed] 9 hours ago
      [deleted]