Is there any changes to JNI going in that will make it possible to call native functions without having to write and compile wrapper code in C?
The problem with wrapping native libraries isn't so much about parsing header files. This would be a problem, but I don't think it's required for the solution. There should be enough information exposed by the libraries themselves to figure out function prototypes, and entry points.
The problem with wrapping native libraries is that most native libraries aren't designed to be auto-wrapped. They are designed to be coded to, and compiled against. Because of this you get one of two choices:
1) Create a fairly simple wrapper, that blindly maps Java objects to native types and structures.
2) Create a sophisticated wrapper that is able to safely map Java objects to native types and structures.
The first choice has some big problems. It lacks good type checking, and doesn't provide a reliable mechanism for error/exception handling. The second is very difficult, to impossible to create. For anyone that could create, it would be a full blown product in its own right. (Probably a product that somebody would charge lots of money to use.)
There are native interfaces that are designed to be wrapped, such as CORBA and COM. These provide specific API that allows a foreign client to query the service, and discover how to use them safely. If you are working with native libraries that implement these interfaces, there are already tools to make access them from Java easier.
> The problem with wrapping native libraries is that
> most native libraries aren't designed to be
See Tool at
It creates in C++ auto-wrapped java classes.
The example at
shows how java interfaces can be auto-wrapped in C++ without writing code in java.
Im a tyro for JNI.
is there any good material for learning JNI?
most sample code on the internet are too simple.
> And what language do you purpose? Do you think it
> should be Sun's job to make it do able in every
> language out there? Or just a select few? And if just
> a few, then when language_x isn't usable, we will be
> right back to where we started, people complaining
> because they either are to lazy to learn how to use
> another language, or people just refuse to learn how
> to do it because its outside of there comfort zone.
Take a look at
The same could be done for any IDE C++,PASCAL,FORTARAN,C#,BASIC,etc.
In the next ver. this tool be able to generate JNI class implementing any java interface without writing java code. Now this feature is under testing.
I wrote JNI code by hand for a number of years and know that this kind of programming is very expensive to be payed. Think about costs of software development.
There are a few little problems with C++ such as include files, function prototypes, and inline methods.
To lay out a C++ struct you need to parse include files. To call a function you need its prototype, so again it's parsing include files. To call inline methods you need to parse and compile the method body from the include file. And if you really want a headache think about C++ templates.
So there really is no such thing as "calling C++ without a C++ compiler"...
And to make matters worse, C++ include files routinely use compiler- and platform-specific extensions. Good luck trying to call Windows C++ with platform-independent tools.
Simple methods can be called with the third party tools mentioned above -- you all know how to google if you want to do that. But anything non-trivial you need a C++ compiler to wrap all the nastiness of C++ into a callable interface. And presto, we have reinvented JNI.
I am not interested in calling C++, I want to call methods in the OS api (and I don't care what they were written in).
> I am not interested in calling C++, I want to call
> methods in the OS api (and I don't care what they
> were written in).
Different people want different things...
Which OS, which API functions do you need to call? Some APIs use structs which still needs parsing include files to figure out layout and how to create the structs.
Maybe someone can suggest a ready-made solution for your needs that doesn't involve adding native calls.
Which of the third party tools have you tried so far? Do they work for your needs?
> Maybe someone can suggest a ready-made solution for
> your needs that doesn't involve adding native calls.
> Which of the third party tools have you tried so far?
> Do they work for your needs?
These are interops:
SWT (by IBM),
As to me, it is easier to write C++ code than to use some third party product. Look at products abovementioned and you will understand why.
>If SUN will not change this policy Java will be substituted with C# in the market in near future.
Ohz noz, the sky is falling...
Seriously, this make JNI easier stuff... Its crap! JNI is not so hard that you can't do it. Yes, you might actually have to learn about how to code in a language that doesn't sugarcoat everything and yes you will have to learn to be responsible for what you do it those languages. Shocking eh?
> I agree that JNI must be made easier and not require
> a C/C++ compiler, to get around JRE platform limitations
And what language do you purpose? Do you think it should be Sun's job to make it do able in every language out there? Or just a select few? And if just a few, then when language_x isn't usable, we will be right back to where we started, people complaining because they either are to lazy to learn how to use another language, or people just refuse to learn how to do it because its outside of there comfort zone.
Making JNI easier is not about the difficulty of coding in C/C++, but that to use it I have to have a compiler for every system on which it is to be used. That also usually means having a machine running each of those systems (or a cross compiler). So even though I can write C++ and know the methods I would like to call I can't ship anything for non Windows platforms ('cause that is all I have).
So even if the 'language' describing the Java / native method binding was quite obscure, it would still be easier than the current mechanism provided that the JRE on the destination system would then automatically generate the necessary linkage.
I agree that JNI must be made easier and not require a C/C++ compiler, to get around JRE platform limitations, however SWT is not a good example (nasty and buggy API). Swing isn't nice in places either, but at least it can be worked around.
> however SWT is not a good example (nasty
> and buggy API). Swing isn't nice in places either,
> but at least it can be worked around.
+1 from me here ;)
Well by the end of the day one can argue that it's not Java's fault / responsibility there, but then we'll fall into the dead-cat throwing exercise here...
It might interest you to know that I am releasing updates to Jace. You can email me off the sourceforge site if you have specific questions or requests. I would also appreciate some help supporting the code ;)
In your case, I'd suggest not using Java for the code, and looking at C#, Mono and its implementation of P/Invoke. See
http://www.linuxgazette.com/node/8794 for an introduction.
If you absolutely have to use Java, try using gcj's CNI, which does a fairly good job of making transparent bindings to C++ code.
JNI is something you don't want to use, unless you absolutely, desperately have to, or someone is paying you really good cash for the pain you'll be suffering through it.
JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java codeâ€”no JNI or native code is required. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes. Access is dynamic at runtime without code generation.
It is pure Java access to native libraries.
Another approach to simplifying JNI is Jace http://sourceforge.net/projects/jace
However if you are looking for something which eliminates the need to have a C/C++ compiler then this isn't it.
There are basically five reasons to use JNI:
1) you need OS/hardware access that Java doesn't give you
2) you need to use code that can't be ported to the JVM because no source is available
3) you need to use code that can't be ported to the JVM because no compiler is available
4) it was written using JNI and changing to pure Java wouldn't be worth the effort
Even though many people think it is, I doubt speed is really a valid reason very often now. The thing to notice about these reasons is that they all require different solutions.
Personally, I wish Sun would supply a mechanism to map between Java interfaces and DLLs/shared libraries. Mapping functions one at a time is tedious, error-prone, and lacks type-safety. A way to map between Java objects and the shared library parameters would usually be needed.
This won't happen, however, because Sun doesn't want using native libraries to be too easy. The sad thing is that they don't seem to realize that by making native libraries hard to use, they are also making native libraryies hard to stop using.
Here are some relevant links on the subject of Java an JNI:
I guess it is useless to wait for making some JNI Tools by SUN. JNI SDK is not friendly for developers, many routine things should be known and done while developing JNI modules. It looks like forcing C++ programmer to write low level OLE code instead of using ATL library in MS VC++. Four years ago I started to develop Object Oriented JNI SDK and Add-In for MS VC++. Just now I have issued the first version (see http://simtel.net/product.php[id]90910[SiteID]simtel.net) that generates C++ JNI wrappers in MS VC++ 7.1. It supports minimum options for JNI code development. But it is enough for reducing costs and time of JNI code writing. The next versions will have features like event handling in C++ from java code, which will be based on generating and embedding java bytecode to C++ while JNI code design (see BCEL project), implementing native methods, etc. The main feature of OOJNI Add-In is that all JNI code is generated without JVM use. It makes it independent from JVM provider and versions.
Sun Studio 8 had released with a Native Connector Tool (NCT) that would read Dwarf2 debug information from a shared C or C++ library (Solaris or Linux) and automatically create the Java layer interfaces into a native library.
Google NativeConnector and you should find some documentation on it. I'm not necessarily recommending it, but Sun has indeed attempted to produced such a beast. For various reasons I'm not sure it is still delivered, but the audience was very limited and the "real" JNI programmers seemed to prefer writing their own code. ;^)
Giving Java access to native code has it's dangers, and getting it right (and who's "right") isn't easy either.
I agree that using JNI is not easy, it never has been. The documentation is slim and you can create some real nightmares doing JNI coding, it's definitely not for the faint of heart. (If anyone has suggestions on articles or documentation on JNI that might help, please let me know).
But there have been some attempts at improving JNI performance and also improving the runtime checking with the -Xcheck:jni option in Mustang. I don't know of any other changes in the JNI area at this time.
you are not right. If you have said 'A' say 'B'! If JNI is available for Developer it should be supported. Otherwise it should be removed from documentation. You refer me to [b]NativeConnector[/b]. But I do not want to do anything with this [b]Monster[/b]. It comes from other "Opera". I mean that for JNI itself some tool should be available to make JNI programming easy. You say that SUN do not want to support JNI. But look at IBM. They issued [b]The Standard Widget Toolkit (SWT)[/b] that makes use of native OS resources easy. It looks like better than OS independent packages SWING and AWT.
If SUN will not change this policy Java will be substituted with [b]C#[/b] in the market in near future.
I'm not sure of what I said that isn't "right", but regardless, I'm sorry my posting didn't help.
I was thinking of having the ability to be able to load a dynamic library and call a function. For example, a java app that uses calls to libburn to handle mastering CD and DVD's. If the java app could easily invoke function calls to the libs with no wrapper function, then I could just distribute my java app as usual (with the requirement that the user has libburn installed on their windows / unix / linux / mac box). Otherwise I think you'd have to write the wrapper, compile it for each platform, and distribute a version for each platform you want to support. (And I'm guessing that you'd have to compile using a similar compiler version that the end-user's libs were compiled with).
I haven't actually used JNI yet so all of this is speculative, if this is completely wrong let me know :)
I haven't tried them myself, but there are things like xFunction, CoRoutine, JNIWrapper, ... Google for those and [i]jni alternative[/i] etc.
I wonder what would be the pros and cons of having something like one of those in the standard JRE...? Wouldn't want to make it too easy to call C if you want to promote 100% Pure Java?
I guessing this be motivated by 1) a lack of knowledge of C/C++, 2) no desire to learn C/C++ but still want to use native calls.
Either way, you do realise how many fundamental differences exist between the languages (not to mention the differences between C varients) that would make automatic marshelling of even primitive values passed in either direction difficult without a wrapper to specify whats needed?
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.