This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The current restriction of placing all native libraries in modules/lib is limiting. I'm attempting to generate module wrappers for Java API extensions with both 32 and 64 bit native libraries (JOGL 1.1.0 and Java3D 1.5.1). Due to the native library naming semantics imposed by System.loadLibrary(...) both 32 and 64 bit native libraries have the same names. With the current NetBeans module ClassLoader all native libraries must exist in modules/lib. While I can generate a single module wrapper supporting different operating systems I can't generate a single module wrapper in the same module cluster supporting 32 or 64 bit execution on the same operating system. One potential solution would be to modify the findLibraryName() function of org.netbeans.StandardModule$OneModuleClassLoader to search for platform specific directories (i.e. for the windows OS, search modules/lib/windows-i586 or modules/lib/windows-amd64).
No plans to introduce such a strategy in SM.OMCL; there is no universal definition of what the desirable platforms would be. Possible workarounds: 1. Patch JOGL/Java3D Java code to load more distinctive lib names acc. to platform. 2. Load the libs in a separate class loader you write, with whatever load order / locations you prefer, and delegate to classes loaded from this loader using interfaces and reflection. 3. Create separate library wrappers for 32- and 64-bit systems (built in separate clusters of course). 4. Rename the DLLs to e.g. jogl32.dll, load them directly from NB module code in the wrapper module (asking for "jogl32" etc.), and also add an empty DLL jogl.dll which could be loaded as a no-op so that calls to lL("jogl") would not fail.
I hope your rejection of this issue was based on the merits of the proposed solution and not a denial that this is a legitimate issue for developers using the NetBeans platform who want develop code with (seamless) use of Java API extensions with 32 and 64 bit native libraries adhering to lL(...) naming semantics (which unfortunately ignores 32 vs 64 differences). For my own sanity it's going to be easiest to build on a modified NB platform with changes to SM.OMCL. I think I'll just add searches for "modules/lib" for 32 bit native libraries and "modules/lib64" for 64 bit native libraries based on the executing JRE. As 64 bit platforms become the standard I can't imaging we're the only development group that will have this issue. Regarding your proposed workarounds: > 1. Patch JOGL/Java3D Java code to load more distinctive lib names acc. to platform. Would then need 32 bit or 64 bit aware java libraries or conditional lL(...) or nested lL(...) calls. I think expecting a user to modify and recompile Java API extenstions just for clean use in NetBeans is a little excessive (JOGL, Java3D, JAI, JAI ImageIO, ...). > 2. Load the libs in a separate class loader you write, with whatever load order / locations you prefer, and delegate to classes loaded from this loader using interfaces and reflection. All JOGL calls in source would have to have packages and/or class names changed to force them through delegating interfaces and then in turn through the delegating ClassLoader. Other jars wrapped by NetBeans modules with dependencies on JOGL and wouldn't have access to JOGL unless modified and recompiled to use delegating interfaces... With this solution I am unable to use existing libraries with Java API extension dependencies w/o modifying and recompiling them. Would need jars for use in NetBeans and jars for use outside NetBeans... > 3. Create separate library wrappers for 32- and 64-bit systems (built in separate clusters of course). Possible but again as in 1) requires shipping a 32 bit and 64 bit aware java code base independent of the JRE ("Java: build-once run everywhere"?). > 4. Rename the DLLs to e.g. jogl32.dll, load them directly from NB module code in the wrapper module (asking for "jogl32" etc.), and also add an empty DLL jogl.dll which could be loaded as a no-op so that calls to lL("jogl") would not fail. Empty native libraries still have to be valid libraries (and then either 32 or 64 bit) in order to be loaded w/o error with lL(...). This leaves me with the original issue.
Yes, the proposed solution is what was rejected, which is why I attempted to offer some workarounds. Otherwise would be INVALID. Regarding #1, I think really the proper solution is in the extensions which load the native libraries to begin with, which would preferably be patched (for the long term, i.e. upstream) to name the libraries distinctively, then use conditional calls to loadLibrary based on calls to System.getProperty. The loader of the native library is always in the best position to decide which variant to use. (32-bit vs. 64-bit for a single OS family such as Windows is a common differentiator, but some libraries need to differentiate based on more specific OS choices, such as XP vs. Vista, or by GNOME vs. KDE vs. XToolkit, etc.) Regarding #2, there is no need to use different interface names. Will not work well for classes, but should be OK for interfaces. See java.lang.reflect.Proxy. Cumbersome to set up, however. Regarding #3, yes - you are not shipping portable code anyway, since it is using native libraries. IIRC when you get a native-based Java extension for official download you pick an architecture and get just the native library for that architecture, so NB is doing no worse in this respect. Regarding #4 - sorry, just a thought. May work for some library formats such as ELF; I know nothing about DLL formats specifically. You can also place the DLLs in some other dirs besides modules/lib, then add the correct version of the dir (based on the current processor architecture) to the $LD_LIBRARY_PATH / %PATH% in the application launcher. This is probably the simplest workaround.
It appears the requested functionality was proposed previously, see http://platform.netbeans.org/articles/installation.html. Under "Target systems and Logical Layout" the following behavior was proposed: == START COPY == lib: contains native JNI libraries and basic boot files. The naming policy of the libraries is in hands of the modules, as that it has worked well enough till now. If it proves unsufficient following conventions shall be obeyed: There are subdirectories under the lib directory that reflect the architecture (e.g. i386, obtained via System.getProperty ("os.arch")) and possibly also subdirectory identifying the system (e.g. i386/linux, obtained via System.getProperty ("os.name").toLowerCase ()). When the system is looking for a particular library it scans the deepest directories first and then the shallow ones (lib/i386/linux, lib/i386, lib). == END COPY == It appears it could be implemented under modules/lib and provide backwards compatibility with existing modules relying solely on modules/lib.
ok, using the property "os.name" looks to be problematic (especially with Windows). grr...