Getting the source and building

• LTS JDK 17, 21 or 25
  • Somewhat in sync with https://github.com/martinpaljak/ant-javacard/wiki/JavaCard-SDK-and-JDK-version-compatibility
• git clone --recursive https://github.com/martinpaljak/jcardengine
• cd jcardengine && ./mvnw initialize && ./mvnw verify
• use tool/target/jcard.jar

[!NOTE] the main branch (for now) is next, from what snapshots are built and PR-s should be made against.

Dependencies

• SLF4J (MIT)
• BouncyCastle (MIT)
• ASM (3-Clause BSD)
• ByteBuddy (Apache 2.0)
• GlobalPlatformPro (LGPL 3)
• jopt-simple (MIT)

Modus Operandi

JCardEngine relies on ASM bytecode manipulation library to inject proxy classes (that resemble JavaCard SDK API by shape) into the vanilla Java Card 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.

Threading and thread-safety

Instances of JavaCardEngine are NOT designed to be thread-safe, and should only be handled from a single controlling thread. Connections to a JavaCardEngine are thread-safe.

Composition over inheritance

Most internal classes shall be final and promote composition instead of inheritance as in jcardsim.