Writing a little app that interfaces with serial port device using the communications API and I'd like to bundle it into an executable JAR. JBuilder will create the JAR for me fine, but the issue is with the win32com.dll file thats part of the comms API. I need to include this, I don't think its possible to include as part of the executable, but otherwise the DLL needs to be in the windows\system folder. Could I include the dll as part of the JAR archive and then extract it upon runtime? If so how would I go about this?

Any help much appreciated.

 

 

No, the DLL doesn't need to be in the Windows/System folder. It does however need to be in some folder under where you installed the JRE (check the installation instructions, I don't recall exactly which one). You cannot distribute it inside the executable jar, that is not going to work. Your installation has to put the various files (that DLL and there's also a properties file, I believe) where they are supposed to go.

 

 

So I'd need an installer that extracts these files to the correct location, and also to bundle the JRE with any deployment?

On my testing PC I have the DLL in only the windows\system (and not in jdk\jre\bin) folder and didn't put the properties file in the required folder and it seems to be working for my purposes (Just sending commands to the serial port).

Is it possible to include the DLL within a JAR archive, find out at runtime where the windows\system folder is and then extract the DLL to there?

Thanks

Andrew

 

 

There are three ways of configuring the DLL to the path

1) Put the DLL in the c:\windows\system32 directory. The Default procedure.
2) Put the DLL in the JAVA_HOME\bin\ directory. If the java bin is configured to path
3) Put the DLL in any directory preferable the same as the program. the program should be run as java -Djava.library.path=[absolute path of the dll or directory] [Your Java Class]

I feel the third option would be the right one for you. You can have all the required files in the same directory, create a command script to invoke java as above.

I have not tried this option because of time. You can leave the same in jar and try to refer the file in the jar itself as depicted below. This is just conceptual based on how the files are referred from jar in the normal application. You can give this a shot and do post your findings :).

jar:[absolute path of jar file]![location of file in jar]

 

 

Hi,

Some finding... thought this would interest you.

http://www.javalobby.org/forums/thread.jspa?threadID=15512&tstart=0

I am also working on the same... will post the moment I am successful

 

 

There is another option. Native libraries need to reside within the java.library.path location. As it turns out, if you, at runtime, grab this property and ADD your own location to it, then set it back in to the System.setProperty() call, it will NOT work. The only way to do it is the -Djava.library.path value that tjmaven suggested.

However, if you read up on how a native library is found, it uses the ClassLoader.loadLibrary() which calls the protected findLibrary() method. You can therefore extend ClassLoader to find a path yourself.

One way is to extend URLClassLoader since it has the protection/security stuff AND the ability to look in .jar files for you. Your custom loader is created by a "launcher" class in your .jar file. First, your luancher uses getClass().getProtectionDomain().getCodeSource().getLocation() to get the absolute location of the .jar file its executing within. From there, you open the jar and look for your native library, extract it using the JAR api to a location of your choosing. Now, you instantiate the custom classloader and using this custom loader instance you load the rest of your classes. The main .jar file contains two classes, the launcher and the custom classloader, and contains the native library if you wish to do it this way. The custom classloader, you specify a URL[] of "classpath" entries. You bundle up the rest of your source in a second .jar file that you pass to the URL[] when creating the custom classloader. It will find all your classes in the 2nd jar no sweat. You can even "reload" these classes on the fly by recreating the custom classloader instance if you so wish to add a sort of "reload" feature.

Now, in your custom classloader, you override the findLibrary() and return the SAME STRING PATH that you used to unjar your native files to. This way, when the JVM asks your custom loader to load the library at some path, you return the right path to find the native files in.

I haven't verified that this works just yet, but I will soon. Primarily, my plugin engine over at www.platonos.org will support the ability to place native libraries in plugins, allowing you to effectively wrap a native library use as a plugin. Not yet working, but we'll soon have it in place.

 

 

For SWT, you can include the .dll files in the same directory as the executable jar file. It works for SWT, but not javax.comm. Why does it work with SWT? (http://www.javalobby.org/forums/thread.jspa?threadID=15512&tstart=0)


Ed

 

 

Got to keep this in perspective. When you ask the jvm to loadLibrary(), you're asking the underlying platform to do it's own sort of library loading. I.e., windows has the ability to load dll's and linux to load so files as a means of allowing dynamic binding for applications, and this means finding something in the platform's file system.

So, unless the underlying OS knows how to load libraries that exist inside compressed beasties (like jar files) it just isn't going to happen. I'd love to be able to deploy a single .jar and have done with it, but it's the concept of the OS dynamic library that's getting in the way here.

 

 

No difficulty in including DLL to jar. But U want to set the library path before referencing DLL. We want to find out the absolute path of jar and then set these path to library path. Which might solve the problem.
Sorry I didn't work as per the suggestion

 

 

related question pl....
So I have a product that potentially has the following:

1) Web Services, xml schemas, java functions etc incl. several scripts
2) couple of J2EE compliant apps incl. UIs (typical UI related widgets...)

the goal is also to ship the source code alongwith the topology (filesystem layout).

Is the delivery method of EAR a sound one (it might be that we will incl. some war's for the Web based entities)?

We need the apps as well as the Metadata to be deployed onto the "up and running" J2EE server(s) on 3rd party vendor middleware infrastructure from Tibco, BEA OR Oracle etc as well as lay down the Filesystem with the source code.

Should we look for any other simplified approaches 'cause we know for a fact that the customers (consuming our software) almost always customize our out-of-the-box delivered software solution...

Sounds a simple question but need your reconfirmation and advice OR pointers to collaterals pl.

thanks much in advance
scott