A reasonably busy April at the cinemas has meant another bigger-than-usual Film Fight, with five films.

Kick-Ass is a ridiculous film. It’s an absurd premise (a kid decides to become a super-hero and finds out he isn’t the first one to try it), that holds together remarkably well when paired up with intentionally over-the-top violence in a pseudo-comic book world. It’s bloody, and goes quite far at times (mostly when it uses Hit Girl), but manages to pull it off by making it clear that this is entertainment and clearly straight out of a graphic novel. While the story isn’t anything to right home about, and it has some cringeworthy moments, it remains entertaining to the end. (See my Kick Ass Twitter review).

Green Zone sees Matt Damon team back up with Paul Greengrass, in a plot pulled straight from a Tom Clancy novel. Yes, it’s the usual military-complex, conspiracy nonsense, but it is reasonably fun. It works best when letting Damon get into the action set-pieces and starts to wane whenever it goes near the reasons for the conspiracy. For the most part, a reasonable balance is found to keep things moving forward. Where it really falls down is in the comparisons that have been drawn to the Bourne trilogy. Even on the action side, this is a much more relaxed affair than the impossibly well-developed skills of Damon’s previous super-spy character. Worth seeing. (See my Green Zone Twitter review).

Comedy, good comedy, can be painfully uncomfortable. Either bringing up subjects that most people consider taboo to shed some light on them or by poking fun at preconceptions. It was surprising to see that Crying With Laughter managed to blend that discomfort so well into a fairly dark thriller so well. It tells the story of a stand-up who is at his make-or-break point, going further and darker with every show, as he bumps into someone he used to know who will give him an incredible story to tell. At moments the film is incredibly funny, and at others it’s horrific as you discover the painful memories that full the lead. A few of the minor characters aside, this is a fantastic film; that brings together two kinds of unease, and produces an excellent story from them. Highly recommended. (See my Crying with Laughter Twitter review).

Mike Judge has an incredibly strong legacy with Beavis & Butthead, King of the Hill, Idiocracy and his classic, Office Space. It’s with that in mind that it’s fairly surprising his new movie, Extract, just isn’t that funny. There are some great moments and some well-observed characters (David Koechner delivers another great small part), but a lot of it falls flat. It’s not awful, but it is entirely forgettable. (See my Extract Twitter review).

Finally, Todd Solondz returns to the characters he introduced in Happiness 12 years ago, recasting them all in a pseudo-sequel, Life During Wartime. If you liked the first film, you’ll wish he hadn’t. It has a scant few jokes that hit the familiar territory of awkwardness that Solondz thrives in, but much of it doesn’t work. As a whole, the film lacks any real cohesion, with fairly uninteresting characters not really doing much or saying anything of real value. There’s not much of a theme, just a series of moments that hang together poorly. It’s a shame because a few of them work incredibly well: the scene where Billy is reunited with his father is absolutely gripping. A quite disappointing effort. (See my Life During Wartime Twitter review).

And the winner is… Crying With Laughter, for walking the fine line between horrific and funny extremely well.

In the previous post, I showed how JSR-303 is making validation neater. I concluded that article with the Person bean looking like this:

@Data
public class Person {
    @NotNull @Size(min=1)
    private String firstName;
    @NotNull @Size(min=1)
    private String lastName;
    @Min(18)
    private int age;
}

If we know we have a valid bean, at some point we probably want to persist it so we can use it again. I won’t waste time on spelling out how much boilerplate code is written for raw JDBC calls as most developers have moved a level of abstraction up from that anyway, with great tools like Spring’s JdbcTemplate.

I also won’t go deeply into the history of ORM in Java, as a lot has already been said. The Java Persistence API (JPA) standardised fairly sensible ideas about how ORM should work, starting from real implementations (primarily Hibernate) and pulling together the main concepts. To prepare a bean for JPA persistence, we merely need to add an @Entity annotation and specify an @Id column (which I’m going to have to add to Person):

@Data @Entity
public class Person {
    @Id
    private Long id;
    @NotNull @Size(min=1)
    private String firstName;
    @NotNull @Size(min=1)
    private String lastName;
    @Min(18)
    private int age;
}

And that’s it. You can then use a properly configured EntityManager to persist() your class (the configuration details are largely implementation specific, but relatively lightweight).

There are a lot of options available to configure exactly how an entity should be persisted when passed into an EntityManager. Again, I won’t cover them all, but it’s generally considered best practice to state your table and column names explicitly (rather than relying on convention, as I have above) and you’ll often want to make use of the built-in optimistic concurrency support to stop multiple changes happening at once.

@Data @Entity @Table(name="people")
public class Person {
    @Id @Column(name="id");
    private Long id;

    @Version @Column(name="version")
    private int version;

    @NotNull @Size(min=1)
    @Column(name="first_name")
    private String firstName;

    @NotNull @Size(min=1)
    @Column(name="last_name")
    private String lastName;

    @Min(18)
    @Column(name="age")
    private int age;
}

As a bonus, if you use a JPA2 provider AND have a JSR-303 validation implementation in your classpath, the default behaviour will be for your bean to get validated before it gets persisted, so you wouldn’t have to explicitly call the validator any more.

Again, there’s a lot more to be said about JPA, and the use cases that it supports (I haven’t touched on object-graphs, embedded collections, or the Java persistence query language), but you should have a flavour for it.

In the previous post on Modern Java, I showed how Lombok is making Java beans more concise. In that post, I showed how we would end up with the following class:

@Data
public class Person {
    private String firstName;
    private String lastName;
    private int age;
}

Given an instance of that class by binding data from a web form, a database or some other data source, a fairly common requirement is to validate it against a series of rules and constraints.

For example, if we assume “age” is the number of years the person being described has been alive, we know that it must be zero or greater. Depending on our application we may also know that it’s above a minimum age (18, say) and is extremely likely to be below a maximum age (there are very few people over 100, and none over 120).

A few years ago, you would have to write a custom piece of code to validate simple rules in all of your domain classes. These would typically be specific to the class in question, running through a series of explicit checks, and produce a list of errors found. While this worked, it was often verbose and tightly-coupled to each domain class. It might look something like this:

public Collection<Error> validate(Person person) {
  Collection<Error> errors = new LinkedList<Error>();
  if(person.getAge() == null) {
    errors.add(new Error("Age cannot be null"));
  }
  if(person.getAge() < 0) {
    errors.add(new Error("Age must be greater than zero"));
  }
  if(person.getAge() > 120) {
    errors.add(new Error("Unlikely to be a real age"));
  }
  return errors;
}

Note that we’re only validating a few rules on one field, and it’s already quite verbose. If we validated every field on an object and the interdependencies between them, then we would have a lot of code.

Both the Spring Framework and Hibernate had come up with their own ways of making writing and integrating validation logic a little easier, but now validation has been standardised in JSR-303. The reference implementation is Hibernate Validator 4, and it’s a great starting point, but most uses of JSR-303 will be relatively agnostic of the implementation. Since this is a finalised specification, you can also make use of it today.

For our Person class above, let’s add the following constraints:

• Age must be 18 or more
• First and last name must be set i.e. they can’t be left null
• First and last name must have at least one character in them

To implement these rules, we need only add a few new annotations, using standard constraints:

@Data
public class Person {
    @NotNull @Size(min=1)
    private String firstName;
     @NotNull @Size(min=1)
    private String lastName;
    @Min(18)
    private int age;
}

You then create a Validator instance (how you do this will depend on your chosen implementation), and pass the class in for validation:

Set<ConstraintViolation<Person>> errors = validator.validate(person);

All the validation is then handled for you, reducing the amount of code and making your bean classes very clearly state the constraints under which they operate. You know a first name is not just any old nullable string by just looking at the class, and you know ages have limitations in your particular domain of interest. The code is more expressive and concise, and that’s a very good thing.

There’s a lot more to the JSR-303 specification, and it has all the features you might want. While I fully intend to go into the other features at another time, I’d strongly recommend browsing the spec to see some of the power and flexibility available to you.

In recent months, I’ve been looking at a lot of new Java libraries to see what I’d like to use and what I think still has a way to go. I’ll be posting about them all in due course but I wanted to mention Lombok first.

First, a class:

public class Person {
    private String firstName;
    private String lastName;
    private int age;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
      this.firstName = firstName;
    }
    public String getLastName() {
      return lastName;
    }
    public void setLastName(String lastName) {
      this.lastName = lastName;
    }
    public int getAge() {
      return age;
    }
    public void setAge(int age) {
      this.age = age;
    }
}

The problem here is that everything after public int age is predictable and verbose; you know that this is a Java bean class and that the fields are likely going to have getters and setters just like those provided. If we know exactly what to expect, shouldn’t the compiler take care of that for us rather than having us specify more code? Less code is often cleaner code.

For several years now, people have been asking for the idea of properties in Java. That is, being able to define fields and automatically having standard getters and setters defined, without having to clutter the class file with boilerplate. The most common (and reasonable) response for avoiding this is that it would be difficult to implement without affecting backwards compatibility.

While those proposals are pretty much dead at the moment, Lombok saves us from having to specify our standard getters and setters by marking our classes as beans and then jumping into the compilation process to make sure getters and setters are generated. The above code becomes:

@Data
public class Person {
    private String firstName;
    private String lastName;
    private int age;
}

That’s right: the 18 or so lines of getter/setter boilerplate are replaced by the tiny little @Data annotation, and the code is much cleaner. As a bonus, @Data also generates a toString(), an equals() and a hashCode(). You can use the other Lombok annotations to tweak the behaviour, but this is what most people are going to want.

Also of note is the @Cleanup annotation, which provides automatic resource management (ARM) for using input/output streams. While this will be less essential if ARM arrives in Java 7, it’s a handy little helper for the time being.

While Lombok can’t make bad code good, it can make verbose code a lot more succinct.

The March 2010 film fight includes no fewer than 6 brand new movies. That should make up for the slightly quieter-than-usual February. Onwards…

The Crazies looked like it had decent potential: a Romero remake about an infected township, lots of explosions and action, and a little humour alongside. It blows it. The action overwhelms the story from the very beginning, moving things on to the next set-piece before really establishing any of the characters. Without anyone we actually care about, the film suffers immensely. The plot itself is as expected, but it fails to hit any of the big scares a film like this needs. It never gets better than mediocre. (See my The Crazies Twitter review).

A lot was expected of Tim Burton’s foray into Lewis Carroll’s classic novel, but Alice In Wonderland disappoints. It’s not a filming of either Alice story but a bizarre sequel/retelling. It fails by paying too much fan-service to the world of Wonderland, attempting to squeeze every character into this semi-new narrative, rather than tell a more coherent tale. The characters themselves are the high-point, with some great (if too short) appearances by the Mad Hatter and the Cheshire Cat. Does the spectacle of 3d make up for some of the story failings? No, not this time. Unlike Avatar, the effects on display are average at best. Some of the scenes work better than others, but some are clearly flat layers. There are also some frankly odd choices in the direction: tightly pulled-focus does not work in 3D. All in all, a disappointment.  (See my Alice In Wonderland Twitter review).

Crazy Heart earned Jeff Bridges an Oscar for his performance as drunken country singer, Bad Blake; and rightly so. The performances in this film are high quality, without ever getting towards scenery-chewing territory. Both Bridges and Maggie Gyllenhaal put in excellent and subtle performances, saying as much with quiet looks as with their words. The solid getting-your-life-together is marred only by a weak ending, when the central character gets his life together a little too fast to feel satisfying. A little more adversity and struggle here would’ve completed this very worthwhile film a lot better. (See my Crazy Heart Twitter review).

Martin Scorsese manages to show some great form with his latest work, Shutter Island, before ruining it with a cheap ending. The story follows a US Marshall tracking down an escaped mental patient on a small island off the US mainland. The film is spiked with a Lynch-ian vibe throughout, that something sinister is happening without being clear about what is wrong. It’s beautifully shot, if a little over-the-top in places. Leonardo Dicaprio pulls in a solid performance, but he can’t cover up the poor ending. The last thirty minutes devolve into cheap, seen-it-before cliche. A great beginning, that deserved a much better conclusion. (See my Shutter Island Twitter review).

The Girl With The Dragon Tattoo fails to live up to the not-inconsiderable hype. While some of the acting is solid, the story is full of cheap genre cliches. If you can imagine taking a high-street bestselling thriller and filming it straight-up, then you can imagine this movie: our heroes get involved in a murder investigation, working through it by uncovering previously indecipherable (but ultimately nonsense) clues. It’s slow to get started, and fails to engage. If you can switch off and not worry too much about how coherent the investigation is, then you can probably get something out of the performances. Otherwise, I’d pass on this film. (See my Girl With The Dragon Tattoo Twitter review).

Finally, I Love You, Phillip Morris is a real wasted opportunity, from what seems like it could be a genuinely brilliant story about a conman who will go to great lengths to get what he wants. Instead we have a movie that sits between flimsy comedy and feel-good movie, but never really reaching either. The central relationship between Jim Carrey and Ewan McGregor never feels convincing or genuine, needing more time to develop than the few moments we are given. The film desperately needed a longer run-time in order to show more development. Here’s a hint: if you have more than one montage (I think there were at least 3-4), you need a longer movie. A real shame, as it would be good to see Carrey do another serious film. (See my I Love You, Phillip Morris review).

The winner this month is Crazy Heart, mostly for the fantastic performances by the central cast and despite the short final act.