I don't think there's any politics to it. This sort of thing is scoped as part of Panama and funded already. Maybe there's a debate to be had about ordering of tasks, but that's a separate thing.
I'm working on a side project that might be relevant to this - I'll email you about it off list Sam. On Wed, May 09, 2018 at 07:09:27, Samuel Audet<samuel.au...@gmail.com>wrote: > Hi, > > Thanks for your interest! I'm always trying to do all that I can, but I'm > pretty much just one guy working on this part-time... > > Besides, this is the kind of thing that should be standardized in the JDK, > and Oracle isn't exactly low in resources ($9 billion net income last year, > wow), so what's the issue? I'm still trying to figure out the politics and > I doubt that one more page about something is going to make a great deal of > a difference... > > Samuel > > On 05/08/2018 09:40 PM, Mike Hearn wrote: > > 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. > >
