Hacker News Reader

Comment by zten | Hacker News Reader

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

View on HN

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.

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.

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.

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.

But you can static link them instead.

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

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

Reply on news.ycombinator.com