Introducing JCommander 1.4.

Here is what’s new:

• You can now specify default values in a more flexible way than at field declaration time (documentation).
• You can use string converter factories instead of specifying converter classes on each @Parameter annotation (documentation).
• The usage is now prettier:

  Usage: <main class> [options]
    Options:
      -debug          Debug mode (default: false)
      -groups         Comma-separated list of group names to be run
    * -log, -verbose  Level of verbosity (default: 1)
      -long           A long number (default: 0)
  

• Many bug fixes and a more clever option parsing to cover odd cases.
• This release actually contains more features but I’m not telling.

All the goodness available at the usual place. Operators are standing by, order now!

If you read the voluminous material that describes the concepts behind the Option class, there are two main benefits:

• It saves you from NullPointerException
• It allows you to tell whether null means “no object” or “an object whose value is null”

I claim that Option solves none of these problems. Here is why.

Here is a typical blog post showing the wonders of Option (I’m not singling out this particular person, you will find many posts making similar claims).

The examples in this post show that with the Option class, you can now have hash tables that contain null values and never be confused when a get() returns null. Fine, but in practice, I find that hash tables allowing null values are rare to the point where this limitation has never bothered me in fifteen years of Java.

The claim that Option eliminates NullPointerException is more outrageous and completely bogus. Here is how you avoid a null pointer exception with the Option class (from the blog):

val result = map.get( "Hello" )

result match {
  case None => print "No key with that name!"
  case Some(x) => print "Found value" + x
}

See what’s going on here? You avoid a NullPointerException by… testing against null, except that it's called None. What have we gained, exactly?

The worst part about this example is that it forces me to deal with the null case right here. Sometimes, that's what I want to do but what if such an error is a programming error (e.g. an assertion error) that should simply never happen? In this case, I just want to assume that I will never receive null and I don't want to waste time testing for this case: my application should simply blow up if I get a null at this point.

And you know what construct does exactly this? NullPointerException! Try to reference a null pointer and that exception will be thrown. It will make its way up the stack frames since you probably never catch it anywhere (nor should you) and it will show you a clear stack trace telling you exactly what happened and where.

In other words, it seems to me that the Option class is bringing us back into the stone age of using return values to signal errors. I can't imagine this being a progress (and I'm equally irritated at the Go language for making the same mistake).

When it comes to alleviating the problems caused by null pointer exceptions, the only approach I've seen recently that demonstrates a technical improvement is Fantom (Groovy also supports a similar approach), which attacks the problem from two different angles, static and runtime:

• Static: In Fantom, the fact that a variable can be null or not is captured by a question mark appended to its type:

  Str   // never stores null
  Str?  // might store null
  

  This allows the compiler to reason about the nullability of your code.

• Runtime: The second aspect is solved by Fantom's "safe invoke" operator, ?.. This operator allows you to dereference a null pointer without receiving a null pointer exception:

  // hard way
  Str? email := null
  if (userList != null)
  {
    user := userList.findUser("bob")
    if (user != null) email = user.email
  }
  
  // easy way
  email := userList?.findUser("bob")?.email
    

  Note how this second example is semantically equivalent to the first one but with a lot of needless boiler plate removed.

So, can someone explain to me how Option addresses the null pointer problem better than Fantom's approach?

]]> 31 http://beust.com/weblog/2010/07/28/why-scalas-option-and-haskells-maybe-types-wont-save-you-from-null/ Cedric http://beust.com/weblog/?p=778 2010-07-26T18:09:59Z 2010-07-26T18:09:59Z

public class App {

  @Subscriber
  public void event1(NotifyEvent ne) {
    System.out.println("event1: " + ne);
  }

}

MessageBus mb = new MessageBus();
mb.register(new App());
mb.post(new NotifyEvent("notify"));

    
    	com.beust
    	jcommander
    	1.3
    

I’m not a big fan of Firefox’s latest experimental feature “Tab Candy” for a couple of reasons.

First, I don’t think that having an application reinvent its own window management system is a step in the direction of better usability. Whatever operating system you are using, it’s already difficult to navigate through windows efficiently as it is, but after some time, you become reasonably proficient with it. And now, you find yourself having to learn yet another window management paradigm, with shortcuts that are by definition different from the ones you are used on the desktop, and a space and interaction logic that is going to be subtly different from the OS.

Second, I tend to use the keyboard to select my windows a lot more than the mouse, so functionalites like Exposé are of no use to me. Tab Candy seems to be no different.

What I really need is an extension that lets me switch to a tab by typing a few letters from either its title or its content. Just now, as I was starting to write this entry, I found myself having to find the article I linked above. I have currently about ten Firefox windows open and each of them has anywhere between one and ten tabs. Finding the correct window required a few Alt-Tab and quite a few Alt-~. And even then, the correct window popped up on my screen several times but I missed it because the tab I was looking for was the fourth in in a group of ten.

What would have been ideal: a text box where I can type “candy” and a drop down containing all the tabs that match the string I just type.

I’m aware of a few Chrome extensions that do this but all of them open a new window when you select the tab, instead of just taking you to the existing one, which defeats the purpose of the idea since it loads the page again and loses the position you were last reading.

Please let me know if you know of any extension that accomplishes what I’m looking for (ideally on Firefox).

]]> 6 http://beust.com/weblog/2010/07/24/firefoxs-tab-candy-pretty-but/ Cedric http://beust.com/weblog/?p=766 2010-07-20T15:12:43Z 2010-07-20T15:12:43Z

Apple gracefully donated the source code of MacPaint and QuickDraw to the San Jose Museum of Computer History. For those of you who don’t want to bother with downloading and unzipping, here are the full sources.

]]>

Type converters

By default, JCommander parses the command line into basic types only (strings, booleans, integers and longs). Very often, your application actually needs more complex types, such as files, host names, lists, etc… You can now write your own type converters by implementing the following interface:

public interface IStringConverter<T> {
  T convert(String value);
}

For example, here is a converter that turns a string into a File:

public class FileConverter implements IStringConverter<File> {
  @Override
  public File convert(String value) {
    return new File(value);
  }
}

Then, all you need to do is declare your field with the correct type and specify the converter as an attribute:

@Parameter(names = "-file", converter = FileConverter.class)
File file;

JCommander ships with a few common converters (e.g. one that turns a comma separated list into a List<String>.

Simple internationalization

The new @ResourceBundle annotation lets you specify the bundle to be used on your parameter class itself. After this, JCommander will use the default locale to resolve your string:

@ResourceBundle("MessageBundle")
public class ArgsI18N2 {
  @Parameter(names = "-host", descriptionKey = "host")
  String hostName;
}

Password parameters

If one of your parameters is a password or some other value that you do not wish to appear in your history or in clear, you can declare it of type password and JCommander will then ask you to enter it in the console:

public class ArgsPassword {
  @Parameter(names = "-password", description = "Connection password", password = true)
  public String password;
}

When you run your program, you will get the following prompt:

Value for -password (Connection password):

You will need to type the value at this point before JCommander resumes.

Installation

JCommander is available either directly or from Maven:

    
      com.beust
      jcommander
      1.1
    

• Support for multiple definition classes. Christian Gruber pointed out that it might be nice to not be restricted to just one class when you declare all your @Parameter fields. For example:

  ArgsMaster.java

  public class ArgsMaster {
    @Parameter(names = "-master")
    public String master;
  }
  

  ArgsSlave.java

  public class ArgsSlave {
    @Parameter(names = "-slave")
    public String slave;
  }
  

  You then pass these objects when you create your JCommander instance, which will collect all the parameter definitions from both objects.

  ArgsMaster m = new ArgsMaster();
  ArgsSlave s = new ArgsSlave();
  String[] argv = { "-master", "master", "-slave", "slave" };
  new JCommander(new Object[] { m , s }, argv);
  
  Assert.assertEquals(m.master, "master");
  Assert.assertEquals(s.slave, "slave");
  

• Support for required. For simple applications, you can just declare @Parameter(required = true) and JCommander will enforce that all such parameters are assigned a value (example).
• Internationalization. You can now use the standard Java resource bundle mechanism to write the descriptions of your options and have JCommander automatically use the translated strings (example).
• Parameters that take more than one value (arities). This functionality allows you to parse command lines such as:

    java Main -pairs slave master foo.xml
    

  Here, the parameter -pairs needs the next two arguments (example).

All these features are now available in JCommander 1.0, which Maven users can download automatically with the following dependency:

  com.beust
  jcommander
  1.0

Recently, I got tired of having to handle command line parsing manually. I took a look at existing frameworks and all the ones that I found (JOpts, JArgs, commons-cli) suffered from the same limitations that I was trying to avoid: they barely cut down on the boiler plate code and they are not very type safe.

So I came up with my own framework, which I called JCommander.

The snippet of code above should give you a pretty good idea of what JCommander looks like, and if you need more information, just head over to the main site. I have already integrated JCommander in TestNG and it has already reduced the code base to handle this simple task significantly.

Let me know what you think.