At present, JNI is not seamless to use in Java. Why can't the JVM provide automatic marshalling from and to C types?
It should be as easy as the following:
@Library("mylib.so") public native myCMethod();
If you are a contributor; maybe you can point us to some introduction and case-example since the project pages lack this info..
The homepage seems to be down..
Sorry, I changed the machine Jace was hosted on recently, and the firewall settings were wrong. That's not so obvious unless you're explicitly checking for it. It's fixed now.
In any case, you can always download Jace directly from SF. It includes all of the documentation (along with the Developer's Guide).
Aside from the complexity of writing the code, JNI also doesn't have any good deployment options. Sounds, images, etc.. can be resources, but there is no easy way to distribute native libraries as resources. Not only should the code be easier to write, but it should be easier to deploy.
I totally agree with you. Accessing JNI libraries today is a pain. You are subject to all kinds of problems: Dll hell, Internet Servers administrators that don't allow you to install native libraries, web containers that don't work well with JNI, etc.
Java was supposed to make things easier for developers and users. With JNI, however, developers have to handle all sorts of problems and users sometimes too. Most users don't know what a dll is or where to put those. Having to ask a user to set java.library.path in order to use your app is a joke.
WebStart can solve the deployment of native libraries.
Java3D has binaries for several platforms available, using a single JNLP file.
In Java this could be made even better than .NET. The .NET P/Invoke facility uses attributes to specify details of marshalling etc., but the resulting performance is worse than JNI (I benchmarked it), perhaps because the attributes are all dynamic and all decisions are made at runtime. With Java's source-only attributes, this info could be used at compile time to generate efficient stub code.
As for stubs and the speed etc:
if you can generate stubs for anything, then they (stubs) should be generated at runtime and by runtime on-the-fly. If you can generate working source code, you can also generate bytecode (and source is unnecessary additional step - not considering debugging).
So complaints about the speed of .NET are about unoptimized implementation not about bad design.
Generating source code for the stubs is workaround of the lazy architect, not the solution...
Hallelujah!! I'm glad someone else wants to see this too.
What you're asking for is provided by JACE: http://sourceforge.net/projects/jace/
I've recently joined development of this project. The source-code is available, the product is mature and it makes JNI development noticably easier (and even cleans up your code).
If you're interested in helping development, let us know...
I'm serious, if a previously unknown scripting language called "Groovy" can become a JSR, then a better JNI library should certainly have a shot. This is not a slam at Groovy, but an example of how good ideas can be embraced "officially" very quickly.
Most of "the world" is outside the JVM... We need projects like JACE to be mainstream instead of stumbled across.
While we're making JNI simpler, how about some supported way of migrating all of our legacy number-crunching C and Fortran code to the JVM?
Yes Yes Yes.
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.