http://imagej.273.s1.nabble.com/null-pointer-exception-on-instanciating-a-matlab-jar-class-from-plugin-tp3683949p3683960.html
>>>>>
>>>>>> 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.
the coder. But will it be displayed via the route of the compiler?