Atom Feed SITE FEED   ADD TO GOOGLE READER

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:

InjectorXML etc.CodeAnnotationsNotes
Spring✔optionaloptional
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) {
  return z != z;
}

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

Show Answer

# 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  4 comments   post a comment

    Jesse and Kevin B help out with Java Posse #239

    I love listening to The Java Posse. Back when they mentioned Glazed Lists on episode 76, I was majorly psyched. I ran home and played the relevant clip for my wife, who's usually annoyed at the amount of time I spend programming,
    "See Jodie? See, see? I feel so proud of myself, having been referenced on my favourite show! They'll know of Glazed Lists across seven continents! Yay!"
    Jodie, "Wow, my hubby is Internet-famous!" She was impressed, but only because I was.

    On Wednesday, I did even better - I got airtime on the Posse! Kevin B and myself got to discuss the news with Dick, Carl, Joe and Tor on Episode 239. Everytime that I listen to the Posse, I always want to participate in the discussion. Well, I had a chance and it was a fairly lively episode.

    You can hear me giggling at the jokes the whole way through. I probably shouldn't have giggled so much, but it's a habit from the previous 238 episodes. Keep up the fantastic work Java Posse.

    # posted by Jesse Wilson on Friday, April 03, 2009  3 comments   post a comment

    Read your address bar carefully

    Internet addresses are no longer stuck with ASCII and English. If you're Greek, you can have a Greek domain name; if you're Japanese you can have a Japanese domain name. To make international characters work on the existing ASCII system, you encode the address in Punycode:
    As an example of how IDNA works, suppose the domain to be encoded is Bücher.ch (“Bücher” is German for “books”, and .ch is the country domain for Switzerland). This has two labels, Bücher and ch. The second label is pure ASCII, and so is left unchanged. The first label is processed by Nameprep to give bücher, and then by Punycode to give bcher-kva, and then has xn-- prepended to give xn--bcher-kva. The final domain suitable for use with the DNS is therefore xn--bcher-kva.ch.

    To avoid spoofing addresses, browsers render the ugly Punycode version whenever there's an ambiguous character. This is necessary to differentiate pаypal.com (where the first a is replaced by a Cyrillic а) from paypal.com.

    http://com丿asp.com


    I registered xn--comasp-yz7i.com, the Punycoded form of com丿asp.com. The fourth character isn't a slash /, but the curlier Japanese character 丿. On current versions of Safari, this character lends itself to fun domain spoofing.

    This probably isn't good enough to fool a seasoned software developer. But could it fool your mom?

    PS: I've already reported the bug to Apple. If your app displays URLs to users, this is something you may need to consider as well.

    # posted by Jesse Wilson on Saturday, March 07, 2009  0 comments   post a comment

    Preprocessing .java with Munge

    In the rare situation that you need to preprocess .java files, Munge is a pretty decent tool for getting it done. From Tom Ball's blog,
    So a combination preprocessor and string translator, Munge, was created to address [supporting Java 1.1 and Java 2] (source). Since its requirements were that it be small, fast and require no maintenance (it wasn't a product, after all), it purposely has no features that weren't needed by the team. It won't have your favorite cpp or sed feature, but what it did, it did quickly and correctly. It wasn't open-source then, but if you wanted a feature you were handed the source and told to have fun.

    We're using Munge in Guice to support both AOP and non-AOP releases. AOP is awesome, but it requires bytecode generation which isn't available on Android yet. To support stripping AOP out, our source files now include preprocessor instructions:
    public interface Binder {

      /*if[AOP]*/
      /**
       * Binds a method interceptor to methods matched by class and method
       * matchers.
       *
       * @param classMatcher matches classes the interceptor should apply to. For
       *     example: {@code only(Runnable.class)}.
       * @param methodMatcher matches methods the interceptor should apply to. For
       *     example: {@code annotatedWith(Transactional.class)}.
       * @param interceptors to bind
       */
      void bindInterceptor(Matcher<? super Class<?>> classMatcher,
          Matcher<? super Method> methodMatcher, MethodInterceptor... interceptors);
      /*end[AOP]*/

      /**
       * Binds a scope to an annotation.
       */
      void bindScope(Class<? extends Annotation> annotationType, Scope scope);

      ...

    I patched Munge to be a bit more careful with C-style comments (/*) inside end-of-line comments and strings. This is necessary to handle calls like filter("/*") and serve("/*") in our updated servlet package.

    Ours also has an Ant task to munge the entire project in one go:
      <target name="no_aop"
              description="Create a copy of the Guice source that doesn't do bytecode generation.">
        <taskdef name="munge" classname="MungeTask" classpath="lib/build/munge.jar"/>
        <mkdir dir="build/no_aop"/>
        <munge todir="build/no_aop">
          <fileset dir="." excludes="build/**/*"/>
          <arg value="-DNO_AOP" />
        </munge>
      </target>

    If you're preprocessing some .java files and can use these features, help yourself to our custom munge.jar. The jar includes both source and classfiles.

    # posted by Jesse Wilson on Wednesday, February 18, 2009  1 comments   post a comment

    Always use jarjar to package implementation dependencies

    jarjar is a sweet Java packaging tool that allows you to embed one .jar file in another. But rather than just smashing the jars together in one big archive, jarjar renames the embedded .jar's classes so that they live in the main jar's namespace. For example, Guice's ProxyFactory.java file has an impressive collection of imports:
    package com.google.inject;

    import com.google.common.collect.ImmutableList;
    import com.google.common.collect.ImmutableMap;
    import com.google.common.collect.Lists;
    import com.google.common.collect.Maps;
    import com.google.inject.internal.*;
    import java.lang.reflect.*;
    import java.util.*;
    import net.sf.cglib.proxy.Callback;
    import net.sf.cglib.proxy.CallbackFilter;
    import net.sf.cglib.proxy.Enhancer;
    import net.sf.cglib.proxy.MethodProxy;
    import net.sf.cglib.reflect.FastClass;
    import net.sf.cglib.reflect.FastConstructor;

    class ProxyFactory implements ConstructionProxyFactory {
      ...
    }

    These imports include classes from net.sf.cglib and com.googe.common.collect. But when we package it up with jarjar, everything gets prefixed with the Guice package name: com/google/inject:
         0 Thu Jan 01 22:13:36 PST 2009 META-INF/
      1726 Thu Jan 01 22:13:34 PST 2009 META-INF/MANIFEST.MF
     11357 Sun May 25 20:34:04 PDT 2008 LICENSE
       101 Sun May 25 20:34:04 PDT 2008 NOTICE
      5975 Thu Jan 01 22:13:20 PST 2009 com/google/inject/AbstractModule.class
      2466 Thu Jan 01 22:13:20 PST 2009 com/google/inject/Binder.class
       806 Thu Jan 01 22:13:20 PST 2009 com/google/inject/Binding.class
       414 Thu Jan 01 22:13:22 PST 2009 com/google/inject/BindingAnnotation.class
       ...
       136 Sun May 25 20:34:04 PDT 2008 com/google/inject/internal/cglib/proxy/Callback.class
       238 Sun May 25 20:34:04 PDT 2008 com/google/inject/internal/cglib/proxy/CallbackFilter.class
     28315 Sun May 25 20:34:04 PDT 2008 com/google/inject/internal/cglib/proxy/Enhancer.class
      5712 Sun May 25 20:34:04 PDT 2008 com/google/inject/internal/cglib/proxy/MethodProxy.class
      5535 Sun May 25 20:34:04 PDT 2008 com/google/inject/internal/cglib/reflect/FastClass.class
      1642 Sun May 25 20:34:04 PDT 2008 com/google/inject/internal/cglib/reflect/FastConstructor.class
      ...
      8144 Sat Nov 29 14:11:22 PST 2008 com/google/inject/internal/collect/ImmutableList.class
      9826 Sat Nov 29 14:11:26 PST 2008 com/google/inject/internal/collect/ImmutableMap.class
      6026 Sat Nov 29 14:11:24 PST 2008 com/google/inject/internal/collect/Lists.class
     12551 Sat Nov 29 14:11:26 PST 2008 com/google/inject/internal/collect/Maps.class

    By using jarjar, Guice encapsulates these library dependencies. This is fantastic! Many problems are avoided by encapsulating the library dependency:
    • Guice users don't need to tell their classpath, IDE or build.xml files about cglib or Google Collections.

    • Other versions of the libraries won't conflict with the Guice version. We can ship one binary and support users of either extremely old or extremely new versions of cglib. Even if cglib broke compatibility every release (it doesn't), we aren't impacted.

    • We can freely change our own libraries. Should we add a dependency on paranamer in a future release, our users don't need to reconfigure their build scripts.

    • Most importantly, we can patch the libraries to fit our needs. If we want a special build of google-collections that includes our own hacks and tweaks, that's just fine. Our build doesn't even need to be compatible with the public version.


    Standard jars for API dependencies


    Guice's dependency on aopalliance doesn't use jarjar. Guice users implement the aopalliance interfaces, so the version independence and encapsulation offered by jarjar doesn't make much sense.

    # posted by Jesse Wilson on Thursday, January 01, 2009  3 comments   post a comment

    howmanyspacesafteraperiod.com

    Inspired by the URL-as-question meme sites http://has the large hadron collider destroyed the world yet.com and http://should I use tables for layout.com, I present http://how many spaces after a period.com:

    # posted by Jesse Wilson on Thursday, November 20, 2008  4 comments   post a comment

    Audible on Android (and other devices)

    I love my new G1, but it doesn't work with Audible yet. Fortunately, I have a workaround. This guide describes how to get audiobooks onto a G1. You'll need a Mac and $40 worth of software.

    Download and install Tune4Mac. This app creates a virtual CD burner on your Mac, so when you tell iTunes to burn a CD, you don't actually need a blank CD-R. It's a clever hack, and the software works as promised. There's a Windows version, but I haven't tried it.

    Register Tune4Mac. It's $39.95. You'll get the license key to your email immediately, paste that in the app's Registration dialog.


    Configure AAC output in Tune4Mac. Tune4Mac automatically encodes audio to either MP3 or AAC. I tried MP3 encoding, and it was flaky, but AAC encoding worked just fine. Save this change by closing the dialog.


    Add audiobooks to iTunes. Purchase DRM-protected books from Audible.com. If this is your first time using Audible, choose format #4, a high quality format that works with iTunes.


    Create a playlist in iTunes. iTunes burns CDs using playlists, and we're going to be burning a virtual CD. I used a different playlist for each part of my two-part audiobook.


    Prepare the fake burn. Click the 'Burn Disc' button in the bottom right corner of the iTunes app. Select Tune4Mac Virtual CDRW, Maximum Possible, Audio CD, none and Include CD Text. Click burn.


    Burn fake CDs. Click 'Burn' on the dialog, and then Audio CDs on the dialog that follows. It took an hour for my computer to burn all the virtual CDs for an entire book. During this time, Tune4Mac automatically cycles fake blank CDs so you can go grab a coffee.


    Use Finder to transfer the book to your device. I opened the Documents folder, and then the Tune4Mac folder to find my audiobook file. I plugged my device into my Mac, causing an icon for it to show up in the Finder. I dragged the .m4a file to this icon to transfer the book.


    Eject the device. In the Finder, click the device's eject icon before detaching it. Otherwise the transfer might not finish properly.

    Enjoy! You can now enjoy audiobooks on your device. Unfortunately, some devices don't bookmark audiobooks, so you'll need to remember your place when you stop listening.

    Disclaimer: I admit that this process is painful and expensive. Hopefully Audible follows Amazon's lead and makes DRM-free audiobooks available for purchase. That way, Audible's huge library will be available to a larger audience.

    # posted by Jesse Wilson on Monday, November 17, 2008  2 comments   post a comment