Category Archives: Java


In a project we’re working on, a Java source file is auto-generated: method names on the interface that is generated (ready for implementing) are based on the HTTP method and URL in the RAML.

The result is this:


What we have here is a single identifier that, at 83 characters in length, is too wide to fit in standard 80-character-wide terminal.

File under “Why Java Is Not My Favourite Programming Language”.

(No, there is no reason why a similar identifier could not in principle be generated in some other programming language. But no other language has the programming culture that make such things possible.)

Dependency injection demystified

At the moment, most of my actual coding work is in Java — which is a novelty for me, as it’s not a language that I am naturally inclined to like. But as I’m coming to grips with it, I’m finding that Java in 2015 is a rather more pleasant language than the one I wrote a CQL parser in back in 2002. The main problem with it is the culture, and in particular the huge vocabulary of patterns, which takes a long time to learn.


So here is today’s brief lesson, which is on dependency injection. Continue reading

We can’t afford to write safe software

Let’s start by thinking about a very simple example.  I’ve recently switched to using Ruby as my language of choice, after a decade as a Perl hacker.  Ruby does a lot of things more nicely than Perl, including having proper object syntax, simple everything-is-an-object semantics, a sweet module/mixin scheme and very easy-to-use closures, so I’ve mostly been very happy with the switch.  In so far as Ruby is a better Perl, I don’t see myself ever writing a new program in Perl again, except where commercial considerations demand it.

Continue reading

Slicing your 2D class/function matrix vertically or horizontally

Today, I want to talk about a problem that I don’t have a good solution for, and throw the floor open in the hope that someone else does.  Teach me, O commenters.

Suppose your program has to build a tree structure — for example, as the result of parsing a query in some kind of structured query language.  And suppose that, having built the tree, you want to do several different operations that involve walking that tree.  How do you design that program?

To make it concrete, consider my (rather aged) package CQL-Java, which — get ready for a big surprise — provides a CQL parser in Java.  CQL is a conceptually simple but very precise and expressive query language used in information retrieval, but for our current purposes all we need to know is that it supports structured boolean queries like these:

kernighan and ritchie
(kernighan and ritchie) or fowler
kernighan and (ritchie or pike)

Our task is to parse such queries, and to be able to render them out either in an XML format called XCQL or in Index Data’s ugly but functional Prefix Query Format.

Continue reading

Early experiments with JRuby

I’ve made no secret on this blog that I am fond of Ruby, and that I find Java rather verbose and awkward.  But at the same time, I realise you can’t deny the commercial importance and ubiquity of Java.  I’ve been hoping to find a way to combine the stronger points of both languages, and of course JRuby gives me just what I need.

So I’ve been experimenting with it for the last few days, and I like what I see.

For example, whereas in vanilla Ruby you might write:

def qsort(a)
return a if a.length <= 1
pivot = a.delete_at rand(a.length)
return (qsort( { |x| x <= pivot }) +
[ pivot ] +
qsort( { |x| x > pivot }))

In JRuby, you simply write:

jrequire ‘java.lang.Jruby.*’
jrequire ‘java.lang.util.ArrayList’
def public ArrayList<T> qsort<T> (theArray is ArrayList<T>)
if Arrays.lengthOfArray(theArray) <= 1
return theArray

theRandomInteger = RandomIntegers.rand(theArray.length)
pivot = Arrays.elementAtIndex(theArray, theRandomInteger)
Array.deleteElementAtIndex(theArray, theRandomInteger)

lowerTemporaryArray = ArrayList<T>.new
Iterator<T> iter = theArray.iterator()
while iter.hasNext()
theValue =
if theValue <= pivot
lowerTemporaryArray = qsort(lowerTemporaryArray)

upperTemporaryArray = ArrayList<T>.new
iter = theArray.iterator()
while iter.hasNext()
theValue =
if theValue > pivot
upperTemporaryArray = qsort(upperTemporaryArray)

resultArray = ArrayList<T>
Arrays.appendElementsOfArray(resultArray, lowerTemporaryArray)
Arrays.appendSingleElement(resultArray, pivot)
Arrays.appendElementsOfArray(resultArray, upperTemporaryArray)

return resultArray

It’s an important step forward.  I think I’m going to be using it a lot.

So what actually is my favourite programming language?

The recent series of Why XYZ Is Not My Favourite Programming Language articles has been fun to do, and it’s been great to see the discussion in the comments (even if it’s mostly people people saying that I am talking a load of fetid dingo’s kidneys).  But I don’t want to extend that series beyond the point of diminishing returns, and it’s time to think about what it all means.  As duwanis commented on the Ruby article, “I’m a bit lost as to the point of these posts”; now I want to try to figure out just what, if anything, I was getting at.

Continue reading

Why Java Is Not My Favourite Programming Language


Java has four different “kinds” of types. Up until Tiger, it had these three:

  1. Primitive types: longs, shorts, booleans, ints, outs, whatever. They map more or less to machine types.
  2. Classes, which are the primary mechanism for extending the language.
  3. Arrays, which are this weird hybrid type that was introduced to make it easy to port C and C++ code to Java. But you can’t make arrays immutable, and you can’t subclass them, and there’s only modest syntactic support for them, and reflecting on them is painful.

The problem, of course, with having different types of types is that all of the code you write, now and forever, has to be prepared to deal with each type-type differently. So you get interfaces like this lovely one. Scroll down to the Method Summary, and looky looky, there are 76 actual methods in the class, but only 10 distinct pieces of functionality.

Just to make things worse, Java 5 added a new kind of type, called an enum. They’re sort of like C enumerations, but they can also have methods. Which makes them sort of like Java classes, but you can’t instantiate them, and you can’t have one enum type inherit from another enum type, so you can’t have polymorphic methods, nor can you declare an enumeration heirarchy. So they’re not really like classes at all.

— Steve Yegge, The Next Big Thing (lightly edited for brevity).

Case closed.