After upgrading to Lion from Snow Leopard, I ran into an immediate problem running unit tests for an application that uses JasperReports. JasperReports makes use of AWT and Swing regardless of whether the application calling it has a GUI interface. Normally this isn’t a problem, and it wasn’t a problem in Snow Leopard, but it has become one on Lion.

The error I received was:

java.lang.NoClassDefFoundError: apple/laf/CoreUIControl

The issue is that when the unit tests run, JasperReports tries to instantiate a Swing control and the Java run-time tries to initialize the default Apple Look-and-Feel. I’m not sure whether Lion has secured access to that (preventing unsigned applications from using it) or whether there’s another configuration issue in Lion. Regardless, the fix is simple for my purposes.

The Java default look-and-feel can be overridden at the command-line using a Java property:

-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel

That will switch the Java instance from using the Apple Look-and-Feel to using Metal. BTW, running “headless” won’t fix the problem. Headless means telling the Java runtime not to make use of the GUI.

If you’re using Maven you might find that your unit tests still aren’t working, in that case, you need to tell Maven to pass the properties down to sub-processes:

mvn -DargLine="-Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel"

And, in case you’re wondering why you would want to run headless, it keeps OS/X from treating your command-line app as a GUI app if it uses AWT or Swing. The property to trigger headless operation is:

-Djava.awt.headless=true

Once upon a time, I did all my development in Linux. It was quite nice: I did my editing in vim and sometimes Eclipse, I typed commands into a terminal window, and managed my software using apt. I was fairly happy with this setup.

With time though, I started to feel the pain of dealing with Windows and its users. I needed to use Microsoft Office for 100% compatibility, suspend and restore reliably, access Exchange without issues and use software that didn’t look like it’s UI was designed by a kindergartner.

So, I abandoned Linux and tried to make Windows work. The command-line was hell, the development tools stunted and broken and it looked even worse then Linux. But I could get Office, and my Exchange issues were gone.

When the pain became unbearable, I went off the reservation and decided to try using OS/X. At first it was a complete pain. The copy and paste keys were different! That’s just change for change sake, right? Until the first time I did a copy and paste in a terminal window and realized the keys didn’t conflict with Ctrl-C.

The window handling just worked. I wasn’t playing around with the window manager du jour and thanks to excellent text editors like TextMate and BBEdit, I didn’t have to deal with vim anymore. And, even better, Terminal.app was pretty good. And if I didn’t like it, there was iTerm and now iTerm 2.

I had a VM of Linux (and Windows) in case I needed them on OS/X, but I never needed the Linux VM and only used the Windows VM when I needed to check code for Windows compatibility.

And, best of all, I could automate anything I wanted to. Thanks to LaunchBar, Automator and AppleScript, I could automate almost everything I wanted to. PDF workflow handling and services are awesome. This was the best decision I’ve made for my workflow and productivity.

Packages

Not everything was wine and roses. I needed software to do my job. IntelliJ became my IDE of choice – that worked beautifully. Microsoft Office 2011 runs well and is completely compatible. Apple Mail (and iCal) has no issues with my companies Exchange server. Printing, which shares a subsystem with Linux, works great in the home but can be hit or miss in support of those giant industrial copy/printers.

And, of course, I wanted command-line tools. Homebrew worked well here for the only three things I ever needed to install: git, imagemagick and python. I’ve installed a few other things using homebrew (nmap and others) but that was just for playing around. It’s actually worked out better then apt-get because I don’t get gigantic lists of packages to update on a regular basis.

When you’ve had to deal with the Linux version of DLL hell, homebrew is a breath of fresh air.

Darwin

And, best of all, I don’t have to give a crap about my kernel version anymore. I don’t have to know or care that it’s darwin vs. Linux 2.6.3.43.1.3.4.6.2. Or which patches my chosen distribution has applied, or whether my distribution is in political favor with the kernel developers or not. It just works.

Though the darwin support for dtrace is pretty amazing.

Workflow

The OS/X terminal is good. If you have issues with it, you’re probably using vim or emacs full screen. Wow. Feel free to use iTerm 2 if you are.

OS/X is highly customizable as well. Managing daemons is far better then most Linux systems due to the modern init replacement. Luckily for Linux, projects like SystemD are catching up.

And with application launchers like LaunchBar, QuickSilver, Sparks, etc. I can work from the keyboard constantly.

Open source

And, as a developer, not having to deal with the open-source politics is a win. I don’t have to defend my betrayal of open-source rights when I choose a closed-source video driver and yet I can still install pretty much any open source project.

And support for future ruby platforms like rubinius and macruby is actually better on OS/X.

Closing thoughts

If everything I said went over your head, and you think I’m crazy, it just means your time hasn’t come yet.

I remember reading Alex Sellier’s counter thoughts on this matter yesterday and being amazed that different people have different viewpoints, both of which are totally valid for them and realizing that this isn’t a zero-sum game. What you believe isn’t the word from God and neither is what I believe. Make your own (hopefully informed) decisions and choose what’s right for you.

I sure do love the Toto blogging engine, though.

I needed a very simple mechanism to perform a gender sanity check on a first name to promote error checking on data entry. After some quick Google searches I compiled a consolidated list of first names and the probable gender of the person with that first name.

This method is obviously error prone. It is not intended to be a 100% validation of a gender based on the first name, it’s intended to be used as a red flag when checking a given gender against a given first name.

You can test individual names using the check-name page or you can just download the CSV file and use it in whatever manner you wish.

If you do development on a Mac and you have a Unix background, you immediately start noticing missing tools and utilities. OS/X doesn’t have an apt-get for package management (or even one of the lousy RPM variants). There are options though. Two of them have been around for quite a while, MacPorts and Fink.

MacPorts is strongly influenced by the BSD ‘ports’ system. Ports are essentially recipes for taking source code and build scripts and making them compile and install on the target operating system. BSD ports organize the recipes and source code into a tree that make adding software easy.

Fink takes a different approach. It’s based around Debian’s packaging tools and apt-get. Fink mainly manages pre-compiled/pre-built applications. So the applications you install using Fink don’t need to be compiled and built on your system.

Between the two of them, MacPorts tends to be the easier solution. Software is more up to date, there are more options, it’s somewhat less intrusive into your system and you get new versions faster when Apple updates OS/X. Ironic when you consider that MacPorts code is compiled on your system while Fink is just downloading binaries.

But MacPorts is still no walk in the park. Even though it’s less intrusive then Fink, it still isn’t a great citizen on OS/X. MacPorts eschews many of the system libraries and software already available in OS/X for other variants. Installing a seemingly simple utility might somehow require a new version of Perl, Python or other set of large software.

Homebrew is a reaction to the complexity of MacPorts. It’s extremely simple. Homebrew appears to be targeted more at individual packages. If you want to pull in the entire world of open source software and want every package, then you’re better off with MacPorts or Fink. But if you’re looking for the occasional tool or utility, Homebrew is for you.

Installation is dead simple:

--- sh
ruby -e "$(curl -fsS http://gist.github.com/raw/323731/install_homebrew.rb)"

That downloads the installer and executes it. Homebrew is based on Ruby and the install script is no exception.

By default Homebrew will try to take over your /usr/local directory. If you’ve already installed anything there (MySQL, etc.) then Homebrew will complain. You can install Homebrew anywhere, but then you’ll have to add that directory to your PATH.

Homebrew also assumes that you’re on a single user system. If that’s not you, then you definitely want to install it to a user-specific location and alter your PATH. But, for most people, the default works just fine.

Once installed, you control Homebrew using the brew command. You can find packages using brew search, install them using brew install and remove them using brew uninstall. Just like any other package manager, Homebrew tracks package dependencies so it will pull in dependent packages as needed and warn you if you try to uninstall a required package.

The major benefits of Homebrew over MacPorts are simplicity, lack of intrusiveness, and speed. Homebrew’s recipes try very hard to use the existing tools and libraries in OS/X, so they tend to build much faster and require fewer dependent libraries. The recipes themselves are Ruby scripts and are small, simple to understand and easy to create and modify. But, honestly, if all you want is to install wget and newer versions of git and other open source tools, you’ll never need to look at or understand Homebrew’s recipes. Just brew install wget, brew install git and be happy.

I didn’t see this one coming. Oracle just sued Google over patents in Java. Oracle contends that Google’s clean room implementation of Java – Dalvik – violates several patents.

Here are the patents referenced in the suit:

• 6125447 – Protection Domains to Provide Security in a Computer System
• 6192476 – Controlling Access to a Resource
• 5966702 – Method and Apparatus for Preprocessing and Packaging Class Files
• 7426720 – System and Method for Dynamic Preloading of Classes through Memory Space
• RE38104 – Method and Apparatus for Resolving Data References in Generate Code
• 6910205 – Interpreting Functions Utilizing a Hybrid of Virtual and Native Machine Instructions
• 6061520 – Method and System for Performing Static Initialization

These are all pretty low-level features. They boil down to how Java handles security, just-in-time compiling, how class files are structured and how the system sets up code.

This is a pretty nasty attack by Oracle. One can only assume that they tried to shake down Google before filing the actual suit. Assuming that the patents stand I don’t see how some of them can be worked around by Google without changing Java.

According to the lawsuit, what does Oracle want? Treble damages and all copies of Android destroyed. That clearly won’t happen so the question is whether Google will cave and license Java from Oracle or fight the suit.

Since the suit was filed at all, I’m assuming that the licensing conversations went poorly. But Google has never been a company to drag through the courts while Oracle most definitely is. So my guess is that unless the patents are quickly invalidated that Google will end up licensing the patents from Oracle.

Here’s another micro-tip. I needed to decompile a Java class to step through for debugging. But I wanted to pick and choose classes from the Finder. No problem, this is OS/X and Automator is your friend.

If you don’t already have it, download JAD (Java Decompiler) from http://www.varaneckas.com/jad.

Then open up Automator and create a new Service. Tell Automator that the service will receive only selected files or folders. You can use any application or just Finder, your call. If you like, filter out only the class files. Then comes the real work. Specify the zsh shell and give it this command line:

jad -lnc -o -d `dirname $1` $1

You’ll have to specify the full path to the jad executable if it’s not in your path. The -lnc tells JAD to add original line numbers as comments – very helpful when debugging. The -o tells JAD to overwrite output files without asking. And the -d tells JAD where to put the decompiled files. In our case we’re only allowing a single file at a time and we’re putting the decompiled file into the same directory as the original class file.

When you’re done, it should look something like this:

Save the workflow service and name it whatever you like, in my case I named it ‘Decompile Java Class’. Close any open Finder windows and re-open them. Now when you right click on a file you’ll see ‘Decompile Java Class’ as an option in the Services menu. Select it and JAD will decompile your selected class file into a .jad file.