Java Card places application logic in a constrained card or secure-element environment. A host sends commands; the selected card applet processes them and returns data plus status. Understanding that boundary is the first useful step before choosing a kit, reader or card.
Identify the host, runtime and applet
The host application talks through a reader or another transport. The card runtime manages applets and dispatches commands. An applet implements a narrow protocol and works within the memory, API and lifecycle rules of its target platform. A regular Java desktop program and a Java Card applet have different execution environments.
Start with Oracle’s Java Card documentation and record the specification version, development tools, simulator version and physical target separately. The simulator release notes define the kit’s scope and requirements. A kit version number is not the same thing as the platform specification number.
On narrow screens, scroll this table horizontally. Keyboard users can focus it and use the arrow keys.
| Stage | Purpose | Evidence to keep |
|---|---|---|
| Develop and convert | Build an applet for the target API and packaging rules | Source, build configuration and tool versions. |
| Load and install | Place the package and create an applet instance | Authorized management procedure and identifiers. |
| Select | Choose an applet for commands | Application identifier and response status. |
| Process and reset | Handle commands and defined state changes | Protocol tests, persistence rules and reset behavior. |
Real card management involves issuer authorization and deployment policies. Begin with a disposable development target or the official simulator, using the kit’s own examples. Production credentials and payment applets require a separate engineering and security process.
Read a command and response
An APDU command has a class byte (CLA), instruction byte (INS), two parameter bytes (P1 and P2), and optional length/data fields. The response can carry data followed by two status bytes, SW1 and SW2. The Java Card APDU API describes the runtime’s command-buffer and transfer model, including cases where input arrives in portions.
Consider this deliberately small teaching protocol. Its private example AID is F0 01 02 03 04 05. A select request is 00 A4 04 00 06 F0 01 02 03 04 05: the 06 denotes six identifier bytes. After selection, the invented command 80 10 00 00 02 asks for two version bytes. The response 01 00 90 00 contains version bytes 01 00 followed by success status 90 00.
These bytes define an educational protocol only. They are not commands for a bank card, identity credential or arbitrary secure element. Real selection options, status conventions and command cases must follow the target application specification.
Run the protocol model
The download is an ordinary Java 25 program with a small state machine. It models selection and a few responses without loading an applet or contacting a reader.
Download the source, checks and README (ZIP)
javac ApduLab.java
java ApduLab8010000002 -> 6985
00A4040006F00102030405 -> 9000
8010000002 -> 01009000
8020000002 -> 6D00
8010000001 -> 6700The first command fails the model’s selected-state rule. Selection then succeeds; a version query returns data and status. Changing the instruction produces the unsupported-instruction response; requesting the wrong length produces a length error. The executable checks compare every response with the expected bytes.
This model accepts only the exact short-command forms shown. It omits transport negotiation, logical channels, extended lengths, cryptography and actual Java Card memory semantics. Its purpose is to make byte layout and state visible before a full development environment adds more variables.
Move from the model to a real applet
Use the official kit’s sample build and simulator instructions first, keeping their required host JDK and supported platform together. Verify installation, selection and one documented command before changing the applet. Record each input and expected response in a regression transcript.
Then add boundary tests: malformed lengths, unsupported instructions, selection of another applet, resets and interrupted operations. Decide which state must survive reset and how partially completed updates are recovered using the target runtime’s documented persistence and transaction facilities. A simulator can establish functional behavior within its model; testing and security evaluation on the intended card address different questions.
The downloadable teaching model was compiled and checked on a desktop JDK. No physical card provisioning or official Java Card simulator run is claimed here. Its next step is a documented kit exercise using your chosen platform, not sending guessed commands to a credential in use.