Hacker News Reader

Comment by malkia | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com