Ein verbessertes Sicherheitsmodell.
Das Sicherheitsrahmenwerk von MIDP 1.0 wurde überarbeitet und unterteilt die MIDlets in zwei Kategorien: Trusted und Untrusted. Hier weiterlesen »

Der persistente Speicher dient für Anwendungsdaten, die dauerhaft gespeichert werden müssen (Konfigurationsdateien, Highscores etc.) und auch nicht beim Ausschalten oder dem Wechsel des Geräteakkus verloren gehen dürfen.

Eine Configuration wird mit Hilfe von Profilen für bestimmte Geräte-Familien spezialisiert und erweitert. MIDP für Handys ist das erste und wichtigste Profil das Sun zur Verfügung stellt. Hier weiterlesen »

Mit der rasanten Weiterentwicklung im Bereich der mobilen Hardware nimmt sowohl die Rechenleistung als auch die Speicherausstattung der Endgeräte zu. Dementsprechend wurde die Nachfolgeversion CLDC 1.1 mit zusätzlichen Fähigkeiten ausgestattet. Hier weiterlesen »

Garbage Collection:
Die finalize() – Methode wird auch nicht unterstützt, diese wird in der Standardedition aufgerufen bevor die Objekte dem Garbage-Collector zum Opfer fallen. Hier weiterlesen »

Threads:
Ebenso sind Thread Groups oder Deamon Threads nicht möglich, genauso wenig wie Weak References. Threads können also nicht zu Gruppen zusammengefasst und so hierarchisch gegliedert werden. Hier weiterlesen »

Classloader:
Es gibt auch keine benutzerdefinierten Classloader. Die KVM verwendet einen fest eingebauten Classloader, die Möglichkeit ihn zu ersetzen besteht nicht. Hier weiterlesen »

Reflection:
Reflection ermöglicht es, Metadaten über die Struktur von Klassen, Methoden und Variablen zur Laufzeit bereitzustellen. Hier weiterlesen »

Java Native Interface:Aus Sicherheitsgründen fehlt das Java Native Interface ( JNI ) völlig, damit lassen sich in der J2SE native Funktionsaufrufe realisieren. Hier weiterlesen »

Fehlerbehandlung:
Auch im Bereich der Klassen Exception und Error ist die API eingeschränkt. Die CLDC 1.0 unterstützt keine „harten Fehler“ aus der Oberklasse java.lang.Error. Hier weiterlesen »