RFR: 8067951: System.loadLibrary cannot find library when path contains quoted entry
ivan.gerasimov at oracle.com
Fri Dec 26 10:02:45 UTC 2014
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:
On 25.12.2014 17:46, Ivan Gerasimov wrote:
> Hi Stuart!
> On 24.12.2014 22:33, Stuart Marks wrote:
>> Hi Ivan,
>> It's not clear to me that quoting should be applied at this level. On
>> Unix, quotes are stripped by the shell at the time the command line
>> is split into arguments, so the values should be treated literally
>> without further quote processing.
> That's correct.
> At least bash does not recognize quoted entries in PATH.
> Thus, we only need to deal with quotes on Windows, so I updated the
>> The referenced blog post at MSDN talks about Windows, which passes
>> the entire command string to the program, which then is responsible
>> for splitting it into arguments or otherwise parsing it. This seems
>> to occur in the file
>> If the logic in that file is mishandling quotes, it seems like the
>> fix ought to be applied there.
> java.library.path variable is set from the PATH env variable, among
> other sources.
> It can be redefined through command line argument, but it's a
> different story.
> In this particular case it's not related to cmdtoargs.c.
> On Windows PATH may contain quoted entries.
> They don't have to be quoted (unless they really contain a semicolon),
> but sometimes they are.
> I guess, people may enclose the path in quotes for no particular
> reason, just because it doesn't hurt.
>> In addition, this change simply strips quotes that happen to occur at
>> the boundaries of substrings between path separators. It doesn't do
>> any actual quoting, that is, protecting the path separator character
>> so that it can be used as part of an actual path instead of as a
>> separator. (But I'm not sure that's actually a supported case
>> anyway.) Simply stripping quotes seems wrong.
> I propose only a partial solution for the only edge case -- when an
> entry of PATH is entirely quoted.
> Later, we may want to implement more complex logic, which deals with
> semicolons in paths and with partially quoted string.
> But in that case the full logic should be well documented somewhere.
>> Unfortunately there are no details in the bug report JDK-8067951, so
>> I can't tell what the real problem is.
> Basically, the complain was about skipping quoted paths from PATH when
> looking for dll's.
> Here's the updated webrev:
> Sincerely yours,
More information about the core-libs-dev