Showing messages 1 through 12 of 12.

• Using JNI for multiplatform integration at runtime
  2006-01-17 02:33:29 vitallis [Reply | View]
  
  My company develops a client side integration solution to provide uniform access and interaction model to virtually any application, across all heterogeneous platforms - regardless of platform, technology or API's. I am developing code for java integration with other application. The main problem is that developer does not have source code of any application integrated. I wrote (generated with my tool in C++) a huge JNI code for injecting to the running java application, parsing its class object model and making Component wrappers (like COM objects for all component types) to access them from other processes.

• mmm JNI...
  2006-01-12 16:39:37 kuchugurov [Reply | View]
  
  In my everyday work I have a good deal ov jni related programming. In my case ov developing BDJ (bluray) player all hardware platform interaction is done using JNI methods. When I joined the project I was surpraised the number of jni methods some classes had... (about 10). As I was merely pure java programmer I decided to refactor some code for removing some native methods.
  In our project the majority of developers come with a C/C++ background. So they tend to move implementation into native, becase there they can do better then in java.
• mmm JNI...
  2006-04-18 12:29:34 vitallis [Reply | View]
  
  See what I did in this direction at
  http://www.simtel.net//product.php%5bid%5d93174%5bSiteID%5dsimtel.net
  http://www.simtel.net/product.php[id]94368[sekid]0[SiteID]simtel.net
  
  Soon I will upload a version for .NET, i.e. for writing JNI as managed code.
  
  
  
  

• Serving two masters
  2005-11-10 04:20:27 grahamm [Reply | View]
  
  

  When I was a Sun engineer writing Java for Trusted Solaris administration I had to use JNI all the time. Writing C JNI code is like serving two masters, the JVM and Solaris. Making sure object references and malloc'd memory had all the T's crossed and I's dotted was the hardest and most interesting part of using JNI.

  Graham

• Do it a lot
  2005-11-09 09:37:07 gregorypierce [Reply | View]
  
  because to access hardware or hardware specific features it is many times necessary as I don't want to wait for the JVM to evolve to the point where that feature is considered necessary or important.
  
  DId a bunch of this in the JOGL, JOAL, JInput, LWJGL space. It would be nice if Sun would look at several of the products out there that make binding to native code stupidly easy and integrate that as a new JNI layer. While many people simply don't need or use JNI, there is no reason why it has to be a complete PITA for those of us who do.
• Do it a lot
  2007-03-27 06:15:31 twalljava [Reply | View]
  
  JNA (http://jna.dev.java.net) makes it "stupidly easy" to access native libraries. There are included demos on cross-platform non-rectangular windows, "move to trash" functionality, and a windows-only file modification monitor.
  
  I wrote this stuff to make it easy to experiment with different native APIs from within Java, and it works in w32, linux, and OSX.
  
  No more JNI compilation hassles.

• I have to
  2005-11-07 20:09:16 swpalmer [Reply | View]
  
  I interface with custom hardware and native video processing software. The hardware interfacing is unavoidable, and quite frankly so is the video processing, since to do it right you must use hand-tuned SIMD instructions in carefully crafted loops or you will get abysmal performance. That's not what Java was made for.
  
  And of course there are all the missing bindings to standard things... like burning CDs and DVDs, accessing digital cameras, & scanners, making translucent or non-square windows, ...

• One more JNI and I go .Net
  2005-11-07 19:54:57 trelony [Reply | View]
  
  What would cost Sun to put normal native interop into Java? Politics... And I have to pay...
  
  - Alexey.
• One more JNI and I go .Net
  2006-01-25 08:49:29 vitallis [Reply | View]
  
  You are right! In my previous posts I wrote that in near future people will switch to C#. There is no problem with JNI.

• Only when unavoidable!
  2005-11-07 11:03:47 cajo [Reply | View]
  
  Fortunately, that happens only very rarely. Typically, it is to drive some specialised data acquisition card, or for some exotic device control hardware. I've even gone so far as to implement TCP stacks on embedded control devices, just so that I could java.io.Socket instead of JNI.

• Why JNI?
  2005-11-05 03:12:05 s690716 [Reply | View]
  
  Java is a platform independant programming language... so, where are the interfaces to use Twain, WIA or Sane? How can I access volume/network share information? Or simply use UPNP to obtain informations about available devices?
  
  And no thanks... no commercial and platform dependant 3rd party APIs...

• Not if I can help it.
  2005-11-04 12:52:51 coxcu [Reply | View]
  
  I write JNI like Russell Nash goes to Jersey.