Public Object

Hexed by converting ints to hex

Java's Integer class includes two methods for converting values into Strings. There's a general one:

    /**
     * Converts the specified integer into a string representation based on the
     * specified radix.
     */
    public static String toString(int i, int radix) { ... }

Plus there's also methods for commonly used bases:

    /**
     * Converts the specified integer into its hexadecimal string
     * representation.
     */
    public static String toHexString(int i) { ... }

    /**
     * Converts the specified integer into its octal string representation.
     */
    public static String toOctalString(int i) { ... }

    /**
     * Converts the specified integer into its binary string representation.
     */
    public static String toBinaryString(int i) { ... }

My expectation was that the first was simply a more general form. Given this assumption, I expected the following program to print the same three lines twice:

  public static void main(String... args) {
    System.out.println(Integer.toHexString(0xCAFE));
    System.out.println(Integer.toHexString(0xBABE));
    System.out.println(Integer.toHexString(0xCAFEBABE));
    System.out.println(Integer.toString(0xCAFE, 16));
    System.out.println(Integer.toString(0xBABE, 16));
    System.out.println(Integer.toString(0xCAFEBABE, 16));
  }

But it turns out that negative numbers have slightly surprising results when combined with arbitrary bases. The program prints the following:

cafe
babe
cafebabe
cafe
babe
-35014542

If you're emitting hex or binary data, you probably should avoid toString(int value, int radix).

# posted by Jesse Wilson on Tuesday, December 15, 2009 1 comments post a comment

Floating point equality

In working through some bugs in Harmony, one thing that's been consistent is my surprise. Floating point's special values slightly complicate things...

Negative Zero: Floats and doubles have two distinct representations for nada: 0.0F and -0.0F.
NaN: Rather than risking an ArithmeticException, floats model error values natively. There are multiple binary representations of NaN; use floatToRawIntBits() to see yours. Most developers will prefer floatToIntBits(), which returns the same bits for all NaNs.

There's also a variety of ways to store floating point values. Each representation has its own merits and drawbacks:

Primitives: Fast, memory efficient, and nonnull.
In wrappers: Classes like Float and Double can be used in collections. Wrapper variables are nullable and implement convenient APIs from Number and Comparable.
In buffers: FloatBuffer and DoubleBuffer store nonnull values in bulk. Buffers provide direct access to data in files and streams.

Unfortunately, the interplay between the values and their representation is imperfect. Consider how equality differs by value and representation.

Values Primitives
== In wrappers
Object.equals() In buffers
Buffer.equals()
-0.0, +0.0 equal not equal equal
NaN, NaN not equal equal equal

Values	Primitives `==`	In wrappers `Object.equals()`	In buffers `Buffer.equals()`
-0.0, +0.0	equal	not equal	equal
NaN, NaN	not equal	equal	equal

This behaviour is inconsistent but I suspect the differences weren't introduced lightly. Primitive types need to work in expressions so that 5/0 doesn't equal 0/0. But wrapper types need to work in collections so that Set.add() is consistent with Set.contains().

On their own, exotic values and exotic representations both make sense. But since complexity is the N×M product of the feature set, our result is inevitable pain. Would be language designers should prefer fewer representations and fewer special values.

# posted by Jesse Wilson on Thursday, November 19, 2009 3 comments post a comment

iPhone Storage

John Gruber praises the iPhone's lack of upgradeable storage:

I simply don’t understand why Motorola doesn’t follow Apple’s lead and provide ample built-in storage rather than relying on removable SD cards.

He overlooks an obvious benefit of having SD cards for storage: they're cheaper! Compare what it costs to equip a device with a substantial amount of memory:

iPhone 3G S Droid
16GB $199 $199
32GB $299 $279

	iPhone 3G S	Droid
16GB	$199	$199
32GB	$299	$279

Apple has a long history of gouging its customers on non-upgradeable memory. 32GB of data is the maximum amount that iPhone users may accumulate. Droid users who have >32GB of data can shuffle multiple cards.

# posted by Jesse Wilson on Monday, November 09, 2009 3 comments post a comment

Champagne Floats

Suppose you've got a string that contains a floating point number: "3.5" or "2.5E-3". Your goal is to get a float from that number. There are a few different techniques to try...

If you're familiar with parseDouble(), you could use that and then cast:

    String s = ...;
    float a = (float) Double.parseDouble(s);

Or you could save some bits and parse directly using parseFloat():

    String s = ...;
    float b = Float.parseFloat(s);

Do the two mechanisms yield the same result?

Ponder the problem, and when you're ready you can read my analysis in the comments...

# posted by Jesse Wilson on Wednesday, October 28, 2009 2 comments post a comment

IntelliJ goes open source!

I absolutely love IntelliJ IDEA; it's my favourite application. This tool makes programming in Java fun. It's my gateway to the zone, that magical hypnotic place where I disappear into the code for hours at a time. I write better code because I use IntelliJ, and I enjoy my job more.

So I am thrilled that the fine folks at JetBrains are open sourcing the core of their flagship product. The Community Edition includes the key features that make using it fun. Hooray!

Cedric doubts that going open source is a good idea:

"JetBrains deserves the utmost respect for what they have created and pioneered, but IDEA going opensource means that it will now slowly die. [...] Commercial software that goes open source never ends well, even for products that don't suck.

I disagree. I predict that going open source will increase the product's revenue. Consider the universe of all Java programmers. JetBrains' potential customer base is limited to those developers that are both:

Fans of IntelliJ. Knowing an IDE deeply is similar to knowing a programming language deeply.
People willing to pay for good tools. These are the serious developers who recognize that their productivity and enjoyment is heavily impacted by their choice of IDE.

This is a small intersection, particularly since many developers start with an open source IDE and never try anything else:

Now let's assume that by going open source, more developers will try IntelliJ to see what the fuss is about. They'll fall in love with it eventually. Those willing to pay will upgrade for some productivity-boosting premium features.

As the IntelliJ userbase grows, the premium edition ownership will follow.

This free/premium model is also used by Flickr and Flickr Pro: give away community editions (which cost nothing) to sell premium editions. Chris Anderson's latest book, Free covers this subject in detail. It's an entertaining read, and you can get a community edition of the book for no charge.

# posted by Jesse Wilson on Friday, October 16, 2009 1 comments post a comment

Shush! Ringer Restorer

I just uploaded a new Android app, Shush! Ringer Restorer:

When you turn your ringer off for a movie, this app turns it back on afterwards.
It's activated when you silence your ringer using the volume buttons. You don't need to remember a special app! Once your ringer is off, it asks you how long to stay silent: ½, 1, 2 or 3 hours. Never miss another important call!

I'm familiar with the Android tools, but this is the first app I've written. The whole project took around 16 hours, including downloading the SDK, writing the code, drawing icons, testing, publishing, and open sourcing.

I love Android because it enables apps like this one. My app receives ringer changes, opens dialogs with a polished UI, schedules background tasks, and turns on the ringer. I wrote in on Sunday and my friends downloaded it on Monday. I couldn't do any of this on the other device platforms.

Shush! was a fun project, and I'm now brainstorming a more ambitious follow-up.

# posted by Jesse Wilson on Monday, August 17, 2009 3 comments post a comment

I dig the Creative Commons

Joe Clark, author of a fantastic book on Canadian English and a childish rant about Google employees is at it again. This time he's planning a book about how copyright benefits creative people:

Who’s sticking up for the individual creator? Neither side is. The maximalist side wants to collect as many copyrights under a corporate umbrella as possible, guarding them forever. The minimalist side wants you to voluntarily surrender most of your important rights – also forever – on the off chance that “the culture” might someday wish to use your work.

I read Mark Helprin's Digital-Barbarism on the same topic. That book was entertaining, but it's more of an old man's rant than a reasoned argument. I assume Mr. Clark will be more disciplined, and read about copyright before he starts to write about copyright.

One premise of the new book is that creative commons is a bad idea. You sign up for creative commons because of peer pressure and don’t even know what you’re signing away. Naturally I feel compelled to share some counter examples that demonstrate the benefit of creative commons, from both sides of the copyright transaction.

As a creative person

While in highschool, I created a few dozen fonts and gave them away under a liberal license (creative commons didn't exist in 1997). I created the fonts because I enjoyed doing so, not because I wanted to become the next Britney Spears of fonts. By lowering the cost of using my fonts (to zero!), their use increased. There are great websites organized around sharing free fonts. As a consequence, I get to see my creative works in the wild. I've seen 'em in everything from video games to tattoos. One reason people prefer my fonts over the esthetically superior commercial ones is that they don't need permission to use mine!

As a consumer of creative works

Recently I've been giving tech talks at conferences. I get bored by text-only slides, so I've made my own presentation more interesting with pictures. For example, when explaining the Provider abstraction, I like to show a Pez Dispenser. The pictures are nice-to-have, but not essential. If I needed permission, I probably wouldn't include the pictures! It's a simple consequence of logistics — I may assemble the slides 48 hours before they're shown, but it takes longer than that to negotiate permission. Thanks to creative commons, I have a prettier slide deck.

The long tail

One of Joe Clark's budding arguments is that only the A-list content get remixed. As an amateur artist and a consumer of amateur art, I disagree. Unless you're doing it for the money, consider licensing your photos, fonts, music, drawings and writing under a creative-commons license. It allows other to showcase your talent!

# posted by Jesse Wilson on Wednesday, June 03, 2009 2 comments post a comment

Inside Guice 2: exercising elements

Part 3 in a Series.

Background: modelling configuration

One of the most distinct features of Guice is our fluent embedded domain specific language (DSL). By chaining method calls, Guice supports a wide combination of binding sources, targets and scopes:

    bind(PaymentService.class)
        .annotatedWith(Names.named("creditCard"))
        .to(VisaPaymentService.class)
        .in(RequestScoped.class);

    bind(new TypeLiteral<Connector<Processor>>() {})
        .annotatedWith(Online.class);
        .toProvider(new CheckoutProcessorConnectorProvider());

    bind(TransactionLog.class)
        .toInstance(new InMemoryTransactionLog());

In our first implementation of the DSL, calls to bind() etc. configured the injector directly. This works well, but it's not very flexible. As long as creating injectors is all that we do with modules, it's sufficient.

The Elements SPI

In Guice 2, the DSL is used to build an intermediate configuration model. Calls to bind() etc. create Element instances. For example, the three statements above will create a LinkedKeyBinding, a ProviderInstanceBinding and an InstanceBinding. The API to get the configuration model from a module is called Elements.getElements().

By converting the method calls into value objects, we get an opportunity to inspect and transform them. For example, the following prints all of the keys bound in a module:

  public static Set<Key<?>> getBoundKeys(Module module) {
    Set<Key<?>> result = newHashSet();
    for (Element element : Elements.getElements(module)) {
      if (element instanceof Binding) {
        result.add(((Binding) element).getKey());
      }
    }
    return result;
  }

Internally, we use this API to simplify injector creation. Now we can process elements in order we want, even when that's different from the order that the user has specified. We prefer to handle scope registrations before bindings, and bindings before injection requests.

These elements are useful in other APIs. For module overrides, we take elements from two modules and compute a union. We can also use elements to unit test modules without having their dependencies on hand. They'll also come in handy for development tools.

By converting method calls into value objects, we can do powerful new things.

# posted by Jesse Wilson on Thursday, May 21, 2009 0 comments post a comment

Inside Guice 2: injecting null

Part 2 in a Series.

Background: marking nulls

Null is bad. Most of the time, use of null indicates clumsy modeling. Instead of null collections, use empty ones. Instead of a null service, use a no-op implementation. The JDK gets this wrong for comparators by using null as a stand-in for natural order; the result is special cases instead of polymorphism.

To help you to detect null problems sooner, Guice refuses to inject null by default. When asked to do so, it will fail with a ProvisionException instead. This increases your confidence in your app by eliminating an entire category of runtime problems.

But sometimes — and only sometimes — null is necessary. Value objects don't lend themselves to the null object pattern. And in some cases you can be sure that a null reference won't be used. To make intentional null use explicit, you can use one of several @Nullable annotations, including those from FindBugs, IntelliJ or old snapshots of Google Collections. These will soon be standardized by another @Nullable in JSR 305.

Injecting null

Guice tolerates null to be injected wherever a parameter is annotated @Nullable:

  public Person(String firstName, String lastName, @Nullable Phone phone) {
    this.firstName = checkNotNull(firstName, "firstName");
    this.lastName = checkNotNull(lastName, "lastName");
    this.phone = phone;
  }

But which @Nullable?

Rather than arbitrarily choosing an @Nullable to support (and alienating everyone else), Guice permits any Nullable annotation to be used. And I do mean any: it scans the injected parameter or field's annotations, looking at their names. If any has the simple name Nullable, it is honoured. This means that even your company's internal com.company.util.Nullable will work.

More generally

This trick works particularly nicely for annotations, since they tag objects without adding behaviour. It also avoids an aggravating problem, where code that looks right doesn't work right. Consider:

import com.google.inject.Inject;
import javax.annotation.Named;

public class RealPaymentService implements PaymentService {

  @Inject
  public RealPaymentService(@Named("creditcard") Processor processor) {
    ...
  }
}

This code appears legitimate, and it might even execute without error. But the wrong @Named annotation is applied! The unreleased javax.annotation.Named is incompatible with Guice and has no effect. Since it looks the same as com.google.inject.name.Named, there's potential for error.

When applying annotations, be careful about overlapping names. When processing them, be mindful of mistakes! What's the annotation-equivalent of a precondition? If a user applies an annotation incorrectly, is it detected?

Part 3.

# posted by Jesse Wilson on Tuesday, May 19, 2009 4 comments post a comment

Inside Guice 2: binder sources

To celebrate the release of Guice 2.0, I'd like to showcase my favourite parts of the new code. In this N-part series, I'll go deep into the implementation details to explain the clever and interesting code within the project. I'll focus on general techniques that you can use in your own applications.

Background: Getting sources

When you invoke methods on a Binder (or invoke them indirectly, via AbstractModule), Guice captures the caller's source. This is used to create javac-like error messages in the event of a configuration problem. For example, the following binding is illegal because Executor is an interface without an implementation:

class BadModule extends AbstractModule {
  protected void configure() {
    bind(Executor.class);
  }
}

When this faulty module is used to create an injector, Guice reports the problem with the source line where it occurred:

Exception in thread "main" com.google.inject.CreationException: Guice creation errors:

1) No implementation for java.util.concurrent.Executor was bound.
  at com.publicobject.blog.Scratch$1.configure(Scratch.java:18)

1 error

To obtain the offending source line, Guice grabs a stacktrace using new Throwable().getStackTrace() and scans through its frames to find the logical source. It has to ignore some classes: AbstractModule.java, RecordingBinder.java, etc.

The stacktrace grabbing trick is extremely cool, but it's not sufficient. Guice can't always know the full set of classes that it should skip. Extensions like Multibinder create bindings on their user's behalf and need to omit additional classes from the trace (RealMultibinder.java, Multibinder.java). And Provider Methods specify their source as a method name instead of relying on a stack trace.

We need an API to specify which classes to skip in stacktraces, and another API to specify a source object directly.

Binder Sources

The difficulty in finding a nice API for configuring sources is that it's naturally temporal. We want to specify a source, use it for a binding or two, and then reset it back:

  public void configure(Binder binder) {
    Method method = ...
    Object previous = binder.getSource();
    binder.setSource(method);
    try {
      binder.bind(method.getGenericReturnType())
          .toProvider(new ProviderMethod(method));
    } finally {
      binder.setSource(previous);
    }
  }

Yuck.

Taking inspiration from List.subList(), our approach is to instead return a new binder that works with the provided source:

  public void configure(Binder binder) {
    Method method = ...
    Binder sourcedBinder = binder.withSource(method);
    sourcedBinder.bind(method.getGenericReturnType())
          .toProvider(new ProviderMethod(method));
  }

Every binding, injection or configuration applied to sourcedBinder will use the user-specified source. But the passed-in binder is untouched. With some inlining and the binder's existing embedded DSL, the whole thing can be a single statement:

  public void configure(Binder binder) {
    Method method = ...
    binder.withSource(method)
          .bind(method.getGenericReturnType())
          .toProvider(new ProviderMethod(method));
  }

This new API is cute and fits nicely with the existing code.

Part 2.

# posted by Jesse Wilson on Tuesday, May 19, 2009 1 comments post a comment

My perspective on Atinject

Back in February, a discussion flared up over Guice's lack of support for industry-standard annotations. James Strachan described the problem succinctly:

So my show stopper issue with ever adopting & recommending Guice is to be able to use IoC framework agnostic annotations for lifecycle & injection (JSR 250/EJB3 for starters, @Resource, @PostConstruct, @PreDestroy - you could throw Spring/WebBeans/JAX-RS/JAXWs in there too really but JSR250/EJB3 is the tip of this massive iceberg). i.e. so that my application code can be used by Spring or Guice IoC containers without having to double-annotate everything (using JSR 250 and Guice annotations) or using JSR 250 annotations then forcing producer methods for every class I write to be written by users using Guice.

In response to the immediate issue, Guice got support for custom injectors. And we're planning an API for lifecycle callbacks.

Unfortunately, the current annotations aren't really sufficient. @Resource precludes immutability. It lacks a compiler-checked way to qualify a type. And it lacks a mechanism for lazy or multiple injection.

Since @Resource is mostly a non-starter, each of the established containers defines its own annotations:

public class TweetsClient {

  @Autowired
  @com.google.inject.Inject
  @org.apache.tapestry5.ioc.annotations.Inject
  public TweetsClient(OpenIdCredentials credentials,
      HttpConnectionFactory connectionFactory) {
    ...
  }
}

The differences between these are superficial. There just aren't many ways to mark an injection point!

To unity their annotations, the established Java dependency injection vendors collaborated on a new API to serve as a common standard. The entire API is five annotations (including @Inject) plus Provider for lazy/multiple injection.

The spec enables class portability. Your classes can be used with any injector: annotate implementation class once to support all of Spring, Guice, PicoContainer, Tapestry IoC, and Simject.

But the new standard does not cover injector configuration. The lack of standardized configuration hurts application portability, because you must reconfigure for each injector.

Configuration was left out because there's no consensus on the best way to do it. Unlike annotations, each injector takes a distinct approach, each with relative strengths and weaknesses. For example, consider this (simplified) matrix:

Injector	XML etc.	Code	Annotations	Notes
Spring	✔	optional	optional
Guice		✔	✔
Butterfly	✔			has its own DSL
JSR 299	✔		✔	plus classpath scanning
PicoContainer		✔	✔

I'm excited about the new proposal because it's pragmatic. It paves the well-worn paths (the annotations), but permits innovation to foster elsewhere. Fantastic work guys!

# posted by Jesse Wilson on Thursday, May 07, 2009 3 comments post a comment

Java Minutiae - Reflex

Pop Quiz
The following is a method from a very decent implementation of Java SE. I've substituted x and y for the actual method name and parameter type. What are the values of x and y ?

public static boolean x(y z)isNaN(float z) {
  return z != z;
}

PS - it's a reasonable method. it may take you a few minutes to come up with the answer.

Show Answer

x = isNaN, y = float

It turns out that Float.NaN != Float.NaN. Weird! The same is true for Double.NAN. Since they're the only values with this property, testing for a lack of reflexivity uniquely identifies these values.

# posted by Jesse Wilson on Monday, May 04, 2009 1 comments post a comment

Some talks for your JavaOne Schedule

JavaOne is coming up, and now is the time to convince your boss to send you. You only need to learn a few productive tools for the conference to pay for itself. In addition to the Guice talk, here's some sessions I'm excited about...

Developing LimeWire: Swing for the Masses
Use painters, AppFramework, XUL and even GlazedLists to create hot Swing apps.

Simply Sweet Components
How Component-oriented design dramatically simplifies UI development.

The Collections Connection
Philosophy behind the Java™ Collections Framework and Google Collections.

JavaOne registration.

# posted by Jesse Wilson on Thursday, April 30, 2009 0 comments post a comment

Two simple classes for text processing in Java

FileCharSequence adapts a java.io.File as a CharSequence which has nice consequences. For example, you can run Java regular expressions directly against a File. And you can easily send part or all of a file to a StringBuilder or Writer:

/**
 * Adapts a text file as a character sequence so that it can be directly
 * manipulated by regular expressions and other character utilities. The
 * file may be at most 2 GB in size and encoded with {@code ISO-8859-1};
 * otherwise behaviour is undefined.
 */
public final class FileCharSequence implements CharSequence {
  ...
}

If you like this, feel free to use the code in your projects.

I prefer to use Java for one-off text processing tools. Partly this is because that's what my development environment is already set up to do, and partly it's because I'm not very productive in Python. With that constraint, I've written Strip.java. It uses FileCharSequence behind-the-scenes to strip all occurrences of a regex from a file. It uses Java's regex syntax, and supports switches like (?m) for multi-line regexes. Just like the Rip.java tool, it can be executed directly from your command line:


jessewilson:~$ Strip.java
Usage: Strip <regex> [files]

  regex: a Java regular expression, with groups
  http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html
         you can (parenthesize) groups
         \s whitespace
         \S non-whitespace
         \w word characters
         \W non-word

  files: files to strip. These will be overwritten!

flags:
  --clober: overwrite the passed in files rather than creating new ones
        -c:

  Use 'single quotes' to prevent bash from interfering

This code is also Apache-licensed for your enjoyment. Download Strip.java, make it executable (chmod a+x Strip.java) and put it somewhere on your path!

# posted by Jesse Wilson on Tuesday, April 21, 2009 3 comments post a comment

Upcoming Guice talks

Dhanji and I are doing some Guice talks over the next two months.

First, we'll be presenting at Google I/O. This conference is fast, web-focused, and cutting edge. It's also affordable: $300 if you register before May 1.

Big Modular Java with Guice
Learn how Google uses the fast, lightweight Guice framework to power some of the largest and most complex applications in the world. Supporting scores of developers, and steep testing and scaling requirements for the web, Guice proves that there is still ample room for a simple, type-safe and dynamic programming model in Java. This session will serve as a simple introduction to Guice, its ecosystem and how we use it at Google.

Then at JavaOne, I'll be providing a technical intro to Guice. It's a Friday afternoon time slot, so hopefully you're not too worn out to make the talk.

Introduction to Google Guice: Java is fun again!
Session TS-5434, Core Technology track
Friday June 5 at 14:50

Before Guice, the Java programming language subjected developers to a false dichotomy:
Use "new" to write concise but tightly coupled code. If you need more abstraction later on, you'll have to update all of the N callers.
Write a factory so you can easily change the implementation later on. You might end up doing unnecessary work, not to mention make your code harder to read.
Guice leverages recently added language features to enable the best of both words: abstraction without the boilerplate! Guice's @Inject is the new new. Start off with coupled and straightforward code. If you need more flexibility down the road, you can change your code in one place; you don't need to update N callers.
Jesse and Bob, each of whom have organized millions of lines of Google code, will compare factories and service locators to dependency injection, with and without Guice. Then, they'll show you how to use Guice to make your code more modular, readable, and testable than ever before. All you need is a working knowledge of the language.

Immediately following the introductory talk, Dhanji Prasanna will be presenting Google open source development with Guice, GWT, and SiteBricks.

Building Enterprise Java™ Technology-Based Web Apps with Google Open-Source Technology
Session TS-4062
Friday June 5 at 16:10

Google open-source technologies bring a new perspective to enterprise Web applications. The company likes simple stuff that's easy to maintain and that works and scales REALLY well. It also believes that the Java™ platform is strong and thriving and can be as lightweight and competitive as other popular dynamic platforms. With the right approach.
This session explores how you can take away the pain of traditional enterprise development with Googley alternatives in your stack. Use Google Guice, the Google Web Toolkit, and SiteBricks to completely rethink how you write applications. These technologies all employ idiomatic Java programming language -- but in highly productive, novel ways -- and have produced enormous success in some of the largest and most complex applications ever built.
Take the simple back! The Googley way.

Please come out! I'm particularly excited to get to spend some time with other developers. Mailing list discussions flow better for me when I can put a face to the names.

# posted by Jesse Wilson on Monday, April 20, 2009 5 comments post a comment