The first thing I ever wrote that other people used was a j2me app freshman year in college. It was a power hour app that played a random simpsons .wav every minute.
I was a pretty poor CS student, in hindsight I'm surprised I got it to work.
One of the very first "hacks" I did was finding instructions via a random WAP website on how to patch a J2ME game for some early phone that could run .jar games, in order to effectively crack it.
I used j2me in the early 2000s to make a mobile app where people could find home data. My first startup experience. Learned a lot but didn't earn a lot.
I can still remember setting up palette swapping (inspired by retro consoles, but still a common contemporary idea e.g. on GBA) by loading the byte data of PNG resources into an array and locating and replacing the PLTE chunk before handing it off to the MIDP image loader. Always wondered if anyone else had picked up the trick. I can also remember people suggesting on Nokia in particular to just store raw bitmaps (since they'd be compressed in the JAR anyway) with their API and that this was saving tons of space for some people... later I found out that one of these reports came from someone who had started out with individual image files for 12x12 tiles that had a full 256-entry PLTE (i.e., more colour entries than pixels).
I also remember a device-specific bug where doing something like `x[y+1]`, where `y` was a static byte set to -1, would produce an `IndexOutOfBoundsError` claiming the index used was -256. I assume this was some threading issue in the Java implementation, where the value would be loaded into a register and then the sign-extension would somehow affect the register after the increment. I only ever reproduced it with static class members, I think (but it did also happen with shorts).
Mr. zahlman, can you please share the source code of "palette swapping by loading the byte data of PNG resources into an array and replacing the PLTE chunk before handing it to the MIDP image loader"?
The Egyptians were able to build pyramids with fairly limited technology. It doesn’t mean the technology was not limited, just means it took a ton of effort. Same thing with your Google Maps example.
IIRC FileInputStream objects in J2ME can only seek (skip) forward. If you might need data from before your current position, you can either reopen the file, or cache the data as you go (if you have the ram). Reverse seek wasn't added until Java 1.4, and J2ME is based on Java 1.3
That's just good old fashioned hacking. Wasn't this more a reflection of the various platforms' limited memory resources, and not really anything to do with J2ME?
Thanks for making me feel old!
One of my first real jobs involved MIDP/J2ME development. I cannot say I loved the platform, but it somehow felt more magical back then to develop something and run it on a Nokia brick than (mobile) development of today.
Wow this brings back a lot. I did J2ME at Macrospace/Glu, Masabi, Javaground and EA, and at one point near the end was simultaneously responsible for 128k jars of Tetris and 4GB apk + obb for Real Racing because that is how rapidly the field exploded. Absolute madness.
J2ME gets a lot of stick, but modern mobile has actually recreated almost all the same problems. The big one for apps was the out of the box UI components were awful and utterly inconsistent between manufacturers. Several of the above companies tackled this (think conceptually like Flutter), but the market wasn't ready largely because data plans were expensive.
For games though, honestly, J2ME was dreadful, but in non-obvious ways: the control interfaces were hopeless, and sound was basically a non starter. People would be willing to forgive a lot more had the controls and sound been decent. Then the graphics stuff was just inconsistent enough that too much time ended up focused on portability and not enough on if the game was actually as fun as it should be. A consequence of that is most of the best J2ME games were ports from other systems or shameless reskins of other things.
But there is something to be said about taking a tube/metro/bus and seeing people playing stuff you did and enjoying it, especially given back then it was impossible to know who the players really were since things were sold through the carriers.
Startup I used to work at fueled Cingular's mobile storefront and distributed those J2ME games along with ringtones and graphics. Those were the days...
Ah, the good old days of browsing wap sites to download "apps". Installing some of them only to find that my budget phone doesn't support the j2me profile required to run them.
The java ecosystem of those days had similar terms like the servlet (still surviving), applet & midlet. Is there a significance of the suffix "let" or somebody thought let's add "let" to everything.
One of the difficulties I had searching for J2ME resources is that the mobile equivalent of the JVM is called KVM (K virtual machine), so most of the search results are about Linux's Kernel-based virtual machine instead.
MeBoy brings back some memories. I used it to catch so many Pokémon in middle school.
What's really cool about that emulator is the way its sound emulation works. Instead of emulating the Gameboy's synthesizer synchronously and outputting a PCM waveform to a buffer, which is probably impossible on J2ME due to hardware and platform constraints, it uses the phone's own MIDI (or square wave) synthesizer to play whatever the GameBoy synthesizer should be playing. This gives the video game music a very idiosyncratic sound when played back in MeBoy.
Have very fond memories of playing J2ME games. Here's some off the top of my head: Zombie Infection (what a great game!), Galaxy on Fire, Sims, Age of Empires, Real Football, Orcs&Elves, Pokémon Crystal on an emulator...
And of course a limited port of Worms Armageddon that has to be one of the games I sunk the most time on, seeing as I played several matches a day with my friends for an entire school year! Ahh I even scribbled a "campaign mode" on my math notebook during class instead of paying attention!
Memories! I built a race timing app in J2ME. A useful exercise in designing a good UX within a constrained environment. Nowadays we just throw browser bloat around without a care.
You can run it under Android, there's a J2ME emulator at https://f-droid.org. Being both platforms Java-like makes emulation much easier as you will find thousand of competent enough people and OFC it woudn't surprise me if Google made tons of similar functions to J2ME ones at Android in order to ease the transition from former developers.
Gemini (the protocol, no the Google hype) it's close to these contraints, and partially the old Gopher. There's even a Gopher client for J2ME, Pocket Gopher, patched at gopher://hoi.st
It was really a euro thing. Think the whole Jamba/Jamster ecosystem (Crazy Frog) and the explosion that occurred with premium SMS and ringtones.
It was all about selling into carriers associated with that, and that was a recipe for pain. I don't believe anyone made a killing in J2ME directly (Gameloft gave the impression of making most money, not entirely undeservedly), and many absolutely struggled, but it did provide the crucible for a lot of what came later.
One of the more curious incidents that stayed with me related to the game "Fatal Force" which had a 64kb build that was incredibly tight. We were mystified to discover a Chinese pirate was distributing a Chinese build of the game, still within 64kb limits. He had decompiled it, reverse engineered it, added more compression so he could fit in localized assets, and released it. The last I heard on the subject there was an effort to pay him for it.
The other was when a game of a game show was advertised in Germany, during the game show, it would generate such a traffic spike that the servers selling the game got knocked out, leading to requiring outsourcing that function to a more scalable competitor, a lesson that was not forgotten for the next company.
LWUIT wasn't particularly awesome, in my opinion. It was enormous and hideous and couldn't integrate with the native cut-and-paste functionality offered by some phones.
Well... 64kb isn't exactly enormous for the type of functionality it offered. It did support copy and paste you just had to enter editing mode. The underlying APIs didn't offer access to copy and paste directly.
Having said that, it doesn't really matter if you didn't like it. It was a pretty big part of the J2ME ecosystem at the time and it's a huge omission.
Still remember installing those j2me games on my classmate's phones. It was a bit hard to figure out and find the right resolutions versions for each phones.
The first thing I ever wrote that other people used was a j2me app freshman year in college. It was a power hour app that played a random simpsons .wav every minute.
I was a pretty poor CS student, in hindsight I'm surprised I got it to work.
One of the very first "hacks" I did was finding instructions via a random WAP website on how to patch a J2ME game for some early phone that could run .jar games, in order to effectively crack it.
> a power hour app
Pardon?
Alcohol abuse marketed as a social drinking game.
Wow, brings back memories!
I used j2me in the early 2000s to make a mobile app where people could find home data. My first startup experience. Learned a lot but didn't earn a lot.
Wrote a paper about MIDP here: https://www.mooreds.com/midp/midp.html . No idea if it is still relevant 20 years on.
I am glad it was helpful.
Thanks for the paper as well. It explains concepts very clearly with a real-life problem statement. Added it to Awesome J2ME.
I did J2ME development in the 64KB JAR era.
I can still remember setting up palette swapping (inspired by retro consoles, but still a common contemporary idea e.g. on GBA) by loading the byte data of PNG resources into an array and locating and replacing the PLTE chunk before handing it off to the MIDP image loader. Always wondered if anyone else had picked up the trick. I can also remember people suggesting on Nokia in particular to just store raw bitmaps (since they'd be compressed in the JAR anyway) with their API and that this was saving tons of space for some people... later I found out that one of these reports came from someone who had started out with individual image files for 12x12 tiles that had a full 256-entry PLTE (i.e., more colour entries than pixels).
I also remember a device-specific bug where doing something like `x[y+1]`, where `y` was a static byte set to -1, would produce an `IndexOutOfBoundsError` claiming the index used was -256. I assume this was some threading issue in the Java implementation, where the value would be loaded into a register and then the sign-extension would somehow affect the register after the increment. I only ever reproduced it with static class members, I think (but it did also happen with shorts).
Mr. zahlman, can you please share the source code of "palette swapping by loading the byte data of PNG resources into an array and replacing the PLTE chunk before handing it to the MIDP image loader"?
Brings back memories but I can't say they are good. It was so limited that it was mostly frustration.
How limited could it have been? They were able to ship Google Maps Mobile with it.
The Egyptians were able to build pyramids with fairly limited technology. It doesn’t mean the technology was not limited, just means it took a ton of effort. Same thing with your Google Maps example.
IIRC FileInputStream objects in J2ME can only seek (skip) forward. If you might need data from before your current position, you can either reopen the file, or cache the data as you go (if you have the ram). Reverse seek wasn't added until Java 1.4, and J2ME is based on Java 1.3
How limited? We packed booleans inside integers instead of allocating separate booleans :P
That's just good old fashioned hacking. Wasn't this more a reflection of the various platforms' limited memory resources, and not really anything to do with J2ME?
J2ME had much more trouble. Basically on every OS and variations of those for different phones your app could behave differently or not run at all.
Thanks for making me feel old! One of my first real jobs involved MIDP/J2ME development. I cannot say I loved the platform, but it somehow felt more magical back then to develop something and run it on a Nokia brick than (mobile) development of today.
Wow this brings back a lot. I did J2ME at Macrospace/Glu, Masabi, Javaground and EA, and at one point near the end was simultaneously responsible for 128k jars of Tetris and 4GB apk + obb for Real Racing because that is how rapidly the field exploded. Absolute madness.
J2ME gets a lot of stick, but modern mobile has actually recreated almost all the same problems. The big one for apps was the out of the box UI components were awful and utterly inconsistent between manufacturers. Several of the above companies tackled this (think conceptually like Flutter), but the market wasn't ready largely because data plans were expensive.
For games though, honestly, J2ME was dreadful, but in non-obvious ways: the control interfaces were hopeless, and sound was basically a non starter. People would be willing to forgive a lot more had the controls and sound been decent. Then the graphics stuff was just inconsistent enough that too much time ended up focused on portability and not enough on if the game was actually as fun as it should be. A consequence of that is most of the best J2ME games were ports from other systems or shameless reskins of other things.
But there is something to be said about taking a tube/metro/bus and seeing people playing stuff you did and enjoying it, especially given back then it was impossible to know who the players really were since things were sold through the carriers.
> data plans were expensive
Hard to overstate how expensive data was! This was also before widespread wifi.
If you want a look at the way the world worked in 2005, check this out: https://www.consumer-action.org/news/articles/2005_interstat...
Topics included:
- calling cards
- voip
- collect calls!
- international rates
Startup I used to work at fueled Cingular's mobile storefront and distributed those J2ME games along with ringtones and graphics. Those were the days...
And yet there were still some amazing games that today would be considered on the same league of the "impossible ports" for the Nintendo Switch.
Do you have any examples of which games you are referring to?
Ha, nostalgic! Was part of a small 3 person team that built the Skype app for J2ME back in the day. Fun times.. :)
Wow, what a project! I've spent a lot of time on j2me developing various utilities. Those were the good old days when you could try everything on your basic Nokia or Symbian. Here are my applications: https://www.8mobile.org/products/j2me/moneymanager/ https://www.8mobile.org/products/j2me/moneymanager2/ https://www.8mobile.org/products/j2me/rssmanager/ https://www.8mobile.org/products/j2me/spymanager/
Thanks Otto
Ah, the good old days of browsing wap sites to download "apps". Installing some of them only to find that my budget phone doesn't support the j2me profile required to run them.
The java ecosystem of those days had similar terms like the servlet (still surviving), applet & midlet. Is there a significance of the suffix "let" or somebody thought let's add "let" to everything.
-let is a diminutive, signifying something small. Like in piglet or booklet.
https://en.wiktionary.org/wiki/-let
> From Middle English -let, -elet, from Old French -elet, a double diminutive from Old French -el + -et.
Oh, TIL! Thank you.
BTW there is J2ME Loader, a free j2me emulator for android devices available through PlayStore, it plays very nice (you can customize your keys too).
One I noticed is j2me games often don't play music on the background and just resorts to sporadic sounds, any reason for that?
One of the difficulties I had searching for J2ME resources is that the mobile equivalent of the JVM is called KVM (K virtual machine), so most of the search results are about Linux's Kernel-based virtual machine instead.
MeBoy brings back some memories. I used it to catch so many Pokémon in middle school.
What's really cool about that emulator is the way its sound emulation works. Instead of emulating the Gameboy's synthesizer synchronously and outputting a PCM waveform to a buffer, which is probably impossible on J2ME due to hardware and platform constraints, it uses the phone's own MIDI (or square wave) synthesizer to play whatever the GameBoy synthesizer should be playing. This gives the video game music a very idiosyncratic sound when played back in MeBoy.
I used to run MeBoy under Sony w200 phone. With some frameskip Zelda for the GB was somehow playable. Pokémon ran well enough OFC.
Have very fond memories of playing J2ME games. Here's some off the top of my head: Zombie Infection (what a great game!), Galaxy on Fire, Sims, Age of Empires, Real Football, Orcs&Elves, Pokémon Crystal on an emulator...
And of course a limited port of Worms Armageddon that has to be one of the games I sunk the most time on, seeing as I played several matches a day with my friends for an entire school year! Ahh I even scribbled a "campaign mode" on my math notebook during class instead of paying attention!
Memories! I built a race timing app in J2ME. A useful exercise in designing a good UX within a constrained environment. Nowadays we just throw browser bloat around without a care.
Someone should make a 4G LTE/5G dumb phone capable of running J2ME. I'd buy it, my dumb phone doesn't even have snake on it lol
You can run it under Android, there's a J2ME emulator at https://f-droid.org. Being both platforms Java-like makes emulation much easier as you will find thousand of competent enough people and OFC it woudn't surprise me if Google made tons of similar functions to J2ME ones at Android in order to ease the transition from former developers.
Well, you can buy something like a Qin F21 and install this on it! https://f-droid.org/app/ru.playsoftware.j2meloader
I remember creating a J2ME game back at uni, where the theme was to pour a beer exactly right.
Tested of course on the latest SonyEricsson of the time!
Maybe i can dig that out again and run it somewhere.
Root Bear is a modern take for the playdate on that genre: https://alexsussy.itch.io/root-bear
What is the next thing coming up? "Awesome WAP"?
> What is the next thing coming up
Awesome Symbian!
https://github.com/hstsethi/awesome-symbian
While WAP was pretty good too, but I doubt there are enough resources on it to create a seperate list. Same goes for Blackberry, Palm OS and others.
Gemini (the protocol, no the Google hype) it's close to these contraints, and partially the old Gopher. There's even a Gopher client for J2ME, Pocket Gopher, patched at gopher://hoi.st
One of my university projects was an encrypted message system via Bluetooth using J2ME. Never worked, but I learnt a lot of things :)
Blast from the past ! I remember building my last J2ME project ~2012 and struggling to find a Nokia phone to test it
Gosh! The memories! No floating point!
It was fun to build small apps and felt like magic at the time.
gopher://hoi.st has Pocket Gopher, a J2ME gopher client.
Also, you can head to gopher://magical.fish, gopher://hngopher.com and gopher://sdf.org to get 'modern' services and news.
Thanks. I have added the Github repo of it on Awesome J2ME, as Gopher links are not allowed by linter.
Would interesting to hear about J2ME gold rush. Any success (or fail) stories?
It was really a euro thing. Think the whole Jamba/Jamster ecosystem (Crazy Frog) and the explosion that occurred with premium SMS and ringtones.
It was all about selling into carriers associated with that, and that was a recipe for pain. I don't believe anyone made a killing in J2ME directly (Gameloft gave the impression of making most money, not entirely undeservedly), and many absolutely struggled, but it did provide the crucible for a lot of what came later.
One of the more curious incidents that stayed with me related to the game "Fatal Force" which had a 64kb build that was incredibly tight. We were mystified to discover a Chinese pirate was distributing a Chinese build of the game, still within 64kb limits. He had decompiled it, reverse engineered it, added more compression so he could fit in localized assets, and released it. The last I heard on the subject there was an effort to pay him for it.
The other was when a game of a game show was advertised in Germany, during the game show, it would generate such a traffic spike that the servers selling the game got knocked out, leading to requiring outsourcing that function to a more scalable competitor, a lesson that was not forgotten for the next company.
Corecursive had an interesting episode with a good story. https://corecursive.com/mobile-ui-with-shai-almog/
No LWUIT?
Thanks for pointing out the omission. I have added it. It certainly deserves it place there.
LWUIT wasn't particularly awesome, in my opinion. It was enormous and hideous and couldn't integrate with the native cut-and-paste functionality offered by some phones.
Well... 64kb isn't exactly enormous for the type of functionality it offered. It did support copy and paste you just had to enter editing mode. The underlying APIs didn't offer access to copy and paste directly.
Having said that, it doesn't really matter if you didn't like it. It was a pretty big part of the J2ME ecosystem at the time and it's a huge omission.
Still remember installing those j2me games on my classmate's phones. It was a bit hard to figure out and find the right resolutions versions for each phones.