5 ms·

How are .so, .dll files handled during Java packing? This is more open question, but say you have one ".exe" file. Now you need to extract the DLL in a place, a

by malkia 9y ago

How are .so, .dll files handled during Java packing? This is more open question, but say you have one ".exe" file. Now you need to extract the DLL in a place, and make sure everytime it's the right one (gets tricky if the tool is ran simualtnenously, like spawned from a build process). While I was at Google, instead of having multiple .so files, the main launcher was a C++ binary, and all external C++ dependencies were linked into it (that's it if you have the source code), then you didn't need that. I guess now it's up to the BUILD system to achieve that, where if you have more flexible BUILD language you can instruct everything to go in the main launcher file, then have all the .jars into one, slapped at the end of the file. At the end, ship or update only one binary to your service, desktop machine, etc.

zten 9y ago
> How are .so, .dll files handled during Java packing? Native libraries used by JNI can be shipped in the jar files and are read from the classpath, in addition to reading them from the ordinary linker path. (edit: turns out I'm wrong about this on Windows)
- malkia 9y ago
  But on Windows you must "extract" and copy the DLL file somewhere (ok, possibly you might be able to do in-memory load, but that is very non-standard and might trigger antiviruses). I think the same is with the Python packagers, or C# shadow copy.
  - weej 9y ago
    You need to package up the JAR with the shared object / dll and install both on the local filesystem in order for the SO to be accessible from the classpath. For example you could apply a package manager (RPM) and include the JAR and .so at install for available use.
    - malkia 9y ago
      But if you were able to "contain" all the source code from your DLL into your main "java.exe" launcher, and then slap the all the .jars at the end of the "java.exe" and then renamed it to "mycoolapp.exe" then it might be just that... off course if licensing agrees with you, and you have the source code, and want to deal recompiling these like that... also compiling it along with the java launcher. This way there is no need for extra install, uninstall. Possibly too much over-engineering for full blown product, but if it's something that needs to be run, and updated on tons of machine - not having to deal with extra artifacts might be a win.
  - zten 9y ago
    Ahh, ok, I didn't understand that part from your post. I haven't used Java on Windows in a long time! Looking at an example of a library that does native binding: https://mvnrepository.com/artifact/com.github.fommil.netlib/netlib-native_system-win-x86_64/1.1 https://mvnrepository.com/artifact/com.github.fommil.netlib/... It appears the artifact is a DLL, and not a JAR. Thus your original question stands.
  - richardwhiuk 9y ago
    I've definitely seen Java code extract a DLL from a JAR at runtime, stick it somewhere (C:\Users\foo\AppData\Local for example) and then use load library to load it (I've seen this leak DLLs as well - with each execution creating a new DLL...).
- pebers 9y ago
  You can't load a native library from inside the .jar file. Typically things that need them extract them to a temporary location and load them from there - there's no standard interface to `dlopen` or similar that lets you load directly from inside a zipfile.
  - malkia 9y ago
    on linux with fuse this could be done (possibly tricky), and on windows there are several ways, but I agree - they are non-standard, hence you are on your own when it doesn't work. I've tried loading dlls from memory (there are several examples on the net) only to understand that there is more to be done (like getting the PDB information correctly loaded, and then some more).
  - pjmlp 9y ago
    But you can static link them instead. http://openjdk.java.net/jeps/178 http://openjdk.java.net/jeps/178
deleted 9y ago
[deleted]
pjmlp 9y ago
One option available since Java 8, would be to statically link them instead, http://openjdk.java.net/jeps/178 http://openjdk.java.net/jeps/178

by malkia 9y ago

zten 9y ago

> How are .so, .dll files handled during Java packing? Native libraries used by JNI can be shipped in the jar files and are read from the classpath, in addition to reading them from the ordinary linker path. (edit: turns out I'm wrong about this on Windows)

malkia 9y ago
But on Windows you must "extract" and copy the DLL file somewhere (ok, possibly you might be able to do in-memory load, but that is very non-standard and might trigger antiviruses). I think the same is with the Python packagers, or C# shadow copy.
- weej 9y ago
  You need to package up the JAR with the shared object / dll and install both on the local filesystem in order for the SO to be accessible from the classpath. For example you could apply a package manager (RPM) and include the JAR and .so at install for available use.
  - malkia 9y ago
    But if you were able to "contain" all the source code from your DLL into your main "java.exe" launcher, and then slap the all the .jars at the end of the "java.exe" and then renamed it to "mycoolapp.exe" then it might be just that... off course if licensing agrees with you, and you have the source code, and want to deal recompiling these like that... also compiling it along with the java launcher. This way there is no need for extra install, uninstall. Possibly too much over-engineering for full blown product, but if it's something that needs to be run, and updated on tons of machine - not having to deal with extra artifacts might be a win.
- zten 9y ago
  Ahh, ok, I didn't understand that part from your post. I haven't used Java on Windows in a long time! Looking at an example of a library that does native binding: https://mvnrepository.com/artifact/com.github.fommil.netlib/netlib-native_system-win-x86_64/1.1 https://mvnrepository.com/artifact/com.github.fommil.netlib/... It appears the artifact is a DLL, and not a JAR. Thus your original question stands.
- richardwhiuk 9y ago
  I've definitely seen Java code extract a DLL from a JAR at runtime, stick it somewhere (C:\Users\foo\AppData\Local for example) and then use load library to load it (I've seen this leak DLLs as well - with each execution creating a new DLL...).
pebers 9y ago
You can't load a native library from inside the .jar file. Typically things that need them extract them to a temporary location and load them from there - there's no standard interface to `dlopen` or similar that lets you load directly from inside a zipfile.
- malkia 9y ago
  on linux with fuse this could be done (possibly tricky), and on windows there are several ways, but I agree - they are non-standard, hence you are on your own when it doesn't work. I've tried loading dlls from memory (there are several examples on the net) only to understand that there is more to be done (like getting the PDB information correctly loaded, and then some more).
- pjmlp 9y ago
  But you can static link them instead. http://openjdk.java.net/jeps/178 http://openjdk.java.net/jeps/178

deleted 9y ago

[deleted]

pjmlp 9y ago

One option available since Java 8, would be to statically link them instead, http://openjdk.java.net/jeps/178 http://openjdk.java.net/jeps/178