NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Because VMs from different vendors offer different native method interfaces, programming becomes tricky, because one is forced to produce, maintain, and distribute multiple versions of native method libraries on a given platform. When integrating such libraries into Java applications, the pitfalls are many. Though there is the JNI specification that covers these scenarios, in real life it is just plain hard to set things up in such a way that everything works as expected.
Here are two libraries that I often make use of:
JDIC
.
Provides Java applications with access to functionalities and facilities provided by the native desktop.
JMF
.
Provides audio, video and other time-based media to be added to applications and applets built on Java technology.
Or, in fact, I don't make frequent use of these. But when I need them, I
really
need them. Between one usage and another, there tends to be a space of about 6 months. In the interim, my environment seems to have changed to such a degree that I need to set up these libraries all over again from scratch.
Some of the problems I've had include the problem of packaging multiple libraries for different platforms, the overhead this causes also in terms of testing, the fact that each browser seems to have different requirements for interacting with native libraries (for example,
here
one reads the following about JDIC: "The package has been tested with IE 5.0 and 6.0, Mozilla 1.4, 1.6, 1.7 and 1.8a4. Other browsers including FireFox, Galeon, Epiphany, Opera, etc. are not supported or tested, though they might work"), and the fact that a browser's security doesn't always permit the loading of native libraries. Pinpointing where exactly the problem lies is one of the larger problems. There are just too many variables...
Using such libraries in Java applications shouldn't be this hard. But every time, the many different requirements, the different conflicting actors (browser, VM and os, to name three), and the little "gotchas" ("yes, that works if you have A, B, and C, but if you also have D, as in your specific case, you need to uninstall B and then reinstall it, but then configure it so that it acts like E") are frustrating, to say the least. What are your experiences?
I have to use black box native library in my server process, provided by the other party in the company. It has something like 100MB of compiled code (2-3M LOC in C++), so there is certainly some value there and I'm not willing to rewrite it in java We are generating the interface with swig and it works like a charm - even in case where library is exporting pure virtual classes (interface-like) for us to override in java. Same java code works on multiple platforms (unix-like, we haven't tried windows so far), we just need to recompile one cpp file on target platform.
So, from my experience, I would say that native code integration on server side (where you control all the parts of equation) is painless.
We had a significantly big mathematical computation we wanted to use in a Java application. The problem was that the monster was written in C, and too complex to simply translate verbatim in Java.
The JNA project allowed us to easily interface with the .DLL and access the desired functions without a hitch. It only took me a friday afternoon to understand the examples and make it work for my situation.
I would recommand anyone who think they need to go the JNI way to have a serious look at the JNA project first!
Did you have any experience dealing with the 'pinning of memory' feature in JNI, that seems to be lacking in JNA? For instance, when you want to write some native code that does some image processing, you want the native code to be able to access the memory without the java memory being copied to native space and back to java again. With normal JNI code, I've experienced a near zero penalty when the native code needs access to the java memory data buffer.
But with JNA, I'm clearly seeing that the cpu spends time copying the memory buffer.
For small memory amounts it isn't a problem, but for image processing, especially in real time, this definitely is a problem for me.
All I've done so far was to access native code to "ask a question" and getting the answer back. Nothing involving large objects. You should try the JNA forums or maybe ask Timothy Wall directly on his blog... I think he's the one who's been the most active developper lately.
Quicktime for java, Java Videolan, ffmpeg java from fmj, imagemagick for java but i have allways trouble to find correct native library with java library on windows.
Especially for java videolan and ffmpeg.
Why they don't provide a compiled version for principals platforms ?
Please, make all in one package "java library version X + native library version Y" for Windows, Linux, Mac ...
I think the good solution is to compile C or C++ version on my computer but it's not so easy when you don't have Cygwin gcc or Visual C++.
Going Native
At 3:01 AM on Dec 3, 2007, Geertjan wrote:
Fresh Jobs for Developers Post a job opportunity
Because VMs from different vendors offer different native method interfaces, programming becomes tricky, because one is forced to produce, maintain, and distribute multiple versions of native method libraries on a given platform. When integrating such libraries into Java applications, the pitfalls are many. Though there is the JNI specification that covers these scenarios, in real life it is just plain hard to set things up in such a way that everything works as expected.
Here are two libraries that I often make use of:
Or, in fact, I don't make frequent use of these. But when I need them, I really need them. Between one usage and another, there tends to be a space of about 6 months. In the interim, my environment seems to have changed to such a degree that I need to set up these libraries all over again from scratch.
Some of the problems I've had include the problem of packaging multiple libraries for different platforms, the overhead this causes also in terms of testing, the fact that each browser seems to have different requirements for interacting with native libraries (for example, here one reads the following about JDIC: "The package has been tested with IE 5.0 and 6.0, Mozilla 1.4, 1.6, 1.7 and 1.8a4. Other browsers including FireFox, Galeon, Epiphany, Opera, etc. are not supported or tested, though they might work"), and the fact that a browser's security doesn't always permit the loading of native libraries. Pinpointing where exactly the problem lies is one of the larger problems. There are just too many variables...
Using such libraries in Java applications shouldn't be this hard. But every time, the many different requirements, the different conflicting actors (browser, VM and os, to name three), and the little "gotchas" ("yes, that works if you have A, B, and C, but if you also have D, as in your specific case, you need to uninstall B and then reinstall it, but then configure it so that it acts like E") are frustrating, to say the least. What are your experiences?
6 replies so far (
Post your own)
Server side is painless
I have to use black box native library in my server process, provided by the other party in the company. It has something like 100MB of compiled code (2-3M LOC in C++), so there is certainly some value there and I'm not willing to rewrite it in javaSo, from my experience, I would say that native code integration on server side (where you control all the parts of equation) is painless.
Re: Going Native
We had a significantly big mathematical computation we wanted to use in a Java application. The problem was that the monster was written in C, and too complex to simply translate verbatim in Java.The JNA project allowed us to easily interface with the .DLL and access the desired functions without a hitch. It only took me a friday afternoon to understand the examples and make it work for my situation.
I would recommand anyone who think they need to go the JNI way to have a serious look at the JNA project first!
JNA : https://jna.dev.java.net
Re: Going Native
Did you have any experience dealing with the 'pinning of memory' feature in JNI, that seems to be lacking in JNA? For instance, when you want to write some native code that does some image processing, you want the native code to be able to access the memory without the java memory being copied to native space and back to java again. With normal JNI code, I've experienced a near zero penalty when the native code needs access to the java memory data buffer.But with JNA, I'm clearly seeing that the cpu spends time copying the memory buffer.
For small memory amounts it isn't a problem, but for image processing, especially in real time, this definitely is a problem for me.
Re: Going Native
Sorry, can't help you there...All I've done so far was to access native code to "ask a question" and getting the answer back. Nothing involving large objects. You should try the JNA forums or maybe ask Timothy Wall directly on his blog... I think he's the one who's been the most active developper lately.
Good luck!
Francis
Re: Going Native
Hello,I try video/photo libraries with native code.
Quicktime for java, Java Videolan, ffmpeg java from fmj, imagemagick for java but i have allways trouble to find correct native library with java library on windows.
Especially for java videolan and ffmpeg.
Why they don't provide a compiled version for principals platforms ?
Please, make all in one package "java library version X + native library version Y" for Windows, Linux, Mac ...
I think the good solution is to compile C or C++ version on my computer but it's not so easy when you don't have Cygwin gcc or Visual C++.
Vincent
Re: Going Native
Has you tried JNIEasy ?