As I said in google groups.
( http://groups.google.com/group/jna-users/browse_thread/thread/4f56f70a840c12c2/76334b36c15b380d#76334b36c15b380d )

I tried to rm old class file but it still not work...
So I made a repo here.
(the java code:http://dl.dropbox.com/u/15187846/jnatest.tar)

Thanks.

When using jna under Android armeabi-v7a, jna callbacks crash when called from native code. Our investigation showed that generated callback proxy code is allocated in heap (which does not have executable permission) and memory protection does not allow such call on some devices. Could you point in which code place could we attempt to fix the issue (so that code is allocated into executable piece of memory) ?

Can't find WinDef.HWND GetForegroundWindow() in platform.jar (version 3.3.0), but it is in the JAVA doc. Please implement it. Thx.

The VM error below has occurred twice so on my Ubuntu 10.04 amd64 machine.
Also, twice, the same test passed when I ran the test suite again.

[junit] Running com.sun.jna.DirectTest
[junit] #
[junit] # A fatal error has been detected by the Java Runtime Environment:
[junit] #
[junit] #  SIGSEGV (0xb) at pc=0x00007f1db8bdbc71, pid=16855, tid=139765519607552
[junit] #
[junit] # JRE version: 6.0_26-b03
[junit] # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
[junit] # Problematic frame:
[junit] # C  [ld-linux-x86-64.so.2+0x9c71]  _dl_rtld_di_serinfo+0x1141
[junit] #
[junit] # An error report file with more information is saved as:
[junit] # /home/dan/javadev/dan-jna/jna/hs_err_pid16855.log
[junit] #
[junit] # If you would like to submit a bug report, please visit:
[junit] #   http://java.sun.com/webapps/bugreport/crash.jsp
[junit] # The crash happened outside the Java Virtual Machine in native code.
[junit] # See problematic frame for where to report the bug.
[junit] #
[junit] Running com.sun.jna.DirectTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec

I will attach hs_err_pid16855.log as well.

Dan Rollo

first i have reported the crash to the jdk team - see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7071606
but the guys there told me that that have to be reported to the jna-community..
they said: "Evaluation

The crash can be seen to be occurring in Memory.free which is called as part of a finalizer. This call occurs in the com.sun.jna library. JNA stands for Java Native Access and provides a Java interface to native code:

https://github.com/twall/jna

this library is not part of the JDK and this crash should be reported to the JNA community.
Posted Date : 2011-07-28 03:55:21.0"

Hey, we're using JNA as part of https://github.com/trinidad/trinidad_daemon_extension
We've lately upgraded to the latest 3.4.0 downloaded from http://mvnrepository.com/artifact/net.java.dev.jna/jna
Lastly we've received an issue from a user reporting it's not working for him on RedHat 5 due a glibc incompatibility but replacing the jar with 3.4.0 from https://github.com/twall/jna/downloads resolved the problem for him ...

How could this happen, why do these 2 jars differ ?
Besides being compiled on different OSes there seems to be some binary difference :

kares@theborg:~/tmp/compare$ diff -r jna.jar/ jna-3.4.0.jar/
Binary files jna.jar//com/sun/jna/IntegerType.class and jna-3.4.0.jar//com/sun/jna/IntegerType.class differ
Binary files jna.jar//com/sun/jna/linux-amd64/libjnidispatch.so and jna-3.4.0.jar//com/sun/jna/linux-amd64/libjnidispatch.so differ
Binary files jna.jar//com/sun/jna/Native$1.class and jna-3.4.0.jar//com/sun/jna/Native$1.class differ
Binary files jna.jar//com/sun/jna/Native$2.class and jna-3.4.0.jar//com/sun/jna/Native$2.class differ
Binary files jna.jar//com/sun/jna/Native$3.class and jna-3.4.0.jar//com/sun/jna/Native$3.class differ
Binary files jna.jar//com/sun/jna/Native$4.class and jna-3.4.0.jar//com/sun/jna/Native$4.class differ
Binary files jna.jar//com/sun/jna/Native$5.class and jna-3.4.0.jar//com/sun/jna/Native$5.class differ
Binary files jna.jar//com/sun/jna/Native$6.class and jna-3.4.0.jar//com/sun/jna/Native$6.class differ
Binary files jna.jar//com/sun/jna/Native$7.class and jna-3.4.0.jar//com/sun/jna/Native$7.class differ
Binary files jna.jar//com/sun/jna/Native$8.class and jna-3.4.0.jar//com/sun/jna/Native$8.class differ
Binary files jna.jar//com/sun/jna/NativeLibrary$1.class and jna-3.4.0.jar//com/sun/jna/NativeLibrary$1.class differ
Binary files jna.jar//com/sun/jna/NativeLibrary$2.class and jna-3.4.0.jar//com/sun/jna/NativeLibrary$2.class differ
Binary files jna.jar//com/sun/jna/NativeMappedConverter.class and jna-3.4.0.jar//com/sun/jna/NativeMappedConverter.class differ
Binary files jna.jar//com/sun/jna/Structure$1.class and jna-3.4.0.jar//com/sun/jna/Structure$1.class differ
Binary files jna.jar//com/sun/jna/Structure$2.class and jna-3.4.0.jar//com/sun/jna/Structure$2.class differ
Binary files jna.jar//com/sun/jna/Structure$2$StructureSet.class and jna-3.4.0.jar//com/sun/jna/Structure$2$StructureSet.class differ
Binary files jna.jar//com/sun/jna/Structure$AutoAllocated.class and jna-3.4.0.jar//com/sun/jna/Structure$AutoAllocated.class differ
Binary files jna.jar//com/sun/jna/Structure.class and jna-3.4.0.jar//com/sun/jna/Structure.class differ
Binary files jna.jar//com/sun/jna/Structure$FFIType.class and jna-3.4.0.jar//com/sun/jna/Structure$FFIType.class differ
Binary files jna.jar//com/sun/jna/Structure$FFIType$FFITypes.class and jna-3.4.0.jar//com/sun/jna/Structure$FFIType$FFITypes.class differ
Binary files jna.jar//com/sun/jna/Structure$FFIType$size_t.class and jna-3.4.0.jar//com/sun/jna/Structure$FFIType$size_t.class differ
Binary files jna.jar//com/sun/jna/Structure$LayoutInfo.class and jna-3.4.0.jar//com/sun/jna/Structure$LayoutInfo.class differ
Binary files jna.jar//com/sun/jna/Structure$MemberOrder.class and jna-3.4.0.jar//com/sun/jna/Structure$MemberOrder.class differ
Binary files jna.jar//com/sun/jna/Structure$StructField.class and jna-3.4.0.jar//com/sun/jna/Structure$StructField.class differ
Binary files jna.jar//com/sun/jna/WeakIdentityHashMap$1.class and jna-3.4.0.jar//com/sun/jna/WeakIdentityHashMap$1.class differ
Binary files jna.jar//com/sun/jna/win32/W32APIOptions$1.class and jna-3.4.0.jar//com/sun/jna/win32/W32APIOptions$1.class differ
Binary files jna.jar//com/sun/jna/win32/W32APIOptions$2.class and jna-3.4.0.jar//com/sun/jna/win32/W32APIOptions$2.class differ
Binary files jna.jar//com/sun/jna/win32/W32APITypeMapper$1.class and jna-3.4.0.jar//com/sun/jna/win32/W32APITypeMapper$1.class differ
Binary files jna.jar//com/sun/jna/win32/W32APITypeMapper$2.class and jna-3.4.0.jar//com/sun/jna/win32/W32APITypeMapper$2.class differ
diff -r jna.jar//META-INF/MANIFEST.MF jna-3.4.0.jar//META-INF/MANIFEST.MF
3c3
< Created-By: 1.6.0_29-b11-402-10M3527 (Apple Inc.)

---
> Created-By: 1.5.0_19-b02 (Sun Microsystems Inc.)
9c9
< Implementation-Version: 3.4.0 (b541)

---
> Implementation-Version: 3.4.0 (b5)

Thanks, K.

Pointer.nativeValue(Pointer) takes the pointer for which you want to perform the operation.

i.e. in every way, it pretends to be an instance method, only for some crazy reason it isn't an instance method.

like a dll shdocvw.dll ,i want to call a method named "Navigate2",this method is one member of shdocvw.dll named IWebBrowser,how should i do >?

The ffi_common.h contains definitions:

define LIKELY(x) __builtin_expect((x),1)

define UNLIKELY(x) __builtin_expect((x),1)

I guess that the definition of UNLIKELY should be:

define UNLIKELY(x) __builtin_expect((x),0)

Also some libraries prefer to define LIKELY like this:

define _X_LIKELY(x) __builtin_expect(!!(x), 1)

define __GMP_LIKELY(cond) __builtin_expect ((cond) != 0, 1)

but I'm not sure if it changes the generated code on any platform.

Hello

I'm using jna to get some mac native data from system core functions.

I found JNA unable to retrive UniChar buffers encoded as 16 bit unicode string.

Real memory block i read from function is

[97, 0, 98, 0, 99, 0] == ["abc"]

but string decoded by Memory.getString(0,true) = "ac"

I'm assuing it does 32 bit unicode char length.

http://pastebin.com/VWACgEh5

full source you can find here: http://code.google.com/p/mircle/source/browse/#git%2Fmircle%2Fsrc%2Fmain%2Fjava%2Fcom%2Fgoogle%2Fcode%2Fmircle%2Fos%2Fmac

Hello,

has this patch been merge into the codebase?
http://code.google.com/p/javacv/downloads/detail?name=jna-android-20101202.patch

I'm currently eager to evaluate JNA for Android as described here:
http://code.google.com/p/javacv/wiki/JNAOnAndroid

Thank you

Greetings

Jotschi

I have the following simple DLL that adds two parameters and returns the result: http://dl.dropbox.com/u/9975312/jnaFail/compileTest.c (using the following method: int doTestMethod(int a, int b) )
Which can be compiled on Windows using G++ using the following two calls (in order):
g++ -c -o compileTest.o compileTest.c
g++ -static-libstdc++ -static-libgcc -shared -o compileTest.dll compileTest.o

and I have two programs to use the DLL (dll must be in the same directory as the programs):
http://dl.dropbox.com/u/9975312/jnaFail/doItCStyle.cpp Uses it from a C++ environment (with dependency on Windows), and always succeeds. To compile,
g++ -static-libstdc++ -static-libgcc -o doItCStyle.exe doItCStyle.cpp
http://dl.dropbox.com/u/9975312/jnaFail/test_drive.jar Uses it from Java/JNA (has a dependency on JNA being in the same directory: http://dl.dropbox.com/u/9975312/jnaFail/jna.jar ) and succeeds on Linux, Mac, and most Windows, except for about 50% of Win7x64. One one machine with Win7x64, it will consistently work:
LIB true C:\Users\Harri\Desktop\New folder\compileTest.dll
LIB false C:\Users\Harri\Desktop\New folder\libcompileTest.dll
func(5,8) = 13

On another machine with Win7x64, it consistently reports the following output:
LIB true C:\Users\Josh\Desktop\New folder\compileTest.dll
LIB false C:\Users\Josh\Desktop\New folder\libcompileTest.dll
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'compileTest': The specified module could not be found.

The first line of output tells us that a File constructed using the specified path exists (true). The second line prepends a "lib" similar to jna, and tests the file's existence (false). Since the first path exists, JNA should be finding that dll and passing it off to Native.open, which then throws the UnsatisfiedLinkError, which JNA catches, tests other paths/filenames, and then rethrows, resulting in the final line of output above.

Of course, this is a simplified test case. I'm also working on a much larger team project that uses JNA and must be cross-platform, and one of my main developers (josh, in case you is on Windows 7 and is completely unable to do any work because of this error, so our windows port is falling deplorably behind. As such, I'd gladly accept workarounds in the meantime until you can figure this out and fix it.

-IsmAvatar

Hi, I am getting the following error. Please help.
java.lang.UnsatisfiedLinkError: Error looking up function 'funcA': The specified procedure could not be found.

Am I doing something wrong?

Using the Dependency Walker, it shows MY.DLL has the following dependency and functions:

MY.DLL has a dependency on Kernel32.DLL. Kernel32.DLL has a dependency on NTDLL.DLL

functions:
class SomeClass & SomeClass::operator=(class SomeClass const &)
void FuncA(unsigned short,unsigned char *,unsigned char *)
int FuncB(unsigned char *,unsigned char *)

My JNA interface:

public interface MyDll extends Library {
void funcA(short len, char[] input, char[] output);
int funcB(char[] input, char[] output);
}

Calling:
char[] input = new char[] { [char array initialization] };
char[] output = new char[8]; // output has no more than 8 characters

MyDll myDll = (MyDll) Native.loadLibrary("C:[some path]\my.dll", My.class);
myDll.ecrMac(input, output);

The library is loaded, but why am I getting the error
java.lang.UnsatisfiedLinkError: Error looking up function 'funcA': The specified procedure could not be found.

Hi,

for my project I would need JNA for ARM9 (not armel) and DEBIAN.
I am not sure it it is still available or not?
Thanks a lot
Generic

Originally filed at http://java.net/jira/browse/JNA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315115#action_315115.

The only reason for the win32-specific shutdown hook is to allow the temporary, unpacked dll to be removed from the filesystem.

Rather than getting more complicated (adding free memory hooks or some such), perhaps it'd be simpler to somehow flag the file that needs to be deleted as no longer being in use, and doing the cleanup on the next startup. That'd leave a few files around, perhaps, but should prevent them from accumulating.

Whenever I am using X11.XNextEvent(display, event), the "type" field of the event is set properly, but all events within the event (i.e. event.xkey (XKeyEvent) ) contain empty fields.

how would i run my file "command.java" as a system service using this?

I have a problem with the simultaneous use of two libraries in the JVM on Linux using JNA (3.4.0).

The problem occurs when two third-party libraries (not mine) have global variables with the same name.

When calling functions that manipulate global variables, I have a BIG problem.

I found that the problem only occurs on Linux and probably other platforms using the "dlopen" for Windows works properly.

In revision 771 (svn repo) was added "set RTLD_GLOBAL flag" to dlopen function call.

This flag set all subsequent casll to dlopen to share same namespace for C global variables (shared), not only external vars.

File: dispatch.c
Line 67: #define LOAD_LIBRARY(NAME) dlopen(NAME, RTLD_LAZY|RTLD_GLOBAL)

The fix is remove flag RTLD_GLOBAL for dlopen call or create a option (Map options).

I made a workaround to resolve the problem immediately loading the libraries before using the JNA.

Example

Wrong output:

[root@jbosscluster bin]# java -jar Main.jar
Foo count: 1
Func number: 2
Current foo count: 2
Current func number: 2
Foo count: 3
Func number: 4
Current foo count: 4
Current func number: 4
[root@jbosscluster bin]#

Correct output:

[root@jbosscluster bin]# java -jar Main.jar
Foo count: 1
Func number: 1
Current foo count: 1
Current func number: 1
Foo count: 2
Func number: 2
Current foo count: 2
Current func number: 2
[root@jbosscluster bin]#

Main.java

public interface Foo extends Library {
    void addCount();
    int getCount();
}

public interface Func extends Library {
    void addNumber();
    int getNumber();
}

public interface DL extends Library {
   public static final int
             RTLD_LOCAL      = 0x00000,
             RTLD_LAZY       = 0x00001,
             RTLD_NOW        = 0x00002,
             RTLD_BINDING_MASK   = 0x3,
             RTLD_NOLOAD     = 0x00004,
             RTLD_DEEPBIND   = 0x00008,
             RTLD_GLOBAL     = 0x00100,
             RTLD_NODELETE   = 0x01000;

   public Pointer dlopen(String file, int mode);
   public int dlclose(Pointer handle);
}

public class Main {
    public static void main(String args[]) throws Exception {
        /*
         * Workarround for RTLD_GLOBAL flag in function dlopen called by JNA
         */
        if (Platform.isLinux()) {
            DL dl = (DL)Native.loadLibrary("dl", DL.class);
            dl.dlopen("libFoo.so", dl.RTLD_LAZY);
            dl.dlopen("libFunc.so",  dl.RTLD_LAZY);
        }

        Foo foo = (Foo)Native.loadLibrary("Foo", Foo.class);
        Func func = (Func)Native.loadLibrary("Func", Func.class);

        foo.addCount();
        func.addNumber();

        System.out.println("Current foo count: "+foo.getCount());
        System.out.println("Current func number: "+func.getNumber());

        foo.addCount();
        func.addNumber();

        System.out.println("Current foo count: "+foo.getCount());
        System.out.println("Current func number: "+func.getNumber());
    }
}

func.c

#include <stdio.h>
#include <stdlib.h>
#include "func.h"

int count = 0;

void addNumber()
{  
    count++;
    printf("Func number: %d\n",count);    
}

int getNumber() {  
    return count;
}

foo.c

#include <stdio.h>
#include <stdlib.h>
#include "foo.h"

int count = 0;

void addCount()
{  
    count++;
    printf("Foo count: %d\n",count);    
}

int getCount() {  
    return count;
}

func.h

extern "C"
{
    void addNumber();
    int getNumber();
}

foo.h

extern "C"
{
    void addCount();
    int getCount();
}

Hi everyone, this is my first post here. I am using JNA in a GUI application to invoke methods in a dll. Though the code
is running fine in some machines, In some machines I am getting the error which I am going to post below. Please note that all the machines, I am running the program have similar platforms(Windows 7 64-bit, minimum 2GB RAM.

A fatal error has been detected by the Java Runtime Environment:

Internal Error (os_windows_x86.cpp:149), pid=2364, tid=3676

guarantee(result == EXCEPTION_CONTINUE_EXECUTION) failed: Unexpected result from topLevelExceptionFilter

JRE version: 7.0_04-b20

Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b21 mixed mode windows-amd64 compressed oops)

Failed to write core dump. Minidumps are not enabled by default on client versions of Windows

If you would like to submit a bug report, please visit:

http://bugreport.sun.com/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

--------------- T H R E A D ---------------

Current thread (0x000000000222c000): JavaThread "main" [_thread_in_native, id=3676, stack(0x0000000002230000,0x0000000002330000)]

Stack: [0x0000000002230000,0x0000000002330000]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.jna.Function.invokeInt(I[Ljava/lang/Object;)I+0
j com.sun.jna.Function.invoke([Ljava/lang/Object;Ljava/lang/Class;Z)Ljava/lang/Object;+315
j com.sun.jna.Function.invoke(Ljava/lang/Class;[Ljava/lang/Object;Ljava/util/Map;)Ljava/lang/Object;+214
j com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+341
j $Proxy0.USBStartup()I+9
j sportkat.SportKatMain.main([Ljava/lang/String;)V+15
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
0x0000000006934800 JavaThread "Image Fetcher 1" daemon [_thread_blocked, id=4028, stack(0x0000000022e00000,0x0000000022f00000)]
0x0000000009415000 JavaThread "Timer-3" [_thread_blocked, id=1212, stack(0x000000000a2b0000,0x000000000a3b0000)]
0x00000000094de000 JavaThread "Timer-2" [_thread_blocked, id=2204, stack(0x0000000009ee0000,0x0000000009fe0000)]
0x0000000006872800 JavaThread "Timer-1" [_thread_blocked, id=2068, stack(0x0000000009d30000,0x0000000009e30000)]
0x000000000687c000 JavaThread "Timer-0" [_thread_blocked, id=1552, stack(0x0000000009be0000,0x0000000009ce0000)]
0x0000000006838000 JavaThread "Image Fetcher 0" daemon [_thread_blocked, id=1844, stack(0x00000000092a0000,0x00000000093a0000)]
0x00000000065d6000 JavaThread "AWT-EventQueue-0" [_thread_in_Java, id=2948, stack(0x0000000007090000,0x0000000007190000)]
0x00000000065cd000 JavaThread "AWT-Windows" daemon [_thread_in_native, id=2104, stack(0x00000000069c0000,0x0000000006ac0000)]
0x00000000065cc000 JavaThread "AWT-Shutdown" [_thread_blocked, id=2072, stack(0x0000000006cd0000,0x0000000006dd0000)]
0x00000000057d2000 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=1580, stack(0x0000000006b60000,0x0000000006c60000)]
0x000000000571e800 JavaThread "Service Thread" daemon [_thread_blocked, id=3592, stack(0x0000000005b30000,0x0000000005c30000)]
0x0000000005718000 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=3900, stack(0x00000000062b0000,0x00000000063b0000)]
0x0000000005711000 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=496, stack(0x00000000060b0000,0x00000000061b0000)]
0x000000000570f800 JavaThread "Attach Listener" daemon [_thread_blocked, id=2784, stack(0x0000000005f00000,0x0000000006000000)]
0x000000000570c000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=1484, stack(0x0000000005db0000,0x0000000005eb0000)]
0x0000000005688000 JavaThread "Finalizer" daemon [_thread_blocked, id=3996, stack(0x0000000005c50000,0x0000000005d50000)]
0x0000000005680000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1816, stack(0x0000000005990000,0x0000000005a90000)]
=>0x000000000222c000 JavaThread "main" [_thread_in_native, id=3676, stack(0x0000000002230000,0x0000000002330000)]

Other Threads:
0x0000000005679000 VMThread [stack: 0x0000000005870000,0x0000000005970000] [id=2116]
0x0000000005734800 WatcherThread [stack: 0x0000000006470000,0x0000000006570000] [id=3968]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
def new generation total 8640K, used 3212K [0x00000000dee00000, 0x00000000df750000, 0x00000000e8350000)
eden space 7744K, 29% used [0x00000000dee00000, 0x00000000df043170, 0x00000000df590000)
from space 896K, 100% used [0x00000000df670000, 0x00000000df750000, 0x00000000df750000)
to space 896K, 0% used [0x00000000df590000, 0x00000000df590000, 0x00000000df670000)
tenured generation total 19136K, used 7407K [0x00000000e8350000, 0x00000000e9600000, 0x00000000fae00000)
the space 19136K, 38% used [0x00000000e8350000, 0x00000000e8a8bf98, 0x00000000e8a8c000, 0x00000000e9600000)
compacting perm gen total 21248K, used 15202K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000000000000)
the space 21248K, 71% used [0x00000000fae00000, 0x00000000fbcd8940, 0x00000000fbcd8a00, 0x00000000fc2c0000)
No shared spaces configured.

Code Cache [0x0000000002490000, 0x0000000002700000, 0x0000000005490000)
total_blobs=526 nmethods=35 adapters=443 free_code_cache=48500Kb largest_free_block=49632256

Compilation events (10 events):
Event: 3.362 Thread 0x0000000005718000 nmethod 28 0x0000000002528f50 code [0x0000000002529100, 0x0000000002529570]
Event: 3.362 Thread 0x0000000005718000 29 java.lang.CharacterDataLatin1::toLowerCase (39 bytes)
Event: 3.362 Thread 0x0000000005718000 nmethod 29 0x000000000252b490 code [0x000000000252b5c0, 0x000000000252b678]
Event: 3.362 Thread 0x0000000005718000 30 java.io.Win32FileSystem::isSlash (18 bytes)
Event: 3.362 Thread 0x0000000005718000 nmethod 30 0x0000000002528d50 code [0x0000000002528e80, 0x0000000002528ed8]
Event: 3.362 Thread 0x0000000005718000 31 java.io.BufferedInputStream::getBufIfOpen (21 bytes)
Event: 3.363 Thread 0x0000000005718000 nmethod 31 0x0000000002528b10 code [0x0000000002528c40, 0x0000000002528cb8]
Event: 3.363 Thread 0x0000000005718000 32 s java.io.BufferedInputStream::read (49 bytes)
Event: 3.364 Thread 0x0000000005718000 nmethod 32 0x00000000025281d0 code [0x0000000002528320, 0x0000000002528788]
Event: 3.429 Thread 0x0000000005711000 nmethod 26 0x0000000002533dd0 code [0x0000000002534140, 0x0000000002537cd0]

GC Heap History (6 events):
Event: 0.712 GC heap before
{Heap before GC invocations=0 (full 0):
def new generation total 8640K, used 5067K [0x00000000dee00000, 0x00000000df750000, 0x00000000e8350000)
eden space 7744K, 65% used [0x00000000dee00000, 0x00000000df2f2f10, 0x00000000df590000)
from space 896K, 0% used [0x00000000df590000, 0x00000000df590000, 0x00000000df670000)
to space 896K, 0% used [0x00000000df670000, 0x00000000df670000, 0x00000000df750000)
tenured generation total 19136K, used 0K [0x00000000e8350000, 0x00000000e9600000, 0x00000000fae00000)
the space 19136K, 0% used [0x00000000e8350000, 0x00000000e8350000, 0x00000000e8350200, 0x00000000e9600000)
compacting perm gen total 21248K, used 9920K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000000000000)
the space 21248K, 46% used [0x00000000fae00000, 0x00000000fb7b03b8, 0x00000000fb7b0400, 0x00000000fc2c0000)
No shared spaces configured.
Event: 0.722 GC heap after
Heap after GC invocations=1 (full 0):
def new generation total 8640K, used 895K [0x00000000dee00000, 0x00000000df750000, 0x00000000e8350000)
eden space 7744K, 0% used [0x00000000dee00000, 0x00000000dee00000, 0x00000000df590000)
from space 896K, 99% used [0x00000000df670000, 0x00000000df74fff8, 0x00000000df750000)
to space 896K, 0% used [0x00000000df590000, 0x00000000df590000, 0x00000000df670000)
tenured generation total 19136K, used 997K [0x00000000e8350000, 0x00000000e9600000, 0x00000000fae00000)
the space 19136K, 5% used [0x00000000e8350000, 0x00000000e84496a0, 0x00000000e8449800, 0x00000000e9600000)
compacting perm gen total 21248K, used 9920K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000000000000)
the space 21248K, 46% used [0x00000000fae00000, 0x00000000fb7b03b8, 0x00000000fb7b0400, 0x00000000fc2c0000)
No shared spaces configured.
}
Event: 0.787 GC heap before
{Heap before GC invocations=1 (full 0):
def new generation total 8640K, used 8637K [0x00000000dee00000, 0x00000000df750000, 0x00000000e8350000)
eden space 7744K, 99% used [0x00000000dee00000, 0x00000000df58f658, 0x00000000df590000)
from space 896K, 99% used [0x00000000df670000, 0x00000000df74fff8, 0x00000000df750000)
to space 896K, 0% used [0x00000000df590000, 0x00000000df590000, 0x00000000df670000)
tenured generation total 19136K, used 997K [0x00000000e8350000, 0x00000000e9600000, 0x00000000fae00000)
the space 19136K, 5% used [0x00000000e8350000, 0x00000000e84496a0, 0x00000000e8449800, 0x00000000e9600000)
compacting perm gen total 21248K, used 10111K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000000000000)
the space 21248K, 47% used [0x00000000fae00000, 0x00000000fb7dffd0, 0x00000000fb7e0000, 0x00000000fc2c0000)
No shared spaces configured.
Event: 0.797 GC heap after
Heap after GC invocations=2 (full 0):
def new generation total 8640K, used 77K [0x00000000dee00000, 0x00000000df750000, 0x00000000e8350000)
eden space 7744K, 0% used [0x00000000dee00000, 0x00000000dee00000, 0x00000000df590000)
from space 896K, 8% used [0x00000000df590000, 0x00000000df5a3778, 0x00000000df670000)
to space 896K, 0% used [0x00000000df670000, 0x00000000df670000, 0x00000000df750000)
tenured generation total 19136K, used 7013K [0x00000000e8350000, 0x00000000e9600000, 0x00000000fae00000)
the space 19136K, 36% used [0x00000000e8350000, 0x00000000e8a294d8, 0x00000000e8a29600, 0x00000000e9600000)
compacting perm gen total 21248K, used 10111K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000000000000)
the space 21248K, 47% used [0x00000000fae00000, 0x00000000fb7dffd0, 0x00000000fb7e0000, 0x00000000fc2c0000)
No shared spaces configured.
}
Event: 2.697 GC heap before
{Heap before GC invocations=2 (full 0):
def new generation total 8640K, used 7821K [0x00000000dee00000, 0x00000000df750000, 0x00000000e8350000)
eden space 7744K, 100% used [0x00000000dee00000, 0x00000000df590000, 0x00000000df590000)
from space 896K, 8% used [0x00000000df590000, 0x00000000df5a3778, 0x00000000df670000)
to space 896K, 0% used [0x00000000df670000, 0x00000000df670000, 0x00000000df750000)
tenured generation total 19136K, used 7013K [0x00000000e8350000, 0x00000000e9600000, 0x00000000fae00000)
the space 19136K, 36% used [0x00000000e8350000, 0x00000000e8a294d8, 0x00000000e8a29600, 0x00000000e9600000)
compacting perm gen total 21248K, used 12907K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000000000000)
the space 21248K, 60% used [0x00000000fae00000, 0x00000000fba9ad78, 0x00000000fba9ae00, 0x00000000fc2c0000)
No shared spaces configured.
Event: 2.708 GC heap after
Heap after GC invocations=3 (full 0):
def new generation total 8640K, used 896K [0x00000000dee00000, 0x00000000df750000, 0x00000000e8350000)
eden space 7744K, 0% used [0x00000000dee00000, 0x00000000dee00000, 0x00000000df590000)
from space 896K, 100% used [0x00000000df670000, 0x00000000df750000, 0x00000000df750000)
to space 896K, 0% used [0x00000000df590000, 0x00000000df590000, 0x00000000df670000)
tenured generation total 19136K, used 7407K [0x00000000e8350000, 0x00000000e9600000, 0x00000000fae00000)
the space 19136K, 38% used [0x00000000e8350000, 0x00000000e8a8bf98, 0x00000000e8a8c000, 0x00000000e9600000)
compacting perm gen total 21248K, used 12907K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000000000000)
the space 21248K, 60% used [0x00000000fae00000, 0x00000000fba9ad78, 0x00000000fba9ae00, 0x00000000fc2c0000)
No shared spaces configured.
}

Deoptimization events (8 events):
Event: 0.653 Thread 0x00000000065d6000 Uncommon trap -34 fr.pc 0x00000000025071e4
Event: 0.654 Thread 0x00000000065d6000 Uncommon trap -34 fr.pc 0x00000000025071e4
Event: 0.669 Thread 0x00000000065d6000 Uncommon trap -34 fr.pc 0x00000000025071e4
Event: 0.669 Thread 0x00000000065d6000 Uncommon trap -34 fr.pc 0x00000000025071e4
Event: 0.864 Thread 0x000000000222c000 Uncommon trap -34 fr.pc 0x0000000002508228
Event: 0.864 Thread 0x000000000222c000 Uncommon trap -34 fr.pc 0x0000000002508228
Event: 3.367 Thread 0x00000000065d6000 Uncommon trap -34 fr.pc 0x0000000002508228
Event: 3.367 Thread 0x00000000065d6000 Uncommon trap -34 fr.pc 0x0000000002508228

Internal exceptions (10 events):
Event: 2.878 Thread 0x00000000065d6000 Threw 0x00000000deed2348 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166
Event: 2.879 Thread 0x00000000065d6000 Threw 0x00000000deedaff0 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166
Event: 2.879 Thread 0x00000000065d6000 Threw 0x00000000deedc120 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166
Event: 2.879 Thread 0x00000000065d6000 Threw 0x00000000deedd9d0 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166
Event: 2.879 Thread 0x00000000065d6000 Threw 0x00000000deedebb8 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166
Event: 2.885 Thread 0x00000000065d6000 Threw 0x00000000deee2b20 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166
Event: 2.885 Thread 0x00000000065d6000 Threw 0x00000000deee8e10 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166
Event: 2.886 Thread 0x00000000065d6000 Threw 0x00000000deeed0f0 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166
Event: 2.887 Thread 0x00000000065d6000 Threw 0x00000000deef0918 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166
Event: 2.888 Thread 0x00000000065d6000 Threw 0x00000000deef4b38 at C:\jdk7u2_64p\jdk7u4\hotspot\src\share\vm\prims\jvm.cpp:1166

Events (10 events):
Event: 3.381 loading class 0x000000000675aac0 done
Event: 3.381 loading class 0x00000000093ddc60
Event: 3.381 loading class 0x00000000093ddc60 done
Event: 3.383 loading class 0x00000000095859a0
Event: 3.384 loading class 0x000000000962bfa0
Event: 3.384 loading class 0x000000000962bfa0 done
Event: 3.384 loading class 0x00000000095859a0 done
Event: 3.384 loading class 0x000000000951af40
Event: 3.384 loading class 0x000000000951af40 done
Event: 3.386 Thread 0x0000000006934800 Thread added: 0x0000000006934800

Dynamic libraries:
0x000000003f2c0000 - 0x000000003f2f3000 C:\Program Files\Java\jdk1.7.0_04\bin\java.exe
0x0000000076cb0000 - 0x0000000076e59000 C:\Windows\SYSTEM32\ntdll.dll
0x00000000766d0000 - 0x00000000767ef000 C:\Windows\system32\kernel32.dll
0x00000000fd1c0000 - 0x00000000fd22c000 C:\Windows\system32\KERNELBASE.dll
0x00000000feee0000 - 0x00000000fefbb000 C:\Windows\system32\ADVAPI32.dll
0x00000000fddc0000 - 0x00000000fde5f000 C:\Windows\system32\msvcrt.dll
0x00000000fed80000 - 0x00000000fed9f000 C:\Windows\SYSTEM32\sechost.dll
0x00000000fedb0000 - 0x00000000feedd000 C:\Windows\system32\RPCRT4.dll
0x00000000765d0000 - 0x00000000766ca000 C:\Windows\system32\USER32.dll
0x00000000fd750000 - 0x00000000fd7b7000 C:\Windows\system32\GDI32.dll
0x00000000fd8f0000 - 0x00000000fd8fe000 C:\Windows\system32\LPK.dll
0x00000000fdbf0000 - 0x00000000fdcb9000 C:\Windows\system32\USP10.dll
0x00000000fbb20000 - 0x00000000fbd14000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\COMCTL32.dll
0x00000000fdd40000 - 0x00000000fddb1000 C:\Windows\system32\SHLWAPI.dll
0x00000000fd720000 - 0x00000000fd74e000 C:\Windows\system32\IMM32.DLL
0x00000000fd7c0000 - 0x00000000fd8c9000 C:\Windows\system32\MSCTF.dll
0x000000006d040000 - 0x000000006d111000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\msvcr100.dll
0x000000006c920000 - 0x000000006d03a000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\server\jvm.dll
0x00000000f8d80000 - 0x00000000f8d89000 C:\Windows\system32\WSOCK32.dll
0x00000000fdfa0000 - 0x00000000fdfed000 C:\Windows\system32\WS2_32.dll
0x00000000feda0000 - 0x00000000feda8000 C:\Windows\system32\NSI.dll
0x00000000f8460000 - 0x00000000f849b000 C:\Windows\system32\WINMM.dll
0x0000000076e70000 - 0x0000000076e77000 C:\Windows\system32\PSAPI.DLL
0x000000006ef10000 - 0x000000006ef1f000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\verify.dll
0x000000006eee0000 - 0x000000006ef08000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\java.dll
0x000000006eec0000 - 0x000000006eed5000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\zip.dll
0x000000006c780000 - 0x000000006c914000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\awt.dll
0x00000000fdb10000 - 0x00000000fdbe7000 C:\Windows\system32\OLEAUT32.dll
0x00000000fd900000 - 0x00000000fdb03000 C:\Windows\system32\ole32.dll
0x00000000fb940000 - 0x00000000fb996000 C:\Windows\system32\uxtheme.dll
0x00000000f7ed0000 - 0x00000000f7ee7000 C:\Program Files (x86)\TeamViewer\Version7\tv_x64.dll
0x00000000fdff0000 - 0x00000000fed78000 C:\Windows\system32\SHELL32.dll
0x00000000fb2b0000 - 0x00000000fb2c8000 C:\Windows\system32\dwmapi.dll
0x00000000fd040000 - 0x00000000fd04f000 C:\Windows\system32\CRYPTBASE.dll
0x00000000f5ef0000 - 0x00000000f60ef000 C:\Windows\system32\d3d9.dll
0x00000000fc010000 - 0x00000000fc01c000 C:\Windows\system32\VERSION.dll
0x00000000fbaf0000 - 0x00000000fbaf7000 C:\Windows\system32\d3d8thk.dll
0x00000000eba80000 - 0x00000000ecb69000 C:\Windows\system32\nvd3dumx.dll
0x00000000fa720000 - 0x00000000fa74c000 C:\Windows\system32\powrprof.dll
0x00000000fd540000 - 0x00000000fd717000 C:\Windows\system32\SETUPAPI.dll
0x00000000fd2f0000 - 0x00000000fd326000 C:\Windows\system32\CFGMGR32.dll
0x00000000fd2d0000 - 0x00000000fd2ea000 C:\Windows\system32\DEVOBJ.dll
0x00000000fc9a0000 - 0x00000000fc9b7000 C:\Windows\system32\CRYPTSP.dll
0x00000000fc6a0000 - 0x00000000fc6e7000 C:\Windows\system32\rsaenh.dll
0x00000000fc460000 - 0x00000000fc47e000 C:\Windows\system32\USERENV.dll
0x00000000fd110000 - 0x00000000fd11f000 C:\Windows\system32\profapi.dll
0x000000006eea0000 - 0x000000006eeb9000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\net.dll
0x00000000fc940000 - 0x00000000fc995000 C:\Windows\system32\mswsock.dll
0x00000000fc930000 - 0x00000000fc937000 C:\Windows\System32\wship6.dll
0x00000000fa2a0000 - 0x00000000fa2b5000 C:\Windows\system32\NLAapi.dll
0x00000000f5210000 - 0x00000000f5225000 C:\Windows\system32\napinsp.dll
0x00000000f51f0000 - 0x00000000f5209000 C:\Windows\system32\pnrpnsp.dll
0x00000000fc7c0000 - 0x00000000fc81b000 C:\Windows\system32\DNSAPI.dll
0x00000000f8b90000 - 0x00000000f8b9b000 C:\Windows\System32\winrnr.dll
0x00000000fc340000 - 0x00000000fc347000 C:\Windows\System32\wshtcpip.dll
0x00000000f9fd0000 - 0x00000000f9ff7000 C:\Windows\system32\IPHLPAPI.DLL
0x00000000f9fc0000 - 0x00000000f9fcb000 C:\Windows\system32\WINNSI.DLL
0x00000000f8450000 - 0x00000000f8458000 C:\Windows\system32\rasadhlp.dll
0x00000000f9bc0000 - 0x00000000f9c13000 C:\Windows\System32\fwpuclnt.dll
0x000000006ee80000 - 0x000000006ee91000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\nio.dll
0x0000000080000000 - 0x0000000080037000 C:\Users\vojustest\AppData\Local\Temp\jna3107110738316524598.dll
0x00000000fb180000 - 0x00000000fb18f000 C:\Users\vojustest\Desktop\KoreBalance 1.0-2012-05-16\KoreBalance 1.0-2012-05-16\KoreBalance1.0\MaritzaDll.dll
0x00000000f2330000 - 0x00000000f239f000 C:\Windows\SYSTEM32\MSCOREE.DLL
0x000000006c740000 - 0x000000006c774000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\fontmanager.dll
0x00000000ecec0000 - 0x00000000ed85d000 C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll
0x0000000071570000 - 0x0000000071639000 C:\Windows\WinSxS\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4940_none_88df89932faf0bf6\MSVCR80.dll
0x00000000eaba0000 - 0x00000000eba7c000 C:\Windows\assembly\NativeImages_v2.0.50727_64\mscorlib\f73f0a9c9a83dcd3ff428be509a7992f\mscorlib.ni.dll
0x000000006c6f0000 - 0x000000006c731000 C:\Program Files\Java\jdk1.7.0_04\jre\bin\t2k.dll

VM Arguments:
java_command: KoreBalance1.0.jar
Launcher Type: SUN_STANDARD

Environment Variables:
CLASSPATH=C:\Program Files\Java\jdk1.7.0_04\lib
PATH=C:\Program Files\Java\jdk1.7.0_04\bin;C:\Program Files\Java\jdk1.7.0_04\bin
USERNAME=vojustest
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 23 Stepping 10, GenuineIntel

--------------- S Y S T E M ---------------

OS: Windows 7 , 64 bit Build 7601 Service Pack 1

CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 23 stepping 10, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, tsc

Memory: 4k page, physical 1833464k(603320k free), swap 3666928k(2044352k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (23.0-b21) for windows-amd64 JRE (1.7.0_04-b20), built on Apr 12 2012 02:28:20 by "java_re" with unknown MS VC++:1600

time: Thu May 17 03:21:09 2012
elapsed time: 3 seconds

3.3.0 is not getting pushed to maven central. Maybe consider pusing directly to central via https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide or similar ?

After downloading the jna.jar and examples.jar , having tried to view the classes by adding them to the building path using eclipse IDE , the following error occured "The jar file has no source attachment " , and offers me to attach the source file/folder .
are there any prerequisites to be done before trying to open the classes ?

Platform mappings should reflect the preferred usage of throwing LastErrorException over checking Native.getLastError() after a native call.

For win32 mappings, any change of signature should also ensure that any errors described in the MS docs are also defined in the JNA platform API.

Hey,

I think I ran into an issue in the toArray method in class Structure:

public Structure[] toArray(Structure[] array) {
    ensureAllocated();
    if (this.memory instanceof AutoAllocated) {
        // reallocate if necessary
        Memory m = (Memory)this.memory;
        int requiredSize = array.length * size();
        if (m.size() < requiredSize) {
            useMemory(autoAllocate(requiredSize));
        }
    }
    array[0] = this;
    int size = size();
    for (int i=1;i < array.length;i++) {
        array[i] = Structure.newInstance(getClass());
        array[i].useMemory(memory.share(i*size, size));
        array[i].read();
    }

    if (!(this instanceof ByValue)) {
        // keep track for later auto-read/writes
        this.array = array;
    }

    return array;
}

It looks like the first element in array is purposely skipped and set to the "this" instance. The problem is that read() is then never called for the first element and thus the fields aren't getting populated.

I have worked around this by doing:

...
// array[0] = this;
int size = size();
for (int i=0;i < array.length;i++) {
...

, but it seems like there was some thought to this, other than what I might recognize.

This is probably not the correct solution, but I believe that read() needs to get called for the "this" instance aswell. Maybe at construction.

The way Im reproducing this issue is by running WinspoolUtil.getPrinterInfo1() and test returned Structure's fields. With the repository code as it is, no fields are populated in the first element. The remaining elements are properly populated as the nature of the code suggests.

I have an app that uses JNA to call a couple native libraries on Win32 and Linux 32 platforms. However, I am having trouble running the same code on Win7 64 and Linux 64.

The C++ libraries have been compiled on the 64 bit platforms.

Are there any other tricks needed or pitfalls to be aware of to get running on 64 bit platforms?

Are there any known issues with the garbage collection on the 64 bit platforms? Is there a way to make sure the objects I am sending down to the native code do not get garbage collected until after I leave a particular code block? The reason I ask this is on Linux I can step through via the debugger and everything works properly, but if I just run it crashes. I still need to confirm this is the case in Win7 64.

Also, I'm leaning more to the garbage collection because I do not have any long data types any where either.

Any ideas are welcome.

Thanks!

Following self contained example demonstrates the issue:

Instead of the expected result:

11

*_Hello World_

we get

11

Hello World*********

the code:

import java.nio.ByteBuffer;

import com.sun.jna.*;

public class Test {
static Win32APILibrary lib = (Win32APILibrary) Native.loadLibrary("kernel32", Win32APILibrary.class);

public interface Win32APILibrary extends Library { Pointer CreateFileA(String fn, int access, int mode, Pointer sec, int create, int atts, Pointer tmplt); boolean WriteFile(Pointer h, ByteBuffer buf, int nw, int[] nwn, Pointer olp); boolean ReadFile(Pointer h, ByteBuffer bud, int nr, int[] nrn, Pointer olp); boolean CloseHandle(Pointer hFile); }

final static int GENERIC_READ = 0x80000000;

final static int GENERIC_WRITE = 0x40000000;

final static int GENERIC_EXECUTE = 0x20000000;

final static int GENERIC_ALL = 0x10000000;

final static int CREATE_NEW = 1;

final static int CREATE_ALWAYS = 2;

final static int OPEN_EXISTING = 3;

public static void main(String[] args) {
{
boolean ok;
Pointer h = lib.CreateFileA("test.txt", GENERIC_WRITE, 0, null, CREATE_NEW, 0, null);
ByteBuffer out = ByteBuffer.wrap("Hello World".getBytes());
int[] outn = { 0 };
ok = lib.WriteFile(h, out, out.capacity(), outn, null);
ok = lib.CloseHandle(h);
}

{
boolean ok;
Pointer h = lib.CreateFileA("test.txt", GENERIC_READ, 0, null, OPEN_EXISTING, 0, null);
byte [] bts="********************".getBytes();
ByteBuffer in = ByteBuffer.wrap(bts,5,11);
int[] inn = { 0 };
ok = lib.ReadFile(h, in, in.capacity(), inn, null);
ok = lib.CloseHandle(h);
System.out.println(inn[0]);
System.out.println(new String(in.array()));
}

}
}

It seems to me like jna requires cygwin and a c-compiler (?) to build. A few words about what is needed would be nice in the .md file.

W32FileMonitorTest reproduces the problem

Hi,

After updating from 3.3.0 (b1) (according to jna.jar's manifest file) to 3.4.0 FileListener.fileChanged() no longer gets called.
Below is a simplified piece of code that I used for testing this issue. I'm using Windows7 64bit and jdk1.6.0_27 32bit.

public static void main(String[] args) throws Exception {
    FileMonitor fm = FileMonitor.getInstance();
    FileListener fl = new FileListener() {

        @Override
        public void fileChanged(FileEvent fe) {
            System.out.println(fe.getFile().getAbsolutePath() + ", " + fe.getType());
        }
    };
    fm.addFileListener(fl);

    File m = new File("C:/temp/");
    fm.addWatch(m);

    Thread.sleep(30000);
    System.out.println("woke up");

    fm.removeWatch(m);
    fm.removeFileListener(fl);
}

We're lacking constants for COINIT_MULTITHREADED and COINIT_APARTMENTTHREADED, and why you would choose each one.

I've done some changes locally, and while it's stupid (at least it seems that way to me) to paste a patch, it's stupider not to do it at all. In reality it'll take me a month to get around to some more free time to figure out how to set up github on windows with my other commitments.

So here it is, apply or wait for me to do a proper pull request:

edit: sorry about the formatting mess, but without an RTE button to "make code block" I dare not play with it manually... Grab the patch by editing.

HG changeset patch

User skestle

Date 1334665884 -43200

Node ID 2149a00f2c82c2ebb377dd062c1473de4cc35b79

Parent c37fe59dddcd9b373150dc6ca3c7a184247a5857

Added COINIT_MULTITHREADED and COINIT_APARTMENTTHREADED to Ole32 and updated the tests to reference the constants.

diff -r c37fe59dddcd -r 2149a00f2c82 contrib/platform/src/com/sun/jna/platform/win32/Ole32.java
--- a/contrib/platform/src/com/sun/jna/platform/win32/Ole32.java Thu Apr 12 13:19:40 2012 -0300
+++ b/contrib/platform/src/com/sun/jna/platform/win32/Ole32.java Wed Apr 18 00:31:24 2012 +1200
@@ -25,6 +25,8 @@

• @author dblock[at]dblock.org
  */
  public interface Ole32 extends StdCallLibrary {

  • public static final int COINIT_APARTMENTTHREADED = 0x2;
  • public static final int COINIT_MULTITHREADED = 0x0;

  Ole32 INSTANCE = (Ole32) Native.loadLibrary(
  "Ole32", Ole32.class, W32APIOptions.UNICODE_OPTIONS);
  @@ -74,8 +76,14 @@

  • thread. Values for this parameter are taken from the COINIT enumeration.
  • Any combination of values from COINIT can be used, except that the
  • COINIT_APARTMENTTHREADED and COINIT_MULTITHREADED flags cannot both be

    • \* set. The default (and only sane choice) is COINIT_MULTITHREADED.
      

    • \* set. The default is COINIT_MULTITHREADED.
      

    • \* <ul><li>COINIT_MULTITHREADED allows object methods to be called from any thread, 
      

    • \* but requires the COM objects to be thread-safe</li>
      

    • \* <li>COINIT_APARTMENTTHREADED allows the COM objects to not be thread-safe, but 
      

    • \* requires method calls to be serialized through the message boundaries (in {@link User32})
      

    • \* </li></ul>  
      

  • @return This function can return the standard return values E_INVALIDARG, E_OUTOFMEMORY, and E_UNEXPECTED, as well as the following values. S_OK, S_FALSE, RPC_E_CHANGED_MODE

    • \* @see http://msdn.microsoft.com/en-us/library/windows/desktop/ms678505(v=vs.85).aspx
      

      */
      HRESULT CoInitializeEx(Pointer reserved, int dwCoInit);

diff -r c37fe59dddcd -r 2149a00f2c82 contrib/platform/test/com/sun/jna/platform/win32/Ole32Test.java
--- a/contrib/platform/test/com/sun/jna/platform/win32/Ole32Test.java Thu Apr 12 13:19:40 2012 -0300
+++ b/contrib/platform/test/com/sun/jna/platform/win32/Ole32Test.java Wed Apr 18 00:31:24 2012 +1200
@@ -17,6 +17,7 @@
import com.sun.jna.Native;
import com.sun.jna.Pointer;
import com.sun.jna.platform.win32.Guid.GUID;
+import com.sun.jna.platform.win32.Ole32;
import com.sun.jna.platform.win32.WinNT.HRESULT;
import com.sun.jna.ptr.PointerByReference;

@@ -69,14 +70,14 @@
}

 public void testCoInitializeEx() {

•    HRESULT hr = Ole32.INSTANCE.CoInitializeEx(null, 0);
  

•    HRESULT hr = Ole32.INSTANCE.CoInitializeEx(null, Ole32.COINIT_MULTITHREADED);
   assertTrue(W32Errors.SUCCEEDED(hr.intValue()) || hr.intValue() == W32Errors.RPC_E_CHANGED_MODE);
   if (W32Errors.SUCCEEDED(hr.intValue()))
       Ole32.INSTANCE.CoUninitialize();
  

  }

  public void testCoCreateInstance() {

•    HRESULT hrCI = Ole32.INSTANCE.CoInitializeEx(null, 0);
  

•    HRESULT hrCI = Ole32.INSTANCE.CoInitializeEx(null, Ole32.COINIT_MULTITHREADED);
  
   GUID guid = Ole32Util.getGUIDFromString("{13709620-C279-11CE-A49E-444553540000}"); //Shell object
   GUID riid = Ole32Util.getGUIDFromString("{D8F015C0-C278-11CE-A49E-444553540000}"); //IShellDispatch
  

Here is a simple class that loads an X11 library and maps some function:

public class Test {
    static {
        Native.register("X11");
    }

    public static native Pointer XOpenDisplay(String name);


    public static void main(String[] args) {
        XOpenDisplay(null);
    }
}

it all works fine with jna 3.2.7, but with 3.3.0, I get the following exception:

Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'X11': com.sun.jna.Native.open(Ljava/lang/String;)J
    at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:166)
    at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:239)
    at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:202)
    at com.sun.jna.Native.register(Native.java:1032)
    at com.tulskiy.keymaster.Test.<clinit>(Test.java:12)

it seems to be finding the library fine, but always fails in Native.open(). Interface mapping fail as well. I'm running Ubuntu 10.10 32-bit.

On russian Windows I obtain this (maybe it's a cp1251):

Caused by: java.lang.UnsatisfiedLinkError: Unable to load library 'C:\WINDOWS\system32\SignHost.dll': ?? ?????? ????????? ??????.
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:164)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:237)
at com.sun.jna.Library$Handler.(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:375)
at com.sun.jna.Native.loadLibrary(Native.java:360)
at com.pb.finmonitor.server.nbu.SignHostImpl.(SignHostImpl.java:24)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:126)
... 59 more

What are those question marks?
I already found what that means but maybe those question marks will be more helpful if they will be as text :)
On english Windows:

Caused by: java.lang.UnsatisfiedLinkError: Unable to load library 'C:\WINDOWS\system32\SignHost.dll': The specified module could not be found.
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:164)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:237)
at com.sun.jna.Library$Handler.(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:375)
at com.sun.jna.Native.loadLibrary(Native.java:360)
at com.pb.finmonitor.server.nbu.SignHostImpl.(SignHostImpl.java:24)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:126)
... 59 more

And it will be more helpful if JNA will check which architecture JVM is and check maybe dll is with other architecture.
Make it in catch block.

Hi,

I want to acess a function like the following one:

include "stdafx.h"

include <stdio.h>

extern "C" __declspec(dllexport) int test(char *data, long flag, char *buffer, long *bufferlength) {

long f = flag;
long bl = *bufferlength;
printf("buffer: %s\n", buffer);
printf("data: %s\n", data);
printf("flag: %i\n", f);

printf("bufferlength: %li\n", bl);

return 0;

}

When I access this function via JNA witch this method test( byte[] data, long flag, byte[] buffer, NativeLongByReference bufferlength ) buffer in C is (null).
When leaving long flag buffer is filled with correct data.

Greetz
Hildegunst

I extended StdCallLibrary but the instantiation cannot find my dll stdcall functions. The only way that I have been able to get a working StdCallLibrary is to provide the function mapper on instantiating the Library with Native.loadLibrary(lib, class, option).

The following DOESN'T WORK:
public interface Test3Lib extends StdCallLibrary {
Test3Lib INSTANCE = (Test3Lib)Native.loadLibrary("Test3",Test3Lib.class);
public String func(String s1, String s2);
}

The following WORKS:
public interface Test3Lib extends Library {
Test3Lib INSTANCE = (Test3Lib )Native.loadLibrary("Test3",Test3Lib .class,
new HashMap<String, FunctionMapper>() {{
put(Library.OPTION_FUNCTION_MAPPER, new StdCallFunctionMapper());
}});
public String func1(String s1, String s2);
}

Just for clarity, I also did this the long way:
Map options = new HashMap();
options.put(Library.OPTION_FUNCTION_MAPPER, new StdCallFunctionMapper());
Test3Lib t3 = (Test3Lib) Native.loadLibrary("Test3", Test3Lib.class, options);
And it works.

I checked my dll and func1 is exported as _func1@8 which I expected.

I have tried this with jna.jar 3.4.0 and 3.3.0.

New to JNA. Any advice appreciated.

Thanks,
Ralph

Due to a simple blank line in the MANIFEST.MF file, Eclipse treats the jna.jar file as an invalid OSGi bundle.

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: 1.6.0_29-b11-402-10M3527 (Apple Inc.)
Main-Class: com.sun.jna.Native

Name: com/sun/jna/
Implementation-Title: com.sun.jna
Implementation-Vendor: JNA Development Team
Implementation-Version: 3.4.0 (b541)
Specification-Title: Java Native Access (JNA)
Specification-Vendor: JNA Development Team
Specification-Version: 3
Bundle-ManifestVersion: 2
Bundle-Name: jna
Bundle-Description: JNA Library
Bundle-SymbolicName: com.sun.jna
Bundle-Version: 3
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Bundle-Vendor: JNA Development Team
Bundle-ActivationPolicy: lazy
Export-Package: com.sun.jna,com.sun.jna.ptr,com.sun.jna.win32
Bundle-NativeCode: com/sun/jna/win32-x86/jnidispatch.dll; processor=x8
6;osname=win32, com/sun/jna/win32-amd64/jnidispatch.dll; processor=x8
6-64;osname=win32, com/sun/jna/w32ce-arm/jnidispatch.dll; processor=a
rm;osname=wince, com/sun/jna/sunos-x86/libjnidispatch.so; processor=
x86;osname=sunos, com/sun/jna/sunos-amd64/libjnidispatch.so; processo
r=x86-64;osname=sunos, com/sun/jna/sunos-sparc/libjnidispatch.so; pro
cessor=sparc;osname=sunos, com/sun/jna/sunos-sparcv9/libjnidispatch.s
o; processor=sparcv9;osname=sunos, com/sun/jna/linux-ppc/libjnidispa
tch.so; processor=ppc;osname=linux, com/sun/jna/linux-ppc64/libjnidis
patch.so; processor=ppc64;osname=linux, com/sun/jna/linux-i386/libjni
dispatch.so; processor=x86;osname=linux, com/sun/jna/linux-amd64/libj
nidispatch.so; processor=x86-64;osname=linux, com/sun/jna/linux-arm/l
ibjnidispatch.so; processor=arm;osname=linux, com/sun/jna/linux-ia64/
libjnidispatch.so; processor=ia64;osname=linux, com/sun/jna/openbsd-
i386/libjnidispatch.so; processor=x86;osname=openbsd, com/sun/jna/fre
ebsd-i386/libjnidispatch.so; processor=x86;osname=freebsd, com/sun/jn
a/freebsd-amd64/libjnidispatch.so; processor=x86-64;osname=freebsd,
com/sun/jna/darwin/libjnidispatch.jnilib; osname=macos,

The blank line between the Main-Class: header and the Name: header needs to be removed.

I am using Windows 7SP1 64bit (but 32-bit JVM). I was trying to use ntservice from the contrib directory, but couldn't get it to work. So I modified it slightly - added "throw LastErrorException" to all the API calls, and added some code to open a logfile and redirect stderr/stdout to it (since otherwise you can't get the output of the service). And I discovered that RegisterServiceCtrlHandlerEx fails with error 126 (The specified module could not be found). Investigating further, I believe what is happening is as follows:

1. RegisterServiceCtrlHandlerExW calls GetModuleHandleExW on the function pointer passed in
   -- I guess, for some unknown reason, it wants to know what DLL/EXE the pointer belongs to
2. With a normal service, this will return the module handle for some DLL or EXE
3. But with a JNA callback, this points to a memory buffer VirtualAlloc-allocated by FFI
4. So GetModuleHandleExW fails with 126 and RegisterServiceCtrlHandlerExW as a whole fails

Solution: It is a hard one. I guess the only way forward would be to modify FFI to write out the trampoline code to a DLL in a temporary directory, and then load that into memory. From reading the FFI code, it looks like it actually does this on some other platforms, but not windows. Obviously you would not want it to do this for every callback, but only for ones like this where the VirtualAlloc issue is a problem. But making modifications to the FFI code like this is a bit beyond me - maybe someone else will feel sufficiently inclined?

Since it looks like others have got this working before, maybe RegisterServiceCtrlHandlerExW calling GetModuleHandleExW is new code in some new versions of Windows.

Seems that I am working with some Domain Trusts that do not DNS entries and this is causing some issues because the code assumes that a String will always be returned.
Looking at the lines 609 and 610
@ https://github.com/twall/jna/blob/master/contrib/platform/src/com/sun/jna/platform/win32/Netapi32Util.java
a NPE could be thrown.

For a day or so I have been investigating a strange issue in Win32Service where onStart() gets called, we attempt to start our service but calls to ServiceLoader fail with mysterious "not found" errors which don't happen if you run the same executable directly.

private static class ServerService extends Win32Service {
    @Override
    public void onStart() {
        System.out.println("Starting...");
        System.out.println("Providers:");
        for (Bootstrap bootstrap : ServiceLoader.load(Bootstrap.class)) {
            System.out.println(bootstrap.getClass());
        }
    }

    @Override
    public void onStop() { 
        //...
    }
}

This will fail with:

java.util.ServiceConfigurationError: com.acme.bootstrap.Bootstrap: Provider com.acme.stuff.MonitoringBootstrap not found
    at java.util.ServiceLoader.fail(ServiceLoader.java:231)
    ...

The bizarre thing here is that Java is somehow finding the META-INF/services file indicating which class to use but then failing to find the class itself.

I notice that other projects like YAJSW appear to have avoided the issue by not actually starting the service from the onStart() callback, which feels like a dodge to me (why have a start service callback if you can't use it to start the service?)

I had a theory that perhaps the thread was ruined somehow by Windows when it called it back and tried spawning a new thread instead of doing the startup on the same thread, but this doesn't appear to help either. I'm guessing I will probably resort to the same workaround others used, where I do the startup outside the callback.

Copy of JNA-138:

Would you please be so kind to update the MANIFEST.MF file with OSGi bundle
headers so we could use it in an OSGi environment without repacking the lib?

Something like this (comming from the SVNKit):

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.4.2_17-b06 (Sun Microsystems Inc.)
Bundle-ManifestVersion: 2
Bundle-Name: JNA Library Plug-in
Bundle-SymbolicName: com.sun.jna
Bundle-Version: 3.1.0
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Bundle-ClassPath: jna.jar
Export-Package: com.sun.jna,com.sun.jna.win32,com.sun.jna.ptr
Bundle-Vendor: Timothy Wall
Bundle-ActivationPolicy: lazy

This can be done easily using the existing build system and the bnd plugin in Maven or Ant at the jar/package stage.
http://www.aqute.biz/Bnd/Ant

I try to read the number logical processors of the system on a windows platform with the following code:

    SYSTEM_INFO lpSystemInfo = new SYSTEM_INFO();      
    Kernel32.INSTANCE.GetNativeSystemInfo(lpSystemInfo);        
    return lpSystemInfo.dwNumberOfProcessors.longValue();

On a 64-bit-system (Windows 7) this code always returns 65536. But nevertheless the same code works fine on 32-bit-Windows7-System. What am i doing wrong? I´m using version 3.3.0 of the platform.jar and jna.jar.

The FAQ states:
"
How do I map a native long type?
Actually, no one ever asks this question, but they really need the answer. Do not use Java long!

On Windows, you can use a Java int, since the native long type is always 32 bits. On any other platform, the type may be 32 or 64 bits, so you should use the NativeLong type to ensure the proper size is used.
"

This is incorrect. I am not aware if this was the case on previous windows version but it certainly isn't the case on my windows 7 machine (a standard i7 on windows 7 64bit).

ALSO MORE WORRYING

The JNA source assumes DWORD and NativeLong are always 4 byte sized on windows, also wrong, and this leads to big errors.

Example: I cannot use mappings like

public static class MEMORY_BASIC_INFORMATION extends Structure {
    public Pointer BaseAddress;
    public Pointer AllocationBase;
    public NativeLong AllocationProtect;
    public NativeLong RegionSize;
    public NativeLong State;
    public NativeLong Protect;
    public NativeLong Type;
}

but must resort to ugly solutions

public static class MEMORY_BASIC_INFORMATION extends Structure {
    public Pointer BaseAddress;
    public Pointer AllocationBase;
    public Pointer AllocationProtect;
    public Pointer RegionSize;
    public Pointer State;
    public Pointer Protect;
    public Pointer Type;
}

which works fine.

I don't understand how this has not been caught ......

Try with

static {
    Native.register("Kernel32");
}
public static native long VirtualQuery(Pointer p, MEMORY_BASIC_INFORMATION infoOut, NativeLong sz);

void foo() {
MEMORY_BASIC_INFORMATION memBasicInfo = new MEMORY_BASIC_INFORMATION();
VirtualQuery(anyPointer, memBasicInfo, new NativeLong(memBasicInfo.size()));
}

EDIT:
And before you go asking, of course my (only) jre is also 64bit :).

JNA 3.40 seems to use a symbol from libc version 2.11, it would be great if it could be made to work also with older versions.

Running a program using JNA 3.4.0 results in the following stacktrace, downgrading to JNA 3.2.7 solved the problem.

java.lang.UnsatisfiedLinkError: /tmp/jna/jna6331993596205149685.tmp: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by /tmp/jna/jna6331993596205149685.tmp)
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1699)
        at java.lang.Runtime.load0(Runtime.java:770)
        at java.lang.System.load(System.java:1003)
        at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:771)
        at com.sun.jna.Native.loadNativeLibrary(Native.java:697)
        at com.sun.jna.Native.<clinit>(Native.java:127)
        at de.beit.adpPortal.geraetepark.FreischaltcodeJNA.<clinit>(FreischaltcodeJNA.java:15)
        at de.beit.adpPortal.geraetepark.FreischaltcodeTest.testAlt(FreischaltcodeTest.java:7)

Inspecting the dynamic library reveals the following details:

$ objdump -p com/sun/jna/linux-amd64/libjnidispatch.so 
com/sun/jna/linux-amd64/libjnidispatch.so:     file format elf64-x86-64
...
Version References:
  required from libc.so.6:
    0x06969191 0x00 05 GLIBC_2.11
    0x0d696914 0x00 04 GLIBC_2.4
    0x09691974 0x00 03 GLIBC_2.3.4
    0x09691a75 0x00 02 GLIBC_2.2.5

$ objdump -t com/sun/jna/linux-amd64/libjnidispatch.so  | grep 2.11
0000000000000000       F *UND*  0000000000000000              __longjmp_chk@@GLIBC_2.11

I'm getting the following c exception (presumably in the jna dll?? I've been developing with Canon's EDSDK and am returning from a dispatched event.

The last java line executed is CallbackReference callback(Object[]), and it's returning an Integer of 0.

Am I doing something wrong, is there a bug in JNA, or is this a JVM bug?

I've replicated in JNA 3.3.0 and 3.4.0, as well as jdk 6.0_17 and jre 6.0_30

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x18667504, pid=11744, tid=12368
#
# JRE version: 6.0_30-b12
# Java VM: Java HotSpot(TM) Client VM (20.5-b03 mixed mode windows-x86 )
# Problematic frame:
# C  0x18667504
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x017d9800):  JavaThread "main" [_thread_in_native, id=12368, stack(0x00370000,0x003c0000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x00000000

Registers:
EAX=0x00000000, EBX=0x00000000, ECX=0x003bf0dc, EDX=0x18241b6c
ESP=0x003bf110, EBP=0x003bf150, ESI=0x18666f78, EDI=0x00000201
EIP=0x18667504, EFLAGS=0x00010246

Top of Stack: (sp=0x003bf110)
0x003bf110:   00000001 183fb61c 18962ab8 9df3eaed
0x003bf120:   18662f40 18660c68 1895caf0 18951870
0x003bf130:   00000001 00000000 18667500 00000000
0x003bf140:   003bf11c 003bf234 1842f1eb ffffffff
0x003bf150:   18662f08 1840d114 00000000 18662f40
0x003bf160:   183f047d 18660c68 000c1272 00000000
0x003bf170:   003bf1c8 00000000 773941d4 1895cac0
0x003bf180:   0000c092 18662f58 18662f40 1895cac0 

Instructions: (pc=0x18667504)
0x186674e4:   03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x186674f4:   00 00 00 00 a5 97 d6 18 00 00 00 8c 1c 5f 43 18
0x18667504:   02 30 00 00 70 2a 96 18 7c 2a 96 18 7c 2a 96 18
0x18667514:   01 38 00 00 99 97 d6 18 00 00 00 88 00 00 00 00 


Register to memory mapping:

EAX=0x00000000 is an unknown value
EBX=0x00000000 is an unknown value
ECX=0x003bf0dc is pointing into the stack for thread: 0x017d9800
EDX=0x18241b6c is an unknown value
ESP=0x003bf110 is pointing into the stack for thread: 0x017d9800
EBP=0x003bf150 is pointing into the stack for thread: 0x017d9800
ESI=0x18666f78 is an unknown value
EDI=0x00000201 is an unknown value


Stack: [0x00370000,0x003c0000],  sp=0x003bf110,  free space=316k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x18667504

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.sun.jna.Native.invokeInt(JI[Ljava/lang/Object;)I+0
j  com.sun.jna.Function.invoke([Ljava/lang/Object;Ljava/lang/Class;Z)Ljava/lang/Object;+333
j  com.sun.jna.Function.invoke(Ljava/lang/Class;[Ljava/lang/Object;Ljava/util/Map;)Ljava/lang/Object;+214
j  com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+341
j  $Proxy2.DispatchMessage(Lcom/sun/jna/platform/win32/WinUser$MSG;)Lcom/sun/jna/platform/win32/WinDef$LRESULT;+16
j  net.kestle.platform.windows.User32$.dispatchMessage(Lcom/sun/jna/platform/win32/WinUser$MSG;)Lcom/sun/jna/platform/win32/WinDef$LRESULT;+5
j  EosTest$.consumeAndDispachMessage()V+27
j  EosTest$.main([Ljava/lang/String;)V+110
j  EosTest.main([Ljava/lang/String;)V+4
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x019bfc00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=11988, stack(0x17cd0000,0x17d20000)]
  0x019b2800 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=12548, stack(0x17c80000,0x17cd0000)]
  0x019b1800 JavaThread "Attach Listener" daemon [_thread_blocked, id=13580, stack(0x17c30000,0x17c80000)]
  0x019ae800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11152, stack(0x17be0000,0x17c30000)]
  0x01974c00 JavaThread "Finalizer" daemon [_thread_blocked, id=13724, stack(0x17b90000,0x17be0000)]
  0x01970000 JavaThread "Reference Handler" daemon [_thread_blocked, id=12296, stack(0x17b40000,0x17b90000)]
=>0x017d9800 JavaThread "main" [_thread_in_native, id=12368, stack(0x00370000,0x003c0000)]

Other Threads:
  0x0196cc00 VMThread [stack: 0x17af0000,0x17b40000] [id=13500]
  0x019da800 WatcherThread [stack: 0x17d20000,0x17d70000] [id=7384]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 def new generation   total 4928K, used 2377K [0x039e0000, 0x03f30000, 0x08f30000)
  eden space 4416K,  44% used [0x039e0000, 0x03bcd5a0, 0x03e30000)
  from space 512K,  78% used [0x03eb0000, 0x03f14e98, 0x03f30000)
  to   space 512K,   0% used [0x03e30000, 0x03e30000, 0x03eb0000)
 tenured generation   total 10944K, used 0K [0x08f30000, 0x099e0000, 0x139e0000)
   the space 10944K,   0% used [0x08f30000, 0x08f30000, 0x08f30200, 0x099e0000)
 compacting perm gen  total 12288K, used 5795K [0x139e0000, 0x145e0000, 0x179e0000)
   the space 12288K,  47% used [0x139e0000, 0x13f88ec0, 0x13f89000, 0x145e0000)
No shared spaces configured.

Code Cache  [0x019e0000, 0x01a88000, 0x039e0000)
 total_blobs=266 nmethods=107 adapters=95 free_code_cache=32888704 largest_free_block=0

Dynamic libraries:
0x00400000 - 0x00425000     C:\Program Files\Java\jre6\bin\javaw.exe
0x77940000 - 0x77a7c000     C:\Windows\SYSTEM32\ntdll.dll
0x76b90000 - 0x76c64000     C:\Windows\system32\kernel32.dll
0x75cc0000 - 0x75d0a000     C:\Windows\system32\KERNELBASE.dll
0x77500000 - 0x775a0000     C:\Windows\system32\ADVAPI32.dll
0x76de0000 - 0x76e8c000     C:\Windows\system32\msvcrt.dll
0x76b70000 - 0x76b89000     C:\Windows\SYSTEM32\sechost.dll
0x772b0000 - 0x77351000     C:\Windows\system32\RPCRT4.dll
0x77360000 - 0x77429000     C:\Windows\system32\USER32.dll
0x76d90000 - 0x76dde000     C:\Windows\system32\GDI32.dll
0x77b60000 - 0x77b6a000     C:\Windows\system32\LPK.dll
0x77aa0000 - 0x77b3d000     C:\Windows\system32\USP10.dll
0x77b40000 - 0x77b5f000     C:\Windows\system32\IMM32.DLL
0x77430000 - 0x774fc000     C:\Windows\system32\MSCTF.dll
0x7c340000 - 0x7c396000     C:\Program Files\Java\jre6\bin\msvcr71.dll
0x6d7f0000 - 0x6da9f000     C:\Program Files\Java\jre6\bin\client\jvm.dll
0x73900000 - 0x73932000     C:\Windows\system32\WINMM.dll
0x75a00000 - 0x75a4b000     C:\Windows\system32\apphelp.dll
0x6d7a0000 - 0x6d7ac000     C:\Program Files\Java\jre6\bin\verify.dll
0x6d320000 - 0x6d33f000     C:\Program Files\Java\jre6\bin\java.dll
0x6d7e0000 - 0x6d7ef000     C:\Program Files\Java\jre6\bin\zip.dll
0x6d000000 - 0x6d14c000     C:\Program Files\Java\jre6\bin\awt.dll
0x718d0000 - 0x71921000     C:\Windows\system32\WINSPOOL.DRV
0x77680000 - 0x777dc000     C:\Windows\system32\ole32.dll
0x748a0000 - 0x74a3e000     C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16661_none_420fe3fa2b8113bd\COMCTL32.dll
0x77250000 - 0x772a7000     C:\Windows\system32\SHLWAPI.dll
0x75650000 - 0x75666000     C:\Windows\system32\CRYPTSP.dll
0x73d70000 - 0x73dab000     C:\Windows\system32\rsaenh.dll
0x75150000 - 0x75167000     C:\Windows\system32\USERENV.dll
0x75ad0000 - 0x75adb000     C:\Windows\system32\profapi.dll
0x75a50000 - 0x75a5c000     C:\Windows\system32\CRYPTBASE.dll
0x6d600000 - 0x6d613000     C:\Program Files\Java\jre6\bin\net.dll
0x777e0000 - 0x77815000     C:\Windows\system32\WS2_32.dll
0x76c70000 - 0x76c76000     C:\Windows\system32\NSI.dll
0x75550000 - 0x7558c000     C:\Windows\system32\mswsock.dll
0x75670000 - 0x75676000     C:\Windows\System32\wship6.dll
0x739a0000 - 0x739b0000     C:\Windows\system32\NLAapi.dll
0x753a0000 - 0x753e4000     C:\Windows\system32\DNSAPI.dll
0x6f900000 - 0x6f908000     C:\Windows\System32\winrnr.dll
0x6f8f0000 - 0x6f900000     C:\Windows\system32\napinsp.dll
0x6f8d0000 - 0x6f8e2000     C:\Windows\system32\pnrpnsp.dll
0x6f8c0000 - 0x6f8cd000     C:\Windows\system32\wshbth.dll
0x6f890000 - 0x6f8b7000     C:\Program Files\Common Files\Microsoft Shared\Windows Live\WLIDNSP.DLL
0x77a80000 - 0x77a85000     C:\Windows\system32\PSAPI.DLL
0x6f7d0000 - 0x6f7f1000     C:\Program Files\Bonjour\mdnsNSP.dll
0x73740000 - 0x7375c000     C:\Windows\system32\Iphlpapi.DLL
0x73730000 - 0x73737000     C:\Windows\system32\WINNSI.DLL
0x75060000 - 0x75065000     C:\Windows\System32\wshtcpip.dll
0x6f720000 - 0x6f726000     C:\Windows\system32\rasadhlp.dll
0x71fb0000 - 0x71fe8000     C:\Windows\System32\fwpuclnt.dll
0x18160000 - 0x181d2000     C:\Users\Stephen\AppData\Local\Temp\jna\jna4222644062414367285.dll
0x183e0000 - 0x18454000     C:\development\Projects\TechShred\CanonEos\src\main\native\EDSDK.dll
0x76e90000 - 0x7702d000     C:\Windows\system32\SETUPAPI.dll
0x75d10000 - 0x75d37000     C:\Windows\system32\CFGMGR32.dll
0x76c80000 - 0x76d0f000     C:\Windows\system32\OLEAUT32.dll
0x75b50000 - 0x75b62000     C:\Windows\system32\DEVOBJ.dll
0x74580000 - 0x745c0000     C:\Windows\system32\uxtheme.dll
0x745e0000 - 0x745f3000     C:\Windows\system32\dwmapi.dll
0x68720000 - 0x68753000     C:\Windows\system32\STI.DLL
0x18a40000 - 0x18b44000     C:\development\Projects\TechShred\CanonEos\src\main\native\EdsImage.dll
0x75b70000 - 0x75b9d000     C:\Windows\system32\WINTRUST.dll
0x75ba0000 - 0x75cbc000     C:\Windows\system32\CRYPT32.dll
0x75b40000 - 0x75b4c000     C:\Windows\system32\MSASN1.dll
0x775f0000 - 0x77673000     C:\Windows\system32\CLBCatQ.DLL
0x18b50000 - 0x18bd9000     C:\Windows\system32\PortableDeviceApi.dll
0x6e590000 - 0x6e5bb000     C:\Windows\system32\PortableDeviceTypes.dll
0x746b0000 - 0x747a5000     C:\Windows\system32\PROPSYS.dll
0x75ac0000 - 0x75ace000     C:\Windows\system32\RpcRtRemote.dll
0x75ef0000 - 0x76b39000     C:\Windows\system32\SHELL32.dll
0x6f730000 - 0x6f763000     C:\Program Files\Windows Portable Devices\SqmApi.dll

VM Arguments:
jvm_args: -Djna.library.path=src\main\native -Dfile.encoding=Cp1252 -Xbootclasspath/p:C:\development\Tools\eclipse-indigo\configuration\org.eclipse.osgi\bundles\1061\1\.cp\lib\scala-library.jar;C:\development\Tools\eclipse-indigo\configuration\org.eclipse.osgi\bundles\1061\1\.cp\lib\scala-dbc.jar;C:\development\Tools\eclipse-indigo\configuration\org.eclipse.osgi\bundles\1061\1\.cp\lib\scala-swing.jar 
java_command: EosTest
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_17
CLASSPATH=.;C:\Program Files\Java\jdk1.6.0_17\lib\ext\QTJava.zip;C:\Program Files\Java\jre6\lib\ext\QTJava.zip
PATH=C:/Program Files/Java/jre6/bin/client;C:/Program Files/Java/jre6/bin;C:/Program Files/Java/jre6/lib/i386;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files\PC Connectivity Solution\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Common Files\Adobe\AGL;C:\Program Files\TortoiseSVN\bin;O:\CommonPlatform\build\ant\bin;C:\Program Files\Java\jdk1.6.0_17\bin;C:\development\Tools\Maven\bin;C:\Program Files\Windows Live\Shared;C:\development\Tools\pax-runner-1.5.0\bin;C:\Program Files\Git\cmd;C:\development\Tools\sbt;C:\Program Files\TortoiseHg\;C:\Program Files\QuickTime\QTSystem\;C:\development\Tools\eclipse-indigo;
USERNAME=Stephen
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 10, GenuineIntel



---------------  S Y S T E M  ---------------

OS: Windows 7 Build 7600 

CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 15 stepping 10, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3

Memory: 4k page, physical 3145016k(222444k free), swap 7503996k(2463040k free)

vm_info: Java HotSpot(TM) Client VM (20.5-b03) for windows-x86 JRE (1.6.0_30-b12), built on Nov 10 2011 01:51:00 by "java_re" with MS VC++ 7.1 (VS2003)

time: Fri Mar 02 00:51:33 2012
elapsed time: 9 seconds

hello,

here the declaration:

    MyKernel32  INSTANCE    = (MyKernel32) Native.loadLibrary("kernel32", MyKernel32.class);

    /*
     * typedef struct _MEMORYSTATUSEX { DWORD dwLength; DWORD dwMemoryLoad;
     * DWORDLONG ullTotalPhys; DWORDLONG ullAvailPhys; DWORDLONG
     * ullTotalPageFile; DWORDLONG ullAvailPageFile; DWORDLONG
     * ullTotalVirtual; DWORDLONG ullAvailVirtual; DWORDLONG
     * ullAvailExtendedVirtual; } MEMORYSTATUSEX,LPMEMORYSTATUSEX;
     */
    static class MEMORYSTATUSEX extends Structure
    {
        public int          dwLength;
        public int          dwMemoryLoad;
        public NativeLong   ullTotalPhys;
        public NativeLong   ullAvailPhys;
        public NativeLong   ullTotalPageFile;
        public NativeLong   ullAvailPageFile;
        public NativeLong   ullTotalVirtual;
        public NativeLong   ullAvailVirtual;
        public NativeLong   ullAvailExtendedVirtual;
    }

    /*
     * BOOL WINAPI GlobalMemoryStatusEx( __inout LPMEMORYSTATUSEX lpBuffer
     * );
     */
    boolean GlobalMemoryStatusEx(MEMORYSTATUSEX lpBuffer);

}

There seem to be cases when a call to

new MyKernel32.MEMORYSTATUSEX()

hangs.
see

https://sourceforge.net/projects/yajsw/forums/forum/810311/topic/4685606

is this a windows issue or jna ?

-- Ron

Found where its supposed to go....

Latest version of JNA is not available in the maven repo http://repo1.maven.org/maven2/net/java/dev/jna/jna/ ,

Thanks,
Ajay K

According to Microsoft documentation DWORD is a 32-bit unsigned integer:
http://msdn.microsoft.com/en-us/library/cc230318%28PROT.10%29.aspx

In com/sun/jna/platform/win32/WinDef.java#54 DWORD is defined as a 4 byte IntegerType

The problem is that com/sun/jna/IntegerType.java.setValue#55 casts the value as a Java Integer, thus making the value a 32-bit signed integer

Here is a simple example:

    System.out.println(new DWORD(4294967295L).longValue());

This prints out "-1" where "4294967295" is expected

This bugs makes RecordNumber for event logs to be false in some cases as com.sun.jna.platform.win32.WinNT.EVENTLOGRECORD.RecordNumber is defined as a DWORD

jna-3.4.0.jar's manifest contains various OSGi-related attributes such as Bundle-SymbolicName. However these are all within the section named com/sun/jna/, whereas OSGi only interprets attributes in the main section of the manifest. (*) So as far as I know none of these do anything at all. Intentional or mistake?

(*) As opposed to Specification-Version and the like which are defined by the JAR specification and are supposed to be in a named section. Hardly anything pays attention to these attributes, though java.lang.Package can be used to introspect them.

[platform.win32.User32.SetWindowPos](http://twall.github.com/jna/3.4.0/javadoc/com/sun/jna/platform/win32/User32.html#SetWindowPos(com.sun.jna.platform.win32.WinDef.HWND, com.sun.jna.platform.win32.WinDef.HWND, int, int, int, int, int)) from [WinAPI](http://msdn.microsoft.com/en-us/library/windows/desktop/ms633545(v=vs.85\).aspx) accepts a number of constant arguments.

• HWND_BOTTOM
• HWND_NOTOPMOST
• HWND_NOTOPMOST
• HWND_TOPMOST

can't be found in platform.win32. They are supposed to be typed as platform.win32.WinDef.HWND and creation of this class instances in user code smells bad. Can they be a part of platform.win32.WinUser?

https://github.com/basilevs/jna/commit/09c0d30e11044414ff2e0c47d2516ab89629aec6

Hi,

JNA 3.4.0.0 (and 3.3.0.0) are not compatible with JRE 1.4.2. I checked out the sources many files are incompatible. We still need JRE 1.4.2 compatibility (don't ask :-)) - if you plan to move to >= 1.5 (understandable to me) please note this in the homepage (as there is still mentioned the component works with JRE >= 1.4).

What is the latest version (jna.jar + platform.jar) with 1.4.2 compliancy and where can I get it? I'll try to build my own version but I would like to use the "official" release.

Thanks & warm regards,

Martin

MEMORYSTATUSEX lpBuffer = new MEMORYSTATUSEX();
Kernel32.INSTANCE.GlobalMemoryStatusEx(lpBuffer);
lpBuffer.ullTotalVirtual.longValue() // incorrect

What we really want here is an unsigned __int64. This value should be about 2GB (C++ code gives 2147352576), while it's garbage on my 64-bit windows 7 (8796092891136).

Note that other values, such as ulTotalPhys look right.