Discussions

News: JNIEasy 1.0 final, Java Native Objects

Bookmark and Share Get thread feed

  1. JNIEasy 1.0 final, Java Native Objects (15 messages)

    Sometimes the Java standard is not enough and your application needs to deal with mature and legacy libraries (usually developed with C/C++) or use a specific feature of the underlying operating system or to access to the hardware. JNI, the Java Native Interface, is the standard tool to bridge native code and Java. JNIEasy is a tool to integrate legacy DLLs and C/C++ libraries from Java. JNIEasy avoids the tedious task of bridging Java and C/C++ code with the complex and error-prone JNI with no C/C++ programming and using a Java-friendly syntax. JNO (Java native objects, the name used for the technology in JNIEasy) is like the transparent persistence paradigm into the integration world: Transparent Native Programming with Java. With JNIEasy a normal Java class, with fields and methods, is reflected as a normal C++ class or C structure or union and vice versa. A Java integer, String, array, etc., is seen as a native integer, string, and array. No more strange Java artifacts, no more strange and unfriendly Java-to-C++ programming. Using Java only code helps you to achieve your own WORA (Write Once Run Anywhere), your application can easily decide what platform specific Java code to use. Currently JNIEasy works in Windows (Win32) only, but more platforms upcoming. JNIEasy is FREE to personal and non-profit use, using an temporal evaluation key that can be renewed in the web, no registry and user data is required. (Commercial licenses start at 499EU, roughly $530 USD at the time of writing.) JNIEasy is the first product of Innowhere Software Services S.L. Message was edited by: joeo@enigmastation.com
    Reply to this

    Threaded Messages (15)

  2. Re: JNIEasy 1.0 final, Java Native Objects[ Go to top ]

    Do you have any benchmarks for how this compares with using CORBA or SOAP to integrate Java and C++ applications? Note that I don't think benchmarks against 'pure' JNI are appropriate because nobody want's to have to write and maintain JNI code. PJ Murray, CodeFutures Software Data Access Objects and Service Data Objects
    Reply to this Reply to original

  3. Benchmarks[ Go to top ]

    Do you have any benchmarks for how this compares with using CORBA or SOAP to integrate Java and C++ applications?

    Note that I don't think benchmarks against 'pure' JNI are appropriate because nobody want's to have to write and maintain JNI code.


    PJ Murray, CodeFutures Software
    Data Access Objects and Service Data Objects
    I don't have any "net based integration" vs JNIEasy benchmark but I think any net approach falls behind any same memory/in-process solution, and JNIEasy is a same memory/in-process solution: it reads/writes the C/C++ memory from Java directly (of course using JNI behind the scenes, JNIEasy is a sophisticated layer on top of JNI). Perhaps an ORB tuned to in-process calls like ORBit ... but it only works in the same language. JNIEasy is oriented to create applications mixing both worlds (Java and C/C++) using Java only with tight integration with the C/C++ world (in fact there is an option to map a "semi" plain old C++ object to a Java class without JNI linking C++ to Java methods using a similar approach to the Win32's GetProcAddress). JNIEasy is not oriented to communicate a C/C++ and Java running applications (of course JNIEasy can help to do this because the C++ code can use the Java ORB, RMI etc without JNI and vice versa Java can use operating system techniques to communicate processes like Windows messages). I have a rough real world benchmark: the LAMEOnJ project (based on JNIEasy and using the LAME DLL) encodes a big MP3 with no significative time difference than the LAME command line (a C based program). SOAP benchmarks? no comments, it is another world, time is not so important in the SOAP camp (CORBA will be quicker ever).
    Reply to this Reply to original

  4. Re: Benchmarks[ Go to top ]

    Explanation: the LAME DLL (lame_enc.dll) has no method like "encode to MP3 this file at once", it encodes to MP3 chunks of audio data (aprox. 2k of WAV data per call).
    Reply to this Reply to original

  5. Re: Benchmarks[ Go to top ]

    Do you have any benchmarks for how this compares with using CORBA or SOAP to integrate Java and C++ applications?

    Note that I don't think benchmarks against 'pure' JNI are appropriate because nobody want's to have to write and maintain JNI code.


    PJ Murray, CodeFutures Software
    Data Access Objects and Service Data Objects


    I don't have any "net based integration" vs JNIEasy benchmark but I think any net approach falls behind any same memory/in-process solution, and JNIEasy is a same memory/in-process solution: it reads/writes the C/C++ memory from Java directly (of course using JNI behind the scenes, JNIEasy is a sophisticated layer on top of JNI). Perhaps an ORB tuned to in-process calls like ORBit ... but it only works in the same language.

    JNIEasy is oriented to create applications mixing both worlds (Java and C/C++) using Java only with tight integration with the C/C++ world (in fact there is an option to map a "semi" plain old C++ object to a Java class without JNI linking C++ to Java methods using a similar approach to the Win32's GetProcAddress). JNIEasy is not oriented to communicate a C/C++ and Java running applications (of course JNIEasy can help to do this because the C++ code can use the Java ORB, RMI etc without JNI and vice versa Java can use operating system techniques to communicate processes like Windows messages).

    I have a rough real world benchmark: the LAMEOnJ project (based on JNIEasy and using the LAME DLL) encodes a big MP3 with no significative time difference than the LAME command line (a C based program).

    SOAP benchmarks? no comments, it is another world, time is not so important in the SOAP camp (CORBA will be quicker ever).
    Sure, I understand your claim that your performance is better. It should be much better. But you still need to prove it with benchmarks against the two most common alternatives - CORBA and SOAP.
    Reply to this Reply to original

  6. Jace[ Go to top ]

    JACE is still available for free (even for commercial use) at http://sourceforge.net/projects/jace/ It is also open-sourced.
    Reply to this Reply to original

  7. Re: Jace[ Go to top ]

    Yes, Jace is good and is free, but it is a C++ centric solution, basically is coding Java in C++. JNIEasy is a Java centric solution, Java programs are enriched with already compiled DLLs, no C/C++ code, the future is in Java (ok in .Net too) not in C++. The C++ class proxy (to a Java class) option is ... an option, to enrich with Java your C++ program, in this case the JNIEasy approach is more C++ friendly than Jace because the C++ proxy attributes and methods use normal C/C++ data types: int, char*, int[], MyClass* etc not String, Object etc as seen in Jace’s C++ code, these data types are reflected in Java as normal Java data types int, String, int[], MyClass reference. And JNIEasy is supported ... ok is paid support but there is someone in the other side ... open source is good, but not supported open source is not so good (to commercial uses). Anyway Tony Rebelts (Jace author) is a C++ top programmer.
    Reply to this Reply to original

  8. Jace[ Go to top ]

    Yes, Jace is good and is free, but it is a C++ centric solution, basically is coding Java in C++.
    Jace is designed around making the easy problems easy and the difficult problems possible. Between the rich data types available in C++, and the arbitrary user-defined ownership semantics, it makes more sense to me to implement the adapters in C++ than vice-versa.
    The C++ class proxy (to a Java class) option is ... an option, to enrich with Java your C++ program
    It doesn't make any difference whether you have a "C++ program" or a "Java program". If you're primarily interested in implementing a few native methods, that's what Jace peers are designed for.
    And JNIEasy is supported.
    Jace is supported in the same manner as most open-source projects. While that does mean that no one is banking their living on supporting it, there are discussion forums, all of the source is freely available, and I do personally answer questions.
    Anyway Tony Rebelts (Jace author) is a C++ top programmer.
    Thanks for the compliment (I think), but I wouldn't categorize myself as a C++ programmer. (My day job is "platform architect"). I use whatever fits the bill. Most of the time that has been Java, some times it's been C++, and other times it's some thing else.
    Reply to this Reply to original

  9. Can use SWIG.ORG[ Go to top ]

    To inteface java to C++ code, can use http://www.swig.org more details here http://www.swig.org/Doc1.3/Java.html
    Reply to this Reply to original

  10. Re: Can use SWIG.ORG[ Go to top ]

    To inteface java to C++ code, can use http://www.swig.org
    more details here http://www.swig.org/Doc1.3/Java.html
    That's the wrong way. Calling Java _from_ C++ is the problem. JNI isn't the only solution and, IMO, not the best. I would start the Java program as separate process and communicate with it e.g. via Sockets.
    Reply to this Reply to original

  11. Re: Can use SWIG.ORG[ Go to top ]

    To inteface java to C++ code, can use http://www.swig.org
    more details here http://www.swig.org/Doc1.3/Java.html


    That's the wrong way. Calling Java _from_ C++ is the problem.
    JNI isn't the only solution and, IMO, not the best. I would start the Java program as separate process and communicate with it e.g. via Sockets.
    SWIG is good stuff and can solve unidirectional Java to C++ communication, but I think JNIEasy has many advantages over SWIG (of course I'm biased): * No C/C++ code, no C/C++ IDE, compiler, project setup (SWIG generates C/C++ code). A JNIEasy based application is more portable, only the JNIEasy library is platform dependent (JNIEasy supports Windows only today but it will be ported to other platforms, in fact the API is platform agnostic, and is prepared to 64 bits processors with no code changes). The cited LAMEOnJ is 100% Java. * Callbacks: C/C++ native code can call Java methods. How can you implement the Win32's EnumWindows callback with SWIG?. With the JNIEasy approach the Java callback method is a straightforward copy of the EnumWindows required callback. A Java method (C or C++) is seen from C/C++ like a pointer to method (and can be called using this pointer). * No Java source code generated: your user defined native Java class is a POJO with normal attributes, constructors, methods etc, can be extended, modified, mixing normal methods (optionally callable from C++) and empty methods declared as proxies of C/C++ methods. * Native Java objects can be attached/detached/cloned from native. A detached object can be serialized and saved in a file or sent "by value" using RMI, moreover the other side can receive the object and use it with no native dependency (no JNIEasy instalation), or reattach it again to the native world. * JNIEasy has advanced features as native transactions, native methods callable using reflection (optional, JNIEasy does not use reflection to call/access Java methods/fields)
    That's the wrong way. Calling Java _from_ C++ is the problem.
    JNI isn't the only solution and, IMO, not the best. I would start the Java program as separate process and communicate with it e.g. via Sockets.
    Why use sockets? the Java/C++ impedance has been reduced to the minimum !!
    Reply to this Reply to original

  12. Price error[ Go to top ]


    Price error: JNIEasy royalty free development license starts at 420 euros (not 499), aprox. 528,35 dollars.
    Reply to this Reply to original

  13. JACE[ Go to top ]

    does anyone of you have a good JACE example? thanks
    Reply to this Reply to original

  14. Jace examples[ Go to top ]

    does anyone of you have a good JACE example?

    thanks
    There are examples in the download bundle which the documentation walks through, step by step.
    Reply to this Reply to original

  15. Re: JNIEasy 1.0 final, Java Native Objects[ Go to top ]

    I'm apalled by the hostility of most of the replies. In any case, you might re-think your company name ... it sounds like you might be going nowhere with it :-)
    Reply to this Reply to original

  16. Re: JNIEasy 1.0 final, Java Native Objects[ Go to top ]

    I'm apalled by the hostility of most of the replies.
    In any case, you might re-think your company name ... it sounds like you might be going nowhere with it :-)
    Innowhere means many things: innovation, now, here, where ... and of course in-no-where :)
    Reply to this Reply to original