Java Native Access

Last update: Jan 1, 2023

Related tags

Overview

Java Native Access (JNA)

The definitive JNA reference (including an overview and usage details) is in the JavaDoc. Please read the overview. Questions, comments, or exploratory conversations should begin on the mailing list, although you may find it easier to find answers to already-solved problems on StackOverflow.

JNA provides Java programs easy access to native shared libraries without writing anything but Java code - no JNI or native code is required. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes.

JNA allows you to call directly into native functions using natural Java method invocation. The Java call looks just like the call does in native code. Most calls require no special handling or configuration; no boilerplate or generated code is required.

JNA uses a small JNI library stub to dynamically invoke native code. The developer uses a Java interface to describe functions and structures in the target native library. This makes it quite easy to take advantage of native platform features without incurring the high overhead of configuring and building JNI code for multiple platforms. Read this more in-depth description.

While significant attention has been paid to performance, correctness and ease of use take priority.

In addition, JNA includes a platform library with many native functions already mapped as well as a set of utility interfaces that simplify native access.

Projects Using JNA

JNA is a mature library with dozens of contributors and hundreds of commercial and non-commercial projects that use it. If you're using JNA, feel free to tell us about it. Include some details about your company, project name, purpose and size and tell us how you use the library.

Apache Cassandra: Large-scale NoSQL data store.
Rococoa: Java bindings to the Mac OS X Cocoa framework, by Duncan McGregor.
jna-posix: Common POSIX Functions for Java.
JNAerator: Pronounced "generator", auto-generates JNA mappings from C headers, by Olivier Chafik.
Freedom for Media in Java by Ken Larson/Dieter Krachtus.
GStreamer-Java: Java bindings and utilities for GStreamer 1.x.
VLCJ: Java bindings for libVLC.
SVNKit: Pure Java Subversion client library.
OmegaT Computer-Aided Translation.
IntelliJ IDEA by JetBrains.
Apache NetBeans IDE by Apache Software Foundation.
FileBot Media Renamer by Reinhard Pointner.
USB for Java by Mario Boikov.
Waffle: Enables SSO on Windows in Java applications, by Daniel Doubrovkine.
leveldb-jna: Cross-platform JNA based adapter for LevelDB (used in Keylord).
bolt-jna: Cross-platform JNA based adapter for Bolt (used in Keylord). It is show how to use JNA for binding to Go library.
JVM OpenVR Bindings.
Apache Ignite: Direct IO plugin
Domino JNA: Cross-platform access to HCL Notes/Domino C API methods from Java
OSHI: Cross-platform Operating System and Hardware Information library for Java
jAlbum: Desktop based web gallery software for any web site.
jacknji11: Provides a Java PKCS#11 interface.
JNAJack: Java bindings for JACK Audio Connection Kit.

Interesting Investigations/Experiments

Drive Lego Mindstorm NXT by Emmanuel Pirsch.
Detect User Inactivity by Olivier Chafik.

There are also a number of examples and projects within the contrib directory of the JNA project itself.

Supported Platforms

JNA will build on most linux-like platforms with a reasonable set of GNU tools and a JDK. See the native Makefile for native configurations that have been built and tested. If your platform is supported by libffi, then chances are you can build JNA for it.

Pre-built platform support may be found here.

Download

Version 5.7.0

JNA

jna-5.7.0.jar jna-5.7.0-jpms.jar

This is the core artifact of JNA and contains only the binding library and the core helper classes.

JNA Platform

jna-platform-5.7.0.jar jna-platform-5.7.0-jpms.jar

This artifact holds cross-platform mappings and mappings for a number of commonly used platform functions, including a large number of Win32 mappings as well as a set of utility classes that simplify native access. The code is tested and the utility interfaces ensure that native memory management is taken care of correctly.

See PlatformLibrary.md for details.

Features

Automatic mapping from Java to native functions, with simple mappings for all primitive data types
Runs on most platforms which support Java
Automatic conversion between C and Java strings, with customizable encoding/decoding
Structure and Union arguments/return values, by reference and by value
Function Pointers, (callbacks from native code to Java) as arguments and/or members of a struct
Auto-generated Java proxies for native function pointers
By-reference (pointer-to-type) arguments
Java array and NIO Buffer arguments (primitive types and pointers) as pointer-to-buffer
Nested structures and arrays
Wide (wchar_t-based) strings
Native long support (32- or 64-bit as appropriate)
Demo applications/examples
Supported on 1.4 or later JVMs, including JavaME (earlier VMs may work with stubbed NIO support)
Customizable marshalling/unmarshalling (argument and return value conversions)
Customizable mapping from Java method to native function name, and customizable invocation to simulate C preprocessor function macros
Support for automatic Windows ASCII/UNICODE function mappings
Varargs support
Type-safety for native pointers
VM crash protection (optional)
Optimized direct mapping for high-performance applications.
COM support for early and late binding.
COM/Typelib java code generator.

Community and Support

All questions should be posted to the jna-users Google group. Issues can be submitted here on Github.

When posting to the mailing list, please include the following:

What OS/CPU/architecture you're using (e.g. Windows 7 64-bit)
Reference to your native interface definitions (i.e. C headers), if available
The JNA mapping you're trying to use
VM crash logs, if any
Example native usage, and your attempted Java usage

It's nearly impossible to indicate proper Java usage when there's no native reference to work from.

For commercial support, please contact twalljava [at] java [dot] net.

Using the Library

Primary Documentation (JavaDoc)

The definitive JNA reference is in the JavaDoc.

Developers

Contributing

You're encouraged to contribute to JNA. Fork the code from https://github.com/java-native-access/jna and submit pull requests.

For more information on setting up a development environment see Contributing to JNA.

If you are interested in paid support, feel free to say so on the jna-users mailing list. Most simple questions will be answered on the list, but more complicated work, new features or target platforms can be negotiated with any of the JNA developers (this is how several of JNA's features came into being). You may even encounter other users with the same need and be able to cost share the new development.

License

This library is licensed under the LGPL, version 2.1 or later, or (from version 4.0 onward) the Apache License, version 2.0. Commercial support may be available, please e-mail twall[at]users[dot]sf[dot]net. See LICENSE for more information.

NOTE: Oracle is not sponsoring this project, even though the package name (com.sun.jna) might imply otherwise.

Comments

Add win32-aarch64 support
TODO

[x] Review by jna team

[x] Fix compiler warnings

[x] Review unit tests

[x] Discuss libffi changes/upstream contributions (Relevant discussion: https://github.com/java-native-access/jna/issues/1259#issuecomment-721856499)

[x] Possibly add AppVeyor support?

[x] Documentation

[x] Fix x86 builds https://github.com/java-native-access/jna/pull/1264#issuecomment-725626587 (possibly https://github.com/libffi/libffi/issues/71?)

[x] Fix newly failing +173 tests (e.g. testSyncronizedAccess unit test). (Upstream regression: https://github.com/libffi/libffi/pull/593#issuecomment-735451629. Reverted.)

[x] Fix unexpected line-ending in native/libffi/libtool-ldflags (https://github.com/java-native-access/jna/pull/1264/commits/97a66a78264602b60b57cb4f7aa5b6c8d18bd921)

Changes

Updates native/libffi to latest version, adding Windows arm64 support 2bf1593

Disables DLL callback functionality for win43-aarch via ASMFN_OFF (no mingw support)

Disables DLL callback tests for win32-aarch64 2ff29eb

Fixes marshal test for win32-aarch64 e3ad29d

Patches msvcc.sh to handle the following scenarios/regressions:

Re-adds mvvcc.sh's cygpath calculation for cl.exe 112d76d

Quotes mvvcc.sh's include (-I) files with spaces (e.g. -I"C:\Program Files\AdoptOpenJDK11\...\include) 112d76d

Brings back mvvcc.sh's eval for assembly files 112d76d

Adds win32-aarch64 native build option

Toggled via:
ant native -Dos.prefix=win32-aarch64

Sets ${make.ARCH}=aarch64, reusing Android's property

Produces new artifact lib/native/win32-aarch64.jar

Tested build using MSVC v142 - VS 2019 C++ ARM64 build tools (v14.27) on Windows 10 x86_64

Tested binary using Surface Pro X and openjdk-aarch64 from Microsoft

Steps

See the updated www/WindowsDevelopmentEnvironment.md

Hidden, outdated

[x] ~~Bump jna.jar~~ No, per https://github.com/java-native-access/jna/pull/1264#issuecomment-731357977

Install and configure ant for your system

Install cygwin per Windows steps

Install Visual Studio 2019 with ARM build tools (other versions should also work).

Disable CRLF globally for git (use with caution, this will affect all projects. Alternately, you can skip this step and use dos2unix on each failing file)

git config --global core.autocrlf false git config --global core.eol lf # Fixes error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with ACLOCAL_AMFLAGS=-I m4 # See also: https://stackoverflow.com/q/47582762

Clone this PR

git clone -b win-arm64 https://github.com/tresf/jna --depth 10 cd jna

From a Command Prompt, configure MSVC to build using arm64

"%ProgramFiles(x86)%\Microsoft Visual Studio\2019\Community\Common7\Tools\VsDevCmd" -arch=arm64 -host_arch=amd64 # or on native aarch64 use "-host_arch=x86"

Append cygwin to your path (Append, DO NOT prepend, if you prepend, link.exe will fail!)

set PATH=%PATH%;C:\cygwin64\bin\ # or on native aarch64, "C:\cygwin\bin"

Fire the build: :warning: Note: Windows Defender real-time protection makes this very, very slow. Consider disabling or adding an exception to the jna directory.

ant native -Dos.prefix=win32-aarch64 # or on native aarch64, just type "ant"

Clean between errors:

ant clean

Optionally, enable debugging

Change verbose= to verbose=1 in native/libffi/msvcc.sh

Append -DEXTRA_MAKE_OPTS="--debug=v" to ant command
opened by tresf 54
Add mappings for CoreFoundation, IOKit, DiskArbitration

Part one of three framework mappings. Will submit DiskArbitration and IOKit mappings later, but as they depend on this one, I want to submit them separately and get any needed reviews on this PR completed.

opened by dbwiddis 26
improve loading native library

Make native library loading also works on some customized classloader, which cannot provide URL url = loader.getResource(resourcePath); but do provides InputStream is = loader.getResourceAsStream(resourcePath).

opened by neoedmund 25

Premature GC of Pointer object when invoking getWideString

(Copied from jna-users forum post on 2015-12-23, https://groups.google.com/forum/#!topic/jna-users/dCPnztnQnRw.)

I compiled JNA myself, and when I ran the test suite, the testLongStringGeneration(com.sun.jna.NativeTest) test sometimes failed with a "Invalid memory access" error indicating a JVM segfault. Here's what it looks like running JUnit from the command-line:

C:\rprichard\work\jna>c:\java\jdk1.8.0_60\bin\java -cp "build/jna.jar;build/jna-test.jar;lib/junit.jar;lib/hamcrest-core-1.3.jar" org.junit.runner.JUnitCore com.sun.jna.NativeTest
JUnit version 4.11
............E..E........JNA Warning: Encoding 'unsupported' is unsupported
JNA Warning: Encoding with fallback Cp1252
.......E
Time: 0.374
There were 3 failures:
1) testSynchronizedAccess(com.sun.jna.NativeTest)
java.lang.UnsatisfiedLinkError: Unable to load library 'testlib': Native library (win32-x86/testlib.dll) not found in re
source path ([file:/C:/rprichard/work/jna/build/jna.jar, file:/C:/rprichard/work/jna/build/jna-test.jar, file:/C:/rprich
ard/work/jna/lib/junit.jar, file:/C:/rprichard/work/jna/lib/hamcrest-core-1.3.jar])

... elided ... (test setup issue)

2) testOptionsInferenceFromInstanceField(com.sun.jna.NativeTest)
java.lang.UnsatisfiedLinkError: Unable to load library 'testlib': Native library (win32-x86/testlib.dll) not found in re
source path ([file:/C:/rprichard/work/jna/build/jna.jar, file:/C:/rprichard/work/jna/build/jna-test.jar, file:/C:/rprich
ard/work/jna/lib/junit.jar, file:/C:/rprichard/work/jna/lib/hamcrest-core-1.3.jar])

... elided ... (test setup issue)

3) testLongStringGeneration(com.sun.jna.NativeTest)
java.lang.Error: Invalid memory access
        at com.sun.jna.Native.getWideString(Native Method)
        at com.sun.jna.Pointer.getWideString(Pointer.java:696)
        at com.sun.jna.Memory.getWideString(Memory.java:561)
        at com.sun.jna.NativeTest.testLongStringGeneration(NativeTest.java:77)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at junit.framework.TestCase.runTest(TestCase.java:176)
        at junit.framework.TestCase.runBare(TestCase.java:141)
        at junit.framework.TestResult$1.protect(TestResult.java:122)
        at junit.framework.TestResult.runProtected(TestResult.java:142)
        at junit.framework.TestResult.run(TestResult.java:125)
        at junit.framework.TestCase.run(TestCase.java:129)
        at junit.framework.TestSuite.runTest(TestSuite.java:255)
        at junit.framework.TestSuite.run(TestSuite.java:250)
        at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
        at org.junit.runners.Suite.runChild(Suite.java:127)
        at org.junit.runners.Suite.runChild(Suite.java:26)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
        at org.junit.runner.JUnitCore.run(JUnitCore.java:117)
        at org.junit.runner.JUnitCore.runMain(JUnitCore.java:96)
        at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:47)
        at org.junit.runner.JUnitCore.main(JUnitCore.java:40)

FAILURES!!!
Tests run: 29,  Failures: 3

I'm using 32-bit Windows 7 SP1, with jdk1.8.0_60.

I worked on the test a bit, and came up with this standalone test program that segfaults using the official JNA 4.2.1 JAR.

package com.example;
import com.sun.jna.Memory;
import com.sun.jna.Native;

public class JnaTest {
    public static void main(String[] args) {
        // This code below is reduced from a different test.  (I forget which.)
        new Memory(4);

        // The code below comes from NativeTest.testLongStringGeneration.
        StringBuilder buf = new StringBuilder();
        final int MAX = 2000000;
        for (int i=0;i < MAX;i++) {
            buf.append('a');
        }
        String s1 = buf.toString();
        Memory m = new Memory((MAX + 1)*Native.WCHAR_SIZE);
        m.setWideString(0, s1);
        m.getWideString(0);
    }
}

C:\rprichard\proj\JnaTest>c:\Java\jdk1.8.0_60\bin\java.exe -cp build\classes\main;lib\jna-4.2.1.jar com.example.JnaTest
Exception in thread "main" java.lang.Error: Invalid memory access
        at com.sun.jna.Native.getWideString(Native Method)
        at com.sun.jna.Pointer.getWideString(Pointer.java:696)
        at com.sun.jna.Memory.getWideString(Memory.java:561)
        at com.example.JnaTest.main(JnaTest.java:19)

With lots of printf debugging, I think I identified the cause. The final m.getWideString call ultimately calls Java_com_sun_jna_Native_getWideString. Once the JVM reaches this native function, there are no live references remaining to the Memory object. newJavaString calls back into the JVM, ((*env)->NewString), to create the 2MB String object, at which point the JVM finalizes the Memory object, which frees the buffer. The JVM then attempts to read from the freed buffer and segfaults.

bug

opened by rprichard 25

Enable building jna for Darwin arm64

We are interested in getting JNA running on Darwin arm64.

I was able to get JNA compiling and working for the use cases most important to us with these changes and env JDK_HOME=… SDKROOT=… ant -DCC=clang -Dmake.OPTS="DYNAMIC_LIBFFI=true DARWIN_USE_SDK_LIBFFI=true". Nevertheless, I am not too familiar with JNA and would love to hear your feedback and whether you are interesting in the changes in their current state.

Summary of the changes:

Introduced checks in the Makefile to determine which architectures should be built on Darwin and added flag to allow linking against the system libffi.
Big Sur uses a shared dylib cache to lookup system libraries and frameworks. Checking existence in the file system will fail, but loading them will succeed nevertheless. Adapted LibraryLoadTest accordingly.
Arm64 calling convention requires varargs to always be passed on the stack. JNA's and ffi's argument handling logic seems to handle this case correctly, but it is important that the Java definitions match their native counterparts exactly. Adapted VarArgsTest accordingly.

Unfortunately, some tests still fail…

Testsuite: com.sun.jna.AnnotatedLibraryTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1,818 sec

Testsuite: com.sun.jna.ArgumentsMarshalNullableTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,303 sec

Testsuite: com.sun.jna.ArgumentsMarshalTest
Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,432 sec

Testsuite: com.sun.jna.ArgumentsWrappersMarshalTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,293 sec

Testsuite: com.sun.jna.BufferArgumentsMarshalTest
Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,369 sec

Testsuite: com.sun.jna.ByReferenceArgumentsTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,296 sec

Testsuite: com.sun.jna.ByReferenceToStringTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,262 sec

Testsuite: com.sun.jna.CallbacksTest
Exception in thread "Thread-0" JNA: error while handling callback exception, continuing
Exception in thread "main" JNA: error while handling callback exception, continuing
Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9,849 sec

------------- Standard Error -----------------
java.lang.StackOverflowError
Warning: JVM did not GC Thread mapping after native thread terminated
------------- ---------------- ---------------
Testsuite: com.sun.jna.DefaultMethodInvocationTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,341 sec

Testsuite: com.sun.jna.DirectArgumentsMarshalNullableTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,315 sec

Testsuite: com.sun.jna.DirectArgumentsMarshalTest
Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,384 sec

Testsuite: com.sun.jna.DirectArgumentsWrappersMarshalTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,395 sec

Testsuite: com.sun.jna.DirectBufferArgumentsMarshalTest
Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,379 sec

Testsuite: com.sun.jna.DirectByReferenceArgumentsTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,329 sec

Testsuite: com.sun.jna.DirectCallbacksTest
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (os_bsd_zero.cpp:241), pid=75646, tid=5635
#  fatal error: caught unhandled signal 11 at address 0x0400000001000009
#
# JRE version: OpenJDK Runtime Environment (14.0.1) (build 14.0.1-internal+0)
# Java VM: OpenJDK 64-Bit Zero VM (14.0.1-internal+0, interpreted mode, serial gc, bsd-aarch64)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# hs_err_pid75646.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Testsuite: com.sun.jna.DirectCallbacksTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec

Testcase: com.sun.jna.DirectCallbacksTest:testUnionByValueCallbackArgument:	Caused an ERROR
Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
	at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


Test com.sun.jna.DirectCallbacksTest FAILED (crashed)
Testsuite: com.sun.jna.DirectReturnTypesTest
Tests run: 19, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,337 sec

Testsuite: com.sun.jna.DirectStructureByValueTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,317 sec

Testsuite: com.sun.jna.DirectTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,335 sec

Testsuite: com.sun.jna.DirectTypeMapperTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,332 sec

Testsuite: com.sun.jna.ELFAnalyserTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,199 sec

Testsuite: com.sun.jna.FunctionTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,283 sec

Testsuite: com.sun.jna.HeadlessLoadLibraryTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,265 sec

Testsuite: com.sun.jna.IntegerTypeTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,288 sec

Testsuite: com.sun.jna.JNALoadTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,58 sec

Testsuite: com.sun.jna.LastErrorTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,345 sec

Testsuite: com.sun.jna.LibraryLoadTest
Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,787 sec

Testsuite: com.sun.jna.MemoryTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13,652 sec

Testsuite: com.sun.jna.NativeLibraryTest
Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2,393 sec

Testsuite: com.sun.jna.NativeTest
Tests run: 33, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2,162 sec

------------- Standard Error -----------------
Jul 21, 2020 3:07:10 PM com.sun.jna.Native getCharset
WARNING: JNA Warning: Encoding 'unsupported' is unsupported (unsupported)
Jul 21, 2020 3:07:11 PM com.sun.jna.Native getCharset
WARNING: JNA Warning: Using fallback encoding UTF-8
------------- ---------------- ---------------
Testsuite: com.sun.jna.NativedMappedTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,303 sec

Testsuite: com.sun.jna.PerformanceTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,153 sec

Testsuite: com.sun.jna.PlatformTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,164 sec

Testsuite: com.sun.jna.PointerBufferTest
Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,255 sec

Testsuite: com.sun.jna.PointerTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,273 sec

Testsuite: com.sun.jna.PrematureGCTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,623 sec

Testsuite: com.sun.jna.ReturnTypesTest
Tests run: 19, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,338 sec

Testsuite: com.sun.jna.StructureBufferFieldTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,276 sec

Testsuite: com.sun.jna.StructureByValueTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,307 sec

Testsuite: com.sun.jna.StructureFieldOrderInspectorTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,986 sec

Testsuite: com.sun.jna.StructureTest
Tests run: 90, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,578 sec

Testsuite: com.sun.jna.TypeMapperTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,314 sec

Testsuite: com.sun.jna.UnionTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,327 sec

Testsuite: com.sun.jna.VMCrashProtectionTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,278 sec

Testsuite: com.sun.jna.VarArgsCheckerTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0,159 sec

Testsuite: com.sun.jna.VarArgsTest
Tests run: 9, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0,309 sec

Testcase: testShortVarArgs(com.sun.jna.VarArgsTest):	FAILED
16-bit integer varargs not added correctly expected:<3> but was:<-697827325>
junit.framework.AssertionFailedError: 16-bit integer varargs not added correctly expected:<3> but was:<-697827325>
	at com.sun.jna.VarArgsTest.testShortVarArgs(VarArgsTest.java:66)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


Test com.sun.jna.VarArgsTest FAILED

opened by fkistner 24

Dead Lock in class initialization

I have observed a dead lock in class initialization, if two threads try to initialize a COM-Connection. My analysis is based on version 4.1.0. I have observed some bigger delay (~6s) in Thread-1 before the lock, while the Application is found in the RunningObjectTable. This is because of doors, which delays until the login is shown, but register in the ROT before.

Thread-1 is in Native.loadLibraryInstance with lock on libraries but waits for DISPPARAMS containing class OleAuto: sun.misc.Unsafe.ensureClassInitialized(Class) Unsafe.java (native) sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(Field, boolean) UnsafeFieldAccessorFactory.java:43 sun.reflect.ReflectionFactory.newFieldAccessor(Field, boolean) ReflectionFactory.java:140 java.lang.reflect.Field.acquireFieldAccessor(boolean) Field.java:1057 java.lang.reflect.Field.getFieldAccessor(Object) Field.java:1038 java.lang.reflect.Field.get(Object) Field.java:379 com.sun.jna.Native.loadLibraryInstance(Class) Native.java:447 com.sun.jna.Native.getLibraryOptions(Class) Native.java:508 com.sun.jna.Native.getStructureAlignment(Class) Native.java:596 com.sun.jna.Structure.setAlignType(int) Structure.java:251 com.sun.jna.Structure.(Pointer, int, TypeMapper) Structure.java:176 com.sun.jna.Structure.(Pointer, int) Structure.java:172 com.sun.jna.Structure.(int) Structure.java:159 com.sun.jna.Structure.() Structure.java:151 com.sun.jna.platform.win32.OleAuto$DISPPARAMS.() OleAuto.java:379 com.sun.jna.platform.win32.OleAuto$DISPPARAMS$ByReference.() OleAuto.java:359 com.sun.jna.platform.win32.COM.util.ProxyObject.oleMethod(int, Variant$VARIANT$ByReference, IDispatch, OaIdl$DISPID, Variant$VARIANT[]) ProxyObject.java:596 com.sun.jna.platform.win32.COM.util.ProxyObject.oleMethod(int, Variant$VARIANT$ByReference, IDispatch, String, Variant$VARIANT[]) ProxyObject.java:574 com.sun.jna.platform.win32.COM.util.ProxyObject.getProperty(Class, String, Object[]) ProxyObject.java:381 com.sun.jna.platform.win32.COM.util.ProxyObject.invokeSynchronised(Object, Method, Object[]) ProxyObject.java:260 com.sun.jna.platform.win32.COM.util.ProxyObject.invoke(Object, Method, Object[]) ProxyObject.java:220 […]

Thread-2 tries to initialize Class OleAuto but this requires the libraries Lock: com.sun.jna.Native.cacheOptions(Class, Map, Object) Native.java:1547 com.sun.jna.Native.loadLibrary(String, Class, Map) Native.java:428 com.sun.jna.platform.win32.OleAuto.() OleAuto.java:102 com.sun.jna.platform.win32.Variant$VARIANT.(String) Variant.java:198 com.sun.jna.platform.win32.COM.util.Convert.toVariant(Object) Convert.java:41 com.sun.jna.platform.win32.COM.util.ProxyObject.invokeMethod(Class, String, Object[]) ProxyObject.java:407 com.sun.jna.platform.win32.COM.util.ProxyObject.invokeSynchronised(Object, Method, Object[]) ProxyObject.java:267 com.sun.jna.platform.win32.COM.util.ProxyObject.invoke(Object, Method, Object[]) ProxyObject.java:220
fixed in branch

opened by bschwert 23
Two contrib/platform/win32 changes...
Added a WinNT.REG_QWORD case to Advapi32Util.registryGetValues

Merged Advapi32Util.getFileSecurity changes from the java.net SVN repository (February).

These changes work well in conjunction with my project (jOVAL), so I was just hoping you'd want to merge them back in with your mainline.

This is my first Github pull request, so please be gentle! :)
opened by joval 23
Reworked the way allocated memory is tracked

Replaced the WeakHashMap with a doubly linked list of WeakReferences to improve performance by reducing the time spent in synchronized blocks.

| Benchmark | Branch | Java version | Mode | Cnt | Score | Error | Units | -----------------------------------|------------------|--------------|--------|-----------|-------------|--------------|------- | MemoryBenchmark.allocateWithMemory | master | 1.8 | thrpt | 25 | 1420406.020 | ± 46239.151 | ops/s | MemoryBenchmark.allocateWithMemory | linked-reference | 1.8 | thrpt | 25 | 2020881.615 | ± 33498.284 | ops/s | MemoryBenchmark.allocateWithMemory | master | 11 | thrpt | 25 | 1526824.044 | ± 106555.120 | ops/s | MemoryBenchmark.allocateWithMemory | linked-reference | 11 | thrpt | 25 | 2615836.523 | ± 171918.750 | ops/s | MemoryBenchmark.allocateWithMemory | master | 14 | thrpt | 25 | 1877610.032 | ± 108837.116 | ops/s | MemoryBenchmark.allocateWithMemory | linked-reference | 14 | thrpt | 25 | 2289198.917 | ± 175390.679 | ops/s

opened by joerg1985 22
Added arm64 support to .travis.yml file
Added arm64 support to .travis.yml file.

JDK 11 is used to build jna on arm64. Thus, "openjdk-11-jdk" will be installed and JAVA_HOME and PATH will be set according to that.

libltdl-dev package needs to be installed for supporting arm64.
opened by odidev 22
Synchronized map poor performance

We have issues with the performance because of this: https://github.com/java-native-access/jna/blob/master/src/com/sun/jna/Memory.java#L57-L58 Lock waiting can get up to 99% of the time under a heavy load. SynchronizedMap works very slow in a multi-threaded environment. I suggest replacing it with any parallel map implementation.

opened by Karasiq 20
COM support: Added significant enhancements.

Added significant enhancements to the COM support. Most of this is under the com.sun.jna.platform.win32.COM.util package, with a few additions to the com.sun.jna.platform.win32.COM package.

there are tests added (which I think cover all the added enhancements), plus we have now been using it extensively for 3 months.

opened by dhakehurst 20
Add 'uses' information to OSGI metadata in MANIFEST.MF

When multiple versions of JNA are present in a single OSGI environment, it can happen that OSGI computes an incorrect dependency chain, which can lead to exceptions like the following:

This can be addressed by enriching the Export-Package metadata with ;uses="..." information [1].

Fixes #1487.

[1] https://spring.io/blog/2008/10/20/understanding-the-osgi-uses-directive/

opened by sratz 3

OSGI metadata in MANIFEST.MF is missing 'uses:' information

When multiple versions of JNA are present in a single OSGI environment, it can happen that OSGI computes an incorrect dependency chain, which can lead to exceptions like the following:

java.lang.LinkageError: loader constraint violation: when resolving interface method 'boolean com.sun.jna.platform.win32.Kernel32.ReadFile(com.sun.jna.platform.win32.WinNT$HANDLE, byte[], int, com.sun.jna.ptr.IntByReference, com.sun.jna.platform.win32.WinBase$OVERLAPPED)' the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @216be7ba of the current class, com/sap/adt/sapgui/ui/internal/win32/embedding/PipeHelper, and the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @1885dc2b for the method's defining class, com/sun/jna/platform/win32/Kernel32, have different Class objects for the type com/sun/jna/ptr/IntByReference used in the signature (com.sap.adt.sapgui.ui.internal.win32.embedding.PipeHelper is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @216be7ba, parent loader 'platform'; com.sun.jna.platform.win32.Kernel32 is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @1885dc2b, parent loader 'platform')
	at com.sap.adt.sapgui.ui.internal.win32.embedding.PipeHelper.readNamedPipe(PipeHelper.java:119)
	at com.sap.adt.sapgui.ui.internal.win32.embedding.WinGuiServerProxy$2.run(WinGuiServerProxy.java:133)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

This is a known issue in OSGI when metadata is insufficient and can be addressed by enriching the Export-Package metadata with ;uses="..." information: https://spring.io/blog/2008/10/20/understanding-the-osgi-uses-directive/

A patch could look like this:

diff --git a/build.xml b/build.xml
index 93bad0971..aab63fb33 100644
--- a/build.xml
+++ b/build.xml
@@ -470,7 +470,7 @@
               <attribute name="Bundle-RequiredExecutionEnvironment" value="JavaSE-1.6"/>
               <attribute name="Bundle-Vendor" value="${vendor}"/>
               <attribute name="Bundle-ActivationPolicy" value="lazy"/>
-              <attribute name="Export-Package" value="com.sun.jna;version=${jna.major}.${jna.minor}.${jna.revision}, com.sun.jna.ptr;version=${jna.major}.${jna.minor}.${jna.revision}, com.sun.jna.win32;version=${jna.major}.${jna.minor}.${jna.revision}"/>
+              <attribute name="Export-Package" value="com.sun.jna;version=${jna.major}.${jna.minor}.${jna.revision}, com.sun.jna.ptr;version=${jna.major}.${jna.minor}.${jna.revision};uses:=&quot;com.sun.jna&quot;, com.sun.jna.win32;version=${jna.major}.${jna.minor}.${jna.revision};uses:=&quot;com.sun.jna&quot;"/>
               <!-- Note that no terminal "*" is included in this list,
                  which will force failure on unsupported platforms.
               -->
diff --git a/contrib/platform/build.xml b/contrib/platform/build.xml
index 47fa8ed33..b7f04d393 100644
--- a/contrib/platform/build.xml
+++ b/contrib/platform/build.xml
@@ -147,20 +147,20 @@
                 <attribute name="Require-Bundle" value="com.sun.jna;bundle-version=&quot;${osgi.version}&quot;"/>
                 <attribute name="Export-Package"
                            value="
-com.sun.jna.platform;version=${osgi.version},
-com.sun.jna.platform.dnd;version=${osgi.version},
-com.sun.jna.platform.linux;version=${osgi.version},
-com.sun.jna.platform.mac;version=${osgi.version},
-com.sun.jna.platform.unix;version=${osgi.version},
-com.sun.jna.platform.unix.aix;version=${osgi.version},
-com.sun.jna.platform.unix.solaris;version=${osgi.version},
-com.sun.jna.platform.win32;version=${osgi.version},
-com.sun.jna.platform.win32.COM;version=${osgi.version},
-com.sun.jna.platform.win32.COM.tlb;version=${osgi.version},
-com.sun.jna.platform.win32.COM.tlb.imp;version=${osgi.version},
-com.sun.jna.platform.win32.COM.util;version=${osgi.version},
+com.sun.jna.platform;version=${osgi.version};uses:=&quot;com.sun.jna,com.sun.jna.platform.win32,javax.swing&quot;,
+com.sun.jna.platform.dnd;version=${osgi.version};uses:=&quot;javax.swing&quot;,
+com.sun.jna.platform.linux;version=${osgi.version};uses:=&quot;com.sun.jna,com.sun.jna.platform.unix&quot;,
+com.sun.jna.platform.mac;version=${osgi.version};uses:=&quot;com.sun.jna,com.sun.jna.platform,com.sun.jna.platform.unix,com.sun.jna.ptr&quot;,
+com.sun.jna.platform.unix;version=${osgi.version};uses:=&quot;com.sun.jna,com.sun.jna.ptr&quot;,
+com.sun.jna.platform.unix.aix;version=${osgi.version};uses:=&quot;com.sun.jna&quot;,
+com.sun.jna.platform.unix.solaris;version=${osgi.version};uses:=&quot;com.sun.jna&quot;,
+com.sun.jna.platform.win32;version=${osgi.version};uses:=&quot;com.sun.jna,com.sun.jna.platform,com.sun.jna.platform.win32.COM,com.sun.jna.ptr,com.sun.jna.win32&quot;,
+com.sun.jna.platform.win32.COM;version=${osgi.version};uses:=&quot;com.sun.jna,com.sun.jna.platform.win32,com.sun.jna.platform.win32.COM.util,com.sun.jna.ptr,com.sun.jna.win32&quot;,
+com.sun.jna.platform.win32.COM.tlb;version=${osgi.version};uses:=&quot;com.sun.jna.platform.win32.COM.tlb.imp&quot;,
+com.sun.jna.platform.win32.COM.tlb.imp;version=${osgi.version};uses:=&quot;com.sun.jna.platform.win32,com.sun.jna.platform.win32.COM&quot;,
+com.sun.jna.platform.win32.COM.util;version=${osgi.version};uses:=&quot;com.sun.jna,com.sun.jna.platform.win32,com.sun.jna.platform.win32.COM,com.sun.jna.platform.win32.COM.util.annotation,com.sun.jna.ptr&quot;,
 com.sun.jna.platform.win32.COM.util.annotation;version=${osgi.version},
-com.sun.jna.platform.wince;version=${osgi.version}
+com.sun.jna.platform.wince;version=${osgi.version};uses:=&quot;com.sun.jna,com.sun.jna.platform.win32&quot;
 "/>
             </manifest>
             <manifest file="@{target}" mode="update" if:true="@{module-info}">

I can open a pull-request to provide a patch.

However, it's a bit fragile to keep maintaining this metadata by hand. A better solution might be to automate the generation of the MANIFEST.MF metadata with bnd: https://bnd.bndtools.org/

opened by sratz 1

Improper thread detaching causes deadlock in LDR on Windows 10+

JNA: any JVM: any OpenJDK based OS: Windows 10+

Recently I analyzed a hang in a customer application raised against Zulu11.54+26-SA (before the same customer complained about a jdk-8 based JVM assemlage). The dump for the issue had the following stacktrace

.306  Id: 27f4.3f70 Suspend: 0 Teb: 00000000`54696000 Unfrozen "foo"
      Start: .306  Id: 27f4.3f70 Suspend: 0 Teb: 00000000`54696000 Unfrozen "foo"
      Start: ucrtbase!thread_start<unsigned int (__cdecl*)(void * __ptr64)> (00007ffb`6a092650)ucrtbase!thread_start<unsigned int (__cdecl*)(void * __ptr64)> (00007ffb`6a092650)
      Priority: 0  Priority class: 32  Affinity: fff
 # Child-SP          RetAddr               Call Site

      Priority: 0  Priority class: 32  Affinity: fff
 # Child-SP          RetAddr               Call Site
00 00 00000001`7f60e698 00007ffb`6a458933     ntdll!NtWaitForSingleObject+0x14
00000001`7f60e698 00007ffb`6a458933     ntdll!NtWaitForSingleObject+0x14
01 01 00000001`7f60e6a0 00007ffb`3bc1226f     KERNELBASE!WaitForSingleObjectEx+0x93
00000001`7f60e6a0 00007ffb`3bc1226f     KERNELBASE!WaitForSingleObjectEx+0x93
02 02 00000001`7f60e740 00007ffb`3bbe61dc     jvm!os::PlatformEvent::park+0x8f00000001`7f60e740 00007ffb`3bbe61dc     jvm!os::PlatformEvent::park+0x8f [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\os\windows\os_windows.cpp @ 5370]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\os\windows\os_windows.cpp @ 5370] 

03 03 (Inline Function) --------`--------     jvm!ParkCommon+0x8(Inline Function) --------`--------     jvm!ParkCommon+0x8 [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\mutex.cpp @ 404]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\mutex.cpp @ 404] 

04 04 00000001`7f60e770 00007ffb`3bbe6a81     jvm!Monitor::ILock+0x5c00000001`7f60e770 00007ffb`3bbe6a81     jvm!Monitor::ILock+0x5c [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\mutex.cpp @ 465]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\mutex.cpp @ 465] 

05 05 (Inline Function) --------`--------     jvm!Monitor::lock_without_safepoint_check+0x8(Inline Function) --------`--------     jvm!Monitor::lock_without_safepoint_check+0x8 [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\mutex.cpp @ 938]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\mutex.cpp @ 938] 

06 06 00000001`7f60e7a0 00007ffb`3bc7ad23     jvm!Monitor::lock_without_safepoint_check+0x3100000001`7f60e7a0 00007ffb`3bc7ad23     jvm!Monitor::lock_without_safepoint_check+0x31 [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\mutex.cpp @ 944]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\mutex.cpp @ 944] 

07 07 00000001`7f60e7d0 00007ffb`3bc7d328     jvm!SafepointSynchronize::block+0x17300000001`7f60e7d0 00007ffb`3bc7d328     jvm!SafepointSynchronize::block+0x173 [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\safepoint.cpp @ 939]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\safepoint.cpp @ 939] 

08 08 00000001`7f60e810 00007ffb`3bd5daa1     jvm!SafepointMechanism::block_if_requested_slow+0x1800000001`7f60e810 00007ffb`3bd5daa1     jvm!SafepointMechanism::block_if_requested_slow+0x18 [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\safepointmechanism.cpp @ 91]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\safepointmechanism.cpp @ 91] 

09 09 (Inline Function) --------`--------     jvm!SafepointMechanism::block_if_requested+0x1f(Inline Function) --------`--------     jvm!SafepointMechanism::block_if_requested+0x1f [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\safepointmechanism.inline.hpp @ 62]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\safepointmechanism.inline.hpp @ 62] 

0a 0a 00000001`7f60e840 00007ffb`3b794f08     jvm!JavaThread::check_safepoint_and_suspend_for_native_trans+0xe100000001`7f60e840 00007ffb`3b794f08     jvm!JavaThread::check_safepoint_and_suspend_for_native_trans+0xe1 [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\thread.cpp @ 2524]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\thread.cpp @ 2524] 

0b 0b 00000001`7f60fb20 00007ffb`3ba266a5     jvm!ThreadStateTransition::transition_from_native+0x8800000001`7f60fb20 00007ffb`3ba266a5     jvm!ThreadStateTransition::transition_from_native+0x88 [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\interfacesupport.inline.hpp @ 175]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\runtime\interfacesupport.inline.hpp @ 175] 

0c 0c 00000001`7f60fb50 00007ffb`446e1115     jvm!jni_DetachCurrentThread+0x6500000001`7f60fb50 00007ffb`446e1115     jvm!jni_DetachCurrentThread+0x65 [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\prims\jni.cpp @ 4359]  [c:\jenkins\workspace\zulu11-build-win64\zulu-src.git\src\hotspot\share\prims\jni.cpp @ 4359] 

0d 0d 00000001`7f60fb80 00007ffb`446e11ef     jna6833526131579377318!Java_com_sun_jna_Native_getDirectByteBuffer__Lcom_sun_jna_Pointer_2JJJ+0x2665
00000001`7f60fb80 00007ffb`446e11ef     jna6833526131579377318!Java_com_sun_jna_Native_getDirectByteBuffer__Lcom_sun_jna_Pointer_2JJJ+0x2665
0e 0e 00000001`7f60fbe0 00007ffb`446e956f     jna6833526131579377318!Java_com_sun_jna_Native_getDirectByteBuffer__Lcom_sun_jna_Pointer_2JJJ+0x273f
00000001`7f60fbe0 00007ffb`446e956f     jna6833526131579377318!Java_com_sun_jna_Native_getDirectByteBuffer__Lcom_sun_jna_Pointer_2JJJ+0x273f
0f 0f 00000001`7f60fc20 00007ffb`6de95d37     jna6833526131579377318!Java_com_sun_jna_Native_getDirectByteBuffer__Lcom_sun_jna_Pointer_2JJJ+0xaabf
00000001`7f60fc20 00007ffb`6de95d37     jna6833526131579377318!Java_com_sun_jna_Native_getDirectByteBuffer__Lcom_sun_jna_Pointer_2JJJ+0xaabf
10 10 00000001`7f60fc80 00007ffb`6de933f4     ntdll!LdrpCallInitRoutine+0x6f
00000001`7f60fc80 00007ffb`6de933f4     ntdll!LdrpCallInitRoutine+0x6f
11 11 00000001`7f60fcf0 00007ffb`6deca33e     ntdll!LdrShutdownThread+0x154
00000001`7f60fcf0 00007ffb`6deca33e     ntdll!LdrShutdownThread+0x154
12 12 00000001`7f60fdf0 00007ffb`6a49992a     ntdll!RtlExitUserThread+0x3e
00000001`7f60fdf0 00007ffb`6a49992a     ntdll!RtlExitUserThread+0x3e
13 13 00000001`7f60fe30 00007ffb`6a092794     KERNELBASE!FreeLibraryAndExitThread+0x4a
00000001`7f60fe30 00007ffb`6a092794     KERNELBASE!FreeLibraryAndExitThread+0x4a
14 14 00000001`7f60fe60 00007ffb`6a0e0809     ucrtbase!common_end_thread+0xa4
00000001`7f60fe60 00007ffb`6a0e0809     ucrtbase!common_end_thread+0xa4
15 15 00000001`7f60fe90 00007ffb`4593f72c     ucrtbase!endthreadex+0x9
00000001`7f60fe90 00007ffb`4593f72c     ucrtbase!endthreadex+0x9
16 16 00000001`7f60fec0 00007ffb`6a09268a     glib_2_0_0!g_rw_lock_writer_unlock+0x33c
00000001`7f60fec0 00007ffb`6a09268a     glib_2_0_0!g_rw_lock_writer_unlock+0x33c
17 17 00000001`7f60ff00 00007ffb`6b0b7974     ucrtbase!thread_start<unsigned int (__cdecl*)(void * __ptr64)>+0x3a
00000001`7f60ff00 00007ffb`6b0b7974     ucrtbase!thread_start<unsigned int (__cdecl*)(void * __ptr64)>+0x3a
18 18 00000001`7f60ff30 00007ffb`6deca2d1     kernel32!BaseThreadInitThunk+0x14
00000001`7f60ff30 00007ffb`6deca2d1     kernel32!BaseThreadInitThunk+0x14
19 19 00000001`7f60ff60 00000000`00000000     ntdll!RtlUserThreadStart+0x21
00000001`7f60ff60 00000000`00000000     ntdll!RtlUserThreadStart+0x21

and I found the code causing such stack trace callback.c:587

static void dispose_thread_data(void* data) {
  thread_storage* tls = (thread_storage*)data;
  JavaVM* jvm = tls->jvm;
  JNIEnv* env;
  int is_attached = (*jvm)->GetEnv(jvm, (void*)&env, JNI_VERSION_1_4) == JNI_OK;
  jboolean detached = JNI_TRUE;
  if (is_attached) {
    if ((*jvm)->DetachCurrentThread(jvm) != 0) {
      fprintf(stderr, "JNA: could not detach native thread (automatic)\n");
      detached = JNI_FALSE;
    }
  }
  if (tls->termination_flag && detached) {
    *(tls->termination_flag) = JNI_TRUE;
  }
  free(data);
}

BOOL WINAPI DllMain(HINSTANCE hDLL, DWORD fdwReason, LPVOID lpvReserved) {
  switch (fdwReason) {
  ...
  case DLL_THREAD_DETACH: {
    thread_storage* tls = (thread_storage*)TlsGetValue(tls_thread_data_key);
    if (tls) {
      dispose_thread_data(tls);
      TlsSetValue(tls_thread_data_key, 0);
    }
    break;
  }
  ...
  return TRUE;
}

The Invokation API tells explicitly

A native thread attached to the VM must call DetachCurrentThread() to detach itself BEFORE exiting.

The problem here is that you cannot consider a thread to detach as completely done. If at the moment JVM runs a safepoint synchronization the thread gets lock and stays awaiting until all other threads reach the safepoint (see the callstack). That still might work before Windows 10 introduced parallel algorithm of DLL loading/releasing, but now... I do not have an access to Windows source code, but ReactOS project shows us that LDR calls DllMain(..., DLL_THREAD_DETACH, ...) under taken critical section

NTSTATUS
NTAPI
LdrShutdownThread(VOID)
{
    ...
    /* Get the Ldr Lock */
    RtlEnterCriticalSection(&LdrpLoaderLock);
    ...
    /* Start at the end */
    ListHead = &Peb->Ldr->InInitializationOrderModuleList;
    NextEntry = ListHead->Blink;
    while (NextEntry != ListHead)
    {
        ...
                            LdrpCallInitRoutine(EntryPoint,
                                                 LdrEntry->DllBase,
                                                 DLL_THREAD_DETACH,
                                                 NULL);
        ...
    }
    ...
    /* Free TLS */
    LdrpFreeTls();
    RtlLeaveCriticalSection(&LdrpLoaderLock);
    ...
}

that locks LDRP workers, so other threads loading/releasing DLL's at the moment get locked just like

. 76  Id: 27f4.2de0 Suspend: 0 Teb: 00000000`0023e000 Unfrozen
      Start: . 76  Id: 27f4.2de0 Suspend: 0 Teb: 00000000`0023e000 Unfrozen
      Start: mswsock!SockAsyncThread (00007ffb`696d0460)mswsock!SockAsyncThread (00007ffb`696d0460)
      Priority: 1  Priority class: 32  Affinity: fff
 # Child-SP          RetAddr               Call Site

      Priority: 1  Priority class: 32  Affinity: fff
 # Child-SP          RetAddr               Call Site
00 00 00000000`415efd18 00007ffb`6de983f5     ntdll!NtWaitForSingleObject+0x14
00000000`415efd18 00007ffb`6de983f5     ntdll!NtWaitForSingleObject+0x14
01 01 00000000`415efd20 00007ffb`6de93338     ntdll!LdrpDrainWorkQueue+0x15d
00000000`415efd20 00007ffb`6de93338     ntdll!LdrpDrainWorkQueue+0x15d
02 02 00000000`415efd60 00007ffb`6deca33e     ntdll!LdrShutdownThread+0x98
00000000`415efd60 00007ffb`6deca33e     ntdll!LdrShutdownThread+0x98
03 03 00000000`415efe60 00007ffb`6a49992a     ntdll!RtlExitUserThread+0x3e
00000000`415efe60 00007ffb`6a49992a     ntdll!RtlExitUserThread+0x3e
04 04 00000000`415efea0 00007ffb`696d0569     KERNELBASE!FreeLibraryAndExitThread+0x4a
00000000`415efea0 00007ffb`696d0569     KERNELBASE!FreeLibraryAndExitThread+0x4a
05 05 00000000`415efed0 00007ffb`6b0b7974     mswsock!SockAsyncThread+0x109
00000000`415efed0 00007ffb`6b0b7974     mswsock!SockAsyncThread+0x109
06 06 00000000`415eff30 00007ffb`6deca2d1     kernel32!BaseThreadInitThunk+0x14
00000000`415eff30 00007ffb`6deca2d1     kernel32!BaseThreadInitThunk+0x14
07 07 00000000`415eff60 00000000`00000000     ntdll!RtlUserThreadStart+0x21
00000000`415eff60 00000000`00000000     ntdll!RtlUserThreadStart+0x21

.319  Id: 27f4.3e58 Suspend: 0 Teb: 00000000`54700000 Unfrozen
      Start: .319  Id: 27f4.3e58 Suspend: 0 Teb: 00000000`54700000 Unfrozen
      Start: ucrtbase!thread_start<unsigned int (__cdecl*)(void * __ptr64)> (00007ffb`6a092650)ucrtbase!thread_start<unsigned int (__cdecl*)(void * __ptr64)> (00007ffb`6a092650)
      Priority: 0  Priority class: 32  Affinity: fff
 # Child-SP          RetAddr               Call Site

      Priority: 0  Priority class: 32  Affinity: fff
 # Child-SP          RetAddr               Call Site
00 00 00000001`5204f898 00007ffb`6de983f5     ntdll!NtWaitForSingleObject+0x14
00000001`5204f898 00007ffb`6de983f5     ntdll!NtWaitForSingleObject+0x14
01 01 00000001`5204f8a0 00007ffb`6de935f7     ntdll!LdrpDrainWorkQueue+0x15d
00000001`5204f8a0 00007ffb`6de935f7     ntdll!LdrpDrainWorkQueue+0x15d
02 02 00000001`5204f8e0 00007ffb`6dee8625     ntdll!LdrpInitializeThread+0x8b
00000001`5204f8e0 00007ffb`6dee8625     ntdll!LdrpInitializeThread+0x8b
03 03 00000001`5204f9c0 00007ffb`6dee8203     ntdll!LdrpInitialize+0x409
00000001`5204f9c0 00007ffb`6dee8203     ntdll!LdrpInitialize+0x409
04 04 00000001`5204fa60 00007ffb`6dee81ae     ntdll!LdrpInitialize+0x3b
00000001`5204fa60 00007ffb`6dee81ae     ntdll!LdrpInitialize+0x3b
05 05 00000001`5204fa90 00000000`00000000     ntdll!LdrInitializeThunk+0xe
00000001`5204fa90 00000000`00000000     ntdll!LdrInitializeThunk+0xe

and cannot get to the safepoint rendezvous. We get the deadlock.

We provided a workaround to the customer but the changes are very tricky and risky and they touch JDK logic that stays immutable for years, so there is not a chance to push the changes to OpenJDK. Please fix the issue on your side. Thank you

opened by apavlyutkin 12

#463 breaks objective-c's `objc_msgSend` call

patch #463 breaks objective-c's `objc_msgSend` call.

i request JNA to make #463 float promotion pluggable.

i mentioned here but i got no response so i promote that to this issue.

i use JNA in my project to talk to objective-c natives. objective-c natives need to get float argument value of method as float, but the patch #463 promotes float to double. and #463 is hardcoded, there is no way to change.

below is how i found this issue.

obj-c side

https://github.com/umjammer/rococoa/blob/0.8.5/rococoa-core/src/main/native/test.m#L121-L125

java side

https://github.com/umjammer/rococoa/blob/0.8.5/rococoa-core/src/test/java/org/rococoa/FoundationStructureReturnTest.java#L127-L136

log

main	Foundation.send - sending (boolean) [ID 0x7ff0e3c62650].testGetFloatByValue:(3.14:Float)  # <---- still float
main	Foundation.send - @@@0: 3.14:Float
java.lang.Exception: @@@1:  boolean:Class, [ID 0x7ff0e3c62650]:ID, [Selector testGetFloatByValue:]:Selector, 3.140000104904175:Double, null   # <---- changed as double!!!
	at org.rococoa.internal.MsgSendHandler.invoke(MsgSendHandler.java:122)
	at com.sun.jna.Library$Handler.invoke(Library.java:263)
	at com.sun.proxy.$Proxy13.syntheticSendMessage(Unknown Source)
	at org.rococoa.Foundation.send(Foundation.java:242)
	at org.rococoa.Foundation.send(Foundation.java:220)
	at org.rococoa.FoundationStructureReturnTest.test2(FoundationStructureReturnTest.java:132)
36893488147419103232.0                  # <--- printf shows passed float value is broken

org.opentest4j.AssertionFailedError: 
Expected :true
Actual   :false

i traced around before the call below using a debugger

at com.sun.jna.Library$Handler.invoke(Library.java:263)

then i found https://github.com/java-native-access/jna/blob/3705b849892aa3c37e5608e640eff19047811a5c/src/com/sun/jna/Function.java#L776 caused this issue.

Version of JNA: 5.12.1 Java Virtual Machine:

java version "1.8.0_291"
Java(TM) SE Runtime Environment (build 1.8.0_291-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.291-b10, mixed mode)

Operating system:

$ uname -a                                                                                                                                                                                                                       1.0.10
Darwin nsanomac4 20.6.0 Darwin Kernel Version 20.6.0: Tue Apr 19 21:04:45 PDT 2022; root:xnu-7195.141.29~1/RELEASE_X86_64 x86_64

feature request

opened by umjammer 5

the encoding in test.c affects the compile failure on Windows OS

Versions in use JDK: 1.8 OS: Windows 10 Architecture: x86_64

Description of compile failure: [exec] 正在创建库 ../build/native-win32-x86-64/jnidispatch.lib 和对象 ../build/native-win32-x86-64/jnidispatch.exp [exec] ../build/native-win32-x86-64/jnidispatch.dll [exec] /cygdrive/d/work/workspace/jna/jna_0930/jna/native/libffi/msvcc.sh -m64 -W -Wall -Wno-unused -Wno-parentheses -DPSAPI_VERSION=1 -DFFI_BUILDING -DUNICODE -D_UNICODE -DHAVE_PROTECTION -DUSE_STATIC_RTL -I"D:\system\jdk8-64\jdk1.8.0_252\jre/../include" -I"D:\system\jdk8-64\jdk1.8.0_252\jre/../include/win32" -I"D:\work\workspace\jna\jna_0930\jna\build\headers" -I../build/native-win32-x86-64/libffi/include -DJNA_JNI_VERSION='"6.1.5"' -DCHECKSUM='"147a998f0cbc89681a1ae6c0dd121629"' -Wno-unknown-warning-option -Werror -Wno-clobbered -Wno-unused-variable -c testlib.c -o ../build/native-win32-x86-64/testlib.o [exec] D:/work/workspace/jna/jna_0930/jna/native/testlib.c: error C2220: 警告被视为错误 - 没有生成“object”文件 [exec] D:/work/workspace/jna/jna_0930/jna/native/testlib.c: warning C4819: 该文件包含不能在当前代码页(936)中表示的字符。请将该文件保存为 Unicode 格式以防止数据丢失 [exec] link /DLL /OUT:../build/native-win32-x86-64/testlib.dll ../build/native-win32-x86-64/testlib.o psapi.lib [exec] Microsoft (R) Incremental Linker Version 14.16.27041.0 [exec] Copyright (C) Microsoft Corporation. All rights reserved. [exec] [exec] LINK : fatal error LNK1181: 无法打开输入文件“..\build\native-win32-x86-64\testlib.o” [exec] make: *** [Makefile:492: ../build/native-win32-x86-64/testlib.dll] Error 157

The Chinese punctuation mark at line 897 in testlib.c affects compilation and causes compilation failure on Windows OS

opened by wutongyuyu 0

Java Native Access

Related tags

Overview

Java Native Access (JNA)

Projects Using JNA

Supported Platforms

Download

JNA

JNA Platform

Features

Community and Support

Using the Library

Primary Documentation (JavaDoc)

Developers

Contributing

License

Comments

TODO

Changes

Steps

patch #463 breaks objective-c's objc_msgSend call.

i request JNA to make #463 float promotion pluggable.

obj-c side

java side

log

Owner

Java Native Access

The missing bridge between Java and native C++

Compile Java byte-code to native CPU's.

Jssembly is a library that allows you to execute native assembly from Java.

Java Abstracted Foreign Function Layer

Java Bindings for V8

Low-overhead, non-blocking I/O, external Process implementation for Java

cglib - Byte Code Generation Library is high level API to generate and transform Java byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.

Just-In-Time Access is an AppEngine application that lets you manage just-in-time privileged access to Google Cloud projects.

Spring Native provides beta support for compiling Spring applications to native executables using GraalVM native-image compiler.

JPassport works like Java Native Access (JNA) but uses the Foreign Linker API instead of JNI. Similar to JNA, you declare a Java interface that is bound to the external C library using method names.

LWJGL is a Java library that enables cross-platform access to popular native APIs useful in the development of graphics (OpenGL, Vulkan), audio (OpenAL), parallel computing (OpenCL, CUDA) and XR (OpenVR, LibOVR) applications.

Java Native Access

LWJGL is a Java library that enables cross-platform access to popular native APIs useful in the development of graphics (OpenGL, Vulkan), audio (OpenAL), parallel computing (OpenCL, CUDA) and XR (OpenVR, LibOVR) applications.

MixStack lets you connects Flutter smoothly with Native pages, supports things like Multiple Tab Embeded Flutter View, Dynamic tab changing, and more. You can enjoy a smooth transition from legacy native code to Flutter with it.

Sceneform React Native AR Component using ARCore and Google Filament as 3D engine. This the Sceneform Maintained Component for React Native

React native wrapper for Jitsi Meet SDK Library that rely on the native view (Activity / ViewController)

With react-native-update-in-app library you can easily implement in-app updates in your React Native app using CDN or any other file server

An awesome native wheel picker component for React Native.

jdbi is designed to provide convenient tabular data access in Java; including templated SQL, parameterized and strongly typed queries, and Streams integration

patch #463 breaks objective-c's `objc_msgSend` call.