Native code, JNI

Recently I posted on how to incorporate native code in OSGi bundles. Well, some questions surface now and then, particularly "then" nowadays (thanks to the recent posting), regarding the actual native code production.

To start with there is a good tutorial on the subject provided by Sun. Secondly, and probably a bit harder to obtain, is a very good book on the subject: Essential JNI - Java Native Interface, by Rob Gordon (ISBN 0-13-679895-0). It seems to have gone out of print. That is a pity as it is considered one of the best books on the subject. It explains all parts of JNI well, and it has very good examples.

But, how do you get about dealing with native code? What pitfalls are there? Rules of Thumb? Here is a check list for you, hope it is of help when you are about to select the path ahead:

1. When do I need to employ JNI? Answer: Never!
   Well, in 99,9 % of the cases you are better off not using JNI. I.e. native code does not always execute faster - running Java code in the HotSpot JVM can actually be equally as fast or sometimes even faster! Further; check to see if there is another solution, open source maybe, that does what you need. They might have fixed the interfacing chore for you...


2. Ok, but you've got some legacy stuff on your hands. Now do you need JNI? Yes, maybe, but there might be other techniques you can employ. Have you checked pipes, shared memory or sockets? Please keep in mind that loading a shared library into a process space might crash the process if some piece of code in the library crashes. You are outside the Java Sandbox, but still within the same process space. The other techniques mentioned have the library execute in a separate process, then you have a problem of checking liveliness instead.


3. You are about to interface and use COM-components or ActiveX Controls on Windows. Required to learn everything about COM, DCOM, ActiveX, etc? No, not really. Ok, knowledge is no burden, as every abstraction leaks you should at least learn the basics on COM. For the interfacing problem, as mentioned before, somebody else has already taken care of the JNI part you in this case: e.g. the COM - Java Bridge JACOB, and others...


4. You are still here? Ok, maybe JNI is the solution for you. Are there any pitfalls? Oh yes! There are plenty, in most cases we are talking about writing code in C or C++ here. As some of you already are aware of, it is much easier to create code that will malfunction in C/C++ than Java! Do not get me wrong here; C and C++ are perfectly ok languages too, it just that you have to take more aspects into consideration and be careful of pointers, casts, void*, etc.
   Then, there is loading of the library, on Linux/Unix check your LD_LIBRARY_PATH, om Win32 the PATH variable. That also goes for those libraries your library depends on.


5. Other considerations:
   
   
   
   • Strings - in Java a String instance is an object, needs to be converted on the native side using the special GetStringUTFChars function. It is released using the ReleaseStringUTFChars whendone with.
   
   
   • Exceptions - if calling Java code from the native side, under some circumsances you need to check for possible exceptions thrown, or you might run into trouble.
   
   
   • If you are into C++, using the bridge design pattern can be a powerful approach; Java classes are mirrored on the native side implementation in the C++ classes. Have them comminucate through JNI.
   
   
   
   

Despite what I say (write) in the bullets above I am an advocate of JNI. Every Java assignment I've had has involved some work using JNI - there has been no exceptions so far. JNI is a powerful technology and correctly used it will leverage your project.

Christmas beers and ales sampling

A couple of days ago we had a small gathering to sample some of the beers and ales for this Christmas. We had a good time and there where a number of tasty beers. 13 to be precise (Magnus took notes, so I'm not fully responsible...):

1. Stone Old Guardian (USA, 11,26%, 70 cl) Full, some bitterness - Nice!


2. Saint Landelin (France, 6,8%, 75 cl) sweet, artificial flat tase, everybody poured this one in the drain!


3. Samuel Adams Winter lager (USA, 5,6 %, 35,5 cl) good likable taste, most everything in it, not that full taste, goes good with the food. A favorite!


4. N'Ice Chouffe (Belgium, 10%, 75 cl) Nice full taste, typical Belgian, maybe a bit of sweetness. Long after-taste.


5. Token Julefröjd (Sweden, 4,9 %, 50 cl) Strong taste of coffee, sour, no bitterness at all! Is this really beer - disappointment! This brewery usually does much much better.


6. Jämtlands Julöl (Sweden, 6,5 %, 50 cl) Ok, we're back in business! Precisely right on bitterness and sweeness, well balanced, goes very well with the food on the table. Very nice!


7. Gouden Carolous Chritmas (Belguim, 10,5 5, 33 cl) Ohhh! this one is really good! Precise balance in bitterneess, sweetness, dryness, etc. Full, nice taste, long full after-taste. Maybe the best ale tonight?


8. Nøgne Ø God jul (Norway, 8,5%, 50 cl) Some notes of coffee, a litle bit of bitterness, quite good. We like it.


9. Dugges Rudolf Ren Ale (Sweden, 7%, 50 cl) Chemical, acrid taste. What is this.?.. no, it is no favorite of ours.


10. Corsendonk Christmas Ale (Belguim, 8,5 %, 25 cl) Nice, not so full as Gouden Caroulus or Chouffe, but as it is slightly "thinner" it probably goes well will the stuff on the Christmans table. Why the weird size (25 cl) of the bottle??


11. Gulden Draak Vintage (Belguim, 7,5 %, 33 cl) The chock of the evening. Gulden Drrak is a favorite, i.e. the regular Gulden Draak. What this is we don't know. Magnus Baught it while in Belguim. Well, it wont be purchased again, it has a sour acrid vinegar tone, really a disappointment.


12. Regal Christmas (Belguim, 8,1 %, 33 cl) Nice full taste, a tone of spice. Very very nice!


13. Gordon Xmas (Belguim, 8,8%, 33 cl) Almost as the previous, slightly different tone, long after-taste.

Ok, how did we rate them? The order after some discussion, we came to the following conclusion:

1. Gouden Carolous Christmas


2. Regal Chrsitmas


3. >Gordon Xmas


4. Jämtlands Julöl


5. N'Ice Chouffe


6. Stone Old Guardian


7. Nøgne Ø God Jul


8. Samuel Adams Winter Lager


9. Corsendonk Christmas Ale

After that there where really none we liked. So we did not grade them... Further, there are of course several good ones we haven't tried yet, e.g. Nils Oscar Julöl and Kalas Julöl, Wisby Julöl, Anchor Christmas Ale, etc.

Bundle-NativeCode in the OSGi manifest

OSGi is a pretty straight forward and quite easy to use technology. As long as you are doing the thing Java programming language. But, what happens when you start to involve other implementations, i.e. native code (most often compiled C/C++ source). On Windows these libraries are known as Dynamic Link Libraries, or DLL for short. Linux and Unix clones are called shared object libraries and has the .so suffix.
What about Mac OS X? Well, there is also so-files, but I've also encountered so called dynlib:s. Anyhow, do not despair, all these are nicely handled by OSGi. I.e. an OSGi framework will happily load these libraries into the JVM process space and thus make them available to whatever Java class that is about to call them. If you are about to produce some native code, check out the tutorial at Sun.

Ok, you have your Java class defining the native methods, generated the .h-file from it and done the mandatory HelloWorld thing on the native side, also got the System.loadLibrary call right and everything. It works all nice and peachy.

So, now what? How to get it to work encapsulated within an OSGi bundle? as you've got all teh basic stuff in place, it is pretty much a walk in the park. Well, all you actually need is to declare your newly created native library in the bundle manifest and also declare which library goes with which operating system. Yes, you can bundle several libraries for various operating systems in the same bundle and the framework load the correct one depending on the declaration in the manifest.

So how does this portion of the manifest look like? Here is a simple example of declaring a DLL (Windows) named "mylib", located in a directory named "lib":

 .
 .
 Bundle-NativeCode: lib/mylib.dll ;
  osname=Win32 ;
  processor=x86
 .
 .

Please note the placement of the semicolons (';'). That is quite important.

But; what if I've got several DLL:s, or libraries, in my project that need to go into the same bundle? Well, that is not a problem. What you need to keep in mind is the placements of the semicolons.

So, expanding the above simple example with two DLL:s (mylib1 and mylib2) for the same platform it will look like this:

 .
 .
 Bundle-NativeCode: lib/mylib1.dll ; lib/mylib2.dll ;
  osname=Win32 ;
  processor=x86
 .
 .

Ok, everything is nice and peachy. Next iteration of the projects adds a whole bunch of requirements, one is regarding the support for yet another platform: Linux. Can I easily add that?
Sure! Produce the necessary native libraries for the new platform, add them into your project and finally - before launching the debugger - add some more lines to the manifest:

 .
 .
 Bundle-NativeCode: lib/mylib1.dll ; lib/mylib2.dll ;
  osname=Win32 ;
  processor=x86,
 lib/libmylib1.so ; lib/libmylib2.so ;
  osname=linux;
  processor=x86
 .
 .

See the comma (',')? Each "block" is separated by a comma. As you also might have guessed by now is that fact that not only is it possible to qualify on operating system. You can also load different libraries depending on processor architecture, on the same operating system, and operating system version. Further, I haven't discussed another option that is quite powerful; the filter capability. It is also possible to qualify on basically anything, e.g. which windowing system is present and thus load an appropriate library dependent on that.

Maybe I'll discuss how to make use of the filter capability in a future posting. Anyhow, I do recommend that you download and read the OSGi specification from osgi.org, it is one of the best specifications when it comes to readability I've come across. The section on Bundle-NativeCode is very worth studying, it discusses the above and more ...

The history of computer hardware

Reading Wired sometimes render some interesting things; like this one - The history of PC hardware. Fascinating stuff! And, it wasn't that long ago. I actually came across one those early mobile computers, with a detachable keyboard.

Further, I am searching the Internet for articles and pictures on the early versions of the AXE-telephone system, here is another story. I used work with it during the 80:s and 90:s. In the beginning the so called man-machine interface consisted of a number of teletype printer with paper. There could also be VT terminals sometimes. Anybody who could share any knowledge on where to find this stuff?

Shopping at Wal-Mart can be dangerous

You've probably heard the saying "shop until you drop", but being like this!

People are so inclined to consume they care not for others. I've read somewhere, long ago, in a science fiction novel about a society where the rich where those who could afford to live a simple life. While, the poor where forced to consume. At the time I thought the story to be outrageous. But, everyday I see evidence that the author, whoever it is, where quite on spot. That's scary ...


Anybody out there who might know which author? I believe him (yes it's a he) to be one of the more famous American SF novelists.