Thanks Samuel! I wasn't familiar with JavaCPP before, that sounds like a great project.
You are right that there's a lot of overlap here with other efforts, and that standardising some basic things like JAR locations is the right place to begin. I suspect a JEP requires actual changes to OpenJDK to be valid, so a JEP that just proposes whatever JavaCPP does as a convention wouldn't go anywhere. Perhaps integrating JavaCPP's loading mechanism with JavaFX is a good next step, as the community can then learn about it through that and may follow the lead of JavaFX. I suppose someone would have to convince Kevin Rushforth. Samuel - what you could also do is write a one-page "standards document" that describes where exactly JavaCPP puts things on the file system, the algorithm it uses for selecting locations and cache keys, etc, so other projects that unpack libraries to disk can share the same cache location. That would lay the groundwork for it either becoming a widely adopted convention, and/or becoming a future Java standard, and/or being encapsulated in a NativeLoader in future if such an API is added to the Java platform. The Loader class could also be split out into a separate module/project. The Panama/nicl JEP makes mention of improvements to native code loading and discovery. It seems most of the effort in Panama is currently related to vector support. If I were Mr Rose or Mr Reinhold I'd be tempted to try and un-bundle better loading from the rest of the nicl project so it can ship earlier. A NativeLoader style API would be a smaller change to the JVM than all of the binding layer together.
