@Matt – it’s in the pipeline… Matlab’s toolstrip is not simple so investigating it and writing the article takes a long time. I hope to get around to it in a few months.

@Malcolm

Doing a multi-jar build may work, however a problem still lies in having different versions in my project’s Java code and Matlab libraries, say . Not having the new library available results in missing classes/methods for my project’s Java code, and the *.jar might not load using the Matlab classloader. Subsequently, switching to the new version of the library by modifying the static classpath.txt to load the new version results in Matlab trying to call deprecated classes or methods. To fix this would require patching the Matlab binaries which use this deprecated logic, which seems like a pretty painful job to do and to maintain for multiple Matlab machines.

Using a tool like JarJar or Maven shade in the build process allows me to rename duplicate dependencies for my own Java project, such that my own Java code can call into a different version than the default Matlab logic. This seems required to get things working.

On a side-note, after the issues observed with java dependencies and java 7, we’re trying to get java RMI working. This would allow running a separate jvm1.7 with its own classpath, and as such we don’t have to stress Matlab as much.

@Roderick
A multi-jar ANT build, such as that produced by NetBeans should solve your problems without much effort.
Addition of jars is a property of Java/JVM/ANT rather than MATLAB. If a class is already loaded, it will be resolvable by the JVM and not be loaded again.

For example, with the Waterloo graphics project only one jar is added using MATLAB javaaddpath – GraphExplorer.jar. This has many dependencies in the “dist/lib” folder which Java knows about via the META-INF in GraphExplorer.jar (all generated automatically in NetBeans if you select the copy dependencies to lib folder in the build settings). Just make sure that the single jar has all second, third etc order dependencies added (as Yair describes above) i.e if A.jar calls B.jar that depends on C.jar, add C.jar as well as B.jar as a dependency to A.jar.

When classes are already available through the MATLAB static java class path – they will be used and nothing extra will be loaded: Java/ANT resolves what needs to be loaded automatically. Problems arise only when there is a version conflict and then generally only if you are calling an unsupported function. E.g., MATLAB ships with the JOGL1 openGL Java library. To use JOGL2 you would need to edit the static class path (and, in this case, also replace the OS specific binaries).

An advantage of this is you do not need a MATLAB-specific build. GraphExplorer.jar also runs as a standalone executable jar and it can be used from other environments e.g. R and SciLab when the dist/lib jars will all be loaded automatically.

Also note that any jars added through loading a single jar file are then available within MATLAB. E.g, GraphExplorer is written largely in Groovy rather than Java – so Groovy and all its built-in classes are then available in MATLAB. One of those, the GroovyClassLoader can be used to add extra jar files to the class path dynamically by specifying the URL of a jar file (much as the MATLAB javaaddpath – much easier to use than the Java equivalent). GraphExplorer (which is an LGPL project) uses that to load its GPL extensions if they are installed. The advantage here is that the supporting code is in the GraphExplorer.jar file – no need to write specifically for MATLAB again so everything works also for the stand-alone, R etc.

Thanks for the feedback,

I’ve got it working a bit better now it seems. The main solution seems to have been to extract my final jar and add this directory to the Matlab java classpath rather than to the jar itself. I was able to add the directory to both the static and dynamic path and the classes subsequently seem available. This means that it seems I can rely on Maven shade plugin to deal with duplicate dependencies and potential version conflicts.

I’m aware about the java 7 problem, and have been using jvm7 in Matlab for some while now. I had to apply some patches for some issues with graphics and GUIs, and although it is still definitely not bug-free, it seems manageable. It’s a pitty that R2013a still relies on the jvm6 though.

@Roderick – indeed, Matlab is not very verbose when failing to instantiate a class as to the underlying failure reason (to say the least). You could try placing all your classes as standalone files in some folder and then add the folder via javaaddpath, then you would at least be able to test on a class-by-class basis. You should run which(FQCN) before the javaaddpath, to ensure that the class is not already defined somewhere in Matlab. If all your classes reside in a dedicated package (e.g., roderick.MyClass) then this should not be an issue. This would then narrow things down to an instantiation problem. Ensure that both your class AND its constructor are public, then ensure that your are passing the correct params to your constructor.

If all this fails, then a possible reason is that the class references some other class that is not available on the java classpath. For example, class A might call B.method() somewhere (in whichever function), and if B is not available then instatiating A in Matlab will fail without telling you that the actual reason is B and not A…

A final reason might be that the class files were compiles using a newer Java release than Matlab is using – a typical case is using Java 7 rather than Java 6.

Any idea about how the new javaclasspath.txt handles duplicate dependencies to the standard Matlab included jars? Does Matlab actually do something with duplicate dependencies and with potential version conflicts in this case?

Fyi, for the last couple of days I’ve been boxing my head against a wall trying to get a big java project imported into Matlab. To handle version conflicts in the dependencies (which there are and which I can find with trying to add separate jars to the dynamic path), I’ve tried using the Maven shade plugin for renaming all common classes between matlab and my java project and packaging this into one big jar. Seemed like a decent approach. However, after trying to add this final jar to either the static or dynamic classpath, I don’t get any errors from Matlab and it signals that it has indeed added it when calling javaclasspath(), while I cannot call into any class located within this jar. I’ve tried different routes of finding out why Matlab doesn’t pick it up, but cannot seem to get anywhere.

You may be encountering memory-swapping issues, so try restarting the computer and monitoring the process memory while running your simulation. I’m afraid I don’t have anything smarter to suggest except contacting MathWorks customer service.