0

I'm developing a simple standalone java application which uses a (single) dll. So far so good. The problem is that an older version of this dll is already present in most users'PCs (c:\windows\myDLL.dll, so it's in the PATH).

I would like the application to be able to use its own dll, i.e. the newer version, which is located in its "lib" directory.

Any ideas? I even thought I could swap dll (if the application finds the older version in c:\windows then it could overwrite it) but it is (obviously) locked by the application itself, which while loading probably opens the dll in the PATH...

Bya
  • 55
  • 1
  • 12

1 Answers1

0

I note you have the DLL deployed within the .war file. In this scenario you need to extract it from the .war file (on application startup), write it somewhere and then reference the absolute path via System.load(). See this answer for more details.

Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
  • Using NetBeans, I defined the -Djava.library.path in the properties/run section, but I get no result probably because I do not know how to let the application look into its .war file... – Bya Sep 25 '17 at 12:08
  • If you deploy the DLL *in* the war file, you have to extract that at runtime, save it somewhere (say, the c:\temp dir) and then reference it from there. You can't use java.library.path to refer to something *within* the jar file – Brian Agnew Sep 25 '17 at 12:25
  • Ok, thanks. Let's say I will deploy the dll not in the .war file but in a /lib directory which resides in the main application's directory. Could I use System.load() to load it? should I use something like "currentDir/lib/myDLL.dll"? – Bya Sep 25 '17 at 12:40
  • I tried System.load(myDLL.dll) but it fails saying that it cannot load a 64bit dll in a 32 bit environment (for this specific application I am using a 32 bit environment)... quite strange: if I manually overwrite the dll in the Windows dir, the application uses it without any issue. So I tried to delete the old file and to copy the new one, but it is impossible: probably the application does not have any permission to delete a .dll file in the c:\windows dir... – Bya Sep 26 '17 at 13:42