JNA bindings
SkillDev toolsHelps your agent write and debug JNA bindings and ABI layouts in Kotlin or Java code.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the JNA bindings skill
About this capability
Implement or debug JNA bindings and ABI layouts in Kotlin or Java.
What this skill tells your AI
The instructions your AI receives, as published by jetbrains/intellij-community in .agents/skills/jna/SKILL.md and read by ahel’s review.
Treat every mapping as an ABI contract. Verify the native declaration, target architectures, and ownership rules before changing Kotlin or Java code.
Reuse existing mappings
Search JNA Platform and the repository before declaring a native type. Prefer a maintained platform mapping when its field types, alignment, and calling convention match the target API.
Keep reflected types accessible
JNA reflects mapped classes and fields while deriving layouts and invoking callbacks. Make every Structure, Union, callback, and related declaring class JVM-accessible from com.sun.jna:
- In Kotlin, use
internalor public mapped classes; never useprivate, local, or anonymous mapped classes. - Keep the mapped class's enclosing chain accessible too.
- Expose structure fields as real public JVM fields, normally with
@JvmField. - Do not assume public fields compensate for a non-public declaring class. Layout can fail with
IllegalAccessExceptionfromStructure.getFieldValue.
Prefer moving visibility only as far as needed over suppressing reflection errors or opening accessibility globally.
Match the native ABI
- Declare structure fields in native order and use
@Structure.FieldOrder. - Map fixed-width integers, pointers,
size_t, native booleans, wide strings, and platform-dependent numeric types deliberately. Do not infer their size from Kotlin or Java names. - Model embedded values with
Structure.ByValue; model pointers separately withPointeror the appropriate reference type. - Check packing and alignment requirements instead of relying on defaults when the native declaration specifies them.
- Use the correct calling convention and library options.
- Keep callback objects and native memory strongly reachable for the full native lifetime, and release owned resources according to the native API.
- For pointer-backed structures, call
read()andwrite()at the required ownership boundary.
Verify without requiring native UI or permissions
Add a small JVM regression test that constructs each mapped structure and calls size() or otherwise forces JNA to derive its layout. Assert stable sizes or offsets only when they are defined for the tested architecture.
Keep permission-, hardware-, and OS-dependent native integration coverage separate. A layout test should catch visibility and field-order failures before a native callback reaches production code.
When debugging, retain the complete cause chain: wrapper errors often hide the useful IllegalAccessException, invalid field type, alignment error, or callback exception underneath.
Signals
- GitHub stars
- 21k
- Forks
- 6k
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
jna- Source
- github.com/jetbrains/intellij-community