On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >If a .dll depends on another .dll, then it must be found in
> >the system-specific, on Windows the Path (on *nix,
> >LD_LIBRARY_PATH usually).
>
> So to be platform "independend" you use both?
> <java>
> <env value="${thePath}" key="PATH"/>
> <env value="${thePath}" key="LD_LIBRARY_PATH"/>
> </java>
Jokes appart, to really be as platform "independent" as one can be
when not doing 100% pure Java, using java.library.path only is the way
to go. This implies using JNI native libraries which are mostly
"self-containted", i.e. don't depend on other native libs (.dll, .so,
etc... Steve ;-) except for system libraries found by default.
But even Path/LD_LIBRARY_PATH can be hacked around I think, as I've
seen one clever developer do, by "pre-emptive" loading of the libs
depended upon using System.loadLibrary... You need JNI lib Top, which
depends on Middle, which depends on Bottom, and by
System.loadLibrary("Bottom") first explictly, then "Middle", and then
finally "Top", it seems to work and "Top" has all its dependencies
already satified. Weird, I know, but this developer was using this
hack to work around WebStart limitations regarding Java apps that
required native JNI libs. Not recommended for the faint of heart ;-)
Some developers are too clever for their own good ;-))) I'd never have
thought of this scheme. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
