Switch conditional order since 'void' is a primitive class.

[JakeWharton]

No description provided.

[tbroyer]

If void is a primitive type, should we rather move to PrimitiveName.VOID instead of VoidName.VOID?

[JakeWharton]

Possibly. When you say Java primitives types I'm willing to bet almost everyone only lists the 8 value types. So it's whether we want to be exactly correct or more semantically correct.

Thoughts @gk5885?

[eamonnmcmanus]

The area is kind of murky. The JLS does not consider void to be a type at all, but merely says that a method has a Result, which can be either a type or void. On the other hand, given the precedent of Class.isPrimitive() and the nine boxed types in java.lang, perhaps the simplest thing would indeed to get rid of VoidName and add a ninth value to PrimitiveName. Alternatively, we could deal with void properly in the type system by having the returnType parameter to the MethodWriter constructor be a TypeNameOrVoid or an Optional<TypeName>, thus making it a compile-time failure to try to use void anywhere else (for a field or a parameter or a local variable).

[tbroyer]

@eamonnmcmanus Add to that that void is a NoType in javax.lang.model.type. So I think that void.class.isPrimitive() is an unfortunate legacy, and we should probably keep the VoidName (I think the TypeNameOrVoid would unnecessarily complicate things).

In other words, LGTM.

[eamonnmcmanus]

What about Optional<TypeName> for specifying the returnType of a MethodWriter, or a second constructor with no returnType parameter? I think it's a little unfortunate that the current model allows you to ask for a void field or parameter, when it could so easily not.

[JakeWharton]

@eamonnmcmanus Want to open an issue for that? Since this PR is just fixing the existing behavior I'm going to go ahead and merge (especially since it's blocking me).