About time

Mark Reinhold announces the JDK7 release.

UPDATE: And the release notes.

UPDATE: Oops.. I'll wait until the next patch release.

Straight from Darcy: JDK7

Nice keynote deck from Joseph Darcy on JDK7.

JMockit and static methods

Static methods are painful in Java when mocking but JMockit makes some impossible testing possible, though not easy:

public final class MockitEg {
    public static final int SHOE_SIZE = 13;

    public static int shoeSize() {
        System.out.println("MockitEg.shoeSize");
        return SHOE_SIZE;
    }

    private MockitEg() {
    }
}

public class MockitTest {
    private static final int MOCK_SHOE_SIZE = SHOE_SIZE + 29;

    @Test
    public void shouldMockStaticMethod() {
        new NonStrictExpectations() {
            final MockitEg mock = null;

            {
                MockitEg.shoeSize();
                result = new MockitEgDelegate();
            }
        };

        assertThat(MockitEg.shoeSize(),
                is(equalTo(MOCK_SHOE_SIZE)));
    }

    private static final class MockitEgDelegate
            implements Delegate {
        public static int shoeSize() {
            return MOCK_SHOE_SIZE;
        }
    }
}

The test passes.

Two web page nuggets

Two great web page nuggest from colleagues today:

• The C10K problem
• A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux

(Kudos to Gorlak on a clever domain name.)

Farwell LinkedBlockingQueue

More astonishing figures for the LMAX disruptor. More results like this and I feel a new JDK concurrency framework coming soon.

UPDATE:Trisha posts more explanation of the interesting technical tricks in Disruptor: magic cache line padding.

Java Zipper

A colleague moving between Python and Java asked me if there were an implementation of zip. Handling arbitrary tuples is challenging in Java, but the simple 2-tuple is straight-forward enough:

public final class Pair<T, U> {
    public final T first;
    public final U second;

    public static <T, U> Pair<T, U> pair(final T first, final U second) {
        return new Pair<T, U>(first, second);
    }

    private Pair(final T first, final U second) {
        this.first = first;
        this.second = second;
    }
}

public final class Zipper {
    public static <T, U> Iterable<Pair<T, U>> zip(
            final T[] first, final Iterable<U> second) {
        return zip(asList(first), second);
    }

    public static <T, U> Iterable<Pair<T, U>> zip(
            final Iterable<T> first, final U[] second) {
        return zip(first, asList(second));
    }

    public static <T, U> Iterable<Pair<T, U>> zip(
            final T[] first, final U[] second) {
        return zip(asList(first), asList(second));
    }

    public static <T, U> Iterable<Pair<T, U>> zip(
            final Iterable<T> first, final Iterable<U> second) {
        return new Iterable<Pair<T, U>>() {
            @Override
            public Iterator<Pair<T, U>> iterator() {
                return new Iterator<Pair<T, U>>() {
                    private final Iterator<T> fit
                            = first.iterator();
                    private final Iterator<U> sit
                            = second.iterator();

                    @Override
                    public boolean hasNext() {
                        return fit.hasNext() && sit.hasNext();
                    }

                    @Override
                    public Pair<T, U> next() {
                        return pair(fit.next(), sit.next());
                    }

                    @Override
                    public void remove() {
                        throw new UnsupportedOperationException();
                    }
                };
            }
        };
    }

    private Zipper() {
    }
}

I found several functional Java libraries but none as simple as my colleague wanted.

Kotlin: less is more

JetBrains announced a new JVM language underway: Kotlin. Thanks to Cedric Beust for pointing this out.

My first impression of Kotlin is a simpler Scala retaining the core principle: let the compiler do more, the programmer less. Heavy amounts of inference where it is useful, much shared syntax.

Good luck, JetBrains!

UPDATE: I missed this wiki page my first pass through: Comparison to Scala. The page has interesting comments as well.

UPDATE: Stephen Colebourne expresses a lot of my thoughts better than I do on Kotlin.

A subtle shuffling bug

Mike James explains why random shuffling might not be so random. Little surprise here: Knuth has the right solution.

Closure: Google Javascript optimizer and more

Chris Alexander cites Closure as one of the technologies behind Google+. The FAQ contrasts Closure with GWT:

Closure is geared toward developers who want to work with JavaScript and have a strong understanding of the language, while GWT allows developers to work primarily in Java (although they can work in JavaScript, too) without worrying about the underlying JavaScript.

I wonder what my Javascript friends think?

A reminder why make is a beast

At work today was a vivid reminder why make is a beast.
I'm integrating protobuf into a custom build system based on GNU make, call it yamake ("yet another make") and a proprietary IDL-like language, call it SDL ("sort-of definition language"). SDL is firmly rooted in the culture and systems, so it is non-negotiable. Over the course of the past few days, learned the steps:

1. Write a backend for the Python compiler script which translates SDL to your target language, in my case protobuf.
2. Hand off protobuf backend to guru colleague who munges it to better match the overall systems, and patches it into yamake.
3. Work on makefile to actually build usable jar of compiled protobuf for Java.
4. Watch colleague redo munging to something more permanent, less hacktastic.
5. Rework on makefile to actually build usable jar of compiled protobuf for Java.
6. Roll fake maven local repo holding new jar, of course yamake knows nothing about deploying jars.
7. Build new CORBA IDL jar for Java including new interfaces to access protobuf in other systems.

All this, and finally I can actually do useful work. Tomorrow.
But this is not the point of my post.
Yamake is a wrapper around venerable GNU make, so I am editing makefiles. Ultimately I have this dependency chain: SDL to protobuf to Java to classes to jar. But watch:

$ sdlc -t protobuf foobar.sdl -o proto/foobar.proto
$ protoc --java_out=java proto/foobar.proto
$ javac -sourcepath java java/my/package/FoobarProtos.java
$ jar cf foobar.jar -C java my/package/FoobarProtos*.class

It's actually more Rube-Goldbergesque than this, as the C++ versions of the protobuf play games with namespaces requiring various flags at various stages along with directory changes. So I made Java keep up. You come up with dependency rules that cope with option java_package = "something.random" and option java_outer_classname="SomethingProtos" and mismatched output directories!
I opted for using helper shell scripts for parsing protobuf for proper Java packages with class names and generating dependency makefiles to include in my actual makefile.
Maven, remind me to quit poking on you for your ugly XML and ridiculously noisy output. I forgot all the love you give me.