# Port a J2ME game > Java ME games ran on 176 by 220 screens with a numeric keypad and a few hundred kilobytes of heap. Porting one is mostly a rescale and a redesign. - URL: https://www.summerengine.com/port-a-j2me-game - Keyword: port a j2me game - Related: https://www.summerengine.com/porting Porting a J2ME game means rebuilding a Java ME MIDlet you own for hardware that still exists. The Java ME runtime is gone from consumer devices, so the original JAR only runs in an emulator such as J2ME Loader or FreeJ2ME. These games were built under constraints that no longer apply. Screens were commonly 128 by 128 or 176 by 220. Heap was often under a megabyte. The whole game shipped as a JAR of a few hundred kilobytes with a JAD descriptor next to it. Input was a numeric keypad with soft keys. The code targeted MIDP 2.0 and CLDC 1.1, with optional APIs for sound and 3D that varied by handset. Every one of those constraints becomes a design decision in the port. The pixel art is tiny and precise, which scales beautifully with integer scaling. The code is small enough to read in a day. The game loop assumed a fixed low frame rate. Summer Engine rebuilds it as a project you own that exports desktop builds for Steam and itch.io. ## Getting your content out of a JAR A JAR is a ZIP archive. Unpack your own file and the PNG sprites, tilemaps, level data, and any MIDI or WAV audio are usually sitting there in plain form. The compiled classes can be decompiled to read the original logic, which is legitimate for a game you wrote or clearly license. Keep the JAD file too, since it records the MIDlet name, version, and the device profile the game targeted. That tells you the original screen size and API assumptions. ## Screen size is the biggest change A 176 by 220 portrait canvas is a fraction of a modern display. Decide early between two approaches. Preserve the original resolution and scale it up with integer scaling and nearest neighbour filtering, which keeps the art exact and adds letterboxing. Or rebuild at a higher resolution with re-authored art, which suits a commercial re-release. Either way, keep the pixel grid honest, because these sprites were drawn pixel by pixel and any smoothing destroys them. ## Keypad input becomes touch or a gamepad The original used number keys for movement, 5 for action, and the two soft keys for menus. Modern targets have none of that. On mobile, map the directional set to swipes or a small touch layout and keep the verb count low, which is easy because these games rarely had more than three actions. On desktop, map to keyboard and a gamepad. Rebuild the soft key menu bar as a normal interface rather than reproducing the two button convention. ## Logic that assumed tiny hardware Java ME game loops were frame counted at low and inconsistent rates, often around 15 to 20 frames per second, with manual sleep calls. Convert that to delta time so the game behaves the same at 60 frames per second and above. Fixed point math used to avoid slow floating point can become plain floats. Record Store persistence becomes ordinary save files. Vendor specific APIs for sound or vibration are replaced with standard engine features. ## Where an old Java phone game can go now The obvious target is mobile, where the game finally has memory to spare and a colour screen larger than it ever expected. iOS and Android builds need that platform's toolchain and signing and a pass on touch input. A GDScript rebuild can also ship as a web build on Summer Games. Steam works if the game is expanded with more content, options, and controller support. Many J2ME era games were good designs starved of hardware, and that is exactly what a port fixes. ## FAQ ### Can I run a J2ME game on a modern phone? Only through an emulator such as J2ME Loader or FreeJ2ME. No current phone ships a Java ME runtime. For a distributable product you rebuild the game rather than emulate it. ### Can I extract art and code from my own JAR? Yes. A JAR is a ZIP archive, so sprites and audio unpack directly, and the class files can be decompiled to recover the logic. Do this only for a game you created or clearly license. ### How do I handle the original tiny resolution? Either keep the native resolution and scale it with integer scaling and nearest neighbour filtering, or re-author the art at a higher resolution. Do not apply smoothing filters to sprites drawn pixel by pixel. ### Does the Java code transfer? Not as running code. MIDP and CLDC classes do not exist outside Java ME. The logic is rewritten in GDScript or C++, using the decompiled source as an exact specification of the original behavior. ### Who owns an old mobile game from that era? Often a publisher or the operator who commissioned it, not the studio that built it. Java ME games were frequently work for hire with distribution rights held elsewhere. Confirm the rights before planning a commercial release. ### Is a J2ME port worth doing commercially? It can be, with added content and modern conveniences. These games were short by necessity. Expanding the design, adding saves and options, and shipping on Steam and mobile is a realistic path for a title with a real audience behind it. [Start the rebuild](https://www.summerengine.com/download) --- ## Machine-readable resources - Site index for agents: https://www.summerengine.com/llms.txt - Full inlined content: https://www.summerengine.com/llms-full.txt - Porting catalog: https://www.summerengine.com/llms-porting.txt - Structured catalog: https://www.summerengine.com/agent-catalog.json - Sitemap: https://www.summerengine.com/sitemap.xml - Developer resources: https://www.summerengine.com/docs