J/Invoke is a JNI alternative for Java that makes calling functions from a native DLL as easy as P/Invoke does for .NET. Java developers can simply annotate a native method with the DLL and function name and J/Invoke manages the task of loading the specified DLL, automatically converting Java arguments to C arguments and invoking the target function in the DLL. A beta has just been released. It is cross-platform, modern solution(using JDK 5 annotations) that 'brings JNI to the present'. It is our response to this post at JavaLobby - http://www.javalobby.org/java/forums/t83696.html

Any link to homepage ?

Any link to homepage ?

Ermmm.... yeah, hold on. :) (By the time you read this, it should be in the news post.)

and only $1995 USD for a server license ...

and only $1995 USD for a server license ...

Yikes!

and only $1995 USD for a server license ...

Yikes!

Yea but only 300 dollars for the dev license...! Such a deal! I'll pass. :|

https://jna.dev.java.net/

https://jna.dev.java.net/

Very nice - thanks!

Things missing or not very beautiful: * Structures: public fields mandatory. No per-field memory alignment (only global packing). No native memory impact (I suppose) when a field is modified in Java. Can user defined structures be nested? can a user defined structure field be embedded? Java (native) instances are reused? * Callbacks: no way to call from Java, can a Callback represent a C method? * Speed: Java reflection is used I suppose, reflection is slow and slow far far away the speed of a custom JNI solution (or other alternatives). * Threads: no word, I suppose one thread, do methods support multithread? do callbacks support multithread? do structures support multithread? * Arrays: no way to read/write single elements (full read and full write I suppose. * No C++ support An alternative: JNIEasy with some interesting features: * Is free for non-profit projects: anyone can download a 5 days license and when this license ends can download again a new one, with no registry. * 390.00 EUR / 530.704 USD, *royalty free* unlimited time license. * C++ support: including inheritance. A legacy C++ class can export its methods declaring them as "exported" or using C wrapper methods exported (first param must be the class pointer). * Bytecode enhancement: no reflection, max speed, fully "native transparency". Very similar approach as JDO or JPA as in JPOX. * Fully multithread support, any element. * A user defined Java object (native C++ object/C structure/method) is almost indistinct of the C/C++ one including fields (may be private) and methods. Any Java field access (read/write) is a C/C++ native field access, any method call is a C/C++ method call, and inverse, a C++ field modification modifies the Java field (with no user written method call), a C++ method call can call a normal (non-native but "exported") Java method... * Two levels: high level: transparent, fully based on Java types, low level: using framework based types to fully control the native memory layout.

It would have helped if Jose Maria Arranz's quick judgement on J/Invoke and suggestion for another product also mentioned that Jose Maria is the author of the alternative suggested http://64.233.167.104/search?q=cache:TvvWgIDyy7kJ:www.innowhere.com:8080/webapp/jsp/support/jnieasy/doc/html_multiple/index.html+%22jose+maria+arranz%22+jnieasy&hl=en&ct=clnk&cd=3&gl=us&client=firefox-a Bte, most of the problems noticed are in the "I suppose" category... a little better research wouldn't have hurt.

If you see my TheServerSide.com posts (click my name on this post) most of the time I sign with a JNIEasy referral, in fact, JNIEasy is the subject of several threads. In my post I've supposed everybody knew I'm involved in some way in JNIEasy because I promote it. Anyway I'm sorry I *should* have made some kind of referral, and yes I confess *I'm the author of JNIEasy* :) But I think the facts, the technical features, the message, are more important than the messenger. Bte, most of the problems noticed are in the "I suppose" category... a little better research wouldn't have hurt. I say "I suppose" because I can be wrong, the documentation is extremely short. Anyway I know the existing approaches to deal with the Java-native impedance "transparently" and I know the shortcomings of the Java reflection approach. Why hurt? Why does a technical, *polite*, *fair play* discussion hurt?. Competition is the base of the software industry, any software author must be open to receive *polite* criticism. Anyway J/Invoke is the first (I suppose mature) product introducing annotations, it is ok. JNIEasy doesn't use annotations (use XML) because it wants to be JDK 1.4 capable.

JNI is truly a monster. I'd hate to have to use it by hand. However, in a recent project I looked at all of the free and commercial alternatives before settling on using SWIG, and I found it to be pretty easy. I'm usually not a fan of code generation, but it works well in this case, and takes almost all of the pain out of using JNI directly. It also has a powerful macro language that let's you extend the wrappings fairly easily.

I think JNative (http://jnative.free.fr) is also a pretty good library. Its free ;).

Nice, now I can write my famous "I changed your wallpaper!" in Java. 1. Spending 20 minutes writing Java code - $25 2. Spending time debugging the code - $5 3. Seeing your co-workers facial expressions after he noticed your Java program changed his wall paper to an old man in speedo's - Unemployed! Best Regards, Richard L. Burton III

J/Invoke is still easier to use than the other suggested frameworks. I do agree the price is very high. Best Regards, Richard L. Burton III

I note that J/Invoke allows direct access to functions with 'int' pointers, this is not safe and could cause system crashes which may crash the JVM or the OS! Other JNI wrapper APIs provide wrappers which prevent provide stronger type safety so minimize this kind of issue. I also note that the callbacks are tied to static methods in a class, this seems stupid, because it prevents use multi-threading use unless you synchronize the class object. I hope you are aware that _all_ GUI specific operations (excepting native GUI callback code) must be run from the AWT/Swing event queue thread, to avoid nasty AWT/Swing side effects and deadlocks, this is compulsory for _all_ versions of Java (Sun only recently understood and specified this restriction).

Other JNI wrapper APIs provide wrappers which prevent provide stronger type safety so minimize this kind of issue.

should read: Other JNI wrapper APIs provide wrappers often provide access to pointers via type-safe Java wrapper objects, to minimize this kind of issue.

Hmm, this forum really needs an Edit option for posts!

Other JNI wrapper APIs provide wrappers which prevent provide stronger type safety so minimize this kind of issue.

should read: Other JNI wrapper APIs often provide support pointers via type-safe Java wrapper objects, to minimize this kind of issue.

Callbacks are not tied to static methods in a class - they can also be used with instance methods of objects. This was not mentioned in the developer guide earlier, but part of the Callback class's javadoc. This information has now been updated in the dev-guide - thanks for pointing it out! The JVM runs in user space - 'system crashes that can crash the OS' is just not possible. That said, J/Invoke does steer away from use of int pointers in the samples and documentation, while it is possible. With some native APIs, access to raw pointers, doing pointer arithmetic, and interpreting pointers as Structs, Strings, etc is required, and for these extreme cases, J/Invoke provides utility methods in the com.jinvoke.Util class.