7 ms·

J2ME-Loader: J2ME emulator for Android devices

108 points by flykespice 2y ago

usr1106 2y ago
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 2y ago
  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 https://www.coderanch.com/t/229735/Opera-Mini-browser
  - dbtablesorrows 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
    It still does! Ancient versions still work absolutely fine on old phones.
  - throwaway04324 2y ago
    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 2y ago
      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!
      - deleted 2y ago
        [deleted]
  - usr1106 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
  > 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.
  - deleted 2y ago
    [deleted]
- lxgr 2y ago
  > 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 2y ago
    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 2y ago
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 2y ago
  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-device-lab-at-the-prineville-data-center/ https://engineering.fb.com/2016/07/13/android/the-mobile-dev...
  - dale-cooper 2y ago
    Having experience with both platforms I'd say it's not comparable. J2ME was much worse in this regard.
    - pjmlp 2y ago
      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 2y ago
        Perhaps I'm spoiled from working mostly with React Native nowadays and have forgotten the pain :)
  - daghamm 2y ago
    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 2y ago
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 https://www.mobilephonemuseum.com/phone-detail/vodafone-gx10
compsciphd 2y ago
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 2y ago
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 2y ago
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 2y ago
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 2y ago
  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 2y ago
    > 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 2y ago
    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 2y ago
  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 2y ago
Here's my fork of FreeJ2ME, the desktop equivalent with m3g/mascot capsule support: https://github.com/zb3/freej2me https://github.com/zb3/freej2me
- lxgr 2y ago
  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?)
  - zb3 2y ago
    Thanks :D I'm not sure what you meant by that standard hotspot - it can run on java 8 (in my case I use openjdk) albeit it uses the ASM library to modify class bytecode (a custom classloader, used for things like loading resources) and importantly, there are JNI native parts. I'm not an iOS developer, so I can't help here, but my ultimate plan was to make it run.. on the web! Unfortunately this is not feasible since it'd require a custom webgl-based m3g and mascot capsule v3 implementation.. also CheerpJ is said to be too slow. But technically you can run the "freej2me-plus" fork (no natives but no 3d support) on the web via CheerpJ (I hope that works on iOS)
    - lxgr 2y ago
      What I meant by "standard Hotspot" is Oracle/OpenJDK's standard JVM – I believe it only works using JIT compilation these days, and therefore can't run on iOS (since Apple doesn't allow any third-party JIT). There does seem to be an "interpreted only" mode [1], but obviously that by itself does not make an OpenJDK port for iOS feasible either. > but my ultimate plan was to make it run.. on the web! WASM would actually be an interesting path to get a J2ME emulator to iOS! I believe WASM code generation at runtime might be the closest thing on iOS you could get to JIT on iOS from a performance point of view (since the iOS WASM implementation itself compiles to native code, I believe). [1] https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE https://docs.oracle.com/en/java/javase/11/tools/java.html#GU...
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 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 2y ago
    Not having Symbian C++ love, with build scripts being a mix of batch files and Perl scripts? :)
    - 2y ago
kamalamomala 2y ago
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 2y ago
Oh man I played a lot of J2ME games in the past. Fishlabs games, Attack Chopper, various Gameloft games...
lxgr 2y ago
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 2y ago
  From peeking through the code, it seems the latter. It manually implements j2me api (javax.microedition.* packages and extensions) over the android api.
  - lxgr 2y ago
    Ah yes, and there also seems to be a DEX (Dalvik's bytecode format) library included: https://github.com/nikita36078/J2ME-Loader/tree/master/dexlib https://github.com/nikita36078/J2ME-Loader/tree/master/dexli...
butz 2y ago
Very sad, that current dumbphones does not support J2ME. It is almost impossible to write own application for most recent Nokia keypad phones.
- lxgr 2y ago
  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...
  - butz 2y ago
    There are a few models from Nokia running KaiOS (based in Boot2Gecko from FirefoxOS). Lower end devices had MediaTek MRE running and even some sort of dubious SDK available. Most recent Nokia devices switched to Unisoc chips and there seems to be no developer tools available.
thrance 2y ago
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 https://www.youtube.com/watch?v=IsD6irFkY_0

108 points by flykespice 2y ago

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 2y ago
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 https://www.coderanch.com/t/229735/Opera-Mini-browser
- dbtablesorrows 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
  It still does! Ancient versions still work absolutely fine on old phones.
- throwaway04324 2y ago
  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 2y ago
    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!
    - deleted 2y ago
      [deleted]
- usr1106 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
> 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.
- deleted 2y ago
  [deleted]
lxgr 2y ago
> 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 2y ago
  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 2y ago

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 2y ago
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-device-lab-at-the-prineville-data-center/ https://engineering.fb.com/2016/07/13/android/the-mobile-dev...
- dale-cooper 2y ago
  Having experience with both platforms I'd say it's not comparable. J2ME was much worse in this regard.
  - pjmlp 2y ago
    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 2y ago
      Perhaps I'm spoiled from working mostly with React Native nowadays and have forgotten the pain :)
- daghamm 2y ago
  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 2y ago

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 https://www.mobilephonemuseum.com/phone-detail/vodafone-gx10

compsciphd 2y ago

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 2y ago

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 2y ago

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 2y ago

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 2y ago
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 2y ago
  > 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 2y ago
  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 2y ago
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 2y ago

Here's my fork of FreeJ2ME, the desktop equivalent with m3g/mascot capsule support: https://github.com/zb3/freej2me https://github.com/zb3/freej2me

lxgr 2y ago
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?)
- zb3 2y ago
  Thanks :D I'm not sure what you meant by that standard hotspot - it can run on java 8 (in my case I use openjdk) albeit it uses the ASM library to modify class bytecode (a custom classloader, used for things like loading resources) and importantly, there are JNI native parts. I'm not an iOS developer, so I can't help here, but my ultimate plan was to make it run.. on the web! Unfortunately this is not feasible since it'd require a custom webgl-based m3g and mascot capsule v3 implementation.. also CheerpJ is said to be too slow. But technically you can run the "freej2me-plus" fork (no natives but no 3d support) on the web via CheerpJ (I hope that works on iOS)
  - lxgr 2y ago
    What I meant by "standard Hotspot" is Oracle/OpenJDK's standard JVM – I believe it only works using JIT compilation these days, and therefore can't run on iOS (since Apple doesn't allow any third-party JIT). There does seem to be an "interpreted only" mode [1], but obviously that by itself does not make an OpenJDK port for iOS feasible either. > but my ultimate plan was to make it run.. on the web! WASM would actually be an interesting path to get a J2ME emulator to iOS! I believe WASM code generation at runtime might be the closest thing on iOS you could get to JIT on iOS from a performance point of view (since the iOS WASM implementation itself compiles to native code, I believe). [1] https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE https://docs.oracle.com/en/java/javase/11/tools/java.html#GU...

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 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 2y ago
  Not having Symbian C++ love, with build scripts being a mix of batch files and Perl scripts? :)
  - 2y ago

kamalamomala 2y ago

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 2y ago

Oh man I played a lot of J2ME games in the past. Fishlabs games, Attack Chopper, various Gameloft games...

lxgr 2y ago

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 2y ago
From peeking through the code, it seems the latter. It manually implements j2me api (javax.microedition.* packages and extensions) over the android api.
- lxgr 2y ago
  Ah yes, and there also seems to be a DEX (Dalvik's bytecode format) library included: https://github.com/nikita36078/J2ME-Loader/tree/master/dexlib https://github.com/nikita36078/J2ME-Loader/tree/master/dexli...

butz 2y ago

Very sad, that current dumbphones does not support J2ME. It is almost impossible to write own application for most recent Nokia keypad phones.

lxgr 2y ago
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...
- butz 2y ago
  There are a few models from Nokia running KaiOS (based in Boot2Gecko from FirefoxOS). Lower end devices had MediaTek MRE running and even some sort of dubious SDK available. Most recent Nokia devices switched to Unisoc chips and there seems to be no developer tools available.

thrance 2y ago

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 https://www.youtube.com/watch?v=IsD6irFkY_0