JavaCard CAP Components
The 12 component types inside a JavaCard CAP file. Mandatory vs optional, what each carries, and why each matters for the on-card verifier.
What this reference covers
Spec
JavaCard Virtual Machine Specification 3.x §6.
Companion tool
Reading
What this reference does not cover
The component list describes the CAP file format, not the loading process. How a package actually reaches a card is a GlobalPlatform matter: INSTALL for load, a sequence of LOAD blocks, then INSTALL for install, all inside an authenticated secure channel. A structurally valid CAP file will still be refused if that sequence or its keys are wrong.
Nor does it cover on-card resource limits, which are what most deployment problems come down to. Persistent storage is small and has finite write endurance, transient memory is smaller still, and a package that converts cleanly can exhaust either. Size the applet against the target chip before treating a failed install as a format problem.
Frequently asked questions
What is a CAP file?
The deployment unit of a JavaCard applet: a set of components carrying converted class data in the form the card installer consumes.
Why twelve components?
So the card can load selectively. Header and Directory describe the package, Applet and Method carry executable content, Import and ConstantPool carry linkage, Descriptor and Debug are optional metadata.
Which components can be omitted in production?
Descriptor and Debug. They are stripped to save scarce on-card storage and are not needed to install or run the applet.
What does the Import component do?
Lists the packages this one depends on by AID and version. A version mismatch against the card is a common cause of installation failures that look like file corruption.
How does a CAP file differ from a JAR?
A JAR holds class files for a full JVM. A CAP file holds a converted, linked, space-optimised form for the JavaCard VM, which has no class loader and very little memory.