Since MATLAB requires Java for some of its features (e.g. for displaying the GUI or running Java programs within MATLAB), it ships with Sun’s Java Runtime Environment (JRE). Most people already have installed a JRE on their system that usually is newer than the one MATLAB comes with. Therefore, it seems to be a good idea to let MATLAB make use of the installed JRE instead of its own. This easily can be done by setting the environment variable
MATLAB_JAVA. That’s the theory.
In practice, changing MATLAB’s JRE makes some trouble—at least when you are running Linux. Currently, I’m running MATLAB R2008b (aka 7.7) on Fedora 10 and notice some problems with MATLAB’s own JRE: First, printing does not work. Second, when starting MATLAB I get some strange error (locking assertion failure), which luckily does not seem to have any further consequences. Therefore, I decided to switch to OpenJDK, which comes with Fedora. Setting
/usr/lib/jvm/jre should do the job. Unfortunately, with this setting MATLAB fails to start, giving me the following error message:
Unable to initialize com.mathworks.mwswing.MJStartup Fatal Error on startup: Failure loading desktop class
Although I spent some time in debugging this issue, I still have no clue what’s going wrong. My hope is that this issue will be resolved in the next release of MATLAB.
And indeed, MATLAB R2009a (aka 7.8) can be started using OpenJDK. However, MATLAB’s help browser displays only empty pages, which actually are not very helpful. When opening the help browser I get the following Java error:
So, what can be done to get rid of this problem? As a workaround (until the developers of OpenJDK finally fix this problem) I suggest to delete the symlink
/usr/lib/jvm/java-1.6.0-openjdk-18.104.22.168.x86_64/jre/lib/rhino.jar, which currently points to
Now, OpenJDK works fine with MATLAB and I’m even able to print. Apart from that, the fonts look better.
To summarize: MATLAB R2008b does not work with OpenJDK, but MATLAB R2009a does if you remove rhino.jar from OpenJDK.
UPDATE: The IcedTea/OpenJDK guys managed to move OpenJDK’s version of Rhino to a different namespace (as of IcedTea6 1.8), which should solve the problem described in this post.