ImageJ

Loading native DLLs into InageJ

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Burger Wilhelm

Loading native DLLs into InageJ

Hello all, I wonder if someone can help me with the following technical problem:

I am loading a native DLL into ImageJ (e.g., for using OpenGL or OpenCV, under Windows). Everything works nicely if I execute precompiled plugins that use the native methods in that DLL, even repeatedly. However, when I execute the same plugin with "Compile and run" I get the following errors:

java.lang.UnsatisfiedLinkError: Native Library XXX.dll already loaded in another classloader

As a remedy I tried to load the DLL by a static block of a special class, placed in a separate JAR file (read somewhere that this might help), and referenced that class "by name" - but with no avail.

I am not sure I understand well enough how class loaders and DLLs work together but assume somebody else must have encountered the same mess before. Any hints or suggestions for how to solve this?

Thanks much,
Wilhelm

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

John Hayes

Re: Loading native DLLs into InageJ

Hi Wilhelm,

It's been a while since I looked at the codebase, but I believe the IJ startup classloader is going to be different than the one used during "compile and run" and that would be consistent with your error message. You can check for references to each by putting in your plugin code by logging/printing something like "Your_Plugin.getClass().getClassLoader()" under the working and non-working conditions to discriminate them.

Are you explicitly loading the DLL from your plugin? If so, what is that code?

Best,

John

Le 23 sept. 2015 à 10:19, Burger Wilhelm a écrit :

> Hello all, I wonder if someone can help me with the following technical problem:
>
> I am loading a native DLL into ImageJ (e.g., for using OpenGL or OpenCV, under Windows). Everything works nicely if I execute precompiled plugins that use the native methods in that DLL, even repeatedly. However, when I execute the same plugin with "Compile and run" I get the following errors:
>
> java.lang.UnsatisfiedLinkError: Native Library XXX.dll already loaded in another classloader
>
> As a remedy I tried to load the DLL by a static block of a special class, placed in a separate JAR file (read somewhere that this might help), and referenced that class "by name" - but with no avail.
>
> I am not sure I understand well enough how class loaders and DLLs work together but assume somebody else must have encountered the same mess before. Any hints or suggestions for how to solve this?
>
> Thanks much,
> Wilhelm
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Burger Wilhelm

Re: Loading native DLLs into InageJ

Hello John,

thanks for the quick response. No, I am not loading the DLL directly from my plugin but through a static block in another class. Here is my (minimalistic) setup:

First, there is this 'DllLoader' class which I placed in a separate JAR file. It should not be reloaded when a plugin is loaded:

// ----------------------------------------------------------
public class DllLoader {
static {
String dllname = "opencv_java300";
System.out.println("DllLoader: loading native library");
try {System.loadLibrary(dllname);}
catch (UnsatisfiedLinkError ule) {
System.out.println("Failed to load " + dllname);
ule.printStackTrace(System.out);}
}

public static void main(String[] args) {}
}
// ----------------------------------------------------------

And this is my stripped-off ImageJ test plugin:

// ----------------------------------------------------------
import ij.IJ;
import ij.plugin.PlugIn;

public class Dll_Load_Test implements PlugIn {

public void run(String args) {
loadDll();
// use native methods ...
}

void loadDll() {
try {
Class.forName("DllLoader");
} catch (ClassNotFoundException e) {
System.out.println("DllLoader not found!");
e.printStackTrace(System.out);
}
}
}
// ----------------------------------------------------------

Does this make any sense to you?

--Wilhelm

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> John Hayes
> Sent: Wednesday, September 23, 2015 4:30 PM
> To: [hidden email]
> Subject: Re: Loading native DLLs into InageJ
>
> Hi Wilhelm,
>
> It's been a while since I looked at the codebase, but I believe the IJ startup
> classloader is going to be different than the one used during "compile and
> run" and that would be consistent with your error message. You can check
> for references to each by putting in your plugin code by logging/printing
> something like "Your_Plugin.getClass().getClassLoader()" under the working
> and non-working conditions to discriminate them.
>
> Are you explicitly loading the DLL from your plugin? If so, what is that code?
>
> Best,
>
> John
>
> Le 23 sept. 2015 à 10:19, Burger Wilhelm a écrit :
>
> > Hello all, I wonder if someone can help me with the following technical
> problem:
> >
> > I am loading a native DLL into ImageJ (e.g., for using OpenGL or OpenCV,
> under Windows). Everything works nicely if I execute precompiled plugins
> that use the native methods in that DLL, even repeatedly. However, when I
> execute the same plugin with "Compile and run" I get the following errors:
> >
> > java.lang.UnsatisfiedLinkError: Native Library XXX.dll already loaded in
> another classloader
> >
> > As a remedy I tried to load the DLL by a static block of a special class, placed
> in a separate JAR file (read somewhere that this might help), and referenced
> that class "by name" - but with no avail.
> >
> > I am not sure I understand well enough how class loaders and DLLs work
> together but assume somebody else must have encountered the same mess
> before. Any hints or suggestions for how to solve this?
> >
> > Thanks much,
> > Wilhelm
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Robert Dougherty

Re: Loading native DLLs into InageJ

In reply to this post by Burger Wilhelm

Wilhelm,

Have a look at "Save As Movie" by Qingzong TSENG. It uses OpenCV and ffmpeg to save movies. Here is the experiment I just did on a Windows 64-bit system.

1. Install Save As Movie per the instructions. (McAfee warned me about opencv.x86_64.jar. Not sure what to think about that...)
2. Verify that it works: Plugins/Input-Ouput/Save as Move exists and somewhat functions. (There may be missing codec issues. .avi/H.264 worked for me.)
3. Delete SaveAsMovie_.jar. This removes the class file SaveMovie.class, which was in the folder ffmpegMovieIO in the .jar, as well as the plugins.config file that installed ffmpegIO.saveMovie on the menus.
4. Open the source, SaveMove.java from the "Save As Movie" web page, comment out the first line, "package ffmpegIO;", change the class name from SaveMove to SaveMovie_ , and save it in the plugins folder as SaveMove_.java
5. Try Compile and Run... SaveMovie_
6. Try it again. Nothing different seems to happen.

Of course, it would be best to leave the package structure and the menus as they were. I just wanted to show that Compile and Run can work this way.

Bob

On Sep 23, 2015, at 7:19 AM, Burger Wilhelm wrote:

Robert Dougherty, Ph.D.
President, OptiNav, Inc.
1414 127th Place NE #106
Bellevue, WA 98005
Tel. (425)891-4883
FAX (425)467-1119
www.optinav.com
[hidden email]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Burger Wilhelm

Re: Loading native DLLs into InageJ

Hello Bob,

thanks for the interesting hint - I had not been aware of any other plugin using the OpenCV library. I installed as instructed and it works flawlessly as far as I can tell, even going through compile-and-run.

The difference seems to be that "SaveMovie" uses another OpenCV/Java package that is based on javacpp -- which apparently defines its own loading scheme. I have already contacted the author for more information, particularly if it uses the latest OpenCV 3.0 release.

I am still interested in how to robustly load a native DLL into ImageJ, since I experienced the very same problem with OpenGL.

Thanks again,
Wilhelm

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Robert Dougherty
> Sent: Wednesday, September 23, 2015 9:45 PM
> To: [hidden email]
> Subject: Re: Loading native DLLs into InageJ
>
> Wilhelm,
>
> Have a look at "Save As Movie" by Qingzong TSENG. It uses OpenCV and
> ffmpeg to save movies. Here is the experiment I just did on a Windows 64-
> bit system.
>
> 1. Install Save As Movie per the instructions. (McAfee warned me about
> opencv.x86_64.jar. Not sure what to think about that...)
> 2. Verify that it works: Plugins/Input-Ouput/Save as Move exists and
> somewhat functions. (There may be missing codec issues. .avi/H.264 worked
> for me.)
> 3. Delete SaveAsMovie_.jar. This removes the class file SaveMovie.class,
> which was in the folder ffmpegMovieIO in the .jar, as well as the
> plugins.config file that installed ffmpegIO.saveMovie on the menus.
> 4. Open the source, SaveMove.java from the "Save As Movie" web page,
> comment out the first line, "package ffmpegIO;", change the class name
> from SaveMove to SaveMovie_ , and save it in the plugins folder as
> SaveMove_.java
> 5. Try Compile and Run... SaveMovie_
> 6. Try it again. Nothing different seems to happen.
>
> Of course, it would be best to leave the package structure and the menus as
> they were. I just wanted to show that Compile and Run can work this way.
>
> Bob
>
> On Sep 23, 2015, at 7:19 AM, Burger Wilhelm wrote:
>
> > Hello all, I wonder if someone can help me with the following technical
> problem:
> >
> > I am loading a native DLL into ImageJ (e.g., for using OpenGL or OpenCV,
> under Windows). Everything works nicely if I execute precompiled plugins
> that use the native methods in that DLL, even repeatedly. However, when I
> execute the same plugin with "Compile and run" I get the following errors:
> >
> > java.lang.UnsatisfiedLinkError: Native Library XXX.dll already loaded in
> another classloader
> >
> > As a remedy I tried to load the DLL by a static block of a special class, placed
> in a separate JAR file (read somewhere that this might help), and referenced
> that class "by name" - but with no avail.
> >
> > I am not sure I understand well enough how class loaders and DLLs work
> together but assume somebody else must have encountered the same mess
> before. Any hints or suggestions for how to solve this?
> >
> > Thanks much,
> > Wilhelm
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> Robert Dougherty, Ph.D.
> President, OptiNav, Inc.
> 1414 127th Place NE #106
> Bellevue, WA 98005
> Tel. (425)891-4883
> FAX (425)467-1119
> www.optinav.com
> [hidden email]
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Mark Hiner

Re: Loading native DLLs into InageJ

Hi Wilhelm,

If you use Fiji there is some support for automatically managing native
libraries[1]. You may notice in Fiji that Compile and Run is disabled, I
believe specifically because of the desire to avoid multiple ClassLoaders -
although you can still write and run Java classes in the script editor[2].

We recently did some work building an ITK bridge in ImageJ[3][4], so
looking at that project may be helpful to you.

Best,
Mark

[1] http://imagej.net/Developing_using_native_libraries#Support_in_ImageJ
[2] http://imagej.net/Scripting_Help
[3] https://github.com/imagej/imagej-itk
[4] http://imagej.net/ITK

On Thu, Sep 24, 2015 at 6:24 AM, Burger Wilhelm <
[hidden email]> wrote:

> Hello Bob,
>
> thanks for the interesting hint - I had not been aware of any other plugin
> using the OpenCV library. I installed as instructed and it works flawlessly
> as far as I can tell, even going through compile-and-run.
>
> The difference seems to be that "SaveMovie" uses another OpenCV/Java
> package that is based on javacpp -- which apparently defines its own
> loading scheme. I have already contacted the author for more information,
> particularly if it uses the latest OpenCV 3.0 release.
>
> I am still interested in how to robustly load a native DLL into ImageJ,
> since I experienced the very same problem with OpenGL.
>
> Thanks again,
> Wilhelm
>
>
>
> > -----Original Message-----
> > From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> > Robert Dougherty
> > Sent: Wednesday, September 23, 2015 9:45 PM
> > To: [hidden email]
> > Subject: Re: Loading native DLLs into InageJ
> >
> > Wilhelm,
> >
> > Have a look at "Save As Movie" by Qingzong TSENG. It uses OpenCV and
> > ffmpeg to save movies. Here is the experiment I just did on a Windows
> 64-
> > bit system.
> >
> > 1. Install Save As Movie per the instructions. (McAfee warned me about
> > opencv.x86_64.jar. Not sure what to think about that...)
> > 2. Verify that it works: Plugins/Input-Ouput/Save as Move exists and
> > somewhat functions. (There may be missing codec issues. .avi/H.264 worked
> > for me.)
> > 3. Delete SaveAsMovie_.jar. This removes the class file SaveMovie.class,
> > which was in the folder ffmpegMovieIO in the .jar, as well as the
> > plugins.config file that installed ffmpegIO.saveMovie on the menus.
> > 4. Open the source, SaveMove.java from the "Save As Movie" web page,
> > comment out the first line, "package ffmpegIO;", change the class name
> > from SaveMove to SaveMovie_ , and save it in the plugins folder as
> > SaveMove_.java
> > 5. Try Compile and Run... SaveMovie_
> > 6. Try it again. Nothing different seems to happen.
> >
> > Of course, it would be best to leave the package structure and the menus
> as
> > they were. I just wanted to show that Compile and Run can work this way.
> >
> > Bob
> >
> > On Sep 23, 2015, at 7:19 AM, Burger Wilhelm wrote:
> >
> > > Hello all, I wonder if someone can help me with the following technical
> > problem:
> > >
> > > I am loading a native DLL into ImageJ (e.g., for using OpenGL or
> OpenCV,
> > under Windows). Everything works nicely if I execute precompiled plugins
> > that use the native methods in that DLL, even repeatedly. However, when I
> > execute the same plugin with "Compile and run" I get the following
> errors:
> > >
> > > java.lang.UnsatisfiedLinkError: Native Library XXX.dll already loaded
> in
> > another classloader
> > >
> > > As a remedy I tried to load the DLL by a static block of a special
> class, placed
> > in a separate JAR file (read somewhere that this might help), and
> referenced
> > that class "by name" - but with no avail.
> > >
> > > I am not sure I understand well enough how class loaders and DLLs work
> > together but assume somebody else must have encountered the same mess
> > before. Any hints or suggestions for how to solve this?
> > >
> > > Thanks much,
> > > Wilhelm
> > >
> > > --
> > > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
> > Robert Dougherty, Ph.D.
> > President, OptiNav, Inc.
> > 1414 127th Place NE #106
> > Bellevue, WA 98005
> > Tel. (425)891-4883
> > FAX (425)467-1119
> > www.optinav.com
> > [hidden email]
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Burger Wilhelm

Re: Loading native DLLs into InageJ

Hi Mark,

thanks for these hints. I was not aware that compile-and-run was disabled in Fiji - does this mean that one has to restart Fiji after each editing/compiling a plugin in Eclipse (say) or is there some other mechanism for reload updated class files?

I will look closer at the ITK bridge implementation. From what I saw yet it loads the DLLs in the usual way, which is just fine as long as no class reload happens.
Nevertheless, I am still somewhat clueless as of how to proceed ...

Regards,
Wilhelm

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Mark Hiner
> Sent: Thursday, September 24, 2015 2:50 PM
> To: [hidden email]
> Subject: Re: Loading native DLLs into InageJ
>
> Hi Wilhelm,
>
> If you use Fiji there is some support for automatically managing native
> libraries[1]. You may notice in Fiji that Compile and Run is disabled, I
> believe specifically because of the desire to avoid multiple ClassLoaders -
> although you can still write and run Java classes in the script editor[2].
>
> We recently did some work building an ITK bridge in ImageJ[3][4], so
> looking at that project may be helpful to you.
>
> Best,
> Mark
>
> [1]
> http://imagej.net/Developing_using_native_libraries#Support_in_ImageJ
> [2] http://imagej.net/Scripting_Help
> [3] https://github.com/imagej/imagej-itk
> [4] http://imagej.net/ITK
>
> On Thu, Sep 24, 2015 at 6:24 AM, Burger Wilhelm <
> [hidden email]> wrote:
>
> > Hello Bob,
> >
> > thanks for the interesting hint - I had not been aware of any other plugin
> > using the OpenCV library. I installed as instructed and it works flawlessly
> > as far as I can tell, even going through compile-and-run.
> >
> > The difference seems to be that "SaveMovie" uses another OpenCV/Java
> > package that is based on javacpp -- which apparently defines its own
> > loading scheme. I have already contacted the author for more information,
> > particularly if it uses the latest OpenCV 3.0 release.
> >
> > I am still interested in how to robustly load a native DLL into ImageJ,
> > since I experienced the very same problem with OpenGL.
> >
> > Thanks again,
> > Wilhelm
> >
> >
> >
> > > -----Original Message-----
> > > From: ImageJ Interest Group [mailto:[hidden email]] On Behalf
> Of
> > > Robert Dougherty
> > > Sent: Wednesday, September 23, 2015 9:45 PM
> > > To: [hidden email]
> > > Subject: Re: Loading native DLLs into InageJ
> > >
> > > Wilhelm,
> > >
> > > Have a look at "Save As Movie" by Qingzong TSENG. It uses OpenCV and
> > > ffmpeg to save movies. Here is the experiment I just did on a Windows
> > 64-
> > > bit system.
> > >
> > > 1. Install Save As Movie per the instructions. (McAfee warned me about
> > > opencv.x86_64.jar. Not sure what to think about that...)
> > > 2. Verify that it works: Plugins/Input-Ouput/Save as Move exists and
> > > somewhat functions. (There may be missing codec issues. .avi/H.264
> worked
> > > for me.)
> > > 3. Delete SaveAsMovie_.jar. This removes the class file SaveMovie.class,
> > > which was in the folder ffmpegMovieIO in the .jar, as well as the
> > > plugins.config file that installed ffmpegIO.saveMovie on the menus.
> > > 4. Open the source, SaveMove.java from the "Save As Movie" web page,
> > > comment out the first line, "package ffmpegIO;", change the class name
> > > from SaveMove to SaveMovie_ , and save it in the plugins folder as
> > > SaveMove_.java
> > > 5. Try Compile and Run... SaveMovie_
> > > 6. Try it again. Nothing different seems to happen.
> > >
> > > Of course, it would be best to leave the package structure and the menus
> > as
> > > they were. I just wanted to show that Compile and Run can work this
> way.
> > >
> > > Bob
> > >
> > > On Sep 23, 2015, at 7:19 AM, Burger Wilhelm wrote:
> > >
> > > > Hello all, I wonder if someone can help me with the following technical
> > > problem:
> > > >
> > > > I am loading a native DLL into ImageJ (e.g., for using OpenGL or
> > OpenCV,
> > > under Windows). Everything works nicely if I execute precompiled
> plugins
> > > that use the native methods in that DLL, even repeatedly. However,
> when I
> > > execute the same plugin with "Compile and run" I get the following
> > errors:
> > > >
> > > > java.lang.UnsatisfiedLinkError: Native Library XXX.dll already loaded
> > in
> > > another classloader
> > > >
> > > > As a remedy I tried to load the DLL by a static block of a special
> > class, placed
> > > in a separate JAR file (read somewhere that this might help), and
> > referenced
> > > that class "by name" - but with no avail.
> > > >
> > > > I am not sure I understand well enough how class loaders and DLLs
> work
> > > together but assume somebody else must have encountered the same
> mess
> > > before. Any hints or suggestions for how to solve this?
> > > >
> > > > Thanks much,
> > > > Wilhelm
> > > >
> > > > --
> > > > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> > >
> > > Robert Dougherty, Ph.D.
> > > President, OptiNav, Inc.
> > > 1414 127th Place NE #106
> > > Bellevue, WA 98005
> > > Tel. (425)891-4883
> > > FAX (425)467-1119
> > > www.optinav.com
> > > [hidden email]
> > >
> > > --
> > > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Burger Wilhelm

Re: Loading native DLLs into InageJ

Just a short update for anyone interested in this issue:

I found a simple (interim) solution by placing my DLL-loader JAR and all DLL-dependent JAR files in the 'lib/ext/' directory of the JRE installation. This causes the associated classes to *always* be loaded by Java's (unique) Extension class loader. The DLL itself just needs to be somewhere in the runtime's library path ('lib/ext/' is not, btw.) -- e.g., right in the 'ImageJ/' directory.

Admittedly not very elegant, but it works flawlessly (under Windows at least). The problem of multiple class loaders with native DLLs pops up frequently in the context of Java-based web services. I still hope to find a better solution eventually, educated hints are still welcome.

--Wilhelm
www.imagingbook.com

________________________________________
From: Burger Wilhelm
Sent: Friday, September 25, 2015 09:25
To: [hidden email]
Cc: Mark Hiner; Burger Wilhelm
Subject: RE: Loading native DLLs into InageJ

Hi Mark,

thanks for these hints. I was not aware that compile-and-run was disabled in Fiji - does this mean that one has to restart Fiji after each editing/compiling a plugin in Eclipse (say) or is there some other mechanism for reload updated class files?

I will look closer at the ITK bridge implementation. From what I saw yet it loads the DLLs in the usual way, which is just fine as long as no class reload happens.
Nevertheless, I am still somewhat clueless as of how to proceed ...

Regards,
Wilhelm

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html