Trailing Commas in Java Arrays and Enums

A lot of Java developers might not know that trailing commas are allowed in Java arrays (see JLS Array Initializers). That means you can do something like this

String[] dinosInJurassic =  {
  "Archaeopteryx",
  "Diplodocus",
  "Plesiosaurus",
  "Triceratops", // ← trailing comma
};

… or even this, if you want (ref):

int i[][] = { {,}, {,}, {,}, }

I have to admit that the first snippet is the better example for the remaining text.

Benefits

Let let me first explain why this is a good thing. There are two main benefits according to Nik Graf, and although he wrote about JavaScript/ECMAScript, I think they are perfectly applicable to Java:

1. Clean diffs
2. Easy code manipulation

If this is not immediately clear, please read his article. It’s a good read with visual examples. The gist: code changes and you want to only see the relevant changes in your diff and don’t want to change more than necessary.

In other words and back to example 1 above: If you find another dinosaur that lived in Jurassic, or find out one of them did not actually live there (yes, it’s the Triceratops), you just add or remove a line.

Automated Checks

Nik alsorecommends enforcing this style with linting. In the Java world a lot of people use Checkstyle to make sure that code adheres to their standards, and of course there is a rule for this: ArrayTrailingComma.

The following is a minimal checkstyle configuration using this setting:

<module name="Checker">
  <module name="TreeWalker">
    <module name="ArrayTrailingComma" />
  </module>
</module>

The good thing about this is that it checks multi-line array definitions, so something like the second example is not enforced. I included this snippet, because I don’t use Checkstyle that much, but wanted to find out, whether it works correctly. There is even more usable stuff around this example here.

Is There More?

The title gave it away: You can also use these trailing commas in enum definitions (see JLS Enum Constants). The code I work with usually contains more enums than multi-line array definitions and I think this is not too uncommon.

I tend to write enums this way:

enum MovieTypes {
  GOOD,
  BAD,
  UGLY,
  ;
}

Same benefits as above, but unfortunately I cannot enforce this using Checkstyle, because I haven’t found the corresponding rule yet.

Long-Term AppEngine Development

I’ve had the chance to talk about my experiences with Google App Engine at a recent local GDG meetup. It was fun, because it was the first time I presented in front of people who were very new to the topic. This talk gave me a chance to think about my history with App Engine and how I’ve been using it. Here are the slides, thoughts after the fold.

My first experience with App Engine was shortly after its public availability in 2008. I used it for an academic project: as a proof of concept of my master thesis on software requirements. I also wanted to learn Python and play around with something new. The other cool thing I got to use at that time was Yahoo Pipes, which only recently, in summer of 2015, was shut down.

Since that time, the App Engine platform has progressed a lot and keeps improving. We’ve been using it for JS error logging in the web frontend at Trayn with only minimal maintenance overhead for the last few years. See the deployment cycles in the slides on page 14 for an example of how often we had to do something with the application.

Last month, among several announcements during GCP Next 2016, Managed VMs were rebranded as Flexible Environment. The now so-called Standard Environment is still an impressive piece of technology, but for me, more than that, encapsulates the web architecture and mindset we now all rely on when we use App Engine or similar platform. I hope I can follow up with some details at a later point in time.

Until then, I will try to collect my thoughts in upcoming posts and at this location.