For the last year, Apple's Java proposition for Mac OS X has been that it will be the best platform "on the planet" for running J2SE applications. The Java team at Apple wants developers to, at the very least, commit to deploying on the Mac. Their next goal is to convince developers that OS X is a great platform for developing Java applications. In future articles, we'll look at tweaking your Swing application to run more like a native Cocoa app and how to take advantage of functionality available to other Cocoa apps.
In this article we'll look at how to take a Swing application that was never designed to run on the Mac and run it in progressively easier ways. As our example, we'll look at the JUnit developer tool available from JUnit.org. You use this tool for unit testing as part of the XP (extreme programming -- not the office product from Microsoft) methodology. No longer will Mac programmers have tool envy -- we can run these 100% Pure Java tools too.
Finally, this month it's time for a community challenge. If it's this easy to run pure Java tools not intended for a Mac, why not download the latest Jini distribution and run its GUI tools with the Aqua look and feel?
(As a side note, I realize there are many different types of Java programmers working with Mac OS X. There are the hardcore Unix guys who code in vi and emacs and spit out shell scripts in their sleep. There are the GUI guys who want to use powerful RAD tools and can hardly wait for JBuilder to go final on the platform. There are a ton of hobbyists and a core of commercial developers. This column will try to balance those needs. If you have thoughts on how I can better meet your needs, please write me at email@example.com.)
OK, there's not much to this part, but that's the point. Go to JUnit.org and follow the links to download the latest version of JUnit. Currently, that's version 3.7. A Zip file downloads to your home machine and casually unzips itself into the directory
junit3.7 using the helper application StuffIt Expander. This free, long-time Mac favorite is installed by default into the Applications/Utilities/ folder. Many of your Windows cohorts are clicking the "I Agree" button on the WinZip evaluation license for the 83rd time -- almost a year after they downloaded it. You didn't even have to install the application!
If you are more of a hardcore Java programmer and "don't want to use no stinkin' helper application," you can start by just downloading the Zip file. Back in the Applications/Utilities/ folder, you'll find the terminal. Open it up and navigate to the directory containing
junit3.7.zip. Type in
jar xvf junit3.7.zip. This is Mac OS X; you've got options.
Check out the installation directions in the ReadMe file. We've already performed the first step by unzipping the file. The second step asks us to add
junit.jar to the class path. For example:
set classpath=%classpath%;INSTALL_DIR\junit3\junit.jar. By now you can plainly see that this distribution is designed for a Windows audience. Actually we can set the class path by modifying our
.tcshrc file. Because many Mac programmers are new to Unix and the enhanced C shell
tcsh, we'll defer talking about modifications to this file to a later article. We can set the class path from the command line using the
The next step is to run the program. We'll do so, adding the class path specified above. Open up a terminal window and navigate to just inside the
junit3.7 folder. Now enter the command
java -cp [Install Dir]/junit3.7/junit.jar junit.swingui.TestRunner junit.samples.AllTests. You should, of course, replace "[Install Dir]" with the directory in which you installed JUnit. In my case,
junit3.7 is a subdirectory of
/Users/dhs/ so my class path is
Oops -- this doesn't look good. Don't panic. The reason that the class
junit.samples.AllTests couldn't be found is that your current location isn't part of class path. We'll fix this by adding the current directory to the class path and modifying the previous call to be the following:
java -cp [Install Dir]/junit3.7/junit.jar:. junit.swingui.TestRunner junit.samples.AllTests. Note: Adding "." to the class path adds the current directory. Windows users should note that Mac programs use the Unix separator ":" and not ";". This time the result is much better.
That's not bad. It almost has the Aqua look and feel. It would be nice if the JUnit menu appeared where Mac menus are supposed to appear, but we can live with this approximation. The three buttons in the upper-left corner behave mostly the way they should.
If we had a double-clickable app for Jini tools, Mac could be the platform of choice for Jini development. Is there any work underway in this area?
If you click on the green button, there can be a redrawing problem with the larger window that is corrected if you do a live resize by grabbing the lower-right corner. There's more, however, to the Mac experience than just being able to use the genie effect while shrinking JUnit down to the dock. In the next section, we'll look at making the user experience more Mac-like.
You don't want a user to have to navigate to the right directory and type in the class path every time they run JUnit. One of the cool things Apple did in shipping Mac OS X was to ship the developer tools along with the operating system. We'll use
MRJAppBuilder to quickly package JUnit up as a double-clickable app. You'll find
MRJAppBuilder in the /Developer/Applications/ directory. Start it up and let's start filling in the various fields in the Application tab pane.
In our first shot, let's fill in the fields with the same values we used from the command line. There the main class name was
junit.swingui.TestRunner and the class path was
[Install Dir]/junit3.7/junit.jar:. . This class path is interesting because it uses one absolution path and one relative path. The "." assumes that we're inside of the
[Install Dir]/junit3.7 directory, so we're forced to put our output file there. We could change the "." to an absolute path and place the output file anywhere. For now, we choose the clever name
junit.app for our output file and set the fully qualified name as
This is fine if you are just creating a quick application that will sit on your own machine. If you use absolute paths, you can move
junit.app anywhere on your machine. On the other hand, if you are interested in using this technique to deploy applications to other users, you should use relative paths. This way your application is not dependent on the directory structure of the user's machine. In our case, we can change the class path to
junit.jar:., and choose "Build Application".
You'll notice that we didn't enter the name of the test suite being run. To add a parameter, select the Java Properties tag. You'll see that you can add properties to be set and modify many of the ones that you see. If you'd like, add the parameter
junit.samples.AllTests and rebuild your application. In this case, we won't notice a real difference, but with other applications this will be useful.
Perhaps the hardest thing about working with Jini is getting all of the pieces working on your machine. There are many sites that are devoted to long descriptions of the steps involved in getting
rmid, a web server, Reggie, Mahalo, and Outrigger up and running.
Our first community challenge is to use the discussion forums on this page to come up with a very simple solution for running Jini on Mac OS X. You can find out more about Jini at Jini.org, and in Jini section of the Sun Microsystems web site. You can start up Jini with a GUI tool that comes with the distribution. To do this, just load the
jini11_unix.properties file you will find in
Daniel H. Steinberg is the editor for the new series of Mac Developer titles for the Pragmatic Programmers. He writes feature articles for Apple's ADC web site and is a regular contributor to Mac Devcenter. He has presented at Apple's Worldwide Developer Conference, MacWorld, MacHack and other Mac developer conferences.
Read more Java Programming on the Mac columns.
Return to the Mac DevCenter.
Copyright © 2009 O'Reilly Media, Inc.