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.

Bug 118951 - Add ability to wrap java libraries with both 32 and 64 bit native libraries
Summary: Add ability to wrap java libraries with both 32 and 64 bit native libraries
Status: RESOLVED WONTFIX
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker with 1 vote (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-15 23:02 UTC by tkunicki
Modified: 2008-12-22 11:53 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tkunicki 2007-10-15 23:02:36 UTC
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).
Comment 1 Jesse Glick 2007-10-16 00:49:29 UTC
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.
Comment 2 tkunicki 2007-10-17 00:17:52 UTC
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.
 
Comment 3 Jesse Glick 2007-10-17 21:42:11 UTC
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.
Comment 4 tkunicki 2007-11-05 07:14:44 UTC
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.
Comment 5 tkunicki 2007-11-05 07:26:38 UTC
ok, using the property "os.name" looks to be problematic (especially with Windows). grr...