Request: Migrate Aspose.Cells for Node.js via Java from node-java (NAN) to N-API

coopelkatz · December 23, 2025, 12:51pm

We would like to use Aspose.Cells for Node.js via Java in an Electron application on Windows.

However, Aspose.Cells for Node.js via Java depends internally on node-java, which is built on NAN.
NAN relies directly on V8 C++ APIs, which are not ABI-stable and change frequently across Electron releases.
As a result, node-java encounters linker errors when built against Electron on Windows.

The Electron team explicitly recommends using N-API (Node-API) instead of NAN for native addons, and has stated that resolving NAN-based ABI and linker issues in Electron is difficult and not planned:

github.com/electron/electron

[Bug]: Link error for native c++ modules

opened 09:44AM - 25 Jun 21 UTC

closed 02:16AM - 07 Nov 22 UTC

TanninOne

platform/windows bug

13-x-y 14-x-y stale

### Preflight Checklist - [X] I have read the [Contributing Guidelines](https:/…/github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project. - [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to. - [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success. ### Electron Version 13.1.4 ### What operating system are you using? Windows ### Operating System Version Windows 10 Home (19042) ### What arch are you using? x64 ### Last Known Working Electron version _No response_ ### Expected Behavior The native module in the testcase gist should be able to link. The problematic part is the function v8::ArrayBuffer::GetBackingStore() ### Actual Behavior Linking fails with the error `error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::shared_ptr<class v8::BackingStore> __cd ecl v8::ArrayBuffer::GetBackingStore(void)" (__imp_?GetBackingStore@ArrayBuffer@v8@@QEAA?AV?$shared_ptr@VBackingStore@v8@@@std@@XZ) re ferenced in function "void __cdecl foobar(class v8::FunctionCallbackInfo<class v8::Value> const &)" (?foobar@@YAXAEBV?$FunctionCallbac kInfo@VValue@v8@@@v8@@@Z) [c:\Work\repro_bug_arraybuffer\build\foobar.vcxproj]` ### Testcase Gist URL https://gist.github.com/TanninOne/d321ab1676798647cf672f08e78b88d8 ### Additional Information Building the same module for node 14.17.1 works fine. The error message, although cryptic, is correct: the header and link library shipped do not seem to match. the header declares GetBackingStore like this: `std::shared_ptr<BackingStore> GetBackingStore();` but the library exports this: `?GetBackingStore@ArrayBuffer@v8@@QEAA?AV?$shared_ptr@VBackingStore@v8@@@__1@std@@XZ` which demangles to `public: class std::__1::shared_ptr<class v8::BackingStore> __cdecl v8::ArrayBuffer::GetBackingStore(void) __ptr64` so as far as I understand it the namespace is different and thus the linker doesn't find the function. node.exe version 14.17.1 otoh exports `?GetBackingStore@ArrayBuffer@v8@@QEAA?AV?$shared_ptr@VBackingStore@v8@@@std@@XZ` aka `public: class std::shared_ptr<class v8::BackingStore> __cdecl v8::ArrayBuffer::GetBackingStore(void) __ptr64` which matches the declaration in v8.h exactly. With prior versions of electron (up to 12 I think) we could use the deprecated function GetContent to get at the content of an ArrayBuffer but that function has been removed so until this is fixed, if I'm not completely mistaken, any native module that requires access to the content of an ArrayBuffer, including helper libraries like nan or nbind and all modules that depend on _those_ will be broken.

Therefore, we request that Aspose.Cells for Node.js via Java migrate its internal Java bridge from node-java (NAN-based) to an N-API-based solution, such as java-bridge.
https://www.npmjs.com/package/java-bridge

By adopting N-API, Aspose.Cells for Node.js via Java would become usable and stable in Electron on Windows, in line with Electron and Node.js best practices.

Professionalize.Discourse · December 23, 2025, 12:52pm

@coopelkatz

Your request has been noted. Below is a concise summary of the points you raised, each supported by the information you provided:

Dependency on node‑java (NAN‑based).
Aspose.Cells for Node.js via Java uses the node‑java bridge, which is built on the NAN framework.【1】
NAN’s ABI instability with Electron.
NAN directly accesses V8 C++ APIs that are not ABI‑stable; they change frequently across Electron releases, causing linker errors when node‑java is compiled for Electron on Windows.【1】
Electron’s recommendation to use N‑API.
The Electron team advises using N‑API (Node‑API) instead of NAN for native addons and states that fixing NAN‑based ABI/linker issues in Electron is difficult and not planned.【1】
Feature request: migrate to an N‑API‑based bridge (e.g., java‑bridge).
You propose replacing the current NAN‑based node‑java bridge with an N‑API solution such as java‑bridge to achieve stable usage of Aspose.Cells for Node.js via Java in Electron applications on Windows.【1】

If you have additional details (e.g., specific Electron versions, build environment, or any workarounds you have tried), please share them here so we can better assess the impact.

amjad.sahi · December 23, 2025, 2:03pm

@coopelkatz,

Thanks for sharing the details.

We require thorough evaluation of your requested feature. We will check the feasibility if we could migrate Aspose.Cells for Node.js via Java from node-java (NAN) to N-API. We have opened the following new investigation ticket(s) in our internal issue tracking system.

Issue ID(s): CELLSNODEJSJAVA-86

Once we have an update on it, we will you know here.

amjad.sahi · December 23, 2025, 2:08pm

@coopelkatz,

By the way, if possible, could you please try Aspose.Cells for Node.js via C++ for your scenario/case as we generally recommend users who want high performance and stable compatibility in different environments?

feng.ge · December 23, 2025, 2:37pm

@coopelkatz

We kindly suggest trying Aspose.Cells for Node.js via C++ as an alternative for Electron integration. We have prepared a working sample project for your reference.

ElectronAppDemo.zip (5.4 KB)

To get started, please run:

npm install
npm start

coopelkatz · December 24, 2025, 2:32am

@amjad.sahi @feng.ge
Thank you for the suggestion.

We understand that Aspose.Cells for Node.js via C++ can work with Electron, and we appreciate you pointing that out.
However, there are several practical reasons why this option is difficult for us.

First, Aspose.Cells for Node.js via Java and Aspose.Cells for Node.js via C++ require separate licenses.
Maintaining licenses for both products is financially challenging for us, especially when we aim to use Aspose.Cells consistently across our environments, including Electron.

Second, our existing codebase is already tightly integrated with Aspose.Cells for Node.js via Java.
Migrating to Aspose.Cells for Node.js via C++ would require refactoring and revalidation, which represents somewhat engineering cost and risk.
In addition, we currently use Aspose.Cells for Node.js via Java in non-Electron environments as well, such as inside Docker containers, and both our Docker-based applications and our Electron application share the same codebase.
Because of this, switching to Aspose.Cells for Node.js via C++ only when integrating with Electron would be difficult.
Maintaining different Aspose.Cells integrations depending on the runtime environment would significantly increase complexity and maintenance overhead.

Finally, as long as the integration continues to use the legacy NAN/V8 APIs directly, it will remain susceptible to the same class of ABI and linker issues that we encountered in the Electron environment.
The Node.js documentation explicitly states that Node-API (N-API) provides a stable ABI independent of the underlying JavaScript engine (such as V8), and recommends using Node-API for native addons instead of directly depending on V8 or NAN in order to remain ABI-stable across releases.
This ABI stability is a core reason why Node-API exists and why it is recommended for native addon development in Node.js.

For these reasons, while we acknowledge that the C++ variant is an option, we would strongly prefer to see Aspose.Cells for Node.js via Java adopt an N-API–based integration (instead of node-java), so that it can be used reliably in Electron on Windows.

Thank you for your understanding and consideration.

Nick.Liu · December 24, 2025, 3:49am

@coopelkatz
Aspose.Cells for Node.js via C++ is implemented using the node-addon-api, so it doesn’t have ABI stability issues. I will attempt to migrate Aspose.Cells for Node.js via Java from node-java (NAN) to N-API, which may take a considerable amount of time. Thanks.