You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Matlab has a way to register event listeners. Basically, whenever you pass a Matlab function (possibly having to manipulate it with the handle function first) to a Java method expecting an event listener, that Matlab function gets wrapped in a correct Java class. The trick seems to be that the parameter passed to the callback has to be a subclass of java.util.EventObject. See http://undocumentedmatlab.com/blog/matlab-callbacks-for-java-events for details
I'm working on an implementation with MatlabControl right now.. it seems to work very nicely. My only complaint is that only the 3.1.0 version is available via Maven right now, and it always needs to launch a new matlab instance.
The 4.x release allows you to both launch Matlab silently and attach to existing Matlab instances, I believe. I would like to e-mail the author about deploying the 4.x line to maven central but all e-mail addresses that I can find are invalid...
@dscho after @ctrueden and I talked, I'm now under the impression that calling MATLAB form within ImageJ could be dangerous license grounds...? And we just want to use the JMI and make the MATLAB language non-functional if Fiji is spun up outside of a MATLAB instance.
So if you happen to launch Java with jmi.jar in the classpath as a user, does that violate any licenses (not a rhetorical question, I don't know)? I am hoping that you could reference the necessary classes (using reflection or scripting if you need the Jar for compilation to succeed) and only expose Matlab support if the class loader could find them. As it is, there are plugins that do not have GPL-compatible licenses so hopefully we have already crossed this bridge.
I'd say it would be useful to provide support in that sort of fashion. I looked at this briefly for CellProfiler and my biggest concern was that the interface libraries were version-specific which would complicate the distribution - so you need directions for users that tell them how to launch Fiji / ImageJ / CellProfiler / Knime with the jmi.jar that came with their Matlab.
I don't know that launching Java with jmi.jar on the classpath violates licensing.. @ctrueden explained it as if you make it possible for multiple users to connect to a single MATLAB instance running on a server, you can be subject to legal action. And I think MatlabControl might make that possible...
So if you happen to launch Java with jmi.jar in the classpath as a user, does that violate any licenses
No, just having stuff with different licenses in your class path does not pose a problem. It is only when you make "derivative" work that licenses kick in. That is, if you requirejmi.jar to be there, you are on shaky grounds.
@ctrueden explained it as if you make it possible for multiple users to connect to a single MATLAB instance running on a server, you can be subject to legal action. And I think MatlabControl might make that possible...
That is easily addressed: we just need to write in our license that we only support legal use.
I did. The submission template is specific to reporting bugs so I decided against it.. I found another reference to the developer's username and was able to send an e-mail that wasn't rejected.
you and Jacques had some experience dealing with MATLAB licenses during your years at the IPF.
Oh yes, the IPF. Where I got oh so much support by the institute's management. Not happy memories!
Anyway, the problem we ran into were some obscure license restrictions of the Matlab Compiler Toolbox. Basically, you cannot distribute binaries built with said toolbox if you compete with Mathworks. While we were convinced that we were not competing with Mathworks, we were also convinced that they would see it differently, so we refrained from shipping such compile products.
In many ways, this is not related at all to this project: this project requires a fully licensed Matlab copy. It simply won't work without. And it does not at all use the Matlab Compiler Toolbox, thus we do not have to abide by that Toolbox' license.
For the record, development is back to a MatlabControl implementation. It's on the WIP branch. I believe the bindings are done, so I just have to figure out how to properly pass input through to MATLAB's eval and feval..
The MATLAB scripting is working, both from without and within MATLAB. Script @Parameters and such are working, and complex java objects can be used when using scripts from within MATLAB.
The only work remaining to merge this is to complete the pref_service branch (as of writing, I used a non-functional Prefs implementation to test... I'll just have to convert to a PrefsService, and then add a high priority implementation in Miji. This is to work around a known java.lang.preferences bug in MATLAB, and it's something we wanted to do anyway).
So I will also have to merge and release my Miji branch.
But, yeah, the actual MATLAB side of things is done now.
I'll write a blog post detailing the script use and limitations after release.
Activity
hinerm commentedon Jul 16, 2014
I'm working on an implementation with
MatlabControlright now.. it seems to work very nicely. My only complaint is that only the 3.1.0 version is available via Maven right now, and it always needs to launch a new matlab instance.The 4.x release allows you to both launch Matlab silently and attach to existing Matlab instances, I believe. I would like to e-mail the author about deploying the 4.x line to maven central but all e-mail addresses that I can find are invalid...
hinerm commentedon Jul 16, 2014
@dscho after @ctrueden and I talked, I'm now under the impression that calling MATLAB form within ImageJ could be dangerous license grounds...? And we just want to use the JMI and make the MATLAB language non-functional if Fiji is spun up outside of a MATLAB instance.
LeeKamentsky commentedon Jul 16, 2014
So if you happen to launch Java with jmi.jar in the classpath as a user, does that violate any licenses (not a rhetorical question, I don't know)? I am hoping that you could reference the necessary classes (using reflection or scripting if you need the Jar for compilation to succeed) and only expose Matlab support if the class loader could find them. As it is, there are plugins that do not have GPL-compatible licenses so hopefully we have already crossed this bridge.
I'd say it would be useful to provide support in that sort of fashion. I looked at this briefly for CellProfiler and my biggest concern was that the interface libraries were version-specific which would complicate the distribution - so you need directions for users that tell them how to launch Fiji / ImageJ / CellProfiler / Knime with the jmi.jar that came with their Matlab.
hinerm commentedon Jul 16, 2014
This is what Curtis wrote ReflectedUniverse for I believe.
Currently I've decided to go in a stubs direction instead: https://github.com/scijava/matlab-jmi-stubs
I don't know that launching Java with jmi.jar on the classpath violates licensing.. @ctrueden explained it as if you make it possible for multiple users to connect to a single MATLAB instance running on a server, you can be subject to legal action. And I think
MatlabControlmight make that possible...dscho commentedon Jul 16, 2014
No, just having stuff with different licenses in your class path does not pose a problem. It is only when you make "derivative" work that licenses kick in. That is, if you require
jmi.jarto be there, you are on shaky grounds.dscho commentedon Jul 16, 2014
@hinerm did you consider opening an issue on https://code.google.com/p/matlabcontrol/issues/list?
That is easily addressed: we just need to write in our license that we only support legal use.
tinevez commentedon Jul 16, 2014
@dscho, I seem to remember that you and Jacques had some experience dealing with MATLAB licenses during your years at the IPF. Any recollection?
hinerm commentedon Jul 16, 2014
I did. The submission template is specific to reporting bugs so I decided against it.. I found another reference to the developer's username and was able to send an e-mail that wasn't rejected.
dscho commentedon Jul 16, 2014
Oh yes, the IPF. Where I got oh so much support by the institute's management. Not happy memories!
Anyway, the problem we ran into were some obscure license restrictions of the Matlab Compiler Toolbox. Basically, you cannot distribute binaries built with said toolbox if you compete with Mathworks. While we were convinced that we were not competing with Mathworks, we were also convinced that they would see it differently, so we refrained from shipping such compile products.
In many ways, this is not related at all to this project: this project requires a fully licensed Matlab copy. It simply won't work without. And it does not at all use the Matlab Compiler Toolbox, thus we do not have to abide by that Toolbox' license.
tinevez commentedon Jul 16, 2014
Ok got it.
hinerm commentedon Jul 16, 2014
For the record, development is back to a
MatlabControlimplementation. It's on the WIP branch. I believe the bindings are done, so I just have to figure out how to properly pass input through to MATLAB'sevalandfeval..hinerm commentedon Jul 18, 2014
A quick update for those interested:
The MATLAB scripting is working, both from without and within MATLAB. Script
@Parametersand such are working, and complex java objects can be used when using scripts from within MATLAB.The only work remaining to merge this is to complete the pref_service branch (as of writing, I used a non-functional
Prefsimplementation to test... I'll just have to convert to a PrefsService, and then add a high priority implementation in Miji. This is to work around a known java.lang.preferences bug in MATLAB, and it's something we wanted to do anyway).So I will also have to merge and release my Miji branch.
But, yeah, the actual MATLAB side of things is done now.
I'll write a blog post detailing the script use and limitations after release.
dscho commentedon Jul 18, 2014
@hinerm you rock!