Time Zones are a pain in the ass.

Some interesting links I found that discuss time zones:

Complete timezone information for all countries. – Just as the label says

The official US time (NIST & USNO) – Displays the current time in the 10 major time zones in the United States.

Time Zone Converter – Allows a search of the various time zones in the world.

What makes time zone conversions a pain in the ass is that each jurisdiction has control over its own timezone. In some places (like California) we’re on Pacific Standard Time/Pacific Daylight Time, period, thankyouverymuch, haveaniceday.

But in places like Indiana, where every blasted county has it’s own ideas as to if it is in Central Standard Time, or Eastern Standard Time, and if the cows there can tolerate the shift between daylight savings time–well, the tz database becomes a hot mess, with things like “America/Indiana/some-random-place” littered throughout. On the other hand, most of that hot mess boils down to “this week, Knox County Indiana has decided to switch time zones from central to eastern”–which, for a UI timezone picker, doesn’t really matter. The fine folks of Knox County can just pick “Central” or “Eastern” and be done with it.

Sometimes the easiest sounding thing, like “pick a time zone”, becomes a royal pain in the neck. And even easier things like “what time is it in GMT at my location” become royally hard. It’s like that, when local politics gets involved.

GWT Weirdness Of The Day.

On the project I’m working on, I noticed that, for whatever reason, it was now taking up to 3 minutes to start a web site running under GWT. That is, from hitting the “Debug” button and opening the web site in the browser, to seeing the web site actually up and running, was taking just shy of three minutes, with most of that time with the Spinning Beach Ball Of Death™.

I finally figured out what was happening. The first clue came from hitting ‘pause’ on the Daemon Thread labeled “Code server for myProject from Safari DMP…”, and noticing a lot of time being spent walking around inside the source kit for resources.

And noticing a lot of that time was spent in a bunch of .svn folders.

I think what was going on is that, for some reason or another, a lot of crud had accumulated in a number of random hidden folders associated with subversion. I don’t know if this is normal or abnormal behavior for Subversion; I just know there was a bunch of crap floating around there–and GWT was spending several minutes walking around the directory structure.

Blowing away the entire source kit and checking it all out fresh from Subversion reduced the startup time to less than 5 seconds. And it greatly improved the performance of the browser in the debugger as well: rollovers which were taking a while to get detected now are fast and responsive.

I suspect all the crud in my source directory was creating a lot of crap for the debugger to deal with, creating a substantial slowdown that got cleared right up.

GWT, ScrollPanel and the iPad.

GWT makes it easy to create a scrolling panel within an HTML driven web site, by using the ScrollPanel class. ScrollPanel itself expands into a div tag containing the overflow attribute; specifying which axes the scroll bars land on translate into overflow-x or overflow-y attributes in the generated HTML DOM object.

And the iPad (and iPhone and iPod Touch) do not allow you to scroll within the overflow tags; the touch-drag gesture only scrolls the entire page.

What this means is if you are putting together a GWT application that you want to work on the iPad, the natural instinct to create a root panel the full size of the screen and tossing in a ScrollPanel area in the lower right that resizes with the window is incorrect. Instead, you are better off generating your GWT code so that it generates the properly sized HTML, and scroll around the GWT application using the window’s scroll bars.

Building a Java RMI system.

Yeah, this is old technology from the stone age. But I wanted to set up a simple Java RMI system.

And it turns out every tutorial I encountered starts with:

        if (System.getSecurityManager() == null) {
            System.setSecurityManager(new SecurityManager());

Then there is a ton of pages showing how we then customize the security manager settings through all sorts of security property files, or extending the SecurityManager class to give us explicit permissions or all of that stuff.

Of course all of this is nice. However, for just testing something it’s unnecessary: the SecurityManager (once set) prohibits access to various things in the JVM unless explicitly opened–and the suggestion to then grant all permissions just seems silly to me: I’m locking the door, then I’m holding it wide open.

Just don’t lock the damned door.

The following seems to work for me; YMMV.


import java.rmi.Remote;
import java.rmi.RemoteException;

public interface TestInterface extends Remote
    String sayHello() throws RemoteException;


import java.rmi.Naming;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.rmi.server.UnicastRemoteObject;

import com.atti.addel.test.springrpc.common.TestInterface;

public class TestServer implements TestInterface
    protected TestServer() throws RemoteException

    private static final long serialVersionUID = 1L;

    public String sayHello() throws RemoteException
        return "Hello World.";
     * Run this as an RMI object
     * @param args
    public static void main(String[] args) 
//        if (System.getSecurityManager() == null) {
//            System.setSecurityManager(new SecurityManager());
//        }
        try {
        catch (RemoteException e) {
            System.out.println("Registry exists.");
        try {
            TestInterface engine = new TestServer();
            TestInterface stub = (TestInterface)UnicastRemoteObject.exportObject(engine,0);
            Registry registry = LocateRegistry.getRegistry();
        catch (Exception ex) {
            System.out.println("Unable to start up.");


import java.rmi.Naming;

import com.atti.addel.test.springrpc.common.TestInterface;

public class TestClient
     * @param args
    public static void main(String[] args)
        try {
            TestInterface test = (TestInterface)Naming.lookup("rmi://localhost/TestServer");
        catch (Exception ex) {

Once you run the server, a service “TestServer” is created in the local RMI registry. The client will then invoke the server ‘sayHello’ method, and return the answer.

Naturally more complex examples and interfaces and stuff can be bolted onto this. But this seems to be the very bare bones system–and it avoids stuff like rmic and security permissions and stuff like that.

I ran this on my Macintosh (System 10.5) running JVM 1.6 in Eclipse 3.5 without any problems, outside of wasting an hour trying to figure out why I was getting an “java.security.AccessControlException” exception–which could directly be traced to setting up a security manager.

It’s not done until you document your code.

I remember the original “Inside Macintosh.” I actually still have the loose-leaf binder version of “Inside Macintosh” that shipped with System v1.

The original Inside Macintosh documented the “Macintosh Toolkit” (the acronym “API” wasn’t in common use then), and, aside from two introductory chapters–one which described the OS and one which documented a sample application–each chapter followed the same formula. The first part of the chapter, consisting of from 1 to a dozen pages, would provide an overview of that toolkit. For example, the “Resource Manager” overview describes what resources are, how resource are important, and how resources are stored on disk. The second part of the chapter would always be “Using the XXX Manager”–giving examples which generally followed the pattern of how you initialized that manager, how to create or manipulate fundamental objects, how to dispose of fundamental objects, and how to shut the manager down. This would consist of the bulk of the chapter. And the end of the chapter would be a summary–generally a summary of the header file for that manager.

It always struck me that such a model was a great way to handle documentation. Start with a 1 to 3 page introduction to whatever fundamental module you are documenting–a “module” consisting of a logical unit of functionality, which could consist of several classes. Then launch into a 20 page document showing how you use that module: how you start it up, how you use the major features, how you configure the major features, how you shut it down. And give snippets of code showing how these are done.

And the summary should point to either the generated JavaDocs or HeaderDoc generated documentation giving the specific calls and specific parameters for each call.

What is interesting about such a model is that it should be fairly easy to write for the technical person creating the toolset: he knows how he wants his class set to be used, so he should be able to craft documentation describing how to use it. For a class which presents a table, for example, the developer has a mental model of how tables are displayed: a delegate or data source is created which responds to certain calls and is attached to the table.

It has always been my opinion that writing code is simply one part of a multi-step process which ultimately results in your code being used. After all, isn’t the whole point of creating code is getting people to use your code? Developers rail against “lusers” who refuse to learn how to use their computers–but I suspect it’s because developers know their fellow developers are more likely to work through the source kit than the average person, and it allows them the excuse not to write the documentation they should write.

Your code isn’t finished until it is well documented. And complaining about people who are confused without good documentation is simply shifting the blame.

Love-hate relationship with reflection, proxy objects and annotations in Java.

I’m finding I have a love-hate relationship with proxy objects, reflection and annotations.

For our project I need to build a module which is capable of serializing our Java objects over JSON. The specifics of our protocol are a little different than most, so I rolled our own parser. No big deal.

But then our requirements on what can be serialized changed; the server team wants to represent the objects passed to me by interface only. So I started playing with using annotations to mark the interfaces and classes that are serialized, and mark how they should be serialized.

It’s convenient: we can declare a class, sprinkle a few annotations in, and call it a day.

Which I love.

The part I hate, however, is that I’ve now, very easily, with just a few lines of code, created a specialized “meta-language” on top of the Java language to handle the serialization code.

And I despise meta-languages with a fiery hatred that could power a thousand suns.

The problem with meta-languages is that they violate the very notion of “discoverability” which is at the heart of code maintenance. No longer can you sort out the functionality of a class or an interface by looking at it’s declaration–now you have to also understand a domain-specific meta-language which alters the behavior of the those classes and interfaces in some hard to understand way.

Yes, I know: the solution to such a thing is documentation, documentation, documentation. I get that. And I certainly plan to spend more time on my documentation than I did adding the annotations in the first place, and putting plenty of references to that documentation in our code.

But there’s the problem: most programmers despise documentation. They think code should be self-documenting. (Which is another way of saying “I’m a damned lazy fool who is too stupid to recognize those shadows on my retinas as fellow co-workers.”) And so we wind up with very strange meta-language components that are impossible to discover doing tricky things that–without proper documentation–is impossible to understand.


So the designer I work with gives me colors to use in our application as a web hex color specification, and I need to put it into my iPhone application as RGB values in the range [0,1]. Or I need to pick some color, and I pick an H=210° color, but I need to plug in the color into my application as integer RGB values. Or I need to type in [UIColor colorWithRed:xxx green:yyy blue:zzz alpha:1.0], and I’ve got r=110, g=250, b=155.

So out goes the calculator, and a lot of “155 [Enter] 255 [div]” and typing in the first three digits past the decimal place.

I’m a programmer. I can create tools.

So I built ColorPicker, a Macintosh-only program which allows you to set and adjust colors, and copy them in four different ways, so they can be quickly pasted into Mac, Windows or Java code.

Redistribute as you please, hopefully it will be useful to folks.

Fixed a bug in the asn.1 library

Actually, it’s not my fault. I got the following message from Al Jeyapal, pointing out the error of my ways.

From: Al Jeyapal 
To: woody@chaosinmotion.com
Date: Tue, 14 Jul 2009 14:29:36 +1000
Subject: BerUTC Parsing in ASN.1 Library

G'day mate,

I'm not sure if you're still maintaining the code for this library, but
thought I'd send this through in case you are.  There is a slight problem
with how BerUTCTime nodes are created.  The SimpleDateFormat needs to have
it's time zone set explicitly to UTC, else it will interpret the date using
the time zone from the current locale.

Diff is as follows:
@@ -40,6 +40,7 @@
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
+import java.util.TimeZone;

 * Represents a UTC time object.
@@ -98,6 +99,7 @@
        if (gFormat == null) {
            gFormat = new SimpleDateFormat("yyMMddHHmmss");
+            gFormat.setTimeZone(TimeZone.getTimeZone("UTC"));


Fixed in the current build.


Of course I feel stupid: I never noticed the problem before. However, in all of the protocols in all of the places where I’ve used the asn.1 library (and I still use it; I prefer asn.1 data streams to XML in my own ad-hoc protocols), I never had need to use the UTC time.


Java System Property Reference for Mac OS X

I don’t know why I keep misplacing this document, so I’m noting it here for future reference: Java System Property Reference for Mac OS X. This contains the various magic runtime system properties in Mac OS X.

The Java Development Guide for Mac OS X is also useful for how to do certain standard Mac-like things in the Java environment.

What I found was that by testing the System.getProperty(“os.name”).toLowerCase() return string to see if it contains “mac os”, then sprinkle various minor changes to make the UI align with the recommendations in the Java Development Guide above, you can build an application that looks Mac-like on a Mac platform with little effort.