wood burning stoves 2.0
The moose likes Java in General and the fly likes JNI to DLL architecture Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "JNI to DLL architecture" Watch "JNI to DLL architecture" New topic

JNI to DLL architecture

Michael Brewer
Ranch Hand

Joined: Jun 27, 2002
Posts: 54
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.
Bill White
Ranch Hand

Joined: Oct 27, 2002
Posts: 82
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.
Michael Brewer
Ranch Hand

Joined: Jun 27, 2002
Posts: 54
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?
Gopi Balaji
Ranch Hand

Joined: Jan 23, 2003
Posts: 84
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.

  • -GB.
    [ February 25, 2003: Message edited by: Gopi Balaji ]
    I agree. Here's the link: http://aspose.com/file-tools
    subject: JNI to DLL architecture
    It's not a secret anymore!