RFC: Replace Java-based EXI codec with native C library (libcbv2g_json_wrapper)

[biubiuzhang]

Summary

We propose replacing the Java-based EXIficient EXI codec in PyEvJosev with a native C shared library (libcbv2g_json_wrapper) that wraps the existing libcbv2g with a JSON-based API, callable from Python via ctypes.

This RFC is opened to get maintainer feedback on the approach before submitting all protocol converters.

Developed by the Enteligent Team.

Problem

The current EV-side simulation stack (PyEvJosev) depends on a closed-source Java JAR (ExiCodec.jar, based on Exificient) for EXI encoding/decoding of ISO 15118 messages. This creates several issues:

1. Closed-source JAR cannot be extended (e.g., for ACDP support) — discussed in Remove deprecated JsAuth module. Was replaced by Auth C++ implementat… EVerest#118
2. Performance: 250ms latency per EXI conversion in DIN CurrentDemandResponse — reported in EcoG-io/iso15118#157
3. Embedded deployment pain: OpenJDK fails to compile on Yocto/embedded targets — reported in everest-demo#129 and everest-demo#144
4. Java process leaks: A new Java process is created per session without proper cleanup — fixed in Upgrading libfsm to v2 libiso15118#56

The EVSE (charger) side is already Java-free — EvseV2G (C/libcbv2g) handles ISO 15118-2/DIN, and Evse15118D20 (C++/libiso15118) handles ISO 15118-20. The Java dependency is isolated to the EV simulation side.

Proposed Solution

A native C shared library (libcbv2g_json_wrapper.so) that:

• Wraps libcbv2g's EXI encode/decode functions with a JSON-based API (using cJSON)
• Is callable from Python via ctypes as a drop-in replacement for ExificientEXICodec
• Supports all protocols: AppHandshake (SAP), DIN 70121, ISO 15118-2, ISO 15118-20 (AC, DC, WPT, ACDP, CommonMessages)
• Works with both system-installed libcbv2g (Yocto) and source-tree builds
• Is Apache-2.0 licensed, compatible with all EVerest dependencies

Architecture

Python (Josev)
    │
    ▼
cbv2g_exi_codec.py  (ctypes bindings, implements IEXICodec)
    │
    ▼
libcbv2g_json_wrapper.so  (C shared library)
    │  ├── apphand_converter.c   (AppHandshake)
    │  ├── din_converter.c       (DIN 70121)
    │  ├── iso2_converter.c      (ISO 15118-2)
    │  ├── iso20_converter.c     (ISO 15118-20)
    │  └── json_utils.c          (shared helpers)
    ▼
libcbv2g  (existing EVerest library)

What Exists Upstream Today — Nothing Equivalent

We surveyed all EVerest repositories and the broader ecosystem:

Project	What It Does	Coverage	Usable?
thesimmermon/libcbv2g (fork)	Same architecture: C shim + cJSON + ctypes	Only ISO-2 CertificateInstall (1 msg type)	Very limited
designwerk-charger/exi_converter	C++ Pybind11 codec	AppProtocol, DIN, ISO-2 (no ISO-20)	No license
EVerest/libiso15118	C++ ISO 15118 library	Full protocol support	No Python bindings

EVerest maintainer @SebaLukas discussed this exact approach in EVerest#118 — using cbexigen-generated C code with cJSON — but it was never implemented for the Python/Josev side.

Upstream Plan

We have a working implementation (~9,365 lines) split into 5 manageable PRs:

PR	Content	~Lines	Status
1	Core library + AppHandshake converter	~750	Submitted (#57)
2	DIN 70121 converter	~1,274	Pending
3	ISO 15118-2 converter	~1,476	Pending
4	ISO 15118-20 converter (AC, DC, WPT, ACDP)	~1,851	Pending
5	Python bindings + integration into Josev	~250	Pending

Questions for Maintainers

1. Is this approach welcome? We understand the long-term plan is a full C++ EV simulator in libiso15118 (libiso15118#125). This is intended as a bridge solution that can be used today while the C++ simulator is being developed.

2. Repo placement: Should this live in ext-switchev-iso15118 (current target), a separate repo (e.g., cbv2g-json-wrapper), or be integrated into libcbv2g itself?

3. cJSON bundling: We bundle cJSON 1.7.19 (MIT) in third_party/. Would you prefer it as an external dependency or a git submodule instead?

4. Any API design feedback? PR Added support for externally provided certificate paths in libiso libiso15118#57 establishes the public API surface — we'd appreciate early review before adding all protocol converters.

Licensing

All dependencies are free and compatible:

Component	License
EVerest/libcbv2g	Apache-2.0
EVerest/cbexigen	Apache-2.0
EVerest/ext-switchev-iso15118	Apache-2.0
cJSON (bundled)	MIT
Our contribution	Apache-2.0

References

• Remove deprecated JsAuth module. Was replaced by Auth C++ implementat… EVerest#118 — Josev ExiCodec.jar limitations
• EcoG-io/iso15118#157 — Slow EXI conversion (250ms)
• EVerest Roadmap — Java replacement planned
• everest-demo#129 — Java build failures on Yocto
• libiso15118#125 — EV-side state machine tracking
• LF Energy mailing list discussion — C++ replacement discussion

[SebaLukas]

First of all, thank you for this suggestion.
I've been thinking about developing something like this myself for years, but never had the time.

I will bring this topic up at the next Car WG meeting to discuss this suggestion with the community.

The next Car WG meeting will take place on February 18, 2026, at 3:30 p.m. CET, so it would be great if some of you could attend.

[biubiuzhang]

@SebaLukas Thank you for the quick response. Michael Magyar and I would be happy to join the meeting.

Please let us know if you prefer to send calendar invitations (in which case I can provide the relevant email addresses) or if you will be sharing a meeting link directly.

[SebaLukas]

You can register or use the zoom link directly here for the meeting: https://zoom-lfx.platform.linuxfoundation.org/meetings/everest?view=week
But you need to select the Car WG meeting on February 18, 2026, at 3:30 p.m. CET

[SebaLukas]

Hi :)

What's the status here? At the Car Comm meeting on February 18, there were still a few open issues that you wanted to address.

I've been thinking again about where the json_wrapper (libcbv2g_json_wrapper.so + cbv2g_exi_codec.py) code is best placed. I would no longer move the code to a separate EVerest repository, but rather place it in everest-core under applications/. Maybe under a new folder called cbv2g_json_wrapper?
That way, libcbv2g would always be available and the wrapper can be built independent.