Monthly Archives: July 2012


I’ve just discovered what Dart’s about by watching Bob Nystrom’s video – Dart’s plan to make it easier for you to build web apps.

In a nutshell:

  • new language, can run on its own VM or be compiled to JavaScript
  • VM available for Chromium, compile to JS for use in other browsers
  • can debug the source Dart code in Chromium (as opposed to generated JS)
  • many nice language features, similar to JS but without many of the nastiness
    • lambda functions
    • proper scope, no hoisting
    • Java-style class declarations, but optional – everything doesn’t have to be in a class
    • avoids need for future proofing boilerplate – get functions have same syntax as variable access
  • new DOM API
  • dynamic, like JS, but with some optional static features at compile time e.g. optional types – that are enforced
  • leads to much better tool support – Dart Editor IDE
    • all the warnings, code navigation, refactoring support etc. you’re used to in IDEs such as Eclipse
  • Tree shaking – the compiled code only includes the parts of libraries that you actually use – a sort of linker
    • no need to avoid using that useful library just to avoid adding to page load time

It looks very promising to me and I look forward to experimenting with it soon.

Version control practices

Thoughts on good practice when using version control, based on my experience, and not in any particular order.

Commit one “thing” at a time, where “thing” is a feature or a bug fix. Don’t commit a feature at the same time as a bug fix, or multiple bug fixes at once.

Review what you’re actually committing – the files, and their contents. You may have temporary changes to some files, you might have forgotten to deal with a FIXME, you might have used an editor that’s messed up the whitespace/indentation of entire files.

Sometimes you get called upon to fix something while you’re working on a feature, with some half-done changes in your working copy. Create a branch, switch to it, commit your half-done stuff, then switch back to trunk to fix whatever it is. When you’re done fixing, either continue your work on the branch or just merge it in to trunk straight away and carry on.

Commit messages should say what you did, and if relevant, why (e.g. what issue it fixes). Bad examples are “changed js file”, “fix bug”. If you’re working on a feature and make multiple commits, “<name of feature>” is not a good message.

Learn how to resolve conflicts properly, take care when doing it, and test after merging (even if there were no conflicts). If in doubt about a conflict, ask someone. Learn how to resolve tree conflicts properly. Use a clean working copy for merges.

Learn how to revert committed changes (reverse merge), or ressurect files with history (svn copy).

Preserve history on file moves. Use svn move, or your SVN-enabled IDE to move files. These will track the fact that the file was moved, and the history will remain linked in SVN – this is called “addition with history”. If you just use Windows Explorer, your move will become just a delete and a corresponding unrelated add.

The Java Class class

I never had to touch this particular class until recently, so I had a look around what methods it has and what it’s useful for.

The most useful methods that I’ve used are forName and newInstance, the former to retrieve a config-file specified implementation of a particular interface, and the latter to instantiate that implementation. As specified by newInstance’s documentation, it’s better to get the class’s Constructor and use its newInstance method, as Class’ newInstance by-passes some exception handling. The method via Constructor also allows passing in parameters.

isAssignableFrom is also notable, as it’s “backwards instanceof” and doesn’t require you to know the class that would go on the right hand side of an instanceof at compile time.

Java Anti-Patterns

“Odi” has an excellent article about Java Anti-Patterns.

Some things I found interesting, learnt/realised or think others could do with knowing are below, with my comments and exclamations in some cases:

  • When initialising a StringBuilder, specify a length if you can in order to avoid unnecessary resizing.
  • Use String.valueOf(int) instead of “” + int
  • Don’t create needless objects, e.g. new Boolean, new Integer – use constants or valueOf.
  • Do not attempt to parse, manipulate or create XML via string processing! Also goes for JSON.
  • Specify encodings for readers and writers – don’t rely on the platform default.
  • Use buffers with streams.
  • Think about handling exceptions. Catch, log and carry on is often not the correct thing to do!
  • Always log the exception, not just it’s message!
  • Don’t re-wrap RuntimeException for throwing.
  • When re-throwing, pass getMessage() of the cause rather than just the cause – the latter uses the toString() of the cause as the message for the new exception, which  can get unwieldy as it includes the fully qualified name of the cause.
  • When catching, either log or throw. Not both. Usually that is, sometimes the caller is outside your control and might neglect to log it.
  • Take care with nulls in finally blocks that close streams etc. – if there are many involved and opening the first one failed, the others will be null when you try to close them.
  • Don’t swallow exceptions that “never happen”! The thrower might change in the future. Catch and throw a runtime exception instead.
  • Use Thread.currentThread().getContextClassLoader(), not getClass().getClassLoader() in application servers to get the right one.
  • SomeClass.class.isAssigableFrom(x) is reverse of instanceof – tells you if you can assign x to a variable of type SomeClass.
  • When passing a capacity to collection constructors, you need to take into account the point at which they auto-grow – this is less than the capacity! e.g. for HashMap it’s 1 + (numOfThingsYoureGoingToPutIn / 0.75).
  • Setters should not modify what they’re given!
  • Date manipulation is generally crazy and misunderstood.
  • SimpleDateFormat is not thread-safe. Use ThreadLocal.
  • Check for overflows before casting longs to ints.
  • Don’t use == with floats and doubles.
  • Timers keep tasks around until they expire, even after they get cancelled.