Add support for finding libraries with multi component versions on Linux #76
Conversation
| @@ -448,22 +447,14 @@ public String getName() { | |||
| /** | |||
| * A {@link Platform} subclass representing the Linux operating system. | |||
| */ | |||
| private static final class Linux extends Supported { | |||
| static final class Linux extends Supported { | |||
|
|
|||
There was a problem hiding this comment.
package private is for testing I guess ?
| import java.util.Arrays; | ||
| import java.util.LinkedList; | ||
| import java.util.List; | ||
| import java.util.*; |
There was a problem hiding this comment.
We prefer that imports be explicit until they get too unwieldy (20 imports).
| return bestMatch != null ? bestMatch : mapLibraryName(libName); | ||
| } | ||
|
|
||
| private static int compareVersions(int[] version1, int[] version2) | ||
| { |
There was a problem hiding this comment.
Our convention is brace-inline, not brace-following.
| import java.util.Collections; | ||
|
|
||
| public class PlatformTest | ||
| { |
There was a problem hiding this comment.
Our convention is brace-inline, not brace-following. The rest of the file is brace-following also.
|
Fixed the brace style and import issues |
|
Thank you! |
| version[i - 1] = Integer.parseInt(parts[i]); | ||
| } | ||
| } | ||
| matches.put(file.getAbsolutePath(), version); |
There was a problem hiding this comment.
This loses the ordering of the library paths and is proving to be problematic for me. I have both /lib64/librt.so.1 and /lib/librt.so.1, with /lib64 before /lib. I'm going to look at stripping out the /lib part, but it's coming from the "java.library.path" system property so it's likely to be there for others, too. In any event, since the HashMap here loses the ordering, /lib/librt.so1 actually comes before /lib64/librt.so.1 during the best match scan. Since they have the same version number, there's no way for the /lib64 version to win and I wind up with an UnsatisfiedLinkError: /lib/librt.so.1: wrong ELF class: ELFCLASS32.
There was a problem hiding this comment.
Simple fix is to use a LinkedHashMap instead of a HashMap for the matches Map. That way insertion order will be retained and the original behaviour should be restored. The only caveat is that, continuing on your example, if lib contains a more precies version than lib64 that the lib version will get picked.
Ideally the library loading code should filter out libraries that are not using the correct ABI I guess. That's new functionality that the old code did not do either though.
There was a problem hiding this comment.
Great. I'd be happy just getting the sort order back. It appears the java.library.path changes were made with JDK 7 to include both 32-bit and 64-bit paths. While I'm not convinced that was a worthwhile change, it's something we'll have to cope with.
No description provided.