Wednesday, March 21, 2012

Jline moves forward

One of my favorite Java libraries, jline, released 2.6 recently. Among the goodies is support for ~/.inputrc. This is as close to readline as Java gets.

Tuesday, March 13, 2012

The science of cloud computing

The physics arXiv blog at MIT Technology Review posts The Hidden Risk of a Meltdown in the Cloud.

As with anytime you bet the farm on a technology, try to have a backup plan.

Monday, March 12, 2012

re: Romans, rubies and the D

Kajetan Rzepecki posts Romans, rubies and the D, a clever comparison of Ruby missing method look up and the compile-time equivalent in D. (It's short, please read.)

This is a clean example in favor of proper macros (not the "CPP" sort).

I've long been impressed by D. It makes up for many of the faults in C++, which impresses me less as time goes on. What is impressive about D? I appreciate that the first thing it says about itself is:

D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.

And that, therefore, this comes only second:

The D language is statically typed and compiles directly to machine code. It’s multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It’s a member of the C syntax family, and its appearance is very similar to that of C++.

That says something good about taste in my book.

Friday, March 02, 2012

Showing test failure name for JUnit parameterized tests

A popular complaint against JUnit is lack of human-readable names for parameterized test cases. There are several solutions, this is mine.

 * {@code ParameterizedTest} simplifies parametered JUnit tests by including a "case label" to
 * identify the failing branch.  (JUnit only provides an index).  The failure message format
 * becomes "descriptive string from JUnit: case label: assertion failure message".
 * <p/>
 * Fully preserves the stack trace of failing tests.
 * <p/>
 * Example: <pre>
 * public class MyTest {
 *     &#64;Parameters
 *     public static Collection<Object[]> parameters() {
 *         return ...; // See JUnit documentation for parameterized tests
 *     }
 *     public MyTest(final String caseLabel, final X x, final Y y) {
 *         super(caseLabel);
 *         this.x = x;
 *         this.y = y;
 *     }
 *     &#64;Test
 *     public void shouldWork() {
 *         // Body of test method ...
 *     }
 * }
 * </pre>
 * When {@code shouldWork()} fails the failure message is more meaningful, including the
 * {@link #caseLabel "case label"} in the JUnit error message.
 * @author <a href="">B. K. Oxley (binkley)</a>
public abstract class ParameterizedTest {
    private final String caseLabel;

     * The JUnit test rule (test extension) which fails bad parameterized cases but provides a
     * {@link #caseLabel case label} identifing the failed test branch.
    public final TestRule parameterizedTestRule = new TestWatcher() {
        protected void failed(final Throwable e, final Description description) {
            final AssertionError x = new AssertionError(
                    description.getDisplayName() + ": " + caseLabel + ": " + e.getMessage());
            throw x;

     * Constructs a new {@code ParameterizedTest} for the given <var>caseLabel</var>.
     * @param caseLabel the case label, never missing
    protected ParameterizedTest(@Nonnull final String caseLabel) {
        this.caseLabel = caseLabel;