3 ms·
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
by fidotron 2y ago
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.
- whizzter 2y agoUgh, 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 2y agoNot having Symbian C++ love, with build scripts being a mix of batch files and Perl scripts? :)
- whizzter 2y agoI don't think I ever built anything, just looked at some files in the SDK iirc. My colleague did mention something about having to use memory handles since the system could move around memory from under you?
- deleted 2y ago[deleted]
- baumschubser 2y 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 2y agoNo, 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.
- auselen 2y 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…
- lxgr 2y agoAt 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).
- pjmlp 2y agoHence 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.
- kimixa 2y 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
- lxgr 2y 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 2y agoThat 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.