Sun and Oracle Community Voices How to Buy Log In United States [Change] English

»  Spotlight Articles
»  Projects
»  Publications
»  People
»  Awards
»  Events
»  Downloads
»  Internships
»  Contrarian Minds
»  About Sun Labs
Squawk for Java Card 3.0

Squawk for Java Card 3.0

(2002-2003)

The primary goal of the Squawk for Java Card 3.0 project was to build a very small footprint CLDC-compatible Java virtual machine.  A secondary goal was to write as much of the system as possible in Java.

The next generation Java Card platform, 3.0, will use 32-bit microprocessors, but will have very limited memory, potentially no more than 8 kB of RAM, 32 kB of non-volatile memory, and 160 kB of ROM. The major challenge of the project was thus to get complete KVM functionality in such constrained space.

The Squawk for Java Card 3.0 implementation makes use of a split VM architecture: an off-device translator which pre-verifies classfiles and translates them into spaced-optimized collections of classes called suites, and the on-device VM that interprets the suites.  Suites average about 35% the size of J2ME classfiles.  The whole VM is written in Java and tested under the Hotspot VM.  For deployment purposes, the VM code is translated into C code and compiled using an optimizing C compiler.

The static footprint of the core system (interpreter, a RAM garbage collector, an non-volatile memory garbage collector), compiled from C, is 25 kB on x86.  The minimum runtime footprint in RAM is 520 bytes for the Java heap and 532 bytes for native stack and data (on x86).  The runtime performance of Squawk is close to that of the KVM.

The Squawk for Java Card 3.0 was considered by the Java Card Forum as one of the candidate for standardization as the next generation Java Card runtime technology.

Related Publications

The team

Nik Shaylor, Doug Simon, and Bill Bush.

Back to the Squawk Project


Contact: Bill Bush