Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loading Issues with Multiple Class Loaders #7

Closed
michaelahlers opened this issue May 18, 2014 · 5 comments
Closed

Loading Issues with Multiple Class Loaders #7

michaelahlers opened this issue May 18, 2014 · 5 comments
Assignees
Labels

Comments

@michaelahlers
Copy link
Contributor

Particularly when working in hosted environments (like IDEs), where different class loaders may be used between one run and the next, developers will encounter errors like the following:

java.lang.UnsatisfiedLinkError: Native Library /private/var/folders/d1/3323g01s4bn3ntx1g_yzm_dc0000gn/T/1621396069368823549/nu/pattern/opencv/osx/x86_64/libopencv_java249.dylib already loaded in another classloader
    at java.lang.ClassLoader.loadLibrary0(test.sc5011658132463706269.tmp:1891)
    at java.lang.ClassLoader.loadLibrary(test.sc5011658132463706269.tmp:1843)
    at java.lang.Runtime.loadLibrary0(test.sc5011658132463706269.tmp:866)
    at java.lang.System.loadLibrary(test.sc5011658132463706269.tmp:1115)
    at nu.pattern.OpenCV$Loader.loadLibrary(test.sc5011658132463706269.tmp:221)
    at nu.pattern.OpenCV$Loader.access$100(test.sc5011658132463706269.tmp:156)
    at nu.pattern.OpenCV.loadLibrary(test.sc5011658132463706269.tmp:153)
    at #worksheet#.get$$instance$$res1(test.sc5011658132463706269.tmp:5)
    at #worksheet#.#worksheet#(test.sc5011658132463706269.tmp:27)
@michaelahlers michaelahlers self-assigned this May 18, 2014
@michaelahlers
Copy link
Contributor Author

@michaelahlers
Copy link
Contributor Author

See the JNI 1.2 specification.

@michaelahlers
Copy link
Contributor Author

If sys_paths is not set to null, and the library is loaded by absolute path, this problem goes away. Comments by Holger Hoffstätte on a similar topic suggest stale class loaders are not garbage collected—possibly due to the reflection hack.

@michaelahlers
Copy link
Contributor Author

michaelahlers pushed a commit that referenced this issue May 19, 2014
… two different use cases. See comments on issue #7.
michaelahlers pushed a commit that referenced this issue May 19, 2014
@michaelahlers
Copy link
Contributor Author

Ultimately, there are no good solutions—only partial workarounds. There are now two loader methods on nu.pattern.OpenCV. Both are now safe to call spuriously, and give developers a choice between adding the native binary to java.library.path at runtime and giving “shared” access, or forcibly loading a different copy of the library (which is not blocked by guards against the static ClassLoader.loadedLibraryNames collection).

michaelahlers pushed a commit that referenced this issue May 19, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant