The automated native library loading currently requires to extract the native libraries into a kind of temporary cache on the file system. It uses a small binary file to detect whether a directory is "executable". However, some virus scanners detect this binary file as a virus, some others detect the extracted libraries as possible viruses. Moreover, GlueGen fails to find a location to build this temporary cache in constrained environments or a valid location might become unusable when there isn't enough available space. Java and the Windows API don't support the native library loading when the library isn't in the file system but it's possible to load a DLL from the memory: https://github.com/fancycode/MemoryModule Actually, a JIT compiler can do something similar. I suggest to copy the native libraries into the memory and to load them from it instead of extracting them into the file system first.
It's too much ambitious. Such a mechanism would be difficult to maintain. However, a more simple solution would be more suitable, for example a property to define the location of the cache.