[HN Gopher] J2ME-Loader: J2ME emulator for Android devices
___________________________________________________________________
J2ME-Loader: J2ME emulator for Android devices
Author : flykespice
Score : 94 points
Date : 2024-09-18 23:17 UTC (23 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| usr1106 wrote:
| 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.
| thomond wrote:
| Was this Opera Mini? I remember installing that on my Nokia
| many years ago. It used compression as well.
| https://www.coderanch.com/t/229735/Opera-Mini-browser
| dbtablesorrows wrote:
| 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).
| dfox wrote:
| Compression is inherent feture of WAP and some WAP browsers
| could use the WAP infrastructure to transfer not only WML,
| but also well-formed XHTML.
| lxgr wrote:
| Opera Mini went way beyond just compression. It
| effectively rendered the website server-side and then
| sent optimized markup to the client (so it's much closer
| to "print site to SVG" on the server than "Content-
| encoding: gzip").
| 71bw wrote:
| It still does! Ancient versions still work absolutely fine on
| old phones.
| throwaway04324 wrote:
| 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.
| lxgr wrote:
| They rendered the site server-side (including JavaScript
| execution for a couple of seconds and all) and then sent
| the rendered page in some binary markup language to the
| client, with images heavily compressed.
|
| I actually still sometimes use it on iOS! The app is no
| longer available in most (all?) App Store regions, but I
| still have it on my account and can redownload it. The
| servers seem to still be there!
| usr1106 wrote:
| 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)
| lysace wrote:
| Perhaps Reqwireless? Acquihired by Google to work on the
| WAP dead-end iirc, when then they were figuring out how to
| deal with mobile.
| usr1106 wrote:
| Reqwireless I have certainly heard. Don't remember in
| which context. If you tell me they had this "browser
| frontend" midlet, it's probably the one I used. 2002ish I
| would guess.
| dfox wrote:
| > Of course JavaScript was rare at the time.
|
| 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.
| lxgr wrote:
| > J2ME is an unprecise term. I'd guess they mean J2ME/MIDP. The
| other profiles did even fly less probably.
|
| 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.
| usr1106 wrote:
| Right those existed, too.
|
| 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.
| black_knight wrote:
| 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.
| pjmlp wrote:
| Android is no different, even though Google used to say
| otherwise to push Android over J2ME.
|
| https://engineering.fb.com/2016/07/13/android/the-mobile-dev...
| dale-cooper wrote:
| Having experience with both platforms I'd say it's not
| comparable. J2ME was much worse in this regard.
| pjmlp wrote:
| I also have experience across Sharp, Nokia and Sony Ericson
| devices from J2ME days, and whatever brands ship Android
| phones, and outside flagship Android models, it is a jungle
| out there in drivers, AOSP customisations, vendor specific
| APIs, so I am of different point of view.
| dale-cooper wrote:
| Perhaps I'm spoiled from working mostly with React Native
| nowadays and have forgotten the pain :)
| daghamm wrote:
| Even iOS exist in many different sizes and configurations
| these days. If you look closer at the pictures in that post
| you will see multiple iphones.
|
| I think it is fair to say that no serious developer will
| publish an app without testing on at least 2-3 physical
| devices.
| pjmlp wrote:
| True, but iOS doesn't have OEMs having their own forks,
| which takes this to the same level as J2ME used to be.
|
| Whatever they come up in GUI features, changes to AOSP
| behaviours, custom drivers, their own extended SDKs on top,
| hardware form factors,...
| daghamm wrote:
| If you mean Chinese or Russian OEMs with their own
| version of ASOP, well that's not really Android anymore
| and is not using the Play app store anyway.
|
| Western devices have to go through certification to use
| the name Android, so its not the wild wild west you think
| it is (although obviously some bugs may fall through).
|
| See for example
|
| https://source.android.com/docs/compatibility/cts
| pjmlp wrote:
| I certainly mean Android device I can buy in any European
| country from the lame 100 euros pre-paid throwaway phone
| up to 2000 euros three ways foldable phone, plus
| everything else running Android on cars, kiosks, TVs,
| handhelds and everywhere else Android gets installed as
| alternative to GNU/Linux by OEMs.
|
| CTS only covers a subset of what everyone is doing with
| Android.
|
| And it will never cover everything, because as the
| Android team likes to point out, they don't want to
| stiffle the innovation of their partners.
| sunaookami wrote:
| You wish. Xiaomi is especially popular in Europe and has
| countless specific bugs. This "certification" does
| nothing.
| inglor_cz wrote:
| I have a few J2ME apps under my belt as well.
|
| 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!_
| throwaway04324 wrote:
| > 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.
| pjmlp wrote:
| Sun lawsuit against Microsoft predated J2ME, and was
| related to language changes.
| ralferoo wrote:
| > Java's official motto of "Write once, run anywhere"
|
| The unofficial motto was "Write once, debug everywhere"
| toast0 wrote:
| > Hey, here are 12 different devices for this year with
| different hardware, screen size and other equipment
|
| Also, they don't have wifi, and they only do GSM 900/1800,
| have fun testing in the US.
| pjmlp wrote:
| This brings back memories, as someone that start developing for
| mobile phones targeting Sharp GX 10 for a Vodafone competition.
|
| https://www.mobilephonemuseum.com/phone-detail/vodafone-gx10
| compsciphd wrote:
| so we've had some success getting libbluray with java working on
| android (i.e. needed for bluray's java support), but that
| requires an entire jvm built for android (heavy). I've always
| wondered if a j2me emulator (as bluray's java spec is built on
| top of j2me as I understand it), would be an easier way.
| nevster wrote:
| 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.
| lormayna wrote:
| I remember one of my senior colleagues (I was just an internship)
| making a J2ME app to calculate who should pay the coffee for
| others.
| znpy wrote:
| Oh the memories, J2ME.
|
| 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...
| markb139 wrote:
| You think you're old? I was part of the team at the other end
| of that stack building and debugging the Java runtime for the
| Nokia Symbian phones :)
| znpy wrote:
| > You think you're old?
|
| 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.
| lxgr wrote:
| Thank you, you did an amazing job! My hot take is that J2ME
| on Symbian was better than the native API/runtime in some
| aspects :)
| flykespice wrote:
| One of my very first ventures into programming as a little
| child was trying to figure out how to write my own games for my
| nokia phone.
|
| 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"
| zb3 wrote:
| Here's my fork of FreeJ2ME, the desktop equivalent with
| m3g/mascot capsule support: https://github.com/zb3/freej2me
| lxgr wrote:
| 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?)
| fidotron wrote:
| 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 wrote:
| 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 wrote:
| Not having Symbian C++ love, with build scripts being a mix
| of batch files and Perl scripts? :)
| baumschubser wrote:
| > 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 wrote:
| 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.
| auselen wrote:
| > 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 wrote:
| Esmertec?
|
| I think they've pivoted into microcontroller stuff.
| lxgr wrote:
| 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).
| pjmlp wrote:
| 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.
| kimixa wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| Websphere sounds familiar - do you know if that was the one
| used for Palm OS (ARM only, I believe) by any chance?
| pjmlp wrote:
| I think not, this was for embedded stuff, soft real time.
|
| Same domain as Aonix, PTC, Aicas, microEJ, and such.
| kamalamomala wrote:
| Oh the special hell that were JSRs. As others mentioned, buying a
| crapload of multi-vendor devices to deploy specific JARs in hope
| to cover a sizeable customer base (not games, but public
| transport related).
| alwyn wrote:
| Oh man I played a lot of J2ME games in the past.
|
| Fishlabs games, Attack Chopper, various Gameloft games...
| lxgr wrote:
| What a great tool!
|
| Does anybody here know how it works at a high level? Does it
| implement a JVM, or is the bytecode recompiled to target
| Android's Dalvik?
| flykespice wrote:
| From peeking through the code, it seems the latter.
|
| It manually implements j2me api (javax.microedition.* packages
| and extensions) over the android api.
| lxgr wrote:
| Ah yes, and there also seems to be a DEX (Dalvik's bytecode
| format) library included:
| https://github.com/nikita36078/J2ME-
| Loader/tree/master/dexli...
| butz wrote:
| Very sad, that current dumbphones does not support J2ME. It is
| almost impossible to write own application for most recent Nokia
| keypad phones.
| lxgr wrote:
| Don't they run some version of Firefox OS these days?
|
| Of course, doing things equivalent to what J2ME did on
| kilobytes of RAM and storage requires hundreds of megabytes for
| webapps now...
| thrance wrote:
| 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.
|
| https://www.youtube.com/watch?v=IsD6irFkY_0
___________________________________________________________________
(page generated 2024-09-19 23:01 UTC)