Hi! Don't know if it has been already answered, I've searched both here and on the web without finding a clear answer. I'm building a kotlin/JVM desktop application with compose, that application will run on Windows and needs a DLL that is used from JVM through JNI. The question is: how can i bundle that DLL within the MSI package such as it will be available to the JVM the application will run into? (If I get it right the MSI, or EXE don't know exactly, will be bundled with a JVM). I've seen on the documentation that you can package resources, but I don't know if it is how I can achieve that: https://github.com/JetBrains/compose-jb/tree/master/tutorials/Native_distributions_and_local_execution#packaging-resources

You could follow the same strategy as, e.g., https://github.com/xerial/sqlite-jdbc does. Put the dll into a jar file and extract it at run time.

The packaging resources guide you linked works perfectly with loading DLLs. I am using that in my app. You don't need to extract anything this way.

@Thomas Good to know. Do you somehow have to set the native library path for that to work?

@Michael Paus Now that you mention it, yes I do have some special code for it. Here is how I did it:

val resources = File(System.getProperty("compose.application.resources.dir"))
System.load(File(resources, "windowsNativeInterop.dll").absolutePath)

@Thomas thank you very much, I will try with your solution and I'll let you know if it works for me too.

@Francesco Pedron Could you please check whether the dll has now been added twice to your bundle because normally everything which is located in src/main/resources is automatically added to the main jar too. Using another folder name might be better.

@Michael Paus Sure, I can check, could you please point me to where I might check this?

@Thomas Actually, it is very much an issue. macOS apps must be notarized unless the user bypasses Gatekeeper, and notarization will block attempts to use the unpack-from-jar-and-load trick.

@mikehearn yes, that was my point. The method I suggested does not have this issue.

@Thomas It does unfortunately. The issue here is not sandboxing related, it's to do with Apple's notarization requirements around the "hardened runtime".

No, the library is not extracted in any way, so it is not affected here. I am completely aware of the Apple requirements but that is exactly why I am using this method.

Ah, I see, sorry. Your initial comment is saying to not use JAR extraction. Then later you mentioned the sandbox and said it's not an issue outside the app store, which is why I got confused. Indeed, the only way is to put the shared libraries into the app package at the top level, sandboxed or not.

Oh I see. I was talking about the “Adding files to packaged application” method. Now I see that “JVM resource loading” is also mentioned in the same guide, that is not what I was suggesting.

@Michael Paus You are right mi JAR contains a "windows" folder with the Jar, will move my resources folder to the readme-suggested location. Thank also to @Thomas

@mikehearn 1. As far as I know the compose gradle plugin already does extract native libraries from jars and signs them. (Jpackage allone doesn’t.) 2. Will your product be able to handle sqlite-jdbc correctly? It contains a lot of different libraries for different platforms but you need only one of them per platform. Extracting them and storing them in a different location might interfere with the internal search strategy.

Yes, it handles that correctly. It detects OS and CPU for native libraries and removes the ones that don't match the target package. The location they're placed is the same place as other JVM libs, so it is found automatically