ProcessBuilder is a great relief. Or will be, when I have 1.5.0 on Mac OS, and can thus afford to lose 1.4.2 compatibility there. At the moment, it's mostly annoying that I can't fix my code on Linux without losing Mac OS. But the prospect of finally having decent control over process creation (and after only a decade of waiting!) is quite exciting. As is the fact that System.getenv has been unbroken too, even if they haven't fixed the name.

(Now I guess I can start holding my breath for decent signal-sending capabilities that don't require me to get naughty with reflection. Sometimes you know you're only writing something for Unix, and don't care that what you've written doesn't necessarily translate to Windows. Bummer; stick it on the pile with all those applications that look terrible on Mac OS because their authors haven't even considered other platforms. Portability is rarely free, and engineering appropriate abstractions to make it free is usually difficult. Deal with it. Until Sun accepts this, we'll have to keep living in denial, and keep writing sub-standard software.)

One thing I find interesting (in a bad way) about ProcessBuilder, though, is the Smalltalk/Objective-C style of naming. So instead of:

File getDirectory();
void setDirectory(File directory);

we have:

File directory();
void directory(File directory);

which is fine – if I'm completely honest, I think I probably prefer it – but not very Java-like. This worries me a little. One of the great things about Java is the completeness of its libraries. And one of the things that makes that size of library manageable is its uniformity; the way you can just guess what something will be called and how it works — and be right.

No matter how funky other languages' traditions and idioms may be, I don't think you can graft them on to Java without paying a price. Particularly if you're not going to revisit the entire library, which I'm sure the Binary Compatibility Boys wouldn't dream of, for better or worse.

There's a difference between overlapping idioms like these two ways of naming accessors, and idioms that have no parallel in one of the languages. For example: other languages make a distinction between asType and toType (wrapping the original object versus creating a new object reflecting the original object's current state), and – if a few existing JDK methods hadn't spoiled things by using the two synonymously – that could usefully be "grafted on". But where you already have a strong well-known idiom for something, as we do with getters and setters in Java, and your new idiom doesn't introduce a useful distinction, things can only get worse.