Posted by
dscho on
Jul 06, 2011; 8:50pm
URL: http://imagej.273.s1.nabble.com/null-pointer-exception-on-instanciating-a-matlab-jar-class-from-plugin-tp3683949p3683959.html
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