Skip to content
cccskills
FreePublished on GitHub

jna

Implement and debug JNA bindings for Kotlin or Java by checking native declarations, field order, alignment, calling conventions, and resource ownership. The guidance also helps catch layout and reflection problems with focused JVM tests before native integration runs.

OriginalShow the original description

Implement or debug JNA bindings and ABI layouts in Kotlin or Java.

JetBrains/intellij-community20,664 stars(GitHub 20,664 + cccskills 0)

Run score Not tested

See how to install

Good for

  • Mapping a native structure in Kotlin or Java
  • Debugging an IllegalAccessException in JNA
  • Checking field alignment and calling conventions
  • Testing structure layouts without native hardware

Files included (1)

  • SKILL.md2.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

<!-- Generated by community/.ai/render-guides.mjs; edit community/.agents/skills/jna/SKILL.md -->

JNA bindings

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 internal or public mapped classes; never use private, 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 IllegalAccessException from Structure.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 with Pointer or 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() and write() 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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

actions

FreeSummary

Implement or update IntelliJ `AnAction` classes and their `plugin.xml` registrations. Keep labels and descriptions in message bundles, configure optional icons, and launch suspending work through the event coroutine scope so synchronous action handling does not freeze the IDE.

  • Adding a new IntelliJ action
  • Updating an action's registration or icon
  • Moving action labels into a message bundle
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

Move IntelliJ JPS test modules to Bazel and diagnose failures that occur only under Bazel. The guide helps trace missing dependencies, plugins, test data, and runfiles, then verify the generated target and migrated tests.

  • Migrating a JPS test module to Bazel
  • Diagnosing a test failure that occurs only in Bazel
  • Checking Bazel dependencies and test data wiring
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

code-style

FreeSummary

Write or review Kotlin and Java code in line with IntelliJ project conventions. The guidance covers language choice, formatting, sealed types, threading annotations, and safe handling of control flow exceptions so changes fit the surrounding codebase.

  • Writing a new Kotlin file that follows IntelliJ conventions
  • Reviewing Java code and checking its style guidance
  • Checking formatting, sealed-type handling, or exception handling
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

commits

FreeSummary

Create, amend, or rename IntelliJ commits with messages that follow the project’s ticket and label formats. Keep each commit focused, explain the reason and decision in the body when needed, and pass the message safely through the shell or PowerShell.

  • Writing a message for a change linked to a YouTrack ticket
  • Preparing a commit message for tests, cleanup, or documentation
  • Amending or renaming an existing IntelliJ commit
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

Compare how Python type checkers interpret a code snippet or file. The script runs selected tools, including ty, pyrefly, basedpyright, mypy, and zuban, then produces a Markdown report with verdicts, timings, and each checker's diagnostic output.

  • Comparing type inference for a Python snippet
  • Checking whether a Python expression should be a type error
  • Reviewing differences among Python type checkers
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

Shape Compose Desktop UI code by keeping composables focused on rendering and placing application decisions in presenters or coordinators. Get guidance on state ownership, effects, reusable component APIs, lazy-list keys, animation, and performance for individual UI changes.

  • Separating screen rendering from application decisions
  • Choosing which UI state belongs in composition
  • Structuring effects and coroutine work
JetBrains/intellij-community20.7KUpdated Oct 26, 2026

See all skills by JetBrains

Report a problem with this skill