SavaJe proposed a phone in which Java reached beyond downloadable games into the handset’s application environment and interface. The LG handset announced in November 2005 illustrates that ambition. Its story is useful for understanding how runtime APIs, device services, interface design and operator control fit together—and why each needs separate evidence.
Follow the evidence through the platform’s history
The Mobile Phone Museum’s LG SavaJe handset record dates its announcement to November 8, 2005 and documents a slider design with a 176 × 220 display. The catalog describes operator customization as a central aim. That is evidence of the handset design and announcement; a claim about widespread retail shipment would require separate records.
On narrow screens, scroll the table horizontally. Keyboard users can focus it and use the arrow keys.
| Date | Evidence | Interpretation |
|---|---|---|
| 2005 | The JCP’s Personal Profile 1.1 work lists SavaJe among its expert-group members. | SavaJe participated in the Java mobile standards ecosystem. |
| November 8, 2005 | LG SavaJe handset announcement, documented by the museum. | A concrete handset project and operator-focused platform proposal. |
| January 2008 | James Gosling discusses acquired SavaJe code in a published interview. | A documented connection to Sun’s contemporary JavaFX Mobile initiative. |
In ADTmag’s January 2008 interview with James Gosling, Gosling says JavaFX Mobile was based on code acquired from SavaJe. This is a first-person account of that technology connection. It supports the lineage described here without establishing which LG devices shipped, in which markets or in what quantities.
Understand the layers of the proposed phone
The 2005 platform description emphasized Java applications, a Java-based handset interface and access to phone services. The diagram below is an explanatory model of those responsibilities, not a vendor block diagram or a claim that all phone firmware was written in Java.
- Hardware and low-level services: the processor, display, radio and device support make physical operations possible.
- Runtime and platform APIs: application code uses the Java execution environment and the implemented service interfaces.
- Interface and built-in applications: menus and everyday handset functions present the device to the user.
- Operator configuration and additional applications: branding, content, distribution and access policies shape what is exposed.
Consider a fictional address-book application that offers a call button. Rendering the button, reading a contact and initiating a call are different responsibilities. A familiar Java language syntax helps the programmer express the application; the device’s APIs and permissions determine whether those operations are available. A successful UI demonstration alone leaves the telephony integration to be verified.
Place CDC, CLDC and profiles in context
Java ME configurations describe a runtime foundation and core APIs, while profiles and optional packages add capabilities for particular device classes. The CLDC 1.1 specification record concerns resource-constrained devices. The CDC 1.1 record addresses a more capable connected-device environment. These are distinct configurations with their own contracts.
The Personal Profile 1.1 specification record places that profile above Foundation Profile/CDC and describes its relationship to Java SE APIs. It also names SavaJe and Vodafone among the initial expert group. Standards participation helps explain the platform’s technical context, but application compatibility still depends on the actual implementation and exposed packages.
When comparing two historical phones, write down the configuration, profile, optional APIs, display/input assumptions and security policy. A claim of Java support needs those details before it can answer whether one particular application will run. The Java mobile game distribution guide shows this problem at the package level.
Ask what an open platform lets someone do
On narrow screens, scroll the table horizontally. Keyboard users can focus it and use the arrow keys.
| Dimension | Question to ask | Evidence that answers it |
|---|---|---|
| Documented APIs | Can a developer learn and use the interfaces? | Specification, SDK documentation and implementation coverage. |
| Source availability | Can the implementation be inspected, modified and redistributed? | The actual source release and its license terms. |
| Application distribution | Who can install and deliver applications? | Device installation, signing and operator distribution policies. |
| Device control | Who can change services, menus and privileged behavior? | Documented permissions and manufacturer/operator configuration tools. |
An operator’s ability to change menus is a different kind of control from an owner’s ability to install any application or replace the operating system. Describe each capability directly and attach it to the relevant actor. The word “open” alone cannot settle those questions.
For a historical exhibit or research note, label artifacts as announced, demonstrated, shipped or independently tested only when the evidence supports that status. Preserve dates, model identifiers and source provenance. This approach lets the SavaJe story explain a distinctive mobile architecture while keeping its commercial reach and implementation details within the surviving record.