Eclipse Community Forums: Eclipse Platform » Loading Windows Native Code (DLLs)

Home » Eclipse Projects » Eclipse Platform » Loading Windows Native Code (DLLs)

Loading Windows Native Code (DLLs) [message #255611]

Fri, 25 June 2004 10:40

Eclipse User

Originally posted by: barlock.usx.ibmx.com

Porting some Eclipse 2 code to 3.0...Some Windows DLLs exist in the
os\win32\x86 of plug-in "A". I can run the project in debug mode and step
over the static loading of this DLL. No errors. However, when plug-in "B"
tries to run, I get an UnsatisfiedLinkError:

Caused by: java.lang.UnsatisfiedLinkError: Can't find library
DMWorkBenchJNI
(DMWorkBenchJNI.dll) in sun.boot.library.path or java.library.path

Has something changed between Eclipse 2 and 3 that would affect the ability
of plug-in B to find these DLLs?

Chris

Re: Loading Windows Native Code (DLLs) [message #255708 is a reply to message #255611]

Fri, 25 June 2004 14:43

Eclipse User

Originally posted by: barlock.usx.ibmx.com

> Porting some Eclipse 2 code to 3.0...Some Windows DLLs exist in the
> os\win32\x86 of plug-in "A". I can run the project in debug mode and step
> over the static loading of this DLL. No errors. However, when plug-in
"B"
> tries to run, I get an UnsatisfiedLinkError:
>
> Caused by: java.lang.UnsatisfiedLinkError: Can't find library
> DMWorkBenchJNI
> (DMWorkBenchJNI.dll) in sun.boot.library.path or java.library.path
>
> Has something changed between Eclipse 2 and 3 that would affect the
ability
> of plug-in B to find these DLLs?

I ran across this in the 3.0 Help. It was regarding Ant builds, but I don't
think that is significant:

Every time an Ant buildfile runs in Eclipse a new classloader is created.
Since a library can only be loaded by one classloader in Java, tasks making
use of native libraries could run into problems during multiple buildfile
runs. If the previous classloader has not been garbage collected at the time
the new classloader tries to load the native library, an exception is thrown
indicating the problem and the build fails. One way of avoiding this problem
is having the library load be handled by a class inside a plug-in library.
The task can make use of that class for accessing native methods. This way,
the library is loaded by the plug-in classloader and it does not run into
the load library conflict.

The key phrase: Since a library can only be loaded by one classloader in
Java...

This seems to support the idea that the native library is available only to
one of the plug-ins in my set (the one that loads it). True? Is there some
way to load the native code so that it can be shared among plug-ins?

Chris

Re: Loading Windows Native Code (DLLs) [message #255729 is a reply to message #255708]

Fri, 25 June 2004 16:32

Eclipse User

>
> Every time an Ant buildfile runs in Eclipse a new classloader is created.
> Since a library can only be loaded by one classloader in Java, tasks
making
> use of native libraries could run into problems during multiple buildfile
> runs. If the previous classloader has not been garbage collected at the
time
> the new classloader tries to load the native library, an exception is
thrown
> indicating the problem and the build fails. One way of avoiding this
problem
> is having the library load be handled by a class inside a plug-in library.
> The task can make use of that class for accessing native methods. This
way,
> the library is loaded by the plug-in classloader and it does not run into
> the load library conflict.
>
> The key phrase: Since a library can only be loaded by one classloader in
> Java...
>
> This seems to support the idea that the native library is available only
to
> one of the plug-ins in my set (the one that loads it). True? Is there
some
> way to load the native code so that it can be shared among plug-ins?
>

I would try just as for the Ant task access:
have one of your plugins load the native code and then make that plugin a
prerequisite for the other plugins that require use of the native code.
Then expose the required functionality/utility from that original plugin to
be available to all the other plugins.

HTH
Darins

Re: Loading Windows Native Code (DLLs) [message #255744 is a reply to message #255729]

Fri, 25 June 2004 16:01

Eclipse User

Originally posted by: barlock.usx.ibmx.com

> I would try just as for the Ant task access:
> have one of your plugins load the native code and then make that plugin a
> prerequisite for the other plugins that require use of the native code.
> Then expose the required functionality/utility from that original plugin
to
> be available to all the other plugins.

That could be a painful exercise. The plug-in that loads the native code
already is a prereq for the other, but all the native interfaces are not
isolated in this prereq plugin. Further, I didn't write this code (just
inherited it), so rewriting it has its challenges....I just want it to run
on Eclipse 3.0!

Chris

Re: Loading Windows Native Code (DLLs) [message #255932 is a reply to message #255611]

Sat, 26 June 2004 11:34

Eclipse User

Originally posted by: barlock.usDOT.ibmDOT.com

> Porting some Eclipse 2 code to 3.0...Some Windows DLLs exist in the
> os\win32\x86 of plug-in "A". I can run the project in debug mode and step
> over the static loading of this DLL. No errors. However, when plug-in
"B"
> tries to run, I get an UnsatisfiedLinkError:
>
> Caused by: java.lang.UnsatisfiedLinkError: Can't find library
> DMWorkBenchJNI
> (DMWorkBenchJNI.dll) in sun.boot.library.path or java.library.path
>
> Has something changed between Eclipse 2 and 3 that would affect the
ability
> of plug-in B to find these DLLs?

Solved! Plug-in "B" needs its own set of native code, of which I was not
aware.

Chris

Previous Topic:	EPL License?
Next Topic:	Log4j in an RCP app?

Goto Forum:

-=] Back to Top [=-

Current Time: Wed May 07 13:41:58 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter