본문으로 건너뛰기
cccskills
무료GitHub에 공개한국어 소개

jna

Kotlin이나 Java의 JNA 바인딩을 구현하거나 디버깅할 때 네이티브 선언, 필드 순서, 정렬, 호출 규약, 리소스 소유권을 확인합니다. 네이티브 통합 테스트 전에 JVM 테스트로 레이아웃과 리플렉션 문제를 찾도록 안내합니다.

원문원문 설명 보기

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

JetBrains/intellij-community스타 20,684(GitHub 20,684 + cccskills 0)

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • JNA용 네이티브 구조체 정의하기
  • JNA 예외 원인 조사하기
  • JVM에서 구조체 레이아웃 테스트하기
  • ABI 유형과 필드 정렬 확인하기

한국어 소개

할 수 있는 일

이 스킬은 Kotlin이나 Java에서 네이티브 API를 호출하는 JNA 바인딩의 구현과 디버깅을 돕습니다. 네이티브 선언에 맞는 유형이 있는지 JNA Platform과 저장소의 기존 매핑을 찾아보고, 일치하면 재사용하도록 안내합니다. 구조체 필드 순서, 정수와 포인터의 너비, 정렬, 호출 규약, 콜백 및 네이티브 메모리의 수명, ABI에 맞는 정의를 다룹니다. JNA 리플렉션에 필요한 매핑 클래스와 필드의 공개 범위도 확인하며, 문제를 추적할 때 예외의 전체 원인 체인을 살펴보는 방법을 설명합니다.

이럴 때 유용합니다

네이티브 라이브러리 연결을 새로 만들거나 구조체 크기 불일치, 필드 접근 예외, 콜백 문제를 조사할 때 유용합니다. 네이티브 UI, 권한, 하드웨어 또는 특정 운영체제에 의존하는 통합 테스트를 실행하기 전에 JVM 레이아웃 회귀 테스트를 준비할 때도 활용할 수 있습니다.

사용 예시

  • “이 C 구조체 선언에 맞춰 JNA Kotlin 정의를 확인해 주세요.”
  • “이 JNA IllegalAccessException의 원인을 찾고 수정 방법을 제안해 주세요.”
  • “이 Structure의 크기를 검증하는 JVM 테스트를 추가해 주세요.”

주의 사항

네이티브 선언, 대상 아키텍처, 소유권 규칙을 확인해야 합니다. 권한, 하드웨어, 운영체제에 의존하는 통합 테스트는 레이아웃 테스트와 분리해 다룹니다.

이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.

문서 점검

AI가 SKILL.md의 내용에서 주의가 필요한 작업과 도입 전제를 확인했습니다. 점수는 실제로 실행한 결과(실행 검증)만으로 매깁니다.

안전성전송·삭제·명령 실행 등을 명시하고 있는가
A양호소유권 확인과 권한 의존 테스트 분리를 명시하며 외부 전송은 설명하지 않습니다.
도입의 용이성필요한 도구나 API 키가 적고 적혀 있는가
B일부 부족JNA, JVM, 네이티브 대상 환경이 필요하지만 설치 절차는 없습니다.

점수에는 넣지 않았습니다. 2026년 10월 28일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.

평가가 다르다고 생각되면 재검토를 요청하기

어느 항목이 왜 다르다고 생각하는지 적어 주세요. 로그인은 필요 없습니다. SKILL.md와 대조해 평가를 다시 만들고 이곳에 반영합니다.

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

포함된 파일(1)

  • SKILL.md2.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

<!-- 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.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

actions

무료요약 있음

IntelliJ `AnAction` 클래스를 구현하거나 수정하고 `plugin.xml`에 등록하도록 안내합니다. 표시 이름과 설명은 메시지 번들에 두고, 필요하면 아이콘을 설정하며, 이벤트 코루틴 범위에서 중단 함수를 실행해 동기식 처리로 IDE가 멈추는 일을 방지합니다.

  • IDE 메뉴에 새 동작 추가
  • 동작 등록이나 아이콘 변경
  • 동작 이름과 설명 정리
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

bazel-test-migration

무료요약 있음

IntelliJ JPS 테스트 모듈을 Bazel로 옮기고 Bazel에서만 발생하는 실패를 조사하는 안내서입니다. 의존성, 플러그인, 테스트 데이터와 runfiles 문제를 확인하고 생성된 대상과 이전된 테스트를 검증합니다.

  • 기존 JPS 테스트 모듈을 Bazel로 이전할 때
  • Bazel에서만 실패하는 테스트를 조사할 때
  • 테스트 의존성과 데이터 설정을 확인할 때
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

code-style

무료요약 있음

IntelliJ 프로젝트 규칙에 맞춰 Kotlin과 Java 코드를 작성하거나 검토합니다. 언어 선택, 서식, 봉인 타입, 스레드 주석, 제어 흐름 예외 처리를 확인합니다.

  • IntelliJ 규칙에 맞는 Kotlin 작성
  • Java 코드 검토
  • 예외 처리와 봉인 타입 분기 확인
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

commits

무료요약 있음

이 가이드는 IntelliJ 프로젝트의 변경 사항을 목적별로 나누고 프로젝트 형식에 맞는 커밋 메시지를 작성하도록 돕습니다. 티켓이 있으면 번호와 변경 설명을, 없으면 레이블과 하위 시스템명을 사용하며 필요에 따라 이유와 판단을 본문에 담습니다.

  • 티켓이 있는 변경의 프로젝트 형식 메시지 작성
  • 테스트나 문서 커밋에 적절한 레이블 적용
  • 기존 커밋 메시지를 규칙에 맞게 수정
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

compare-python-typecheckers

무료요약 있음

여러 Python 타입 검사기로 코드 조각이나 파일의 타입 추론과 오류 판정을 비교합니다. 도구별 결과, 실행 시간, 진단 내용을 Markdown 보고서로 모아 저장할 수 있습니다.

  • 검사기별 타입 추론 비교
  • 코드가 타입 오류로 판정되는지 확인
  • 여러 도구의 진단 결과 비교
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

compose-ui-architecture

무료요약 있음

Compose Desktop 화면을 구성할 때 컴포저블은 렌더링을 맡고 프레젠터나 코디네이터는 앱 결정을 맡도록 구조를 정리합니다. 상태 소유권, Effect, 재사용 컴포넌트 API, 지연 목록 키, 애니메이션과 성능을 개별 UI 변경에 맞춰 살펴봅니다.

  • 화면 렌더링과 프레젠터 판단 분리
  • UI 상태를 둘 위치 정리
  • Effect 키와 코루틴 사용 검토
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

JetBrains의 스킬 모두 보기

이 스킬의 문제 신고