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 (or to support the use cases not possible with Oracle simulator) or just re-arranged according to what seems to fit my personal experience. Migration should be simple and straightforward with the help of modern refactoring tools like IntelliJ (no effort shall be made to try to imitate old behaviours or interfaces).

[!NOTE] Until a non-preview release, class names and package structure may change at any time (but the big picture should remain intact).

JavaCardEngine as the main and only interface

Each JavaCardEngine instance represents a single "secure element" and is isolated from other JavaCardEngine instances in a thread. No unexpected "runtime sharing" between two instances of new Simulator(). In fact, SimulatorRuntime is gone. Multiple threads can access a single Simulator in a thread-safe way for communication, with the preferred method for non-hello-world samples being via AutoClosable EngineSession instances created via JavaCardEngine.connect(String protocol).

• Old: Simulator sim = new Simulator(new SimulatorRuntime());
• New: JavaCardEngine sim = JavaCardEngine.create();

Installation parameters fixed

Applets receive installation parameters as they would on a JavaCard - with instance AID, GlobalPlatform privileges, and rest of application installation parameters, not as arbitrary byte arrays. Installation parameters are forwarded to applets as one would receive on an actual card (JavaCardEngine.installApplet(FooBar.class, XXYY) input is same as gp --install ... --parameters XXYY)

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:jcardengine but all necessary dependencies come as normal (BouncyCastle, slf4j, ASM).

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

No "synthesized load files"

JCardEngine works on classpath level, so the notion of load files and modules makes little sense - all code is readily present in the 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 jcard tool) and the API only takes classes as input. Simulator core does not deal with class loading based on name or .jar file.

Applet isolation by default

Depending on the use case, the default isolation of applets into a single JavaCardEngine instance might be a good or bad feature. It assures that two instances of the same applet in two different JavaCardEngine-s don't interact on static field level, but also disallow introspection into small throwaway applet static fields. Use JavaCardEngine.installExposedApplet() to be able to introspect applet classes from tests instead of the default isolated behaviour of JavaCardEngine.installApplet(). Rule of thumb: if you do simple tests in the context of a single-use JVM, it should be safe to use the exposed methods.

No more APDUScript

"You shouldn't try to 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 JCardEngine remains to be with (unit) tests, where APDU-s are dynamically 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 jcard 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. jcard 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 jcard.jar --atr 3B80800101 --vsmartcard openpgp-applet/openpgp.cap