NativeLibrary tries to load natives from the JRE extension "system" search paths. The JRE extension search path was historically used by SUN's JOGL 1 to store natives. JogAmp should stop supporting the use of the "system" JRE extension mechanism it to prevent the JogAmp modules to load old SUN JOGL 1 natives by mistake. Fixing this bug will cause minor public API changes to NativeLibrary open by removing the searchSystemPathFirst booleans. http://jogamp.org/deployment/jogamp-current/javadoc/gluegen/javadoc/com/jogamp/common/os/NativeLibrary.html
Branch to merge: https://github.com/xranby/gluegen/tree/bug1194 Bug 1194: NativeLibrary: Remove dangerous search paths using the JRE extension mechanism NativeLibrary: API change: Removed searchSystemPathFirst argument to the open and enumerateLibraryPaths methods. Removed the generic sun.boot.library.path system path and the MacOS specific Frameworks paths from enumerateLibraryPaths. JNILibLoaderBase, PlatformPropsImpl & TestElfReader01: Updated to handle the NativeLibrary API change. This change will prevent JogAmp modules to pickup and load unsupported and old SUN JOGL 1 natives that may have been deployed with the JRE.
GlueGen looks for the native libraries in some directories used by the extension mechanism under OS X (/Library/Frameworks/ and /System/Frameworks/) probably to comply with the debatable Apple's choice of shipping Java3D 1.3 + JOGL 1 with OS X. Moreover, the extension mechanism has been removed from Java 1.9 and is already deprecated. http://docs.oracle.com/javase/8/docs/technotes/guides/extensions/index.html "This feature has been deprecated and will be removed in a future release." Finally, this mechanism was a source of conflicts and the developers can still use the Java library path to indicate another location for the native libraries. There are still some hacky solutions to modify it at runtime.
d12e4d4ea279998b27457691038e709879dcaca6 NativeLibrary: Remove dangerous search paths using the JRE extension mechanism NativeLibrary: API change: Removed searchSystemPathFirst argument to the open and enumerateLibraryPaths methods. Removed the generic sun.boot.library.path system path and the MacOS specific Frameworks paths from enumerateLibraryPaths. JNILibLoaderBase, PlatformPropsImpl & TestElfReader01: Updated to handle the NativeLibrary API change. This change will prevent JogAmp modules to pickup and load unsupported and old SUN JOGL 1 natives that may have been deployed with the JRE. 63f11f7ef0a4c52187dc26e641f48e6a5c864815 Merge branch 'bug1145' of https://github.com/xranby/gluegen 7d4b18401ff0a1a6b72237f8c482007fbd2623dd Merge branch 'bug1194' of https://github.com/xranby/gluegen Conflicts: src/java/com/jogamp/common/os/NativeLibrary.java Due to commit for Bug 1145, bf4d8786cb732d86db333b43020ecf0af27f60bf
6557eedd0f0ec98d743c762a698bb028e88a9e16 Bug 1194: Reinstate system-lib search for NativeLibrary.open(..) and PlatformPropsImpl.findSysLib(..). This patch partially reverts of commit d12e4d4ea279998b27457691038e709879dcaca6. NativeLibrary.open(..) requires search of system libraries, since it loads the actual 'tool library' for which we generate the JNI binding. The 'tool library' is preferably the system wide installed version, e.g. libGL.so etc. PlatformPropsImpl.findSysLib(..) also requires finding system libraries as needed for PlatformPropsImpl.queryElfFile(..), i.e. using libjava.so etc. Only the JNI 'glue library', glueing java calls to the 'tool library', shall not use the system wide library search since we shall only use JogAmp provided instances here. This patch also reinstates binary compatibility w/ prev. GlueGen JARs since NativeLibrary.enumerateLibraryPath(..) is public. +++ Further more 'NativeLibrary.enumerateLibraryPath(..)' now adds OSX system framework search _before_ the user path in case 'searchSystemPath && searchSystemPathFirst'. Original code always added this search to the end, which does not match the intended behavior (-> bug).
please validate fix and set status accordingly or reopen - thx!
Isn't there a risk of loading JOGL 1 if we still look at those system framework under OS X?