Fwd: JMOD, native libraries and the packaging of JavaFX

[Mike Hearn]

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.audet at 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.
>
>