GitHub Issue for bytedeco/javacpp-presets (PyTorch binding missing ModuleDictImpl::insert mapping)
Title: Missing binding for void insert(const std::string& key, std::shared_ptr module) in ModuleDictImpl
Description
Problem
The ModuleDictImpl class in javacpp-pytorch does not wrap the official C++ insert method defined in PyTorch C++ frontend headers, which prevents Java/Scala users from dynamically inserting named submodules into a ModuleDict instance at runtime.
C++ Method Signature Reference
The target native method from PyTorch official header torch/csrc/api/include/torch/nn/modules/container/moduledict.h line 68:
运行
void insert(const std::string& key, std::shared_ptr<Module> module);
Source code snippet reference:
https://github.com/albertotrunk/ue-stable-diffusion/blob/bb943fc821a165bd00e67ff4f1f020d504e0e65c/Content/Python/torch/include/torch/csrc/api/include/torch/nn/modules/container/moduledict.h#L68
Reproduction Scenario
When writing Java/Scala code with javacpp-pytorch to build modular networks:
运行
ModuleDictImpl dict = new ModuleDictImpl();
LinearImpl linear = new LinearImpl(128, 64);
// No insert() method available on dict to add named module
dict.insert("fc", linear.ptr()); // Compile error: symbol not found
There is no equivalent Java binding exposed for this core container operation, while ModuleListImpl has complete append/insert APIs.
Expected Fix
Add a javacpp mapping entry in the PyTorch preset headers for ModuleDictImpl::insert with the exact signature:
Input: const std::string& key
Input: std::shared_ptrtorch::nn::Module module
Return type: void
This will generate a corresponding insert(String key, Module module) method on the Java ModuleDictImpl class, matching native C++ behavior exactly.
Environment
Library: javacpp-presets pytorch
Target API: PyTorch C++ Frontend nn::ModuleDict
Affected class: org.bytedeco.pytorch.ModuleDictImpl
Additional Context
This method is critical for implementing dynamic, conditional model architectures where submodules are registered into a dictionary container after initialization. Without this binding, users are forced to use hacky workarounds or static initialization only, breaking parity with Python/PyTorch and C++ native APIs.
Would you like me to shorten this into a compact minimal version ready to directly paste into GitHub?
GitHub Issue for bytedeco/javacpp-presets (PyTorch binding missing ModuleDictImpl::insert mapping)
Title: Missing binding for void insert(const std::string& key, std::shared_ptr module) in ModuleDictImpl
Description
Problem
The ModuleDictImpl class in javacpp-pytorch does not wrap the official C++ insert method defined in PyTorch C++ frontend headers, which prevents Java/Scala users from dynamically inserting named submodules into a ModuleDict instance at runtime.
C++ Method Signature Reference
The target native method from PyTorch official header torch/csrc/api/include/torch/nn/modules/container/moduledict.h line 68:
Source code snippet reference:
https://github.com/albertotrunk/ue-stable-diffusion/blob/bb943fc821a165bd00e67ff4f1f020d504e0e65c/Content/Python/torch/include/torch/csrc/api/include/torch/nn/modules/container/moduledict.h#L68
Reproduction Scenario
When writing Java/Scala code with javacpp-pytorch to build modular networks:
There is no equivalent Java binding exposed for this core container operation, while ModuleListImpl has complete append/insert APIs.
Expected Fix
Add a javacpp mapping entry in the PyTorch preset headers for ModuleDictImpl::insert with the exact signature:
Input: const std::string& key
Input: std::shared_ptrtorch::nn::Module module
Return type: void
This will generate a corresponding insert(String key, Module module) method on the Java ModuleDictImpl class, matching native C++ behavior exactly.
Environment
Library: javacpp-presets pytorch
Target API: PyTorch C++ Frontend nn::ModuleDict
Affected class: org.bytedeco.pytorch.ModuleDictImpl
Additional Context
This method is critical for implementing dynamic, conditional model architectures where submodules are registered into a dictionary container after initialization. Without this binding, users are forced to use hacky workarounds or static initialization only, breaking parity with Python/PyTorch and C++ native APIs.
Would you like me to shorten this into a compact minimal version ready to directly paste into GitHub?