RFR: 8067951: System.loadLibrary cannot find library when path contains quoted entry

[Peter Levart]

On 01/03/2015 06:39 PM, Ivan Gerasimov wrote:
>
> On 03.01.2015 11:50, Alan Bateman wrote:
>> On 26/12/2014 10:02, Ivan Gerasimov wrote:
>>> Hi!
>>>
>>> I changed my mind about handling only entirely quoted entries in PATH.
>>> The webrev was updated.
>>>
>>> Now, on Windows paths with quoted parts are supported.
>>> If the quoted fragment of the path contains the delimiter -- ';', it 
>>> will be preserved as a part of the path.
>>>
>>> This is consistent with how Windows command prompt resolves PATH.
>>>
>>> The regression test was extended to cover new functionality.
>>>
>>> The webrev was updated in place:
>>> http://cr.openjdk.java.net/~igerasim/8067951/2/webrev/
>>>
>> I assume it can't be very common to quote individual elements in this 
>> manner, otherwise we would have had bug reports on this many years ago.
>
> Some applications add their paths to PATH quoted, but these paths are 
> not very common locations to load dlls from.
> In the blog referenced earlier I saw this comment: "Turned out the 
> DirectX SDK inserted its Utilities\Bin\x86 folder at the start of my 
> PATH and used quotes."
>
>> I agree we should probably support this and the approach in your 
>> updated webrev looks reasonable to me. One thing to consider is 
>> refactoring it so that the Windows specific handling is the Windows 
>> implementation of  ClassLoaderHelper rather than in initializePaths.
>>
> Currently, there are tree variants of ClassLoaderHelper: for Windows, 
> for Unix and for MacOS.
> We have to either duplicate code in Unix and MacOS realizations, or 
> introduce another Helper class for initializing paths only, which 
> would have only two realizations: for Windows and all Unixes.
>
> I would choose the second approach.
> What would you suggest?

Hi Ivan,

There were other cases where one wanted to consolidate duplicated code, 
but couldn't easily because of subtle differences among OS platforms 
(UNIXProcess is one of such cases). Perhaps we need something like this:

http://cr.openjdk.java.net/~plevart/misc/OS/webrev/

With this compile-time mechanism, one can use switch or if statements in 
common class to cover subtle differences and only divide code into OS 
platform specific classes where the bulk of it differs.

What do you think?

Regards, Peter

>
> Sincerely yours,
> Ivan
>