7 ms·

I worked at a startup, Javaground [1], where we ported and developed games for J2ME phones. We had a room full of dressers full of all the different mobile pho

I worked at a startup, Javaground [1], where we ported and developed games for J2ME phones. We had a room full of dressers full of all the different mobile phones of the day. Each phone had different implementation quirks, such as variable audio delay when playing a file, audio/image formats that were faster/slower, odd button events (some used press, some used ondown, some had no ondown, etc). A lot of our work was learning all of these quirks and implementing them into the automated porting platform. Then the iPhone came out and started to build momentum. I still have my old flip phone, the one with the least quirks, with some of our games on it. 1: https://en.wikipedia.org/wiki/Javaground https://en.wikipedia.org/wiki/Javaground

meheleventyone 5y ago
My very first industry job was making J2ME games and oh my god does it still give me nightmares.
- pjmlp 5y ago
  If you miss it, just try Android, contrary to Google arguments against J2ME, the fragmentation experience is kept unchanged.
  - m45t3r 5y ago
    We have many more issues supporting multiple versions of iOS than supporting multiple versions of Android. But neither are not even close to the nightmare that was J2ME.
    - pjmlp 5y ago
      Another one that wasn't blessed with OEM deviations from AOSP.
      - m45t3r 5y ago
        We have "been blessed" with OEM deviations from AOSP (we have a big number of clients and most of them are using Android because of regional characteristics), but still we have way more issues with customers using out-dated iOS versions than users on those devices. For comparison, we have way more iOS issues than Android ones, even if Android is the vast majority of our user base (~70% of our customers). Anyway, even including those cases it is still very far from J2ME days.
        pjmlp 5y ago
        - Bluetooth issues - Camera is hit and miss, even after the renewed API - Apps randomly killed on the background - Intents that don't launch as expected - NDK debugging that cannot attach to the server running on the device - Unstable GPGPU drivers - Keyboard handling - Perfectly working code that needs to be rewritten just because Yeah so much better than J2ME.
        EvilEy3 5y ago
        > - Bluetooth issues Aren't they rewriting this thing in Rust? > - Camera is hit and miss, even after the renewed API Give it time. CameraX is already vastly better than what we had before. > - Apps randomly killed on the background Up to OEMs. > - Intents that don't launch as expected ? > - NDK debugging that cannot attach to the server running on the device Welp. > - Keyboard handling Fixed. > - Perfectly working code that needs to be rewritten just because ?
        pjmlp 5y ago
        - Devices never see updates, other than a select few flagship models - It does not matter if the blame is on Google or OEMs, it is still fragmented
        techrat 5y ago
        Circular arguments are circular.
  - throwaway894345 5y ago
    Especially with respect to Bluetooth quirks. Every single phone has a different set of bugs in its bluetooth components, and none of those sets are remotely empty. In the end, we decided we could only afford to support the 5 most popular models of the day and if you don't have that phone, then too bad for you.
    - selfhoster11 5y ago
      Don't get me started on programming with BLE on Android. *shudders*
      - throwaway894345 5y ago
        Our management kept asking us to fix these issues with software. We tried things like transparently rebooting our BT module and prompting the user to do common fixes (e.g., "turn your phone off and on again") but most of the time these wouldn't work, unsurprisingly.
      - markmark 5y ago
        I literally yesterday had to buy my first iphone since the 3G because my wife bought some BLE hardware for her work that won't work properly with her Pixel 3. (It's a set of 12 devices and the Pixel can only connect to six at a time). The manufacturer won't even list Android devices they claim to have tested it with.
    - viraptor 5y ago
      That one doesn't seem like purely on Android. I've never seen a device without Bluetooth bugs. The protocol is so complicated and implementation relies so much on chips that never get fixes that I'm surprised it works anywhere.
      - throwaway894345 5y ago
        I wasn't criticizing Android, I was criticizing Android phones. I'm sure iPhone doesn't implement the protocol perfectly either, but we certainly observed fewer issues. Whether that's because our BT stack vendors did more testing with Apple devices or because Apple has fewer bugs or both, I'm not sure.
  - moshmosh 5y ago
    It's not as bad as it used to be. The "drawers full of devices", all terrible and broken in unique ways, gave me flashbacks to the Android 2.x days.
    - pjmlp 5y ago
      They are still quite actuall, https://pamartinezandres.com/running-android-tests-on-cloud-devices-using-a-jenkins-ci-server-firebase-test-lab-amazon-device-b67cb4b16c40 https://pamartinezandres.com/running-android-tests-on-cloud-...
  - grishka 5y ago
    It's gotten much much better in the modern times. Android 2.x would break your app in many spectacular ways, but Google has been steadily adding more coverage to its "compliance test suite" that a device must pass to be eligible for Play Services preinstall. On 4.x, there were some Chinese phones, like Xiaomi and Meizu, that meddled with notifications, action bars and list views, sometimes to the point of making your app crash, and I do remember having to work around them. But if you support Android 6.0+, like many new apps do these days, you don't have to worry much about device compatibility.
- taneq 5y ago
  I read the J2ME spec, looked at the procedure to draw an array of pixels to the screen, and noped out of there. Browser Java was bad enough, but J2ME? I wasn't gonna do that to myself.
  - pjmlp 5y ago
    What was so hard about it? http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/mid/ui/DirectUtils.html#createImage(byte[],%20int,%20int http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/m...) http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/mid/ui/DirectGraphics.html http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/m...
usertrjx 5y ago
I worked with a few people from JG. I also worked on a bunch of J2me games. It was an interesting time to be in mobile.
- EarthLaunch 5y ago
  I was just out of college, like the 5th employee at Irvine, a lowbie gamedev. I remember doing some collab with nearby studios (like WF), one where my future wife worked!
tauntz 5y ago
Ah, it's nostalgia-a-clock. I worked on Skype for J2ME with a 3-4 person dev team. Custom UI kit, 128x128 screens, 128kb available memory and other fun limitations.. I think we re-wrote our text rendering/styling/wrapping code more times than there were actual releases of the app :) I honestly miss these times - it sparked so much creativity when one needed to achieve something in such a limited environment.
- Andrew_nenakhov 5y ago
  Also that version of Skype was way better than this hot steaming pile of manure currently shipped by Microsoft.
  - tauntz 5y ago
    Thank you! It really was a different era back then :)
- mgkimsal 5y ago
  > I honestly miss these times - it sparked so much creativity when one needed to achieve something in such a limited environment. As someone from the c64/apple][/atari generation... it was constantly amazing to see how much people could push a single device. Lots of creativity, as you say. But... we seemed to hit a wall with the whole j2me-era of "just get creative to work around things!" mindset. Because, IIRC, there were dozens of different devices that all didn't work the same way - you'd have to get really creative to get things to work in 128k, but then do it again and again and again for each target device. There were millions of C64 units in people's hand in, say, 1986. And similar for Apple ][ units. You could be assured of a decent audience/sales/users if you ported to that platform, even if there was a lot of 'creativity' to deal with. The j2me device world always seemed a lot more fragmented to me (but maybe it wasn't?). But just saying "this runs on a java device" was different from distribution - allowing 'regular' people to get something in to a centralized store/distribution point seemed another big win for the iPhone world. EDIT: fwiw, this made me spend a few minutes in youtube looking at old c64 and apple and Atari demos. what people ended up doing with those devices - years after they were mainstream - is still crazy to me.
SLWW 5y ago
> Java be like, "we are cross-platform" > mobile manufacturers, "hold my phone" The problem with cross-platform development in a nutshell. Still to this day writing an Android/iOS app using PCL code is a headache
- viraptor 5y ago
  At least adapting to another private API was easier because the scope was pretty small. It's probably lost forever now, but I had a project which repacked jars to add a few wrapper classes to convert Nokia-specific j2me games to be compatible with my Siemens.
  - SLWW 5y ago
    Yeah; as things get more complicated though i feel that this concept will never return
definitelyhuman 5y ago
Oh wow, yeah my first mobile game studio had a huge industrial fastener shelf with little drawers stuffed with different phones. We started in 2004, and feature phone game dev was indeed wild. We did a lot of WWE games in 2d and 3d, needing ~15 different reference builds ranging from 64k 2d builds to 800k 3d for high end, plus another set for all the BREW devices. Managing code, asset pipelines, and qa across high/med/low 2d/3d Java/cpp permutations was a huge challenge, but it was so satisfying to be good at. I love what mobile has turned into, and never want to debug another random c crash on device ever again, but I do miss the cabinet of phones and all the crazy variation
MobileVet 5y ago
I remember Javaground!! We actually worked with the BREW platform, so we only had 50 phones instead of the 300 java ones. Lol, too funny
- EarthLaunch 5y ago
  Cool! The BREW automation guy at JG was a genius C coder. Those phones seemed more capable in general...but just as quirky.

meheleventyone 5y ago

My very first industry job was making J2ME games and oh my god does it still give me nightmares.

pjmlp 5y ago
If you miss it, just try Android, contrary to Google arguments against J2ME, the fragmentation experience is kept unchanged.
- m45t3r 5y ago
  We have many more issues supporting multiple versions of iOS than supporting multiple versions of Android. But neither are not even close to the nightmare that was J2ME.
  - pjmlp 5y ago
    Another one that wasn't blessed with OEM deviations from AOSP.
    - m45t3r 5y ago
      We have "been blessed" with OEM deviations from AOSP (we have a big number of clients and most of them are using Android because of regional characteristics), but still we have way more issues with customers using out-dated iOS versions than users on those devices. For comparison, we have way more iOS issues than Android ones, even if Android is the vast majority of our user base (~70% of our customers). Anyway, even including those cases it is still very far from J2ME days.
      - pjmlp 5y ago
        - Bluetooth issues - Camera is hit and miss, even after the renewed API - Apps randomly killed on the background - Intents that don't launch as expected - NDK debugging that cannot attach to the server running on the device - Unstable GPGPU drivers - Keyboard handling - Perfectly working code that needs to be rewritten just because Yeah so much better than J2ME.
        EvilEy3 5y ago
        > - Bluetooth issues Aren't they rewriting this thing in Rust? > - Camera is hit and miss, even after the renewed API Give it time. CameraX is already vastly better than what we had before. > - Apps randomly killed on the background Up to OEMs. > - Intents that don't launch as expected ? > - NDK debugging that cannot attach to the server running on the device Welp. > - Keyboard handling Fixed. > - Perfectly working code that needs to be rewritten just because ?
        pjmlp 5y ago
        - Devices never see updates, other than a select few flagship models - It does not matter if the blame is on Google or OEMs, it is still fragmented
        techrat 5y ago
        Circular arguments are circular.
- throwaway894345 5y ago
  Especially with respect to Bluetooth quirks. Every single phone has a different set of bugs in its bluetooth components, and none of those sets are remotely empty. In the end, we decided we could only afford to support the 5 most popular models of the day and if you don't have that phone, then too bad for you.
  - selfhoster11 5y ago
    Don't get me started on programming with BLE on Android. *shudders*
    - throwaway894345 5y ago
      Our management kept asking us to fix these issues with software. We tried things like transparently rebooting our BT module and prompting the user to do common fixes (e.g., "turn your phone off and on again") but most of the time these wouldn't work, unsurprisingly.
    - markmark 5y ago
      I literally yesterday had to buy my first iphone since the 3G because my wife bought some BLE hardware for her work that won't work properly with her Pixel 3. (It's a set of 12 devices and the Pixel can only connect to six at a time). The manufacturer won't even list Android devices they claim to have tested it with.
  - viraptor 5y ago
    That one doesn't seem like purely on Android. I've never seen a device without Bluetooth bugs. The protocol is so complicated and implementation relies so much on chips that never get fixes that I'm surprised it works anywhere.
    - throwaway894345 5y ago
      I wasn't criticizing Android, I was criticizing Android phones. I'm sure iPhone doesn't implement the protocol perfectly either, but we certainly observed fewer issues. Whether that's because our BT stack vendors did more testing with Apple devices or because Apple has fewer bugs or both, I'm not sure.
- moshmosh 5y ago
  It's not as bad as it used to be. The "drawers full of devices", all terrible and broken in unique ways, gave me flashbacks to the Android 2.x days.
  - pjmlp 5y ago
    They are still quite actuall, https://pamartinezandres.com/running-android-tests-on-cloud-devices-using-a-jenkins-ci-server-firebase-test-lab-amazon-device-b67cb4b16c40 https://pamartinezandres.com/running-android-tests-on-cloud-...
- grishka 5y ago
  It's gotten much much better in the modern times. Android 2.x would break your app in many spectacular ways, but Google has been steadily adding more coverage to its "compliance test suite" that a device must pass to be eligible for Play Services preinstall. On 4.x, there were some Chinese phones, like Xiaomi and Meizu, that meddled with notifications, action bars and list views, sometimes to the point of making your app crash, and I do remember having to work around them. But if you support Android 6.0+, like many new apps do these days, you don't have to worry much about device compatibility.
taneq 5y ago
I read the J2ME spec, looked at the procedure to draw an array of pixels to the screen, and noped out of there. Browser Java was bad enough, but J2ME? I wasn't gonna do that to myself.
- pjmlp 5y ago
  What was so hard about it? http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/mid/ui/DirectUtils.html#createImage(byte[],%20int,%20int http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/m...) http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/mid/ui/DirectGraphics.html http://www.j2megame.org/j2meapi/Nokia_UI_API_1_1/com/nokia/m...

usertrjx 5y ago

I worked with a few people from JG. I also worked on a bunch of J2me games. It was an interesting time to be in mobile.

EarthLaunch 5y ago
I was just out of college, like the 5th employee at Irvine, a lowbie gamedev. I remember doing some collab with nearby studios (like WF), one where my future wife worked!

tauntz 5y ago

Ah, it's nostalgia-a-clock. I worked on Skype for J2ME with a 3-4 person dev team. Custom UI kit, 128x128 screens, 128kb available memory and other fun limitations.. I think we re-wrote our text rendering/styling/wrapping code more times than there were actual releases of the app :) I honestly miss these times - it sparked so much creativity when one needed to achieve something in such a limited environment.

Andrew_nenakhov 5y ago
Also that version of Skype was way better than this hot steaming pile of manure currently shipped by Microsoft.
- tauntz 5y ago
  Thank you! It really was a different era back then :)
mgkimsal 5y ago
> I honestly miss these times - it sparked so much creativity when one needed to achieve something in such a limited environment. As someone from the c64/apple][/atari generation... it was constantly amazing to see how much people could push a single device. Lots of creativity, as you say. But... we seemed to hit a wall with the whole j2me-era of "just get creative to work around things!" mindset. Because, IIRC, there were dozens of different devices that all didn't work the same way - you'd have to get really creative to get things to work in 128k, but then do it again and again and again for each target device. There were millions of C64 units in people's hand in, say, 1986. And similar for Apple ][ units. You could be assured of a decent audience/sales/users if you ported to that platform, even if there was a lot of 'creativity' to deal with. The j2me device world always seemed a lot more fragmented to me (but maybe it wasn't?). But just saying "this runs on a java device" was different from distribution - allowing 'regular' people to get something in to a centralized store/distribution point seemed another big win for the iPhone world. EDIT: fwiw, this made me spend a few minutes in youtube looking at old c64 and apple and Atari demos. what people ended up doing with those devices - years after they were mainstream - is still crazy to me.

SLWW 5y ago

> Java be like, "we are cross-platform" > mobile manufacturers, "hold my phone" The problem with cross-platform development in a nutshell. Still to this day writing an Android/iOS app using PCL code is a headache

viraptor 5y ago
At least adapting to another private API was easier because the scope was pretty small. It's probably lost forever now, but I had a project which repacked jars to add a few wrapper classes to convert Nokia-specific j2me games to be compatible with my Siemens.
- SLWW 5y ago
  Yeah; as things get more complicated though i feel that this concept will never return

definitelyhuman 5y ago

Oh wow, yeah my first mobile game studio had a huge industrial fastener shelf with little drawers stuffed with different phones. We started in 2004, and feature phone game dev was indeed wild. We did a lot of WWE games in 2d and 3d, needing ~15 different reference builds ranging from 64k 2d builds to 800k 3d for high end, plus another set for all the BREW devices. Managing code, asset pipelines, and qa across high/med/low 2d/3d Java/cpp permutations was a huge challenge, but it was so satisfying to be good at. I love what mobile has turned into, and never want to debug another random c crash on device ever again, but I do miss the cabinet of phones and all the crazy variation

MobileVet 5y ago

I remember Javaground!! We actually worked with the BREW platform, so we only had 50 phones instead of the 300 java ones. Lol, too funny

EarthLaunch 5y ago
Cool! The BREW automation guy at JG was a genius C coder. Those phones seemed more capable in general...but just as quirky.