Posts Tagged ‘java’

Middle School Math, Reverse Polish Notation, and Software Design

One of the things I remember most about middle school math class is that I went through it in a perpetual state of disorganization. During one particularly bad spell, I lost two calculators within a week. The loss, and the reaction of my parents, drove me to try to fix the problem once and for all. My plan was simple: buy an expensive calculator with the hope that it’d serve as an incentive to keep track of my stuff. The next weekend, I took weeks of allowance money to the local Service Merchandise and bought a new HP-11C pocket calculator. Almost 30 years later, I still have both the calculator and a fascination for its unusual Reverse Polish Notation (RPN) user interface. Over those decades, I’ve also found out that RPN provides a good way to explore a number of fundamental ideas in the field of software design.

Continue Reading…

Logging the Boundaries of TestNG Test Methods with Log Messages

Posted Sep 5 2013 by in Java with 0 Comments

For a variety of reasons (some good, some bad) I tend to fall into the school of developers that debugs primarily with log messages and printf statements. (What can I say… It works for me.) As part of this style of working, I’ve developed a quick mechanism for instrumenting TestNG to print a log message at the beginning and ending of each test method that it executes. This makes it easier to make sense of the other log messages that get issued during a test cycle.

Continue Reading…

Clojure Closures In Java

As part of a team conversation this morning, I worked up a quick Java translation of some more-interesting-than-it-looks Clojure code. It’s a good example of how lexical closures map to objects.

The code we started out with was this:

(defn make-adder [x]
  (let [y x]
    (fn [z] (+ y z))))

(def add2 (make-adder 2))

(add2 4)

What this code does is define and return a new type of function that adds values to the constant x. In Java, it looks like this: Continue Reading…

Nicely Formatted Tabular Output in Java

Posted Aug 6 2013 by with 0 Comments

Occasionally, it’s useful to be able to print nicely formatted tables of data to a textual output stream. This is particularly the case when writing command line tools. To make the output of these tools more readable, any tables they write should have columns that line-up from row to row. The Unix tool ‘ls’ does this when it prints out long form directory listings. In this example, notice how the dates line up, even though the file size column varies in width.

drwxr-xr-x+ 1 mschaef Domain Users        0 Oct  3 09:20 docs
-rwxr-xr-x  1 mschaef Domain Users 29109013 Oct 10 13:38 file.zip
-rwxr-xr-x  1 mschaef Domain Users    77500 Oct 10 13:17 file2.zip

Continue Reading…

Why is Traditional Java I/O Uninterruptable?

Posted Jul 22 2013 by in Java with 0 Comments

One of the best things about writing code in the Java ecosystem is that so much of the underlying platform is open source. This makes it easy to get good answers to questions about how the platform actually works. To illustrate, I’ll walk through the JVM code to show why Java I/O isn’t interruptable. This will explain why threads performing Java I/O can’t be interrupted.

The core issue with interrupting a Java thread performing I/O is that the underlying system call is uninterruptable. Let’s see why that is, for a FileInputStream. Continue Reading…

Thread Local State and its Interaction with Thread Pools

Posted Jul 2 2013 by in Java with 0 Comments

I recently blogged about solving problems with thread local storage. In that instance, thread local storage was a way to add a form of ‘after the fact’ synchronization to an interface that was initially designed to be called from a single thread.  Thread local storage is useful for this purpose, because it allows each thread to easily isolate the data it manipulates from other threads. Unfortunately, while this is the strength of Thread Local storage, it is also the weakness. In modern multi-threaded designs, threading issues are often abstracted behind thread pools and work queues. With these abstractions at work, the threads themselves become an implementation detail, and thread local variables are too low level to serve some useful scenarios.

One way to address this issue is to use some of the techniques from an earlier post on dynamic extent. The general gist of the idea is to provide Runnable‘s with way of reconstructing relevant thread local state at they time they are invoked on a pool thread. This maps well to the idea of ‘dynamic extent’, as presented in the earlier post. ‘Establishing the precondition’ is initializing the thread locals for the run, and ‘Establishing the post condition’ is restoring their original values. Here’s how it might look in code: Continue Reading…

Dynamic Extent in Java

Posted Jun 28 2013 by in Java with 1 Comment

In my work, I tend to borrow heavily from the Lisp tradition, even when writing in Java. One of my go to techniques from the ‘Lisp world’ is using Runnable‘s in API’s to explicitly enforce dynamic extent. Without getting too heavily into the Lisp-specific terminology, dynamic extent is what you need to write code for the following kinds of scenarios:

  • ‘Ensure that an opened file is closed, after it’s been used’
  • ‘Ensure that this lock is released at the end of this critical section’.

These scenarios are common enough that Java provides explicit support for dynamic extent with the try...finally and synchronized(...) { ...} statements. However, both of these have to be explicitly written by the caller of an API, at each call site. There’s no way for a file API to use these constructs to automatically enforce that all opened files are eventually closed. The API is limited to providing open and closed and trusting that the caller will use try...finally. The technique I’m about to describe makes it possible to write an an API that removes that burden from the caller.

Continue Reading…