Project Panama & dynamic library loading

[Ty Young]

On 9/6/19 11:04 PM, Henry Jen wrote:
>
>> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>
>>
>> On 9/6/19 8:12 PM, Henry Jen wrote:
>>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>
>>>>
>>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>>>>> Hi Ty, you are not forced to save the library path in the generated extracted jar with the --record-library-path  option. If you can also omit that option, and then set java.library.path (or LD_LIBRARY_PATH) accordingly when it's time to run your application.
>>>> Can java.library.path be modified in code or does it have to be a launch option to work? I've always assumed it was a launch option only and haven't thought much of it.
>>>>
>>> It’s a launch option, and thus can adapt to your deployment environment.
>>
>> There is no specific "deployment environment". If you were to create bindings in Arch Linux you'd need to specify the pathing for every other Linux distro and even Windows, resulting in not working on more obscure Linux distros and two different builds between Windows and Linux. If you could just dynamically add the paths that'd make this so much easier…
>>
> In this case, you are looking for a sane system default, which as Mauricio mentioned, we need to look for better ways. OpenJDK by default is not providing proper value across various Linux distros. But java.library.path provide a way to accommodate that. Also, it’s possible to
>
> Usually, a Linux distro will have a customized OpenJDK package has customized default.
>
>>>> It would really be nice if the whole thing was dynamic with zero hardcoded values, even if startup time was sacrificed due to library searching. With how fragmented the Linux ecosystem specifically is, there is never any guarantee that any hardcoded values(s) will work for all Linux distros.
>>>>
>>> Dynamic loading is supported since beginning, typical code snippet is like following.
>>>
>>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), "tensorflow");
>>> libTF = Libraries.bind(c_api_h.class, lib);
>>>
>>> As long as you define java.library.path to include correct search path for the native library, it should work just fine.
>>
>> The search path being static is the problem here. Without a dynamic way to add libraries easily things will blowup real badly.
>>
>>
> With jextract, combine -L option with -l and —record-library-path, the provided search paths is saved to be used for runtime. I know it’s not the same as an API, but provide the behavior you described?


Path(s) or path? None of the examples that I see show multiple library 
paths being specified. If it is possible then sure, I guess. It's still 
hardcoded and could break but at least I'll have the three major distros 
covered and don't have to copy libraries around...


That said, can a Windows path be specified alongside the Linux paths?


>
> Cheers,
> Henry
>