Major differences

This fork is not a drop-in replacement for https://github.com/licel/jcardsim. A bunch of things have been removed to keep it simple and easy to maintain, and a few things have been re-designed to be more explicit and direct, to support the use cases not possible with Oracle simulator. Migration should be simple and straightforward (but no effort shall be made to try to imitate old behaviours).

Simulator as the main and only interface

Each Simulator instance represents a single "secure element" and is isolated from other Simulator instances in a thread. No "runtime sharing". In fact, SimulatorRuntime is gone. Multiple threads can access a single Simulator in a thread-safe way for communication.

Installation parameters fixed

Applets receive installation parameters as they would on a JavaCard - with instance AID, GlobalPlatform privileges, and rest of application installation parameters.

Updated build scaffolding

Software has been split into modules of a simulator core and a command line utility (for starting vsmartcard-style "applet servers")

No shaded artefacts

The dependency to use for your source project is still com.github.martinpaljak:jcardsim but all necessary dependencies come as normal (BouncyCastle, slf4j).

The command line utility jcardsim on the other hand includes all dependencies in the executable .jar.

No "synthesized load files"

jcardsim works on class file level, so the notion of load files and modules makes little sense - all code is readily present in classpath.

No hidden class loading

Unlike original jcardsim, this version intends to be a compile-time toolkit. Any class loading should be done by the caller (as is done by jcardsim tool) and the API only takes classes as input. Simulator core does not deal with class loading based on name or .jar file.

No more APDUScript

"You can't test website functionality by replaying PCAP files" Martin P.

Static script files hit a wall very fast with any non-trivial, non-"Hello, World!" applet. There are other tools to send static APDU-s to PC/SC readers once a virtual card has been set up, or the main use of jcardsim remains to be with (unit) tests, where APDU-s are generated (and verified) by actual Java code.

No (system) properties

Old: config file with properties defining class names or AID-s that get converted to system properties or setting system properties with applet class names and AID-s directly

New: N/A, set up the simulator programmatically, or with InstallSpec or via jcardsim command line utility.

No pseudo-apdu for applet creation

The old process of setting applet AID-s and class names via properties/config file, letting the simulator try to load the classes, and do preliminary setup steps and then calling a "create applet" APDU as the first command are gone. Simulator applets must be set up in full programmatically. jcardsim command line utility does that.

No more RMI

No RMI on the host side nor on the JavaCard framework side. If you actually need it (read: are using it on a real card), let me know.

Unified command line tool (with no properties) for "applet servers"

Instead of manually setting up a classpath and deep-calling random classes in the classpath, there is a unified command line tool for starting remote reader processes (and do any necessary class loading)

Old:

echo "com.licel.jcardsim.card.applet.0.AID=D2760001240102000000000000010000" > openpgp_jcardsim.cfg;
echo "com.licel.jcardsim.card.applet.0.Class=openpgpcard.OpenPGPApplet" >> openpgp_jcardsim.cfg;
echo "com.licel.jcardsim.card.ATR=3B80800101" >> openpgp_jcardsim.cfg;
echo "com.licel.jcardsim.vsmartcard.host=localhost" >> openpgp_jcardsim.cfg;
echo "com.licel.jcardsim.vsmartcard.port=35963" >> openpgp_jcardsim.cfg;
java -cp openpgp-build/bin:jcardsim-3.0.5-SNAPSHOT.jar com.licel.jcardsim.remote.VSmartCard openpgp_jcardsim.cfg

New: java -jar jcardsim-25.06.08.jar --atr 3B80800101 --vsmartcard openpgp-applet/openpgp.cap