after_filter :set_content_length

 def set_content_length
   @response.headers['Content-Length'] = @response.body.length
 end

(**) The stalling happens sporadically, not sure with what pattern. In one app we saw it maybe one in 5 requests; some of those were actually HTTP requests so the

(*) Occasionally the page will be fully visible but the cursor will still be a pointer-plus-spinning-hourglass. And this may cause performance problems in high-volume sites.

(***) onInteractive and onComplete are prototype.js event callbacks; the corresponding standard XMLHttpRequest "ready states" are INTERACTIVE and COMPLETE; "ready state" is a parameter to the onReadyStateChange callback.

(****) Apache is nice enough to tack on a proper Content-Length for you, so if you're running behind Apache you're safe from this problem. ]]> General http://purpletech.com/blog/index.php?itemid=43 Mon, 15 May 2006 08:39:20 -0700 http://purpletech.com/blog/index.php?itemid=42 private Map foos = new HashMap(); public void getFoo(String key) { synchronized (foos) { Foo foo = foos.get(key); if (foo == null) { foo = new Foo(key); foos.put(key, foo); } return foo; } If two threads are both trying to get the same item before it exists, the first one will create it, and the second one will block until it's ready. (I've heard of the dreaded double-checked locking conundrum, but I believe that if I close my eyes, plug my ears and say "nah nah nah" then it will never happen.)

This is a common enough creation pattern. So common, in fact, that it feels like there should be a type of Map that does it for you. Well, now there is :-) Christian and I call ours a Closet -- I suppose it's sort of a magic closet that creates things for you if they're not hanging in there already.

private Closet foos = new Closet() {
  protected Foo create(String key) {
    return new Foo(key);
  }
};

public Foo getFoo(String key) {
  return foos.get(key);
}

Much nicer, But wait, we're not done! There's a problem with this design in a world where create() takes a long time. (We came across it while trying to cache Lucene IndexReaders.) If two concurrent threads try to get *different* items, and the first one hasn't been created yet, then the second thread will block even though its item is ready and waiting.

We arrived at a fairly elegant solution to this problem, but the more interesting part was writing the tests first. Writing a unit test for a concurrency problem is always annoying. It's tempting to spawn a bunch of threads and then use sleep() either from your tests or from overridden methods, but that will make your tests slow, and even then they don't always work consistently.

It's better to model your tests either to *simulate* multiple threads, or to actually spawn threads but keep a tight reign on them. The subordinate test threads do a few things, then wait for the main test thread to tell them to proceed. That keeps the logic in your main test clean and simple, like a script for a play with several characters -- Joe does this, Bob says that, Joe walks there, Jane enters stage left.

Now all we need to do is add expiration logic and we've turned our Closet into a cache.

(Full code is unavailable for the moment, sadly... stay tuned.) ]]> General http://purpletech.com/blog/index.php?itemid=42 Mon, 15 May 2006 08:32:14 -0700 http://purpletech.com/blog/index.php?itemid=41 JSLint, which checks the syntax and style of your JS code. I think it's too strict (but it's supposed to be) but I do recommend reading the documentation -- the explanations of /why/ JSLint complains are clear and insightful. For instance:

The == and != operators do type coercion before comparing. This is bad because it causes '' == 0 to be true. This can mask type errors.

When comparing to any of the following values, use the === or !== operators, which do not do type coercion.

0 '' undefined null false true

If you want the type coercion, then use the short form. Instead of

(foo != 0)

just say

(foo)

and instead of

(foo == 0)

say

(!foo)

There's also a command-line version which could be used in a continuous build (though I'd recommend we're careful deciding which checks to activate). P.S. "JSLint is less anal than the sycophantic conformanity demanded by XHTML, but more strict than the popular browsers." That's my favorite sentence I've read all week. ]]> Code http://purpletech.com/blog/index.php?itemid=41 Fri, 28 Apr 2006 07:37:28 -0700 http://purpletech.com/blog/index.php?itemid=40 peripatetic axiom: Keywords, Magic and (E)DSLs -- he gives a pretty good high-level introduction to Smalltalk and what language simplicity really means. He makes the point that Java isn't really object-oriented -- or rather, as I like to put it,

Java is object-oriented, in that it's kind of oriented towards objects, from afar.

There's something beautiful and elegant about a system with as few rules as necessary to get the job done. Java and, sadly, Ruby, overcomplicate life with bifurcations and exceptional cases and defaults and other magic. Only Smalltalk and Scheme reach the level of elegance I'm talking about -- a very small number of rules from which you can derive the universe of software.

(Keith's example is that if, a part of the grammar of any C-style language, is actually implemented as a method of the class Boolean. It takes two blocks as parameters; the concrete Boolean subclass True executes the first and False executes the second.)

And no, I'm not advocating a return to assembly language, although the simplicity of stack- and register-based programming approaches what I'm talking about. In Java there's at least two ways to do so many things. There are primitives *and* objects. There are statics *and* instance members. There are Arrays and ArrayList. There are final classes (like String) and regular ones. And each of these pairs has different semantics, and you keep getting tripped up over things you can and can't do.

Ruby's a little better, in that everything's an object -- oh wait, unless it's a mixin (aka module). Which means that if someone decided to implement some stuff as a mixin, and you want to override it, you can't use "super", you have to declare an alias and call it. And everything following a method name is a parameter, unless it kind of looks like a hash, in which case it's all one parameter, unless it looks like a block, in which case it's the "default block".

My point is, if you remove rules rather than adding them, there's a chance you'll turn Chess into Checkers. But there's also a change you'll reach Go. ]]> General http://purpletech.com/blog/index.php?itemid=40 Sun, 9 Apr 2006 21:14:55 -0700 http://purpletech.com/blog/index.php?itemid=39 Humane Gmail Autosave solved one of the many problems with the so-called text editor in which I spend most of my time these days. Or rather, in which I often type some stuff, then get distracted into a different task or tab and let it sit for hours. Thankfully gmail does autosave by default now, making this extension unnecessary, though it'd be nice to crank the frequency up to once per second or once per keystroke or something.

Why, in this day and age, is there even a Save command in any application? Its very presence implies -- indeed, guarantees -- that the default state of the world is unsafe. This breaks the rule our ancestors learned over billions of years of interaction with the objective world: when you do something, it stays done, until undone.

I have agreed for decades with the following sentiment:

"...[The] user should never have to explicitly save or store work. The system should treat all produced or acquired data as sacred and make sure that it does not get lost, without user intervention. The user may, of course, deliberately delete anything. The ability to delete (or make any changes) means that universal, unlimited-level undo and redo should be inherent to all systems." - Jef Raskin, The Humane Interface

A dialog box in which you're editing existing data should update immediately, and have a "Revert" 'button which puts things back to how they were when you opened the dialog. A dialog box in which you're constructing brand new stuff is temporary, so in that case there could be a "Save" button (or, better, "Create"). But it'd be great if instead, it made a new, persistent "proposal" or "draft" for the item, so it would still be there if the power went out. ]]> General http://purpletech.com/blog/index.php?itemid=39 Sat, 1 Apr 2006 19:27:56 -0800 http://purpletech.com/blog/index.php?itemid=38 Eclipse to IntelliJ IDEA 5.1. Their new JavaScript plugin works like a dream. It makes me hope for an IDEA Ruby plugin.

Here's a short list of what works:

• Shift-F6 - Rename classes, methods, variables
• Renaming a file searches references and changes them (e.g., script tags in jsunit test files)
• Dot completion, Ctl-Space - gives you a list of all methods, and narrows down.
• F4 / Ctl-B / Ctl-Click - go to the definition of the method or class you're looking at
• Ctl-Shift+Alt+N - search across all JS files for any variable, class, constant, method, or other symbol. Goes to to the definition when you hit enter.
• Ctl-Shift-N - go to file (equivalent of Ctl-Shift-R in Eclipse)
• Ctl-F12 - jump to a class or method in your current JS file
• Red syntax error squigglies - You know how you're run jsunit all those times where it just freezes because you have a syntax problem? Steve and I have gone 5 days without having that problem. I expect we won't see that again for some time.
• Alt-F7, on classes and methods - Find usages. YAY.
• Ctl-Alt-L - apply code style (reformat)
• Ctl-Shift-V - multi-level paste

So now it seems Sixth and River may make a Ruby plugin for IDEA. See River of Code: Ruby in IDEA?. Let's flood their blog post with "me too"s to get them in the mood. ]]> Code http://purpletech.com/blog/index.php?itemid=38 Sat, 1 Apr 2006 18:23:56 -0800 http://purpletech.com/blog/index.php?itemid=36 <link href="/css/mysite.css?9238238" rel="stylesheet" type="text/css"> If you use a truly random number (or the current time), it will reload every time. However, this is not exactly what you want; instead, you only want it to reload when the file has changed, and use the cached version when it hasn't. A good way to do this is to use the timestamp of the time the file was last modified.

Here's an easy way to do this in Ruby on Rails.Use the standard Rails helper functions stylesheet_link_tag and javascript_include_tag (which reference static files inside the 'public' directory):

  <%= stylesheet_link_tag 'mysite' %>
  <%= javascript_include_tag "prototype" %>

 def javascript_path(js_file)
   versioned_path(super)
 end

 def stylesheet_path(css_name)
   versioned_path(super)
 end

 def versioned_path(path)
   if (path.include?("http://"))
     path
   else
     timestamp = File.mtime(File.join(RAILS_ROOT, "public",
path)).strftime("%Y%m%d%H%M%S")
     path + "?#{timestamp}"
   end
 end

BTW, in the meantime I've discovered many other UI and feature decisions where the Eclipsers chose... poorly. For example:

• There's no checkbox for "blessing" a Run configuration as a favorite in the Run settings dialog. Instead you have to close that dialog, click on the stupid "ha ha I'm really a separate menu even though I look like a little 8-pixel triangle" "button" next to the big green play button, select "Organize Favorites...", click "Add", scroll through a list of items that are selectable, but don't actually select the one you want -- instead, click on the checkbox next to it in the list -- then click "OK". Twice.
• Double-click-and-drag selection still doesn't work; nor does triple-click to select a line.
• The list of search results don't actually show the results, but just the files in which there were results. And there's no keystroke for showing the next result. These two factors combined means that it's easy to click on a "result", look at it, then click on the next "result" and accidentally skip over several hits from the earlier file. The "proper" behavior is to move your mouse all the way across the panel to the down-arrow "button" (again, one that doesn't look like a button since it doesn't have button-like affordances (a visible border inside which you click)).
• Activating the test runner with Ctl-F11 doesn't update the screen layout to show you the test runner if your current window is maximized (for which, thank Zeus, they now have a keystroke (Ctl-M)). This encourages you to hit Ctl-F11 again, which totally breaks the test runner since it doesn't support multiple simultaneous test runs yet does nothing to prevent you from starting multiple simultaneous test runs.
• Version diffing (from Local History or Repository) is incomprehensible. There are two options -- "Compare with" and "Replace with". They apparently differ only by the presence of a "Replace" button. Why not just have "Replace" be a feature of "Compare"? In the "Replace" window, if you accidentally hit "Enter", the default action is not the expected "Show me the selected version," but is "Replace", which astonishingly replaces your whole file and then closes the window really quickly so you're like, "What the heck just happened?"
• In Eclipse, certain editor keystrokes (ctrl-J, ctrl-K, etc.) only work in certain "perspectives" or "editor types" or whatever the heck modal madness they call it. In contrast, in IDEA, they went the opposite direction, actually making cool features like control-space work inside dialog boxes. Eclipse is shifting sand... you never know what you can do or how you can get it done.

Last night Erik and I decided that Eclipse is like Bizarro IDEA. You remember Bizarro -- he idolized Superman, but was an imperfect duplicate.

Eclipse and IDEA seem to be tracking each other's features, but everything they both do, Eclipse gets wrong somehow.

"Me am Bizarro IDE! Me require many more keystrokes than puny IDEA!"

"Me have lots more clutter on screen! More icons am better!"

"IDEA only allow one project open at a time. More am better! Bizarro IDE open *all* projects all the time! Bizarro IDE do everything on everything, all the time!"

"Bizarro middle finger am *much* stronger from all the right-clicking!"

On that last point -- I have a feeling that Erich Gamma writes entire applications solely via right-clicking. No typing, not even any left-clicking. Pretty much any interface *other* than right-clicking seems like an afterthought in Eclipse.

Then there are the menus which appear and disappear randomly depending on context; the "global search" with a dozen options but no "global search *and replace*"; the fact that you can't see what the keyboard shortcuts are for any of the menu items until you press ALT, and that you can't see any keyboard shortcuts in the tooltips for any icons; the common operations that in IDEA are a single keystroke that in Eclipse are 3 or 4; the strange names for things ("Team" instead of "Version Control"; Perspectives and Views and Workspaces and Workbenches and...)

IDEA's UI seems to work because (a) it was used by the people that wrote it, and (b) the people that wrote it work like I do. Eclipse seems to be more oriented towards uml-diagramming/right-clicking/visual-debugging/code-browsing types; me, I type my code, and I read source files, not hierarchical trees. IDEA always seems to think ahead and automate things I'm *actually* about to do, not force me to stop what I'm doing and go right-click on something else to get the 8 different options for doing something else.

That said, since I found F3 and figured out what (multi-step) keystrokes activate the refactorings, Eclipse is now perfectly tolerable.]]> Code http://purpletech.com/blog/index.php?itemid=29 Sun, 12 Feb 2006 09:11:23 -0800 http://purpletech.com/blog/index.php?itemid=25 Q: What's the first rule of Object-Oriented Design?

A: Put the behavior with the data.

Now, this may seem to be a simple enough rule. But if that's so, why do I keep seeing code like this?

foo.getBar().getBaz().process(getBar().getBaf())

or this?

@iterations.each do |iteration|
  velocity = 0
  iteration.stories.each do |story|
    if story.feature?
      velocity = velocity + story.velocity
    end
  end
  iteration.total_velocity = velocity
end

But I have a dream. I dream of a world without getters. A world where Tell, Don't Ask is the law of the land. A world where every reference to instance data is in the class containing that data. Let me be perfectly clear:

Every. Single. Reference.

Inside the Same. Class. As the data.

A world where in addition to the first rule above, the next four rules are:

1. Put the behavior with the data.
2. Not *near* the data... *with* the data.
3. No, with the *data*.
4. Yes, even with that data.
5. Good. Now keep putting the behavior with the data.

More below the fold...

In other words, write your programs as a series of isolated, encapsulated objects that send messages to each other but are completely responsible for managing their internal state.

In this world, every time a variable is referenced, it's either:

1. a local variable
2. a parameter to the current function
3. an instance variable of the current class
4. a global (boo! hiss!) -- this includes "class variables" and constants which I always try to minimize in any case

I have never yet written an object-oriented program.

If you're at all like me, this coding style may strike you as vastly annoying. Like most programmers, I got into this game because I'm goal-oriented. I see a problem, I see a bunch of tools strewn around and I pick them up and use them on my way to the goal. That leads to functional programming. Even modular decomposition is an afterthought -- a necessary one, and one I now do almost immediately by applying Extract Method liberally, but an afterthought nonetheless. True OOD is a real stretch.

But that's why this is a dream. It's a challenge. Here are some things that may be difficult to do. (If I ever get a chance to do this for real, I'm sure I'll come up with more.)

Methods with return values.

This is value-judgement land. At some point an object will have to report something about its internal state; when it does, isn't it violating the First Rule and letting its instance data leak out? My advice is, whenever possible, avoid with void: make methods without return values and see if you can accomplish what you want by telling, not asking. When you can't get around this, make sure it's transforming its instance data in some way. If all else fails, try to make sure the data you're returning is immutable (or at least doesn't maintain a live pointer back into the original object's internal state). (Returning live objects is especially dangerous when returning collections.)

Rendering.

Normally view code is written like this:

  public void renderPerson(PrintWriter out, Person person) {
    out.print("<h1>" + person.getName() + "</h1>");
    out.print("Age: " + person.getAge() + "<br>");
    out.print("Sex: " + person.getSex() == Sex.MALE ? "Male" : "Female" + "<br>");
    out.print("Address: ");
    renderAddress(out, person.getAddress());
  }

The solution is to use interfaces to make a render method that's HTML-free:

class Person {
  public interface Renderer {
    public void renderPerson(String name, Sex sex, Address address);
  }

  public void renderTo(Renderer renderer) {
    renderer.renderPerson(getName(), getSex(), getAddress());
  }
}

Then inside your View layer you write:

  class PersonInfoPageRenderer implements Person.Renderer, Address.Renderer {
    PrintWriter out;
    public ToHtmlRenderer(PrintWriter out) { this.out = out; }
    public void renderPerson(String name, Sex sex, Address address) {
      out.print("<h1>" + name + "</h1>");
      out.print("Age: " + age + "<br>");
      out.print("Sex: " + sex == Sex.MALE ? "Male" : "Female" + <br>");
      out.print("Address: ");
      address.renderTo(this);
    }

    public void renderAddress(String streetAddress, String city, String state, ...) {
      ...
    }
  }

  person.renderTo(new PersonInfoPageRenderer(out))

Yes, I know this requires more typing. What can I say? Java is a verbose language.

(That reminds me of my favorite joke:

Q: Why were the Java programmer's fingers sore?
A: Because Java is a strongly-typed language!

You could do the same thing in Ruby with fewer lines: just define a "render_person" method and pass in self.

I was never good at dating. My timing was all wrong. I'd meet a girl in a bar and say, "Hi, was it good for you too?"

So here's my take, in proper order, on the progression of patterns for creating an object.

1. Constructor

new Foo(bar)

However, sometimes constructors are too limiting. Maybe there is some initialization that must happen before the object is constructed, or immediately after. Maybe you have lots of constructors with similar or identical parameter lists and you need a series of named methods to distinguish them. In that case, the next step is...

2. Factory Method

createFoo(bar)
createFooForSomeReason(bar)
createFooForSomeOtherReason(baz)

3. Static Factory Method

Foo.create(bar)
Foo.createForSomeReason(bar)
Foo.createForSomeOtherReason(baz)

This also allows your private constructor to become simpler. A factory method can take care of initialization stuff, and the constructor can take in already set-up objects and stick them in instance variables.

However, I am growing more and more reluctant to use statics (aka globals) of any kind. It seems to violate Separation of Concerns to put the code for *creating* an object in the same place as the code for *being* that object.

4. Factory Object

new FooFactory().create(bar)

Allows separation of concerns, and consistency between instances of the same class without relying on nasty static variables. Use this if constructing the factory itself is cheap.

Note that most OO languages, in moving the factory into a separate class you give up the power to access private members of the created class. This may mean you have to refactor the target object to expose a public (or package- or friend-accessible) method to do initialization.

It's a simple step from here to #6, a Dependency-Injected Singleton factory.

5. Static Singleton Factory Object

FooFactory.getInstance().create()

Using a singleton gives you a common entry point for creating objects across your application. That means you can do tricks like caching, instance pooling, referential integrity checking and maintenance, etc.

Static singletons like this are easy to use since you can always just reach out and find one. But this is not ideal cause you need static registry and teardown semantics, and it's hard (OK, annoying) to swap out instances at runtime, for instance for tests, without compromising your ability to do multithreading. Dependency Injection 0wnz0rrz statics of all types (including this one) (see below).

6. Injected Singleton Factory Object

getFooFactory().create()

I might get in trouble for calling this a Singleton. The basic idea behind Dependency Injection that when you want something -- any service, like a factory, a repository, a search server, an asynchronous message scheduler -- you just ask yourself for it. You have it already, since in your constructor your client passed it in to you, and you stashed it away in an instance variable.

This allows the oxymoronic "multiple singletons" pattern: at any given point there's only one of the things in scope, but there can be many in the same application or VM; in fact, many different instances can be active at the same time. This is great for testability and flexibility.

7. Abstract Factory

Abstract Factories are aware of the whole hierarchy of possible subclasses of the target object and return the right one for the given use at runtime. A better name might be "polymorphic factory."

It's a pretty heavyweight pattern and a long way from "new". You may never use it. I never have.

OO is like teenage sex: everyone says they're doing it, almost nobody is doing it, and those who are doing it aren't very good at it.

Usually a Command is used when you want to encapsulate the doing of something, without actually doing it right away. But in this case, we'll execute it immediately. Don't worry, it will carry its own weight by removing the business logic from the original object, and by being cleaner and more isolated, and thus more testable. It will also be set up so that you can do all the cool Command pattern tricks later if you want, like polymorphic dispatch or undo.

Before:

public Money withdraw(int accountNumber, Money amount) throws SessionException {
    try {
        Account account = accountService.findAccount(accountNumber);
        verifyBalance(account, amount);
        account.withdraw(amount);
        return account.getBalance();
    }
    catch (AccountServiceException e) {
        logger.log(e);
        throw new SessionException(e);
    }
}

public Money withdraw(final int accountNumber, final Money amount) throws SessionException {
    return new Withdraw(accountNumber, amount, logger, accountService).execute();
}
...
class Withdraw extends AtmCommand<Money> {
    private final int accountNumber;
    private final Money amount;
    private AccountService accountService;

    public Withdraw(int accountNumber, Money amount, Logger logger, AccountService accountService) {
        super(logger);
        this.accountNumber = accountNumber;
        this.amount = amount;
        this.accountService = accountService;
    }

    protected Money doExecute() throws AccountServiceException, SessionException {
        Account account = accountService.findAccount(accountNumber);
        verifyBalance(account, amount);
        account.withdraw(amount);
        return account.getBalance();
    }
}

In this article on purpletech.com, I will walk through the precise sequence of steps to perform this refactoring in IntelliJ IDEA (version 5). There are some pretty fun keystroke combos you can use to make the whole thing relatively painless and automated. (Automating refactorings is better than just typing because it's less likely to introduce errors, it's got more stable intermediate points so you can safely stop halfway through, and most of all, because it makes you feel cool.)

Full article at: http://www.purpletech.com/articles/combos/extract-command.html
]]> Code http://purpletech.com/blog/index.php?itemid=22 Sun, 20 Nov 2005 18:52:00 -0800 http://purpletech.com/blog/index.php?itemid=21
Make the method static (which means turning the "this" pointer into a named parameter). Now count the number of times each object is referred to.

What object is referenced the most? Chances are that it would go better as a method on that object.

And if you can split it into meaningful chunks, each of which primarily references a different object -- then divide and conquer.
]]> Code http://purpletech.com/blog/index.php?itemid=21 Sat, 19 Nov 2005 23:32:57 -0800 http://purpletech.com/blog/index.php?itemid=20

• pull together all sorts of disparate business logicky transitions into one nice, encapsulated, formally complete model
  
• complain loudly when some application logic tries to make an illegal state transition
  
• output itself in DOT format, creating nifty automatic documentation
  

By extracting the transition logic into a separate object, we apply Separation of Concerns and let the owning object deal with the business of actually verifying whether a transition is desirable, whether other business rules are met, of spawning other processes or notifying listeners, or attaching Command objects to perform entry, exit or transition actions. Of course, any of these features (especially notifying listeners) can easily be added to the machine itself, but let's keep it simple for now.
It's straightforward enough to refactor to the full State pattern (also described by Metzger) if and when we want to.

Why would you want to use a state machine in the first place instead of, say, a bunch of booleans, or just smart methods? As Metzger says:

When you model an object whose state is important, you may find that you have a variable that tracks how the object should behave, depending on its state. This variable may appear in complex, cascading if statements that focus on how to react to the events that an object can experience. One problem with this approach to modeling state is that if statements can become complex. Another problem is that when you adjust how you model the state, you often have to adjust if statements in several methods. The STATE pattern offers a cleaner, simpler approach, using a distributed operation.

 
    enum DayState { 
        DAYTIME, 
        NIGHT, 
        NEVER, 
    } 
 
    enum DayAction { 
        SUNSET, 
        SUNRISE, 
        ARMAGEDDON, 
    } 
 
    class DayMachine extends StateMachine<DayState, DayAction> { 
        { 
            addTransition(DayState.DAYTIME, DayAction.SUNSET, DayState.NIGHT); 
            addTransition(DayState.NIGHT, DayAction.SUNRISE, DayState.DAYTIME); 
            addTransition(DayState.NIGHT, DayAction.ARMAGEDDON, DayState.NEVER); 
        } 
    } 

 
    class Day { 
        private DayMachine dayMachine = new DayMachine(); 
        private DayState state = DayState.DAYTIME; 
 
        public void rotate() { 
            if (state == DayState.DAYTIME) { 
                doSunset(); 
            } 
            else if (state == DayState.NIGHT) { 
                state = dayMachine.move(state, DayAction.SUNRISE, DayState.DAYTIME); 
            } 
        } 
 
        public void doSunset() { 
            state = dayMachine.move(state, DayAction.SUNSET, DayState.NIGHT); 
        } 
 
    } 

 
class Night extends DayState { 
  public DayState sunrise() { 
    return new Daytime(); 
  } 
  public DayState sunset() { 
    throw new InvalidStateTransition("performing sunset on night"); 
  } 
} 

Finally, the coup de grace: the machine can output itself in DOT format:

 
digraph day { 
	daytime [label="daytime"]; 
	nighttime [label="nighttime"]; 
	never [label="never"];	 
	daytime -> nighttime [label="sunset"]; 
	nighttime -> daytime [label="sunrise"]; 
	nighttime -> never [label="armageddon"]; 
} 

Without further ado, here's the code, using Java 1.5 generics, and including (naturally) a unit test:

 
public class StateMachine<STATE extends Enum, ACTION extends Enum> { 
 
    static class Transition<STATE extends Enum, ACTION extends Enum> { 
        STATE from; 
        ACTION action; 
        STATE to; 
 
        public Transition(STATE from, ACTION action, STATE to) { 
            this.from = from; 
            this.action = action; 
            this.to = to; 
        } 
 
        public STATE getFrom() { 
            return from; 
        } 
 
        public STATE getTo() { 
            return to; 
        } 
 
        public ACTION getAction() { 
            return action; 
        } 
    } 
 
    LinkedHashSet<STATE> states = new LinkedHashSet<STATE>(); 
    List<Transition> transitions = new ArrayList<Transition>(); 
 
    public void addTransition(STATE initialState, ACTION action, STATE targetState) { 
        transitions.add(new Transition<STATE, ACTION>(initialState, action, targetState)); 
        states.add(initialState); 
        states.add(targetState); 
    } 
 
    public List<STATE> transitionsFrom(STATE initialState) { 
        List<STATE> targetStates = new ArrayList<STATE>(); 
        for (Transition<STATE, ACTION> transition : transitions) { 
            if (transition.getFrom().equals(initialState)) { 
                targetStates.add(transition.getTo()); 
            } 
        } 
        return targetStates; 
    } 
 
    public STATE move(STATE initialState, ACTION action, STATE targetState) { 
 
        for (Transition<STATE, ACTION> transition : transitions) { 
            if (transition.getFrom().equals(initialState) && transition.getAction().equals(action)) { 
                return transition.getTo(); 
            } 
        } 
        throw new IllegalStateTransition(initialState, action, targetState); 
    } 
 
    public void writeDotFormat(Writer writer) { 
        PrintWriter out = new PrintWriter(writer); 
        out.println("digraph state {"); 
        for (STATE state : states) { 
            out.println(state.name() + " [label=\"" + state.name() + "\"];"); 
        } 
        for (Transition transition : transitions) { 
            out.print(transition.getFrom().name()); 
            out.print(" -> "); 
            out.print(transition.getTo().name()); 
            out.print(" [label=\""); 
            out.print(transition.getAction().toString().toLowerCase()); 
            out.print("\"];"); 
            out.println(); 
        } 
        out.println("}"); 
    } 
} 
 
public class IllegalStateTransition extends RuntimeException { 
    public IllegalStateTransition(Enum initialState, Enum action, Enum targetState) { 
        super("Attempting to perform " + action + " to move from " + initialState + " to " + targetState); 
    } 
} 
 
--- 
 
public class StateMachineTest extends TestCase { 

    private DayMachine dayMachine; 
 
    protected void setUp() throws Exception { 
        super.setUp(); 
        dayMachine = new DayMachine(); 
    } 
 
    public void testTerminalState() throws Exception { 
        assertEmpty(dayMachine.transitionsFrom(DayState.NEVER)); 
    } 
 
    public void testMoveToValidState() throws Exception { 
        assertEquals(DayState.NIGHT, dayMachine.move(DayState.DAYTIME, DayAction.SUNSET, DayState.NIGHT)); 
    } 
 
    public void testMoveToInvalidState() throws Exception { 
        try { 
            dayMachine.move(DayState.DAYTIME, DayAction.ARMAGEDDON, DayState.NEVER); 
            fail("Should have failed"); 
        } 
        catch (IllegalStateTransition e) { 
            assertEquals("Attempting to perform ARMAGEDDON to move from DAYTIME to NEVER", e.getMessage()); 
        } 
    } 
 
    public void testDotFormat() throws Exception { 
        StringWriter writer = new StringWriter(); 
        dayMachine.writeDotFormat(writer); 
 
        BufferedReader reader = new BufferedReader(new StringReader(writer.toString())); 
 
        assertEquals("digraph state {", reader.readLine()); 
        assertEquals("DAYTIME [label=\"DAYTIME\"];", reader.readLine()); 
        assertEquals("NIGHT [label=\"NIGHT\"];", reader.readLine()); 
        assertEquals("NEVER [label=\"NEVER\"];", reader.readLine()); 
        assertEquals("DAYTIME -> NIGHT [label=\"sunset\"];", reader.readLine()); 
        assertEquals("NIGHT -> DAYTIME [label=\"sunrise\"];", reader.readLine()); 
        assertEquals("NIGHT -> NEVER [label=\"armageddon\"];", reader.readLine()); 
        assertEquals("}", reader.readLine()); 
    } 
 
    private void assertEmpty(List<DayState> list) { 
        assertEquals(0, list.size()); 
    } 
 
} 

The theory is that if the compiler forces the programmer to either handle the exception or pass it on in an exception specification, then the programmer's attention will always be brought back to the possibility of errors and they will thus properly take care of them. I think the problem is that this is an untested assumption we're making as language designers that falls into the field of psychology. My theory is that when someone is trying to do something and you are constantly prodding them with annoyances, they will use the quickest device available to make those annoyances go away so they can get their thing done, perhaps assuming they'll go back and take out the device later... In the end, I think we must realize the experimental nature of checked exceptions and look at them carefully before assuming that everything about exceptions in Java is good.

if (e instanceof ThreadDeath) { throw (ThreadDeath) e; }

I know some here are tempted by IntelliJ's IDEA but unwilling to pay
$499 for it, I note that they are doing one of their apparently randomly
scheduled special deals, where you can buy a personal license for $249.
It's a full license; the only catch is that you can't buy more than one
at this price.

For those unfamliar with it, it's my favorite Java editor, with great
refactoring tools and excellent usability. I haven't used Eclipse
lately, but I understand that they keep rough feature parity. To me, the
difference is more in usability; in trying to accomplish the same tasks,
I found IDEA much more pleasant to use.

public class Test

{

    static class AssertionFailed extends RuntimeException

    {

        public AssertionFailed(String msg)

        {

            super(msg);

        }

    }



    static void fail(String msg)

    {

        throw new AssertionFailed(msg);

    }



    static void assertEquals(Object expected, Object actual)



    {

        if (!expected.equals(actual))

        {

            fail("Expected <" + expected + "> but got <" + actual + ">");

        }

    }



    static void assertEquals(double expected, double actual)

    {

        if (expected != actual)

        {

            fail("Expected <" + expected + "> but got <" + actual + ">");

        }

    }



    static void assertEquals(int expected, int actual)

    {

        if (expected != actual)

        {

            fail("Expected <" + expected + "> but got <" + actual + ">");

        }

    }



    static void assertTrue(boolean f)

    {

        if (!f)

        {

            fail("Expected true, but got false");

        }

    }



    static void assertFalse(boolean f)

    {

        if (f)

        {

            fail("Expected false, but got true");

        }

    }



    static void assertNotNull(Object o)

    {

        if (o == null)

        {

            fail("Should not be null");

        }

    }



    static void assertNull(Object actual)

    {

        if (actual != null)

        {

            fail("Expected null but got <" + actual + ">");

        }

    }



    static void assertContains(Collection collection, Object expected)

    {

        if (!collection.contains(expected)) {

            throw new RuntimeException("Expected collection to contain " + expected);

        }

    }



    public static void main(String[] args) throws Exception

    {

        if (args.length == 0)

        {

            System.out.println("Usage: java Test TestClass");

            System.out.println("  where TestClass is the class name of a class that extends Test,");

            System.out.println("  containing methods named testFoo");

            System.out.println("Usage: java Test directory/");

            System.out.println("  where directory is a directory name ending with '/' or '.'");

            System.out.println("  will run all classes whose names end in Test.class in that directory");

            System.exit(1);

        }



        runTests(args);

    }



    private static void runTests(String[] args) throws Exception

    {

        Test t = new Test();



        for (int i = 0; i < args.length; ++i)

        {

            String className = args[i];

            if (className.endsWith("/") || className.equals("."))

            {

                runTests(getTestClassesInDirectory(className));

                continue;

            }



            if (className.endsWith(".class"))

            {

                className = className.substring(0, className.length() - ".class".length());

            }

            t.runTests(className);

        }



        t.printResults();

    }



    public static String[] getTestClassesInDirectory(String dir) throws Exception

    {

        File f = new File(dir);

        return f.list(new TestFilter());

    }



    public static class TestFilter implements FilenameFilter

    {

        public boolean accept(File dir, String name)

        {

            return (name.endsWith("Test.class"));

        }

    }



    int successful = 0;

    int unsuccessful = 0;



    private void printResults()

    {

        if (unsuccessful == 0)

            System.out.println("SUCCESS");

        else

            System.out.println("OK: " + successful + " FAILED: " + unsuccessful);

    }



    private void runTests(String className) throws Exception

    {

        System.out.println("Running " + className);

        Class testClass = Class.forName(className);



        Constructor constructor = testClass.getConstructor(new Class[] {});

        Method[] methods = testClass.getMethods();

        for (int i = 0; i < methods.length; ++i)

        {

            Method method = methods[i];

            if (method.getName().startsWith("test"))

            {

                System.out.print(method.getName() + "...");

                try

                {

                    Object o = constructor.newInstance(new Object[]{});

                    method.invoke(o, new Object[]{});

                    System.out.println("OK");

                    successful++;

                }

                catch (InvocationTargetException ite)

                {

                    System.out.println("FAILURE");

                    ite.getTargetException().printStackTrace(System.out);

                    unsuccessful++;

                }

                catch (Throwable t)

                {

                    System.out.println("FAILURE");

                    t.printStackTrace(System.out);

                    unsuccessful++;

                }

            }

        }

        System.out.println();

    }



}