The Rosetta stone, what a paper

I am really enjoying this paper by John Baez (yes, that John Baez) and Mike Stay. My background is in physics (and music) and the crossing of physics, topology, logic and computation is too much to keep to myself. I hope you enjoy it, too.

Update on Google Phone saga

An update from Google on my continuing Google phone quest:

XXX YYY has posted an answer to the question "Ineligible to purchase phone: T-mobile contract changed too recently": Howdy binkley, We've listened very carefully to everyone's feedback and concerns regarding the upgrade issue and are working with our partners to improve the situation for existing customers. In all instances, Google's web store only passes your information along. The carrier then determines eligibility for a full or partial upgrade, as your service contract is with the carrier. You must be fully upgrade eligible in order to get this device at a discount. Stay tuned for more updates about upgrading! In the meantime, you can use the sticky post at the top of this forum to get the latest information and share any more thoughts you may have: http://www.google.com/support/forum/p/Google+Mobile/thread?tid=3c0fd3870ec370a8&#all Cheers, -XXX

UPDATE: I've received a variant of this text in a second message from another Google employee. It's good they are trying to deal with this mess. I should not be surprised at the form letter template employees work from.

Rusty Java: in-place updating a collection while iterating

Some areas of my Java grow rusty with time, as with all things. This code looks nice, but completely fails:

public static void main(final String... args) {
    final Set<Foo> foos = new HashSet<Foo>(asList(FOO));

    for (final Foo foo : foos)
        foos.addAll(foo.more);

    System.out.println("foos = " + new HashSet<Foo>(foos));
}

enum Foo {
    QUUX,
    BAZ(QUUX),
    BAR(BAZ),
    FOO(BAR, BAZ);

    private final Set<Foo> more;

    Foo(final Foo... more) {
        this.more = new HashSet<Foo>(asList(more));
    }
}

The goal is to collect all transitive dependencies. What is wrong?

The iterator is not a "current picture" of the collection; it is a snapshot. This code prints only foos = [FOO], updates vanish. Changing to ArrayList only worsens things with the dreaded ConcurrentModificationException.

Correct is to use a list iterator and be careful with cursor position:

public static void main(final String... args) {
    final List<Foo> foos = new ArrayList<Foo>(asList(FOO));
    final ListIterator<Foo> lit = foos.listIterator();

    while (lit.hasNext())
        for (final Foo foo : lit.next().more) {
            lit.add(foo);
            lit.previous();
        }

    System.out.println("foos = " + new HashSet<Foo>(foos));
}

This prints foos = [QUUX, BAZ, BAR, FOO] with the happy side effect of depth-first ordering.

Class token nuisance

Fabrizio Giudici posts a nice description of type-safe map keys, a clever way to simplify life for an API user.

It exposes one of the nuisances of class tokens:

@Nonnull
public <T> T get (final @Nonnull Key<T> key)
  throws NotFoundException
  {
    return NotFoundException.throwWhenNull(
        (T)itemMap.get(key), "Not found: " + key);
  }

(Kudos to him for using JSR-305 annotations.)

See the cast (T)? That generates a compile-time warning (link just one of many complaints around this). The correct way to get ride of this warning is to use a class token:

@Nonnull
public <T> T get (final @Nonnull Key<T> key)
  throws NotFoundException
  {
    return NotFoundException.throwWhenNull(
        key.cast(itemMap.get(key)), "Not found: " + key);
  }

Where the Key<T> type is redefined:

@Immutable
public final static class Key<T>
    implements Comparable<Key<T>>
  {
    @Nonnull
    private final String name;
    @Nonnull
    private final Class<T> type;

    protected Key (final @Nonnull String name, final @Nonnull Class<T> type)
      {
        this.name = name;
        this.type = type;
      }

    public T cast(final Object that)
      {
        return type.cast(that);
      }

    @Override
    public int compareTo (final @Nonnull Key<T> other) { ... }

    @Override
    public boolean equals (final @CheckForNull Object object) { ... }

    @Override
    public int hashCode() { ... }
  }

What a nuisance.

ANI, not your usual language

This is interesting: anic, a compiler for the language ANI. It is really the language which is the interesting part, of course.

ANI is automatically parallelizing, and very non-inperative. In its own buzzwords: experimental, high-performance, statically-safe, fully implicitly parallel, object-oriented, general-purpose dataflow programming language.

Take a breath now.

Bad fanboi - no gphone

Continuing my Nexus One story...

So far I cannot get a Google phone. At first the site did not like my T-mobile family plan. So I went from $60/mo. to $130/mo. to break up our plan into a his/hers data/voice plan.

Now Google still does not like my T-mobile plan:

You are not eligible for an upgrade at this time.
You are not eligible because your current contract was initiated too recently.

No love from Google.

IntelliJ and Scala

Thomas Jung writes about using IntelliJ and Scala and is very enthusiastic, as he should be: IntelliJ IDEA remains the best IDE.

I've long been pessimistic of IDEA retaining this position in the face of thousands of Eclipse code monkeys eventually typing the works of Knuth, but JetBrains has admirably kept up.

The struggle between the cathedral and the bazaar continues.

UPDATE: When it rains, it pours.

Those lucky web developers

Those lucky web developers have it so good. Automated functional testing for enterprise integration middleware is a complete pain. You try simulating a dozen distinct systems. Helps keep me warm at night just thinking about it.

Actor thinking from Kresten Krab Thorup

Kresten Krab Thorup posts a long think on objects and processes, full of great references, which I enjoy. Maybe you will, too.

isolate: a new tool for my toolbox

isolate is the newest tool in my toolbox. Paranoids are sometimes correct. (Found thanks to LWN.net.)

Nexus One URL almost there

What is the typical error page for a bad link into Google, say, http://www.google.com/bobsyerunkel? But for http://www.google.com/phone I get a prosaic default 404 page, perhaps in preparation for something more interesting later today.

UPDATE: Not happy! http://www.google.com/phone works now, but T-mobile is disabled as a choice. Only the unlocked phone is offered:

We're unable to sell T-Mobile service plans at this time, but you can still buy the unlocked phone.

This was my Christmas present from my wife!

UPDATE #2: I was premature. The T-mobile option now works, very nicely, too. However, it checked my existing T-mobile phone number and said family plans were not eligible. Time to confer with the wife.

UPDATE #3: Spent 20 minutes on line with T-mobile. She was courteous and did her best, but management left them unprepared for Nexus One release beyond a cursory memo. Several checks with different supervisors, still no answer on how to split family plan, add Nexus One plan for myself. There's always tomorrow.

Revisiting an old post: mixing OSGi, Scala, et al with pax

I overlooked the coolness of Brian Murphy's post the first time I ran across it: OSGi With Scala, Java, Groovy, Maven and PAX. As I am playing with OSGi, guice and peaberry, I ran across his instructions and was struck by how straight-forward pax makes everything.

My contribution to the conversation, bootstrapping a peaberry project:

$ pax-add-repository -i google-maven-repository \
    -u http://google-maven-repository.googlecode.com/svn/repository
$ pax-add-repository -i ops4j.releases \
    -u http://repository.ops4j.org/maven2
$ pax-import-bundle -g com.google.inject -a guice -v 2.0
$ pax-import-bundle -g org.ops4j -a peaberry -v 1.1.1
$ pax-create-module -a wrappers
$ cd wrappers
$ pax-wrap-jar -g aopalliance -a aopalliance -v 1.0
$ cd ..
$ pax-create-bundle -p $your_groupId -n $your_artifactId

This presumes a simple project with only one module ("$your_artifactId").

Top notch post on JDK 1.6 update 14 optimizations

A really good post on JDK 1.6 update 14 optimizations: lock coarsening, biased locking and escape analysis. Found via the Java Specialist newletter.

Google collections: Happy birthday!

Felicem diem natalem!