null pointer exception on instanciating a matlab .jar class from plugin

[Heerpa]

Hi,

I am currently trying to write IJ plugins that access Matlab-generated .jar files.
With the help of http://imagejdocu.tudor.lu/doku.php?id=howto:plugins:how_to_set_up_netbeans_to_work_with_imagej_and_matlab_together
and the mathworks documentation, especially
http://www.mathworks.com/help/toolbox/javabuilder/ug/bsl9gar.html
and some entries in this forum, I can now
- access MATLAB functionality via deployed .jar from a java application
- create an IJ plugin that uses MATLAB types like MWArray, use MWException etc.
- declare a variable of my class (Aclass thismclass = null;)

but one i instanciate my class (thismclass = new Aclass;) ant open the plugin in IJ, I get a nullpointer Exception (even though I try-catch the instanciation).

Has anybody had the same problem or knows what to do to fix it?

best H

[Nathaniel Ryckman]

Could you give us the stack trace?

Also, just to check, you meant to type:

thismclass = new Aclass();

Right? If you only have "thismclass = new Aclass;", then that could be your problem.

Heerpa wrote

Hi,

I am currently trying to write IJ plugins that access Matlab-generated .jar files.
With the help of http://imagejdocu.tudor.lu/doku.php?id=howto:plugins:how_to_set_up_netbeans_to_work_with_imagej_and_matlab_together
and the mathworks documentation, especially
http://www.mathworks.com/help/toolbox/javabuilder/ug/bsl9gar.html
and some entries in this forum, I can now
- access MATLAB functionality via deployed .jar from a java application
- create an IJ plugin that uses MATLAB types like MWArray, use MWException etc.
- declare a variable of my class (Aclass thismclass = null;)

but one i instanciate my class (thismclass = new Aclass;) ant open the plugin in IJ, I get a nullpointer Exception (even though I try-catch the instanciation).

Has anybody had the same problem or knows what to do to fix it?

best H

[Heerpa]

yes, sorry I meant
thismclass = new Aclass();

I do not know the term stack trace - is that the error messages? Those are:
java.lang.NullPointerException
        at Testgetsquare_.run(Testgetsquare_.java:33)
        at ij.IJ.runUserPlugIn(IJ.java:183)
        at ij.IJ.runPlugIn(IJ.java:150)
        at ij.Executer.runCommand(Executer.java:127)
        at ij.Executer.run(Executer.java:64)
        at java.lang.Thread.run(Thread.java:619)

where Testgetsquare_ my plugin is.

I checked java versions: I compile the plugins with java 1.6.0_26; Java HotSpot(TM) Client VM 20.1-b02  on NetBeans 7.0. I copy them into my normally running IJ (v1.45k, java version 1.6.0_14) plugins folder. The Aclass (in my case Testgetsquareclass) is created by the matlab deployment tool (matlab R2007a, it uses java version: Java 1.5.0_07 with Sun Microsystems Inc. Java HotSpot(TM) Client VM mixed mode)
might the different java versions be the reason for the null pointer?

[Heerpa]

Hi,

the last stack trace was from a Netbeans-compiled plugin Testgetsquare_.java file. I put the Testgetsquare_.class into the plugins folder and opened that from ImageJ.
Now I opened the Testgestquare_.java with imageJ and compiled it here. The problem remains the same but I think the stack trace might be more intellible.. Not to me, though.. the javabuilder from the matlab deployment tool seems to load the nativemcl76.dll twice, which is a problem?

java.lang.UnsatisfiedLinkError: Native Library C:\Program Files\MATLAB\R2007a\bin\win32\nativemcl76.dll already loaded in another classloader
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1743)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
        at java.lang.Runtime.loadLibrary0(Runtime.java:823)
        at java.lang.System.loadLibrary(System.java:1028)
        at com.mathworks.toolbox.javabuilder.MWMCR.<clinit>(MWMCR.java:25)
        at dogetsquare.dogetsquareclass.<init>(dogetsquareclass.java:46)
        at Testgetsquare_.run(Testgetsquare_.java:26)
        at ij.IJ.runUserPlugIn(IJ.java:183)
        at ij.ImageJ.runUserPlugIn(ImageJ.java:264)
        at ij.plugin.PlugInExecuter.run(Compiler.java:264)
        at java.lang.Thread.run(Thread.java:619)


best, H

[dscho]

Hi,

On Wed, 6 Jul 2011, Heerpa wrote:

> java.lang.UnsatisfiedLinkError: Native Library C:\Program
> Files\MATLAB\R2007a\bin\win32\nativemcl76.dll already loaded in another
> classloader

Probably you ran "Update Menus" at some stage. For technical reasons (Java
does not offer you to "unload" classes), this creates a new class loader.
For other technical reasons, this new class loader cannot reuse the
previously-loaded native library, and neither can it load it again.

The only thing you can do after that is to restart ImageJ.

Sorry,
Johannes

[Heerpa]

Hum, I have not run "update menus" (I didn't know about it, so I  
always update the menus by restarting IJ).
Might the problem be that I built the file before so that java  
somewhere keeps nativemcl76.dll loaded which causes a problem the  
next time?
But then, the first try this morning went wrong, too..

Is it possible that I implicitely load the dll twice in the plugin?

Thanks, H

[dscho]

Hi,

it is slightly irritating that you neither quote my mail nor send the
answer Cc:ed to me.

On Wed, 6 Jul 2011, Heerpa wrote:

> Hum, I have not run "update menus" (I didn't know about it, so I  
> always update the menus by restarting IJ).
> Might the problem be that I built the file before so that java  
> somewhere keeps nativemcl76.dll loaded which causes a problem the  
> next time?
> But then, the first try this morning went wrong, too..
>
> Is it possible that I implicitely load the dll twice in the plugin?

Must be that.

I fear that you need to use either Matlab's Compiler (not Compiler JA) or
Coder Toolbox instead, since I doubt that you can somehow control how the
Matlab Runtime tries to load the classes when built with Compiler JA.

At least that's what a colleague and me did (work stalled a little, we
wanted to publish an application note about this before offering our work
to others).

Ciao,
Johannes

[Heerpa]

> Hi,
>
> it is slightly irritating that you neither quote my mail nor send the
> answer Cc:ed to me.
>
right, sorry - I am still learning..

> On Wed, 6 Jul 2011, Heerpa wrote:
>
>> Hum, I have not run "update menus" (I didn't know about it, so I
>> always update the menus by restarting IJ).
>> Might the problem be that I built the file before so that java
>> somewhere keeps nativemcl76.dll loaded which causes a problem the
>> next time?
>> But then, the first try this morning went wrong, too..
>>
>> Is it possible that I implicitely load the dll twice in the plugin?
>
> Must be that.
>
> I fear that you need to use either Matlab's Compiler (not Compiler  
> JA) or
> Coder Toolbox instead, since I doubt that you can somehow control  
> how the
> Matlab Runtime tries to load the classes when built with Compiler JA.
>

up to now, I was under the impression that matlab compiler, and  
compiler JA / builder JA was the same.. well I used the tool you get  
with typing deploytool.
using the mcc command, you do not get java files, do you?
http://www.mathworks.com/help/toolbox/compiler/bsl9d99.html


> At least that's what a colleague and me did (work stalled a little, we
> wanted to publish an application note about this before offering  
> our work
> to others).
I totally understand - well I am grateful for as much help as you are  
prepared to give.

Cheers,
    Heinrich

[dscho]

Hi Heinrich,

On Wed, 6 Jul 2011, Heinrich Grabmayr wrote:

> >On Wed, 6 Jul 2011, Heerpa wrote:
> >
> > >Hum, I have not run "update menus" (I didn't know about it, so I
> > >always update the menus by restarting IJ). Might the problem be that
> > >I built the file before so that java somewhere keeps nativemcl76.dll
> > >loaded which causes a problem the next time? But then, the first try
> > >this morning went wrong, too..
> > >
> > >Is it possible that I implicitely load the dll twice in the plugin?
> >
> >Must be that.
> >
> >I fear that you need to use either Matlab's Compiler (not Compiler JA)
> >or Coder Toolbox instead, since I doubt that you can somehow control
> >how the Matlab Runtime tries to load the classes when built with
> >Compiler JA.
>
> up to now, I was under the impression that matlab compiler, and compiler
> JA / builder JA was the same.. well I used the tool you get with typing
> deploytool. using the mcc command, you do not get java files, do you?
> http://www.mathworks.com/help/toolbox/compiler/bsl9d99.html

The Compiler and Compiler JA toolboxes are different (although you cannot
have JA without Compiler, you have to pay for both separately).

What we did -- because we had too many problems trying to get the
JA-compiled code running on all three Operating Systems supported by Fiji,
MacOSX, Windows and Linux -- was to compile using Compiler (because Coder
did not exist yet, back then) and to wrap using JNI.

Ciao,
Johannes

[Heerpa]

> Hi Johannes

>>> On Wed, 6 Jul 2011, Heerpa wrote:
>>>
>>>> Hum, I have not run "update menus" (I didn't know about it, so I
>>>> always update the menus by restarting IJ). Might the problem be  
>>>> that
>>>> I built the file before so that java somewhere keeps  
>>>> nativemcl76.dll
>>>> loaded which causes a problem the next time? But then, the first  
>>>> try
>>>> this morning went wrong, too..
>>>>
>>>> Is it possible that I implicitely load the dll twice in the plugin?
>>>
>>> Must be that.
>>>
>>> I fear that you need to use either Matlab's Compiler (not  
>>> Compiler JA)
>>> or Coder Toolbox instead, since I doubt that you can somehow control
>>> how the Matlab Runtime tries to load the classes when built with
>>> Compiler JA.
>>
>> up to now, I was under the impression that matlab compiler, and  
>> compiler
>> JA / builder JA was the same.. well I used the tool you get with  
>> typing
>> deploytool. using the mcc command, you do not get java files, do you?
>> http://www.mathworks.com/help/toolbox/compiler/bsl9d99.html
>
> The Compiler and Compiler JA toolboxes are different (although you  
> cannot
> have JA without Compiler, you have to pay for both separately).
>
> What we did -- because we had too many problems trying to get the
> JA-compiled code running on all three Operating Systems supported  
> by Fiji,
> MacOSX, Windows and Linux -- was to compile using Compiler (because  
> Coder
> did not exist yet, back then) and to wrap using JNI.
>

I think I am getting it - the way you did is was compile a .dll and  
access that from java via jni, right?
with the coder, you would get c++ code, compile that to a .dll and  
proceed the same way? Or could you use the "mex" functions more  
directly?
The way you put it, it sounds like you would prefer to use the coder  
if you'd start now - why?

Cheers, Heinrich

[dscho]

Hi Heinrich,

On Wed, 6 Jul 2011, Heinrich Grabmayr wrote:

> > > >On Wed, 6 Jul 2011, Heerpa wrote:
> > > >
> > > > >Hum, I have not run "update menus" (I didn't know about it, so I
> > > > >always update the menus by restarting IJ). Might the problem be
> > > > >that I built the file before so that java somewhere keeps
> > > > >nativemcl76.dll loaded which causes a problem the next time? But
> > > > >then, the first try this morning went wrong, too..
> > > > >
> > > > >Is it possible that I implicitely load the dll twice in the
> > > > >plugin?
> > > >
> > > >Must be that.
> > > >
> > > >I fear that you need to use either Matlab's Compiler (not Compiler
> > > >JA) or Coder Toolbox instead, since I doubt that you can somehow
> > > >control how the Matlab Runtime tries to load the classes when built
> > > >with Compiler JA.
> > >
> > >up to now, I was under the impression that matlab compiler, and
> > >compiler JA / builder JA was the same.. well I used the tool you get
> > >with typing deploytool. using the mcc command, you do not get java
> > >files, do you?
> > >http://www.mathworks.com/help/toolbox/compiler/bsl9d99.html
> >
> >The Compiler and Compiler JA toolboxes are different (although you
> >cannot have JA without Compiler, you have to pay for both separately).
> >
> >What we did -- because we had too many problems trying to get the
> >JA-compiled code running on all three Operating Systems supported by
> >Fiji, MacOSX, Windows and Linux -- was to compile using Compiler
> >(because Coder did not exist yet, back then) and to wrap using JNI.
> >
> I think I am getting it - the way you did is was compile a .dll and
> access that from java via jni, right?

Exactly. We even wrote some code wrapping the generated header
automatically in a Java class.

> with the coder, you would get c++ code, compile that to a .dll and
> proceed the same way?

Spot on.

> Or could you use the "mex" functions more directly?

The mex is not as easily accessed, AFAIK it uses a proprietary interface.
There would be a not-quite-performant way to access the .dll via JNA (or
similar approaches), but that adds yet another dependency we tried to
avoid.

> The way you put it, it sounds like you would prefer to use the coder if
> you'd start now - why?

The startup time of the Matlab Common Runtime (MCR) as well as the sheer
size of the installer (together with administration privileges being
required when you want to install the MCR) are limitations Code-generated
code does not have. Besides, calls to the Matlab Common Runtime need to be
serialized, while functions translated by the Coder can be run in
parallel.

Of course, graphical Matlab components cannot be shown from components
translated by the Coder toolbox.

Ciao,
Johannes

[Heerpa]

Hi Johannes,

On Wed, 6 Jul 2011, Heerpa wrote:

>>>>>
>>>>>> Hum, I have not run "update menus" (I didn't know about it, so I
>>>>>> always update the menus by restarting IJ). Might the problem be
>>>>>> that I built the file before so that java somewhere keeps
>>>>>> nativemcl76.dll loaded which causes a problem the next time? But
>>>>>> then, the first try this morning went wrong, too..
>>>>>>
>>>>>> Is it possible that I implicitely load the dll twice in the
>>>>>> plugin?
>>>>>
>>>>> Must be that.
>>>>>
>>>>> I fear that you need to use either Matlab's Compiler (not Compiler
>>>>> JA) or Coder Toolbox instead, since I doubt that you can somehow
>>>>> control how the Matlab Runtime tries to load the classes when  
>>>>> built
>>>>> with Compiler JA.
>>>>
>>>> up to now, I was under the impression that matlab compiler, and
>>>> compiler JA / builder JA was the same.. well I used the tool you  
>>>> get
>>>> with typing deploytool. using the mcc command, you do not get java
>>>> files, do you?
>>>> http://www.mathworks.com/help/toolbox/compiler/bsl9d99.html
>>>
>>> The Compiler and Compiler JA toolboxes are different (although you
>>> cannot have JA without Compiler, you have to pay for both  
>>> separately).
>>>
>>> What we did -- because we had too many problems trying to get the
>>> JA-compiled code running on all three Operating Systems supported by
>>> Fiji, MacOSX, Windows and Linux -- was to compile using Compiler
>>> (because Coder did not exist yet, back then) and to wrap using JNI.
>>>
>> I think I am getting it - the way you did is was compile a .dll and
>> access that from java via jni, right?
>
> Exactly. We even wrote some code wrapping the generated header
> automatically in a Java class.
>
>> with the coder, you would get c++ code, compile that to a .dll and
>> proceed the same way?
>
> Spot on.
>
>> Or could you use the "mex" functions more directly?
>
> The mex is not as easily accessed, AFAIK it uses a proprietary  
> interface.
> There would be a not-quite-performant way to access the .dll via  
> JNA (or
> similar approaches), but that adds yet another dependency we tried to
> avoid.
>
>> The way you put it, it sounds like you would prefer to use the  
>> coder if
>> you'd start now - why?
>
> The startup time of the Matlab Common Runtime (MCR) as well as the  
> sheer
> size of the installer (together with administration privileges being
> required when you want to install the MCR) are limitations Code-
> generated
> code does not have. Besides, calls to the Matlab Common Runtime  
> need to be
> serialized, while functions translated by the Coder can be run in
> parallel.
>
> Of course, graphical Matlab components cannot be shown from components
> translated by the Coder toolbox.

One of my m files displays a figure - so that won't be any use with  
the coder. But will it be displayed via the route of the compiler?

>
> Ciao,
> Johannes
>

[dscho]

Hi Heinrich,

On Wed, 6 Jul 2011, Heinrich Grabmayr wrote:

> One of my m files displays a figure - so that won't be any use with the
> coder. But will it be displayed via the route of the compiler?

Yes, if you use Matlab's Compiler, the resulting code will start a Java
Virtual Machine to display figures, or reuse a running one if it exists in
the current process (except in Matlab R2010a if memory serves correctly,
where they had a bug on MacOSX, and only on MacOSX, trying to start a new
JVM -- even if Compiler JA generated code did not share that problem).

Ciao,
Johannes

[Heerpa]

Hi Johannes,

On Wed, 6 Jul 2011, Heinrich Grabmayr wrote:
>> One of my m files displays a figure - so that won't be any use with the
>> coder. But will it be displayed via the route of the compiler?
> Yes, if you use Matlab's Compiler, the resulting code will start a Java
> Virtual Machine to display figures, or reuse a running one if it exists in
> the current process (except in Matlab R2010a if memory serves correctly,
> where they had a bug on MacOSX, and only on MacOSX, trying to start a new
> JVM -- even if Compiler JA generated code did not share that problem).
I have now looked into JNI a bit, and how to use that in combination
with Matlab compiler. It doesn't seem to be that straight forward
because you have to embed a java header while creating the dll you want
to use in java later.
http://www.haertfelder.com/jni.html
http://www.mathworks.de/matlabcentral/newsreader/view_thread/73070
the latter modifies the a c code generated by matlab during the build
process and compiles that to a dll which he intends to use from java.
That sounds sensible to me, but it seems not to work. I wouldn't have
any idea on how to do it differently. Can you hint me to the way to go?

Best, Heinrich

[dscho]

Hi Heinrich,

On Thu, 7 Jul 2011, Heinrich Grabmayr wrote:

> On Wed, 6 Jul 2011, Heinrich Grabmayr wrote:
> >
> > > One of my m files displays a figure - so that won't be any use with
> > > the coder. But will it be displayed via the route of the compiler?
> >
> > Yes, if you use Matlab's Compiler, the resulting code will start a
> > Java Virtual Machine to display figures, or reuse a running one if it
> > exists in the current process (except in Matlab R2010a if memory
> > serves correctly, where they had a bug on MacOSX, and only on MacOSX,
> > trying to start a new JVM -- even if Compiler JA generated code did
> > not share that problem).
>
> I have now looked into JNI a bit, and how to use that in combination
> with Matlab compiler. It doesn't seem to be that straight forward
> because you have to embed a java header while creating the dll you want
> to use in java later.
>
> http://www.haertfelder.com/jni.html
> http://www.mathworks.de/matlabcentral/newsreader/view_thread/73070
>
> the latter modifies the a c code generated by matlab during the build
> process and compiles that to a dll which he intends to use from java.
> That sounds sensible to me, but it seems not to work. I wouldn't have
> any idea on how to do it differently. Can you hint me to the way to go?

We did not modify the generated code (as that would make it harder later
on, when we develop the .m code further).

Instead, we wrote a wrapper class in Java, compiled it, used the javah
program on it to generate a header and then implemented the function
declared in said header. After that, we only needed to develop glue code
to transform Java data structures (including ImageProcessor) into Matlab
data structures and back.

I sincerely hope that I can show you the code soon so you do not have to
duplicate all that work.

Ciao,
Johannes

[Heerpa]

Hi Johannes,

now I do see the problem caused by lack of quoting ;-)

> >> java.lang.UnsatisfiedLinkError: Native Library C:\Program
> >> Files\MATLAB\R2007a\bin\win32\nativemcl76.dll already loaded in another
> >> *classloader*

> > Is it possible that I implicitely load the dll twice in the *plugin*?

>Must be that.

I remembered today that I have copied the javabuilder.jar to the src
directory of the project (and later into the plugins dir of IJ as
directed by the IJ-plugin Netbeans tutorial linked to above) as well as
specified the classpath in the project properties to be
C:\Program Files\MATLAB\MATLAB Component
Runtime\v76\toolbox\javabuilder\jar\javabuilder.jar

Perhaps the problem is that there are those two same .jars?
When I compile my .java from within IJ, I do not set any classpath (is
it possible to do this? or put it as code into the .java file?), though
- so it should only use the one I copy into the plugins folder.
Is the classpath stored into the .class when compiling in netbeans?
because if not, that would possibly explain why it does work when I run
an application using my matlab jar from netbeans whereas I get this null
pointer when running it from IJ.

Cheers, Heinrich

[Heerpa]

Hey Johannes,

>> >> java.lang.UnsatisfiedLinkError: Native Library C:\Program
>> >> Files\MATLAB\R2007a\bin\win32\nativemcl76.dll already loaded in  
>> another
>> >> *classloader*
>
>> > Is it possible that I implicitely load the dll twice in the  
>> *plugin*?
>
>> Must be that.
>
> I remembered today that I have copied the javabuilder.jar to the  
> src directory of the project (and later into the plugins dir of IJ  
> as directed by the IJ-plugin Netbeans tutorial linked to above) as  
> well as specified the classpath in the project properties to be
> C:\Program Files\MATLAB\MATLAB Component Runtime\v76\toolbox
> \javabuilder\jar\javabuilder.jar
>
> Perhaps the problem is that there are those two same .jars?
> When I compile my .java from within IJ, I do not set any classpath  
> (is it possible to do this? or put it as code into the .java  
> file?), though - so it should only use the one I copy into the  
> plugins folder.
> Is the classpath stored into the .class when compiling in netbeans?  
> because if not, that would possibly explain why it does work when I  
> run an application using my matlab jar from netbeans whereas I get  
> this null pointer when running it from IJ.

To analyze this, I tried to call the javaapplication using the matlab-
jar from the command line instead of netbeans. I thought that maybe  
there are special arguments you had to pass for it to work. There I  
saw that I had to call

java javaapplication1 -fork="true"

so I had to create a new JVM for the call. Otherwise it would give a  
null pointer exception at the same line (although it didn't mention  
the dll). So I imagine that this might be the problem in IJ, too. Do  
you know whether it is possible to make ImageJ call the plugin with  
that argument?

Best, Heinrich