Monday Feb 08, 2010

Tip: Installing JDeveloper on Mac OS

Having gone through this a couple times now, I wanted to capture a couple tips that make JDeveloper installation easy for MacOS X users. The installation itself is very simple: a 'java -jar <jar_file>' does it all. But there is one helpful and one mandatory step you should take first. Thanks go to Steve DiMilla for trying these steps as well.

1. Set JAVA_HOME in your environment

While not really necessary (AFAIK), your life may be easier if you do. You can always just export the environment variable in a terminal, but you might as well do it properly and make it available to your whole environment. That way any process running as you has the information available. I've covered this in a previous blog, but here it is again, nice and simple. Assuming you haven't already:

  1. Create a directory in your home folder called .MacOSX (note the dot, the capitalization, etc.).
  2. Create a file in that directory called environment.plist.
  3. Copy the following into your ~/.MacOSX/environment.plist file:
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
    <plist version="0.9">
        <!-- When changing this, also run Java Preferences and change there. -->
  4. Log out and log back in.
That's it. You can use a different version than I'm using above, but at the time of this writing 1.6 is the latest. Note that Versions/1.6 is a symbolic link to Versions/1.6.0, at least right now on my machine. I prefer setting my home to 1.6 so that, presumably, if Apple removes 1.6.0 at some point and replaces it with 1.6.1, I won't have to change anything. I hope.

2. Create an rt.jar link to classes.jar

The installer for JDeveloper expects the Apple JDK to look like other JDKs. Specifically, it's looking for $JAVA_HOME/jre/lib/rt.jar, which doesn't exist by default. You're going to change that. This information is available as part of the installation insructions (section 6), but they recommend you enable the root user and do the following as root.

(Side note: enabling the root user is different on different versions of MacOS X, so the official instructions may not work for you. Here is Apple's information on enabling root.)

While doing this as root works fine, as long as you have administrative privileges, you can do the same thing with sudo and save yourself a couple steps. Here you go:

  1. cd $JAVA_HOME
  2. sudo mkdir jre (use your login password when prompted)
  3. cd jre
  4. sudo mkdir lib
  5. cd lib
  6. sudo ln -s ../../../Classes/classes.jar rt.jar
There you go. To test, head on into $JAVA_HOME/jre/lib and run a simple 'jar tvf rt.jar' if you'd like.

Now, go ahead and install. Then watch the cool overview demo to see it in action.

Tuesday Oct 13, 2009

Fun With the 'open' Command

In MacOS (I'm running 10.5), the open command is one of those little tools that keeps giving and giving. Sure, it seems simple enough. From the man page:

     The open command opens a file (or a directory or URL), just as if you had double-
     clicked the file's icon. If no application name is specified, the default applica-
     tion as determined via LaunchServices is used to open the specified files.

But I've discovered I use it more and more while I work. In case you haven't thought of all these already, here are some of the things you can do with open besides the very obvious use opening URLs.

Open windows in Finder that Mac won't let you get to normally:

For instance, if you want to open a Finder window to see your original photos under ~/Pictures, it's simply (am using autocompletion to escape the spaces in the path):

     open ~/Pictures/iPhoto\\ Library/Originals/
Trying to click through this in Finder normally will just bring up iPhoto. Generally, that's the correct behavior, but some of us really want the ability to mess things up manually.

Open compressed archives simply:

This one is nice during development. I work on the GlassFish application server, and often hack it all up and need to reset my installation back to some known snapshot. After installing and doing whatever configuration I need, I can tar/gzip the whole thing up into an archive. Then when I need to "reinstall," it's as simple as:

     rm -rf glassfishv3 && open gf3.tar.gz
Sure, that's not much less typing than unzipping and piping the result to tar, but it's short enough that I don't need to think about it.

Edit text files quickly:

Some file types are, by default, opened with heavyweight apps. Opening an xml file, for instance, brings up OpenOffice on my system. The '-e' flag to open will instead bring whatever file you specify up in TextEdit:

     open -e domain.xml
I'm just as likely to use emacs in this case, but sometimes I want to have that text editor open for a while and not taking up one of my terminal windows (so I don't lose it in the cmd-1, cmd-2, cmd-n shuffle). You can also use the -a flag to specify a particular app, which can also be a modest time saver. Just let autocompletion do the path work for you.

Pipe process output to a text editor:

This is a little time saver when you'd normally pipe output to a file and then open that file for editing.

     svn diff | open -f

Find out when a job is done:

On my Solaris machines, I used to have an alias that would print ctrl-g characters (beeps). So I could start a process and have the terminal beep at me when the process was done. iTunes makes this much more fun. Before you try setting an alias (or adding to a script), do the whole open command by itself to let MacOS handle all the escaped characters for you. Then cut and paste, as in:

     alias go="open -g ~/Music/iTunes/iTunes\\ Music/Israel\\ Kamakawiwo\\'ole/Ka\\ \\'Ano\\'i/03\\ Kainoa.mp3"
Then I can run some long process like mvn -u install && go and the music starts when it's done. The '-g' flag in the open command keeps the application in the background.


Whatever part of GlassFish or the Java EE world that catches my attention. (Also, go Red Sox.)


« July 2016