# Java ME and Symbian: same phone, different worlds - **Format:** Editorial research note - **Scope:** Technical distinction and preservation consequences - **Status:** Evidence-backed orientation; validate against a specific build and handset before execution The old mobile-software catalogue is full of a misleading shorthand: *“the Java version”* versus *“the Symbian version.”* It sounds as though Java ME and Symbian were two makes of phone, or two rival operating systems. They were neither. A single Symbian handset could run both kinds of software, sometimes carrying two materially different versions of the same game. One was a small Java application living inside a managed runtime; the other could be a native citizen of the phone's operating system. They shared a pocket. They did not share the same technical world. This is why an archive cannot use a title alone as an identity. “*Game X for Nokia*” may conceal separate Java ME and Symbian releases, each with different assets, controls, screen assumptions, save data, dependencies, permissions, and routes to faithful execution. Preservation begins by naming the layer correctly. ## The short answer **Symbian is an operating system and native application platform.** It manages a handset's processes, files, services, hardware-facing APIs, and application installation. A conventional Symbian application was normally compiled for a particular Symbian generation and platform/UI family, then installed through a Symbian installation package (`.sis` or, on later generations, `.sisx`). **Java ME—usually called J2ME in the period—is a family of Java specifications and runtimes for constrained devices, not an operating system.** Its familiar phone combination was CLDC plus MIDP: a small Java virtual machine and core libraries, with mobile APIs for a MIDlet's lifecycle, display, networking, and record-store persistence. A MIDlet suite commonly arrived as a `.jar`, with a `.jad` descriptor used by the device's application-management software.[^jme-sdk] The relationship is therefore nesting, not substitution: ```text handset hardware └── Symbian OS (on a Symbian handset) ├── native Symbian application └── Java ME implementation └── MIDlet suite (JAR, often with JAD) ``` Not every phone had Symbian; not every Symbian phone exposed the same Java ME features. But where a Java ME implementation was present, the MIDlet ran *on top of* the host system rather than replacing it. Java ME also ran on many non-Symbian phones. That is the central distinction. ## A note on the name Use **Java ME** when writing now and **J2ME** when preserving the period's own terminology. “Java 2 Platform, Micro Edition” was the former name; Oracle's documentation describes Java ME as a platform assembled from a configuration (such as CLDC) and a profile (such as MIDP).[^jme-glossary] For archive metadata, normalise “J@ME” to **Java ME** (with **J2ME** retained as a historical search term), rather than creating a false platform category. ## Two creative bargains The Java ME bargain was reach. A developer wrote Java bytecode against a bounded set of APIs and asked a device's Java runtime to execute it. The common MIDP profile supplied the essential mobile vocabulary: a display toolkit, input, network connections, a simple persistent record store, and the MIDlet lifecycle. The platform deliberately divided its baseline into **configurations**, **profiles**, and optional packages.[^midp-overview] That division helped a game travel from one Java-capable handset to another without being rewritten from scratch. The price was that “write once, run anywhere” was an ambition, not a preservation warranty. A JAR might require a particular MIDP or CLDC version, an optional JSR, or a manufacturer extension; it might be designed around a 128×160 portrait screen, a particular soft-key layout, or a vendor's sound implementation. The MIDP runtime can also make device-specific APIs available beyond the base profile.[^midp-lifecycle] A build labelled merely “Java” is consequently still underspecified. The Symbian bargain was reach *into the handset*. Native software could use the operating system's application frameworks and, when authorised, more capable platform services. That made richer integration possible, but tied the result more closely to operating-system version, UI platform, processor architecture, ROM and device behaviour. “Symbian” itself is not enough either: S60, UIQ, and other platform layers are part of the question, not decorative product names. This is not a clean hierarchy in which native always means better and Java always means lesser. A well-made MIDlet can be the canonical experience for a title; a native port can be a different game wearing the same name. The difference is in the execution contract. Java ME delegates much of that contract to a Java runtime; native Symbian software asks the operating-system platform to honour its compiled agreement directly. ## The technical seam: runtime, package, permissions | Question | Java ME / J2ME MIDlet | Native Symbian application | | --- | --- | --- | | What is it? | Java application running in a Java ME implementation | Compiled application running as part of the Symbian software environment | | Usual distribution unit | MIDlet suite: `.jar`, often accompanied by `.jad` | Symbian installation package: `.sis` or `.sisx` | | Essential compatibility clues | CLDC/MIDP versions, optional JSRs, vendor APIs, screen and key layout | Symbian OS release, UI platform/edition, CPU/ROM, package contents, device family | | Application control | The application-management software starts, pauses, resumes, and destroys a `MIDlet` | The native framework and OS manage the application's processes and services | | Permission model | A MIDlet suite requests named permissions and is placed in a protection domain; some actions may be granted by signing or user consent | Later Symbian platform security uses capabilities, signing, and data caging; requirements vary by OS generation and platform | | Preservation unit | The suite **plus** its declared and observed runtime contract | The installer **plus** the device/platform environment needed to install and run it | The package distinction is not clerical. In MIDP, a MIDlet is not launched through an ordinary `main()` method: it extends `MIDlet`, and the application-management software sequences its lifecycle. The JAR holds classes and resources; the descriptor supplies installation and configuration attributes when present.[^midp-lifecycle] That makes the JAR, JAD, manifest, and their relationship evidentiary objects. Native Symbian packages carry a different history. In the S60 3rd Edition era, platform security introduced capability levels and mandatory signing for `.sis` files; applications seeking restricted APIs needed the appropriate certification. [^s60-security] A broader platform-security account names the three relevant ideas: capabilities, application signing, and data caging.[^symbian-security] Do not retroactively apply that exact policy to every Symbian release—security and packaging rules changed over time—but do record the release-specific evidence. The two permission systems also fail differently. A Java ME suite declares the permissions it requires or can optionally use in `MIDlet-Permissions` attributes; the runtime's protection domain and user policy decide whether protected actions are allowed.[^midp-security] A Symbian native build may instead encounter a missing capability, an installation-signing constraint, or a protected-data boundary. Both can look like “it will not run” to a modern operator. They are not the same defect, and they should not be repaired with the same undocumented workaround. ## The familiar name is not an identity Imagine two listings for the same publisher, title, and year. The Java ME release might be a 176×208 MIDlet with a `Canvas` renderer, a small bundled soundtrack and a record-store save. The Symbian release might install an executable, native assets and libraries, present a different control scheme, and expect the services of a particular S60 generation. Each may be perfectly authentic. Neither is a substitute for the other. For this archive, the safe identity chain is: ```text work/title → platform family → release → build → target device/runtime → evidence ``` `platform family` must explicitly distinguish **Java ME** from **Symbian native**. `target device/runtime` must preserve the facts that make the build executable—not only the marketing handset name. This applies the archive's existing requirement to model game → platform → build → device, rather than treating a file extension as a platform verdict.[^archive-manual] ## What to preserve alongside the binary ### For a Java ME build - Keep the original `.jar`, any `.jad`, the JAR manifest, acquisition provenance, hashes, and a record of whether the descriptor and archive agree. - Record CLDC and MIDP targets, optional JSRs or manufacturer APIs, language and locale, screen geometry, orientation, keypad mapping, and observed audio/input behaviour. - Record the Java ME implementation and host device used for verification. A compatible JAR is not proof of equivalent timing, rendering, prompts, or controls. - Preserve install and permission observations separately from the binary: download route, requested permissions, prompts, signature state, and save-data location/format where known. ### For a native Symbian build - Keep the original `.sis`/`.sisx`, package metadata and contents, hashes, provenance, and any associated data files without breaking their relationship. - Record Symbian OS generation, UI platform and edition, precise handset profile, processor/ROM or firmware prerequisites, display and input assumptions, and installation result. - Record declared capabilities, signing/certificate evidence, installation date conditions when observed, drive/file-path expectations, and relevant emulator configuration. - Separate an observed workaround from the authentic runtime condition. An archive may document a compatibility intervention without presenting it as the original installation experience. In either case, inspect rather than infer. A filename is a lead, not provenance; a shop description is not a build manifest; and a claim that a game “runs on Nokia” is not a compatibility record. Preserve the original artifact under the project's rights-aware access policy, then attach the evidence that lets a future operator reproduce the result without guessing. ## The preservation conclusion Java ME and Symbian meet at the handset, not at the archival object. Java ME is a portable application environment whose portability has edges. Symbian is a mobile operating-system environment whose power has local commitments. Their common history is exactly why collectors encounter them together; their different contracts are exactly why Jarassic Park must catalogue, emulate, and explain them apart. That separation is not pedantry. It is how a recovered game stops being a file that happens to launch and becomes a reproducible experience with an honest technical lineage. ## Sources and evidence notes [^jme-sdk]: Oracle, [*Java ME SDK 3.0: CLDC Projects*](https://docs.oracle.com/javame/dev-tools/jme-sdk-3.0-win/html-helpset/z400008c1314271.html). Defines the CLDC/MIDP stack and describes a MIDlet suite's JAR/JAD distribution. [^jme-glossary]: Oracle, [*Java ME 8 glossary*](https://docs.oracle.com/javame/8.0/get-started-ioe/glossary.htm). Defines Java ME, CLDC, MIDP, JAR, JAD and MIDlet terms. [^midp-overview]: Oracle, [*MID Profile overview*](https://docs.oracle.com/javame/config/cldc/ref-impl/midp1.0/jsr037/overview-summary.html). Lists the MIDP UI, persistence, lifecycle and networking packages. [^midp-lifecycle]: Oracle, [*MIDP 2.0 `javax.microedition.midlet` package*](https://docs.oracle.com/javame/config/cldc/ref-impl/midp2.0/jsr118/javax/microedition/midlet/package-summary.html). Documents suite packaging, optional device APIs and the MIDlet lifecycle. [^midp-security]: Oracle, [*MIDP 2.0 authorization model*](https://docs.oracle.com/javame/config/cldc/ref-impl/midp2.0/jsr118/javax/microedition/midlet/doc-files/Authorization.html). Documents protection domains and required/optional permissions. [^s60-security]: Nokia Developer Library mirror, [*S60 3rd Edition*](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-3D0085C4-22AD-4F15-ADC9-0085649650E1.html). Historical release documentation for platform security and signing. [^symbian-security]: Symbian Platform Development Kit mirror, [*Platform security architecture*](https://akawolf.org/documentation/pdk/GUID-EA20E614-C911-4EE9-92B5-C8F9B657D59E.html). Historical overview of capabilities, signing and data caging. [^archive-manual]: Jarassic Park, [*Symbian heritage archive system manual*](../foundations/symbian-heritage-archive-system-manual.md#11-eka2l1--existing-infrastructure). Project preservation rule to model game → platform → build → device.