-
J/Invoke released - an easy JNI replacement (18 messages)
- Posted by: Tim Barry
- Posted on: September 04 2007 08:01 EDT
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.htmlThreaded Messages (18)
- Re: J/Invoke released - an easy JNI replacement by Iman Rahmatizadeh on September 04 2007 08:41 EDT
- Re: J/Invoke released - an easy JNI replacement by Joseph Ottinger on September 04 2007 08:54 EDT
- Re: J/Invoke released - an easy JNI replacement by jelmer kuperus on September 04 2007 10:29 EDT
- Re: J/Invoke released - an easy JNI replacement by Bradley Smith on September 04 2007 11:20 EDT
- Re: J/Invoke released - an easy JNI replacement by David Orriss Jr on September 04 2007 12:54 EDT
- Re: J/Invoke released - an easy JNI replacement by Bradley Smith on September 04 2007 11:20 EDT
- Open source alternative by ronald miura on September 04 2007 11:49 EDT
- Re: Open source alternative by Bradley Smith on September 04 2007 12:34 EDT
- Re: J/Invoke released - an easy JNI replacement by Jose Maria Arranz on September 04 2007 13:44 EDT
- Full Disclosure? by Omer Demir on September 05 2007 22:31 EDT
- Re: Full Disclosure? by Jose Maria Arranz on September 06 2007 02:48 EDT
- Full Disclosure? by Omer Demir on September 05 2007 22:31 EDT
- Use SWIG by Bruce Fancher on September 04 2007 14:32 EDT
- Re: J/Invoke released - an easy JNI replacement by Vincent van Beveren on September 04 2007 17:47 EDT
- Re: J/Invoke released - an easy JNI replacement by Richard Burton on September 05 2007 12:01 EDT
- Re: J/Invoke released - an easy JNI replacement by Richard Burton on September 05 2007 12:03 EDT
- Too close to the metal by Inf ernoz on September 08 2007 12:08 EDT
- Too close to the metal by Inf ernoz on September 08 2007 12:12 EDT
- Re: Too close to the metal by Inf ernoz on September 08 2007 12:16 EDT
- Clarification by Tim Barry on September 09 2007 05:44 EDT
- Too close to the metal by Inf ernoz on September 08 2007 12:12 EDT
-
Re: J/Invoke released - an easy JNI replacement[ Go to top ]
- Posted by: Iman Rahmatizadeh
- Posted on: September 04 2007 08:41 EDT
- in response to Tim Barry
Any link to homepage ? -
Re: J/Invoke released - an easy JNI replacement[ Go to top ]
- Posted by: Joseph Ottinger
- Posted on: September 04 2007 08:54 EDT
- in response to Iman Rahmatizadeh
Any link to homepage ?
Ermmm.... yeah, hold on. :) (By the time you read this, it should be in the news post.) -
Re: J/Invoke released - an easy JNI replacement[ Go to top ]
- Posted by: jelmer kuperus
- Posted on: September 04 2007 10:29 EDT
- in response to Tim Barry
and only $1995 USD for a server license ... -
Re: J/Invoke released - an easy JNI replacement[ Go to top ]
- Posted by: Bradley Smith
- Posted on: September 04 2007 11:20 EDT
- in response to jelmer kuperus
and only $1995 USD for a server license ...
Yikes! -
Re: J/Invoke released - an easy JNI replacement[ Go to top ]
- Posted by: David Orriss Jr
- Posted on: September 04 2007 12:54 EDT
- in response to Bradley Smith
Yea but only 300 dollars for the dev license...! Such a deal! I'll pass. :|and only $1995 USD for a server license ...
Yikes! -
Open source alternative[ Go to top ]
- Posted by: ronald miura
- Posted on: September 04 2007 11:49 EDT
- in response to Tim Barry
-
Re: Open source alternative[ Go to top ]
- Posted by: Bradley Smith
- Posted on: September 04 2007 12:34 EDT
- in response to ronald miura
https://jna.dev.java.net/
Very nice - thanks! -
Re: J/Invoke released - an easy JNI replacement[ Go to top ]
- Posted by: Jose Maria Arranz
- Posted on: September 04 2007 13:44 EDT
- in response to Tim Barry
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. -
Full Disclosure?[ Go to top ]
- Posted by: Omer Demir
- Posted on: September 05 2007 22:31 EDT
- in response to Jose Maria Arranz
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. -
Re: Full Disclosure?[ Go to top ]
- Posted by: Jose Maria Arranz
- Posted on: September 06 2007 02:48 EDT
- in response to Omer Demir
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. -
Use SWIG[ Go to top ]
- Posted by: Bruce Fancher
- Posted on: September 04 2007 14:32 EDT
- in response to Tim Barry
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. -
Re: J/Invoke released - an easy JNI replacement[ Go to top ]
- Posted by: Vincent van Beveren
- Posted on: September 04 2007 17:47 EDT
- in response to Tim Barry
I think JNative (http://jnative.free.fr) is also a pretty good library. Its free ;). -
Re: J/Invoke released - an easy JNI replacement[ Go to top ]
- Posted by: Richard Burton
- Posted on: September 05 2007 12:01 EDT
- in response to Tim Barry
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 -
Re: J/Invoke released - an easy JNI replacement[ Go to top ]
- Posted by: Richard Burton
- Posted on: September 05 2007 12:03 EDT
- in response to Richard Burton
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 -
Too close to the metal[ Go to top ]
- Posted by: Inf ernoz
- Posted on: September 08 2007 12:08 EDT
- in response to Tim Barry
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). -
Too close to the metal[ Go to top ]
- Posted by: Inf ernoz
- Posted on: September 08 2007 12:12 EDT
- in response to Inf ernoz
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. -
Re: Too close to the metal[ Go to top ]
- Posted by: Inf ernoz
- Posted on: September 08 2007 12:16 EDT
- in response to Inf ernoz
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. -
Clarification[ Go to top ]
- Posted by: Tim Barry
- Posted on: September 09 2007 05:44 EDT
- in response to Inf ernoz
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.