I think this is one of our most requested features, at least on this blog. Let us know what you think!
We’re especially happy that Snow Leopard is being introduced at (almost) the same time as our R2009b release, which includes a shiny new native 64-bit version of MATLAB on the Mac. This will be a boon to anyone working with large data sets in MATLAB. On the user interface side, you can expect to see new features that Mac users will find especially agreeable – stay tuned to this blog over the next several weeks as we talk about the new UI features in R2009b. We also busily continue to remove the last vestiges of X11 from MATLAB. While it will take a couple more releases to completely expunge it, MATLAB is, for the most part, now free of its X11 heritage.
For those migrating to Snow Leopard, you can expect to see the resolution of a couple of irritating UI quirks:
Finally, we also have a few small things to look out for if you’re adopting Snow Leopard. We are working with Apple on all of these issues:
- There is a problem in R2007a and R2007b where the Command History window will not be displayed. While this may be addressed in a future OS X update, if you are still on these older MATLAB releases, we strongly encourage you to upgrade… MATLAB has come a long way on the Mac in the last two years.
- Data tips (the yellow pop-ups you see when you hover the mouse over a variable in the Editor) may show stale values.
- We have noticed that buttons at the bottom of some dialog boxes are clipped by a few pixels (see screenshot below). This is a cosmetic defect only.
We expect these issues to be resolved very soon in an Apple software update.
We look forward to hearing about your MATLAB experiences on Snow Leopard. Will you be upgrading to Snow Leopard in the near future? Do you plan on adopting 64-bit MATLAB?
By
Ken Orr
Ken is a developer on the MATLAB Desktop team. He loves the art of graphic design as well as developing visually pleasing user interfaces - he's one of those 'crazy' Mac guys!
13:39 UTC |
Posted in Desktop, Install, Mac |
Permalink |
80 Comments »
August 24th, 2009
MATLAB webinars
A while back I pointed out how you could watch demos of various things within MATLAB, which serves mainly as a tool to learn about new features. The MathWorks also offers webinars on our website, all of which are free and tend to be much more detailed instructional style resources. You’ll find a catalog of past webinars here, and a listing of the upcoming webinars here.
The webinars span the breadth of MATLAB products, as well as the various levels of MATLAB users. Here are a few webinars you might find interesting:
Large Data Sets in MATLAB
MATLAB for Excel Users
MATLAB for Java Programmers
MATLAB for C/C++ Programmers
Speeding Up MATLAB Applications
Webinars are a great way to receive classroom style instruction, without needing to leave your computer. Have you watched any of the webinars?
By
Ken Orr
Ken is a developer on the MATLAB Desktop team. He loves the art of graphic design as well as developing visually pleasing user interfaces - he's one of those 'crazy' Mac guys!
14:47 UTC |
Posted in web |
Permalink |
No Comments »
August 17th, 2009
Calling Java from MATLAB, Memory Issues
Following up with my previous post about using Java objects in MATLAB, this week I’m going to discuss the memory issues that can crop up.
When a Java object is created in the MATLAB workspace, it is actually created in the Java heap space and not the main memory used by MATLAB. On a 32-bit windows machine, MATLAB might have up to 3 GB available for creating matrices and other MATLAB objects but only 64 or 128 MB (by default) for creating java objects. To find out how much memory is available for creating Java objects, there are three numbers of importance: the free memory, the total memory, and the max memory.
The free memory is the number of bytes available in the heap space for creating new objects. The total memory is the number of bytes allocated to the total heap space which is the size of the objects created + the free memory. When the amount of free memory starts to get low, java will increase the total memory until it equals the the max memory. You can see this in the following animated graph, where the green (total memory) is bumped up when I create the large array of java doubles. The jumps in the blue represent the objects created as I manipulated the editor and command window to set up this demo, and the dips are when those objects get garbage collected, freeing up memory. The actual double array isn’t shown on this graph as it is created and cleared faster than the sampling time of the graph.
This is the demo that was running at the time of the jump: you can see the commands to discover the java memory, as well as the fact that the array creation ups the used java memory but does not affect the memory for MATLAB array creation:
free = java.lang.Runtime.getRuntime.freeMemory
total = java.lang.Runtime.getRuntime.totalMemory
max = java.lang.Runtime.getRuntime.maxMemory
feature(‘memstats’)
x = javaArray(‘java.lang.Double’,400000);
for i=1:400000
x(i)=java.lang.Double(i);
end
free =
13271784
total =
65470464
max =
130875392
Physical Memory (RAM):
In Use: 1911 MB (77755000)
Free: 1655 MB (677f0000)
Total: 3567 MB (def45000)
Page File (Swap space):
In Use: 2205 MB (89dd3000)
Free: 3243 MB (cab14000)
Total: 5448 MB (1548e7000)
Virtual Memory (Address Space):
In Use: 585 MB (24928000)
Free: 1462 MB (5b6b8000)
Total: 2047 MB (7ffe0000)
Largest Contiguous Free Blocks:
1. [at 320b5000] 459 MB (1cb9b000)
2. [at 4edf6000] 279 MB (117da000)
3. [at 21810000] 263 MB (107f0000)
4. [at 605d9000] 146 MB ( 9217000)
5. [at 6d346000] 71 MB ( 470a000)
6. [at 697f6000] 58 MB ( 3a3a000)
7. [at 71ce7000] 19 MB ( 1319000)
8. [at 73026000] 18 MB ( 126a000)
9. [at 7e4a1000] 18 MB ( 124f000)
10. [at 7d1d7000] 18 MB ( 1239000)
======= ==========
1352 MB (548cb000)
ans =
481931264
free = java.lang.Runtime.getRuntime.freeMemory
total = java.lang.Runtime.getRuntime.totalMemory
max = java.lang.Runtime.getRuntime.maxMemory
feature(‘memstats’)
free =
31137576
total =
102739968
max =
130875392
Physical Memory (RAM):
In Use: 1919 MB (77f2a000)
Free: 1648 MB (6701b000)
Total: 3567 MB (def45000)
Page File (Swap space):
In Use: 2238 MB (8be27000)
Free: 3210 MB (c8ac0000)
Total: 5448 MB (1548e7000)
Virtual Memory (Address Space):
In Use: 584 MB (248b8000)
Free: 1463 MB (5b728000)
Total: 2047 MB (7ffe0000)
Largest Contiguous Free Blocks:
1. [at 320b5000] 459 MB (1cb9b000)
2. [at 4edf6000] 279 MB (117da000)
3. [at 21810000] 263 MB (107f0000)
4. [at 605d9000] 146 MB ( 9217000)
5. [at 6d346000] 71 MB ( 470a000)
6. [at 697f6000] 58 MB ( 3a3a000)
7. [at 71ce7000] 19 MB ( 1319000)
8. [at 73026000] 18 MB ( 126a000)
9. [at 7e4a1000] 18 MB ( 124f000)
10. [at 7d1d7000] 18 MB ( 1239000)
======= ==========
1352 MB (548cb000)
ans =
481931264
One caution is that this space is shared between any objects you might create as well as objects created by the Desktop, Editor, Current Folder, etc. Once all the java memory is used up, there is the potential of locking up MATLAB, as there might not be enough room to even create an out-of-memory dialog.
There is a solution to running out of Java memory that is usually safe, although sometimes produces unintended consequences if the numbers are made too large. That is to create or modify a java.opts file in the MATLAB startup directory. This allows you to pass JVM options (such as the total and max memory for the heap) on MATLAB startup. Instructions can be found at this solution.
By
Michael Katz
Mike is a developer on the MATLAB Desktop team. When not describing himself in the third person, biking, homebrewing, or rooting for the home team, he's busy trying to make the world a better place for programming.
18:49 UTC |
Posted in Uncategorized, java |
Permalink |
No Comments »
August 10th, 2009
Tab to narrow completions
Tab completion is a great time saver for me, and helps me find a function when I can’t quite remember the exact name. There’s a little known feature that makes tab completion even more useful, though, and it happens to be off by default.
When you press tab in the Editor or Command Window, if there are functions that start with what you’ve typed, you’ll be shown a popup with a list of all the those functions. If you press tab again, then the selected item is inserted at the caret. But what if the popup is showing, and you want to filter down the list of things by typing more text? You can do that if you turn on the following preference:
Preferences -> Keyboard -> Tab key narrows completions (in the Tab Completion section)
When you press “p” at the command prompt, and then press tab, you’ll see a list of all the functions that start with “p”. So far, nothing is different.
But now, if you type “e” after the “p”, and then press tab, the list of items will be re-filtered, and you’ll see only items starting with “pe” .
Typing “a” with another tab really filters the list down into something usable.
You’ll have to press enter to accept completions now (instead of tab), which is an acceptable trade-off for me.
What do you think? Should this feature be on by default?
By
Ken Orr
Ken is a developer on the MATLAB Desktop team. He loves the art of graphic design as well as developing visually pleasing user interfaces - he's one of those 'crazy' Mac guys!
11:00 UTC |
Posted in Command Window, Editor |
Permalink |
24 Comments »
August 3rd, 2009
More dialogs than you can shake a stick at
I’m going to continue my dialog discussion from two weeks ago with more of the MATLAB dialog gallery. I feel a bit like a car salesman, we’ve got so many dialogs to choose from. I’ve grouped them into two categories: dialogs for messages, and dialogs for setting/getting things.
The first group is the msgbox and it’s specialized variants: warndlg, errordlg, and helpdlg. Msgbox is a basic dialog that presents a message to the user with an “OK” button. The warning, error, and help dialogs are all special cases of msgbox with the icon pre-chosen:
The second group provides common dialogs that are either system, Java, or Handle Graphics based, depending on the dialog and platform. These are dialogs for dealing with files, printing, and picking fonts and colors.
File Picker(s)
uigetfile, uiopen, and uigetdir are all file/folder browsers for selecting a file from the system and returning the result to MATLAB. The uiputfile and uisave are for selecting files for saving as determined by whatever your program wants (uiputfile) or for saving workspace variables (uisave).
Here’s what they look like on Windows and MAC
Setting Fonts and Colors
Sometimes you want to present the chooser with a dialog specialized for selecting a complex data type. We’ve provided two dialogs: one for selecting fonts uisetfont, and one for selecting a color uisetcolor.
I didn’t cover printdlg and printpreview which are dialogs for printing MATLAB figure windows. I recommend checking them out on your own. There’s also a progressbar waitbar:
If all these predefined UI’s aren’t enough for you, check out the MATLAB file exchange. Last week’s pick of the week was STRUCTDLG, a dialog for editing the fields of a struct. This week they’ll highlight another submission in the same vein.
By
Michael Katz
Mike is a developer on the MATLAB Desktop team. When not describing himself in the third person, biking, homebrewing, or rooting for the home team, he's busy trying to make the world a better place for programming.
14:08 UTC |
Posted in MATLAB GUI |
Permalink |
3 Comments »
July 27th, 2009
Here’s what your Desktops look like
As promised (though admittedly a couple weeks late), here are the pictures of your Desktops. Only two screen shots were sent in and a couple text-only descriptions — not quite the level of participation I was hoping for. I guess I should have offered up chocolate peanut butter instead of MATLAB t-shirts!
Brett Shoelson, using 7.8 (R009a)
I have several layouts, and I toggle between them depending on what I’m working on. When I’m playing with images (which is much of the time), I like to give my editor and my figure window prominence. Everything is docked. My Editor and Help windows are stacked; my Workspace Browser, Command History, and Current Directory Browswer are stacked and given little space; and my Figure Window is docked on the top left. That gives me a good way to interact with the images.
Matt Fig, using 7.4 and 7.5 (R007a and R2007b)
Here is my favorite setup for my MATLABing sessions. As you can see, I like it simple. I do use the command history, although maybe only 2-3 times a month. That is the reason it is almost blocked out, I can easily get to it by sliding the command window over yet it is not in my way.
I personally feel that using all of the newer tiled windows is very distracting. These little windows both distract and shrink the available command window size. In my opinion they are not necessary at all, and I get the functionality by writing my own functions to do some of these tasks. For example: for easily loading M-Files, MAT-Files and figures, I wrote WHATS. For dealing with variables, I wrote WHOMS and other functions I haven’t put on the FEX. I much prefer something to be there when I need it, yet NOT be there (at all!) when I don’t.
That being said, the one extra I do use, only on work computers, is the shortcut bar. This is useful for launching GUIs quickly. Even then I probably wouldn’t use this at all if it wasn’t for the fact that I set it up this way when I write a GUI for someone else to use, on their computer. I know many people cannot remember the name of the GUI to launch it, so this little bar is handy in this circumstance.
Christian Peel, using 7.6 (R008a)
(no screen shots)
The only thing that I have Matlab display is the command window. I edit in emacs or xemacs via emacslink, and also use that interface for debugging. Obviously I don’t use R2009a, since emacslink has been disabled in that release; I use 2008a.
You’ve made vague hints in the past about the possibility of scripting the editor; an API or a powerful utility for editor keybindings and macros is even more essential now that you’re dropping emacslink. If I’m to ever use the Matlab edtior, I’d like customizable keybindings for opening files, switching tabs, and every possible thing one could do in the Matlab editor. I don’t want to be required to take my hands off of the keyboard when I’m editing and debugging.
Kevin using 7.8 (R009a)
(no screen shots)
I dual monitor my desktop so I typically have the Matlab editor undocked and taking up the main monitor. On the 2nd monitor I have the Variable Editor and the workspace taking up the upper half of the desktop and the command window and command history on the bottom. I use the variable editor and workspace to dubug a lot of my code and see what exactly is going on with the variables. After reading a prior post I’m going to look into docking the Matlab help, I think that would be very convenient.
Ustun Ozgur (version not specified)
(no screen shots)
I use KDE as my window manager on Linux. I use multiple desktops, and each different application resides in a different desktop.
I keep only MATLAB on Desktop 3 for example, so to switch to MATLAB application, I just press Ctrl-F3. To switch to another application, web browser, for example, I switch to the first desktop etc. So, I rarely need to use Alt-Tab, and that way, I can be sure that I will switch to MATLAB when I press Ctrl-F3.
I use two monitors, a 22′ LCD and a 17′ CRT. I keep the Command window on the right monitor, maximized; and the editor window on the left monitor, again maximized. I don’t use Workspace, Current Directory etc. I sometimes go full screen to get even more space, using Alt-F11 in KDE.
I use the window switching shortcuts a lot (Ctrl-0 for command window, Ctrl-Shift-0 for the editor, Ctrl-4 for the doc). I usually use common commands like cd, pwd to navigate through directories, and use the edit command extensively to open files, rather than rely on the GUI. Sometimes I have several files, and rather than trying to select the correct file from the tab bar, I simply type ‘edit filename.m’ to switch to it. (Actually, I rarely type that whole thing thanks to auto completion by the up arrow key, I usually simply type ‘ed’ and then press Up.) To open a particular file in which I remember which variable was used, I use a function ‘g’ to search for that variable, it finds the file using ‘grep’ in File Exchange, and I simply click the hyperlink to open the file in the Editor.
The g function is below. I use the grep created by us here but made the following modifications to ignore case by default, and print line numbers by default:
———–
Change line 84 from
‘-i’ true 0 [] 0 ‘ignore case’
Change line 89 from
‘-n’ true 0 [] 0 ‘print line number’
———–
function g(string,r)
% Searches for the string in m files
% Usage:
% "g snr" searches for snr in the current dir
% "g snr 1" searches for snr in the current dir and subdirs
if ~exist('r'), r = 0; end
if r
grep('-r', string,'*.m')
else
grep(string,'*.m')
end
I use emacs-style keybindings, and smarttab. Other than these, I have some shortcuts, but use them rarely. I use emacs when I’m not programming a GUI, and when I don’t debug.
One last tip for KDE users is that when I press F1 to read documentation in command window, Alt-F5 which maximizes the window works for that little documentation window, so I don’t have to switch to Doc viewer, or I can view two Docs simultaneously.
Yair Altman using 7.4 and 7.5 (R007b and R2008a)
I normally use R2007b. I have access to R2008a, but my largest client uses 7b so I usually use that version. I find that except for the improved code-folding on later versions (and the new java EDT functions), there aren’t many features I really miss in 7b, so it suits me fine.
I keep my Editor in a separate window from the desktop. The reason for this is because I typically write large m-files - large both in width (my code/comment lines often reach 100+ chars) and in length - some files are thousands of lines long. I know that coding extremely large source-code files goes against several important software-engineering practices, but I find that for me it is much easier to code and maintain a well-commented large file than dozens of small files. Anyway, I need plenty of real-estate for my editor, and so it gets its own large window. In it, I typically arrange all the file tabs on the left - this is handier than the default bottom layout, since it enables easy document switching when I have several dozens of files open as I typically do (just imagine the difficulty in managing the same number times 20-50 if I didn’t use large files in the first place…
My desktop usually has the workspace on the left side, with #bytes and class information replacing the default Min-Max fields. This is very useful in my work, which often uses Java and Matlab class objects, complex data structures, and more memory issues than I would care to have. the majority of the desktop area is reserved for the Command Window, which I heavily use for debugging. I often list (’disp’) the complex data structures there, and so I want to have a large area to easily display the data and pinpoint what I need. The history and profiler panels often reside next to the Command Window, hidden from view until summoned (see attached screenshot). Like Ken, I too use the shortcuts menu for often used projects/tasks. I typically reduce the desktop font to 8-9 pixels (depending on the display), in order to cram more data into my desktop & editor. Setting the font face/size, setting compact format, and increasing the history from 5K to the maximum are usually some of my very first actions when setting up a new environment.
For documentation, I usually use the Command-Window ‘help’ or simply open the file (via Ctrl-D in the Editor) to read its help section(s). I find this to be much faster than the ‘doc’ command, or even worse - the online documentation. Sometimes I use them when the text-based help is insufficient, but the help text is usually good enough for me. When I do open doc, via the help links, or via the ‘docsearch’ command (which is surprisingly better/faster than the standard ‘doc’ command), I use a separate window since the doc window seems too crowded when docked in the desktop.
I do not use docking for my figures - each has a separate window, which is often maximized. The reason is that I typically display figures heavily-laden with data plots and/or uicontrols, and they also seem crowded when docked. When I don’t need them, I simply minimize them to the Windows task bar.
My favorite desktop feature is undoubtedly the debugging integration between the editor and the desktop.
Thanks to all those who sumbited their Desktop configurations!
By
Ken Orr
Ken is a developer on the MATLAB Desktop team. He loves the art of graphic design as well as developing visually pleasing user interfaces - he's one of those 'crazy' Mac guys!
12:25 UTC |
Posted in Desktop |
Permalink |
6 Comments »
July 20th, 2009
The GUI way of doing things
While I like to write software for my own pleasure, sometimes I write programs to be used by other people--meaning I have to implement a user interface. I like the input function for asking simple questions of the user. Its syntax is straightforward, but its output clutters the Command Window, allows the user to make mistakes, is annoying for typing long answers (like a file name and location), and most importantly it makes the program feel like the interactive fiction I used to write in BASIC. Fortunately MATLAB comes with a lot of functions that build simple GUIs for asking the user questions.
The most basic of these is the inputdlg function. Instead of just input:
a=input('What kind of Peanut Butter would you like? ','s')
you could use
b=inputdlg('What kind of Peanut Butter would you like?')
Of course, this leaves the user with the availability of typing anything! He could say that he wants oranges, which is not a valid option (or at least not at my local Stop & Shop). Unfortunately MATLAB provides dialogs with ways of restricting the user's choices. Each one with its pros and cons.
The listdlg provides the user with a list of options. It's by far the ugliest, and you can see by default the sizing is bad and it crops our question.
c = listdlg('PromptString','What kind of Peanut Butter would you like?',...
'SelectionMode','single', 'ListString',{'Crunchy','Creamy','Natural','Chocolate'})
Fortunately, there is an easy fix with some additional inputs to listdlg:
c = listdlg('PromptString','What kind of Peanut Butter would you like?',...
'SelectionMode','single', 'ListString',{'Crunchy','Creamy','Natural','Chocolate'},...
'Name','Select Peanut Butter','ListSize',[230 130])
If you have three or less options, you can go the questdlg route:
d = questdlg('What kind of Peanut Butter would you like?', 'Peanut Butter Selection', ...
'Crunchy','Creamy','Natural','Creamy');
Finally, you could also use a menu dialog to present one button per choice:
e = menu('What kind of Peanut Butter would you like?',...
'Crunchy','Creamy','Natural','Chocolate')
As you can see none of these are as pretty as one could make a custom dialog, however they are quite easy to code and useful for programming user interactions. Even more compelling than these general choice dialogs are the ones provided that allow the user to select a file, color, or font. Those will be the topic of another post. You can find more about them here.
By
Michael Katz
Mike is a developer on the MATLAB Desktop team. When not describing himself in the third person, biking, homebrewing, or rooting for the home team, he's busy trying to make the world a better place for programming.
13:20 UTC |
Posted in Command Window, MATLAB GUI |
Permalink |
16 Comments »
July 13th, 2009
Muting breakpoints
Debugging is an integral part of my workflow. One thing I continually encounter is the need to quickly disable all my breakpoints. After spending time inserting breakpoints at the right places with the right conditions, I sometimes want to quickly mute (disable) all of my breakpoints without actually removing them.
In order to do this, I wrote a couple of scripts, which mute and un-mute your breakpoints. I did this by reinstalling each breakpoint with a disabling expression (e.g. turn 'x==1' into 'false&&(x==1)') . To get all of the breakpoints currently installed in MATLAB, use dbstatus.
Here's what dbmute looks like :
function dbmute
%dbmute disables all breakpoints currently set in MATLAB.
% iterate over each entry in the result of dbstatus,
% and disable each of the breakpoints.
breakpoints = dbstatus('-completenames');
for i=1 : length(breakpoints)
muteDbStatusEntry(breakpoints(i));
end
end
function muteDbStatusEntry(dbstatusEntry)
%muteDbStatusEntry disables each breapoint in the given entry.
for i=1 : length(dbstatusEntry.line)
file = dbstatusEntry.file;
line = dbstatusEntry.line(i);
anonymousIndex = dbstatusEntry.anonymous(i);
expression = dbstatusEntry.expression{i};
lineNumberString = [num2str(line) '@' num2str(anonymousIndex)];
newExpression = createDisabledExpression(expression);
dbstop(file, lineNumberString, 'if', newExpression);
end
end
function newExpression = createDisabledExpression(expression)
%createDisabledExpression wraps the given expression in a disabling
% expression if necessary.
if (isDisabled(expression))
newExpression = expression;
elseif strcmp(expression, '')
newExpression = 'false';
else
newExpression = ['false&&(' expression ')'];
end
end
Here is the full suite of files:
dbmute_dbunmute.zip
I'd recommend also creating shortcuts for them so you can quickly access them from the toolbar.
By
Ken Orr
Ken is a developer on the MATLAB Desktop team. He loves the art of graphic design as well as developing visually pleasing user interfaces - he's one of those 'crazy' Mac guys!
10:56 UTC |
Posted in Debugging, Editor, MATLAB Shortcuts |
Permalink |
11 Comments »
July 6th, 2009
Calling Java from MATLAB
So far no one has taken me up on the extra credit from the Interactive Web Pages post. I thought the problem of displaying a figure without an image file was too interesting to pass up, so I figured out the solution myself and put it up on the file exchange. The second challenge involving ActiveX will remain open until I get chance to write up its solution. Or, if you don't have the time to do that, you can still win a t-shirt by sending us your desktop.
My solution to the image challenge involves encoding binary information from an image file as text through the base64 scheme. At first I thought to implement the base64 algorithm myself in MATLAB, but I learned my lesson the hard way a few years ago writing my own md5 hash-computing program (don't ask). This time I wanted to use a readily-available solution. Since there is no toolbox function for this, I decided to take advantage of a Java library since (a) I could use the same library on every platform (instead of needing a different pre-compiled binary) and (b) I am pretty comfortable with Java. My solution takes advantage of the freely available Apache Commons Codec package.
Using Java from a MATLAB program is as simple as using a MATLAB function, particularly if you are used to using MATLAB package functions. You can use any public method in the Java SE API from the command line. The running version of the JRE depends on your version of MATLAB and operating system and determines what API functionality is available from MATLAB. To determine the Java version use the command version('-java'). To change the Java version (not recommended) you can follow these instructions.
For instance instead of MATLAB's str2num you could use: Double's parseDouble.
str2num('2.3')
java.lang.Double.parseDouble('2.3')
ans =
2.3000
ans =
2.3000
Of course, this is a trivial example. Many of our functions such as xmlread make use of more complicated series of calls to java objects. The payoff in the sendmail function comes at the end using the Transport object to send a pre-constructed MimeMessage.
javax.mail.Transport.send(msg)
My base64 program does not use a class from the standard JRE (in fact, neither does sendmail) but instead uses a third party library (Apache Commons Codec) that I happen to know ships with MATLAB and is already available on the classpath.
encoder = org.apache.commons.codec.binary.Base64;
base64string = char(encoder.encode(bytes))';
These examples has three things about using Java that I want to address so you can use other Java libraries in MATLAB: (1) the class path, (2) calling syntax, and (3) data types.
Java Class Path
MATLAB maintains a path for Java classes separate from the search path. That means even if you have a .class or .jar file on the MATLAB path, unless you use javaaddpath you will not be able to use it. To see what is currently on the path use javaclasspath. Running this command you will show you a long list of files that ship with matlab called the Static Class Path and then you'll see the Dynamic Class Path. The dynamic class path is where classes added to the path with javaaddpath will be placed. They can be removed with javarmpath and have to actively reloaded each session of matlab. The static class path comes from $matlabroot\toolbox\local\classpath.txt and are only added to the class path at MATLAB startup. The ones listed here by default are all the Java classes we write (everything in the com.mathworks package). Calling any of these classes directly is not supported and likely to break on a release-to-release basis, but there are resources on the web that make use of these effectively.
Calling Java Functions
Once you add a class to the classpath and it shows up in the javaclasspath, you can use it from the Command Line or from a MATLAB-file. To do that you can use the fully-qualified name (e.g. javax.swing.JTable) or like with MATLAB packages, you can use the import statement to just call the class name (e.g. import('javax.swing.*'),JTable ).
Data Types
Looking at my string to double example you'll see that I passed a MATLAB char array to the java function and got back a MATLAB double, even though methodsview('java.lang.Double') shows that parseDouble takes a java.lang.String as its input. MATLAB will automatically convert primitive types when calling Java methods, as well as convert char arrays to java.lang.String objects when used as inputs. As you can see in my base64 example, I have to explicitly convert the java.lang.String returned by encoder.encode() to a MATLAB char array.
Those are the basics of calling Java. In future posts I hope to discuss memory management with Java (a topic of some recent technical support queries) as well as threading issues, as related to GUIs.
By
Michael Katz
Mike is a developer on the MATLAB Desktop team. When not describing himself in the third person, biking, homebrewing, or rooting for the home team, he's busy trying to make the world a better place for programming.
11:33 UTC |
Posted in java |
Permalink |
9 Comments »
Recent Comments