This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
My team has to create an application that centers around an API that exists in a DLL. My thoughts are that there are two ways to do this: 1. Put all of the native method calls to the DLL into one Java class. 2. Put the native method calls into individual classes by purpose. If we do the first one, there will be one thick class that handles all of the communication to the DLL. I think this could be bad in that we'd squeeze all of the calls through one method which would result in slower performance. However, the fact that all of the calls are already going through one thick DLL seems to nullify my concerns about approach 1 and may mean that approach 2 would require more work for less benefit. Thoughts?
First my answer: I would take the object oriented approach and split the calls up by purpose. Method 2. Now, my question which will probably nullify my answer. I am just starting out with JNI (Started today) I am using JBuilder8 and MS VC++ 6.0 for my IDE's now. I have built and compiled a very simple "Hello World" program, compiled all my code successfully etc... However when I make the call to System.loadLibrary(String); I get an unsatisfied link exception. Where are your placing your DLL's and what does your String arg look like with the call. Thanks
Joined: Jun 27, 2002
I worked through that problem myself recently. I hope that helps. I'm still looking for more advice on how to architect my application. Anyone? Anyone?
This is how I would go about it.. JNI methods are like any other Java methods. Place them where they make sense (i.e., uphold principles and best practices of OOP). Placing all of them in a single class in highly undesirable. Having a number of Java classes with only native method calls are desirable in these situations:-
When you intend to later replace all native methods with pure Java libraries. In that case, the impact of change will be localized.
When the native methods do not make sense (..OOP principles) in other Java classes.