Hacker News Reader

Comment by malkia | Hacker News Reader

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.

View on HN

> 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)

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.

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.

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.

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/...

It appears the artifact is a DLL, and not a JAR. Thus your original question stands.

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...).

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.

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).

But you can static link them instead.

http://openjdk.java.net/jeps/178

One option available since Java 8, would be to statically link them instead,

http://openjdk.java.net/jeps/178

Reply on news.ycombinator.com