• LTS JDK 11, 17 or 21
  • NOTE: minimal JDK MAY be changed to 17 in future, to be in sync with https://github.com/martinpaljak/ant-javacard/wiki/JavaCard-SDK-and-JDK-version-compatibility
• git clone --recursive https://github.com/martinpaljak/jcardsim
• cd jcardsim && ./mvnw initialize && ./mvnw verify

<repositories>
    <repository>
        <id>javacard-pro</id>
        <url>https://mvn.javacard.pro/maven/</url>
    </repository>
    <!-- for SNAPSHOT version -->
     <repository>
         <id>javacard-pro-snapshots</id>
         <url>https://mvn.javacard.pro/maven/SNAPSHOTS/</url>  
     </repository>
</repositories>

<dependency>
    <groupId>com.github.martinpaljak</groupId>
    <artifactId>jcardsim</artifactId>
    <version>25.06.07-SNAPSHOT</version>
</dependency>

jcardsim does not implement JavaCard API in 100% vanilla Java. Instead, it relies heavily on the ASM bytecode manipulation library to inject the proxy classes (that resemble JavaCard SDK API by shape) into the vanilla SDK API classes during compile time (Maven's process-classes lifecycle), based on a manual mapping as defined by the processing tool.

This assures that the interface fields (constants etc) are copied verbatim, but still requires substantial mirroring of the source and manual coupling on code level.

The proxy classes do the minimal scaffolding necessary (with many crypto objects it is neatly just returning the necessary implementations from getInstance(...) that return actual implementation classes. Actual crypto (that normally is selectively implemented by JavaCard platform) is implemented with the help of BouncyCastle Java provider.

Both Oracle's simulator and standard jcardsim assume that "card lifetime" is "process lifetime" - if the process dies, the card state is destroyed and a new simulator process (or simulator instance, in case of jcardsim) starts with a fresh and clean card.

There is code in jcardsim that supposedly allow to persist card state to a file, with the help of kryo, so a card state could be "shelved" much like a physical card.

Issues with jcardsim and focus of the fork is split as follows:

• "core" and platform correctness
  • JC API revision conformance (transient keys, OneShot etc)
  • internal structures and interfaces (not visible to users)
  • build scaffolding (Maven, ASM, GHA, repo etc)
  • threading assumptions
• algorithm completeness and correction
  • PACE_GM, bugs etc
• interfacing and DX
  • virtual readers (javax.smartcardio, VSmartCard, BixVReader, Oracle PC/SC)
  • explicit composition of card (applets) vs indirect properties + instantiation
  • command line tool (not unlike GlobalPlatformPro)
  • interfacing to Oracle Simulator from same framework

Refs:

• https://forums.oracle.com/ords/apexds/post/jcdk24-1-amservice-generating-applet-code-coverage-using-c-9778