Monday, May 23, 2016

Java Bean Validation Gotcha

A well known trick for doing cross field validation using Java Bean Validation (JSR-303) is to simply put an @AssertTrue annotation on a method that actually does the validation, like so:
public class Document {

   @NotNull
   private Status status;   
   private Date signingDate;

   @AssertTrue(message = "A signed document should have a signing date")
   public boolean isASignedDocumentHasASigningDate() {
      return status != SIGNED || signingDate != null;
   }
}
The fact that the assertion method actually returns a boolean also makes unit testing easy. So far so good!

However, there is a little known gotcha related to this: the annotated validation method actually has to follow the naming conventions of a boolean bean property getter, i.e. getBla() or isBla(). In other words the following would not work:

   @AssertTrue(message = "A signed document should have a signing date")
   public boolean aSignedDocumentHasASigningDate() {
      return status != SIGNED || signingDate != null;
   }
That's quite unfortunate, and certainly doesn't follow the principle of least astonishment: we're explicitly annotating the method so there is no reason why the bean validator should not pick it up! Even worse, unless you're thoroughly testing all you bean validation annotations, it's easy to miss the fact that the validation is not actually happening. Something to keep in mind!

Friday, December 11, 2015

The Benefits of Building on Multiple Platforms

Organizational policy at a client of mine recently saw me switching my development setup from an Ubuntu Linux based machine to Windows 7 Enterprise. Before this switch everything was Linux based: development was done in Linux, continuous integration ran on Linux, and we were ultimately also deploying to Linux, albeit another distribution.

Making the switch to Windows unearthed a few subtle coding errors, mainly related to resource management. It's no secret Windows is a lot stricter when it comes to file manipulation. For instance, consider the following:

File f = new File("test.tmp");
try (FileOutputStream fout = new FileOutputStream(f)) {
 fout.write("foo".getBytes());
 fout.flush();
 Files.move(f.toPath(), new File("test.txt").toPath());
}
Using Java 8, this runs fine on Linux. However, on Windows you get an error:
java.nio.file.FileSystemException: test.tmp -> test.txt: The process cannot access the file because it is being used by another process.
Looking at the code again you can see that the file is being moved inside the try-with-resources block. In other words, we're attempting to move the file before we've closed the output stream!

In general I would advise different developers in your development team to use different platforms. That will highlight these kind of subtle errors early and will generally improve the quality of your system. It of course comes as little surprise that Juergen Hoeller (of Spring fame) told me on several occasions that he's still developing on Windows for exactly this reason! :-)

Friday, November 20, 2015

Bizar replaceAll tricks

Image you want to replace all asterisk (*) characters in an input string with \*. In other words you want to escape them. One way of doing this in Java is using the String.replaceAll() method:
"foo*bar".replaceAll("\\*", "\\\\*");
To understand what's going on here, let's remind ourselves of what replaceAll() actually does:
/**
 * Replaces each substring of this string that matches the given regular expression
 * with the given replacement.
 * ...
 */
public String replaceAll(String regex, String replacement) {
So that already explains why the first argument to replaceAll() is "\\*": for it to be a valid regular expression we need to escape the asterisk (which of course means zero or more times in a regular expression) using a backslash, and we all know that a backslash character in a Java String needs to be escaped.

But what about the second argument? Shouldn't that just be "\\*" also: a backslash followed by an asterisk? It turns out replaceAll() doesn't treat the replacement as a simple string literal. The Javadoc states the following:

* Note that backslashes (\) and dollar signs ($) in the
* replacement string may cause the results to be different than if it were
* being treated as a literal replacement string
So just having "\\*" as the replacement string would mean we have a backslash in there which we again need to escape! Hence the "\\\\*". It's interesting to note that in a funny twist of fate this actually makes the code less bizar. If the replacement string would have been a simple literal the code would have been "foo*bar".replaceAll("\\*", "\\*");. Imagine coming across that gem when trying to maintain some old piece of code... :-)

Friday, September 4, 2015

Java Exception Fun

Look at this:
public class Test {

  public void f() {
  }

  public void g() {
    try {
      f();
    } catch (Exception e) {
      throw e;
    }
  }
}
Does this compile? Notice that method g() is throwing an exception object declared to be of type Exception but does not actually mention this in its throws clause. In Java 6 this indeed does not compile:
Test.java:10: unreported exception java.lang.Exception; must be caught or declared to be thrown
      throw e;
      ^
1 error
But it came as somewhat of a surprise to me that this compiles just fine in both Java 7 and Java 8! Thinking back this was of course part of the exception improvements made in Java 7. Goes to show that you can still come across little fun nuggets like this after all these years :-).

Saturday, April 25, 2015

Ubuntu 15.04 on Lenovo X1 Carbon 3rd Generation

Following up on my previous post, where I talked about installing Ubuntu 14.10 on my Lenovo X1 Carbon 3rd generation, I've now gone ahead and reinstalled the machine from scratch using the recently released Ubuntu 15.04.

I'm happy to tell you installation is now a complete breeze:

  • No more USB startup disk problems.
  • The brightness function keys work out-of-the-box.
  • The trackpoint buttons work out-of-the-box.
  • No more graphics glitches (mainly text rendering) in Unity.

It even seems that the default font sizes are better suited for a WQHD display, although I can't actually confirm anything has changed here compared to 14.10. In the end, the only things I did was setting the "Scale for menu and title bars" to 1,25 in the display settings and changing the "Page zoom" to 125% in Google Chrome.

In summary: Ubuntu 15.10 just works on the 3rd generation Lenovo X1 Carbon. No tweaking required really. I highly recommend this combination for those looking for a new Linux based laptop!

Saturday, February 28, 2015

Ubuntu 14.10 on Lenovo X1 Carbon 3rd Generation

I just switched my main laptop from an Asus Zenbook Prime UX31A to a Lenovo X1 Carbon 3rd generation (the 2015 model). Since I always run Ubuntu, I got started wiping the hard disk and installing Ubuntu 14.10 as the main operating system.

Although installing Linux on brand new hardware like the Lenovo X1 Carbon can be a hairy adventure, it turned out to be a pretty smooth ride. I thought I'd share what I had to do to get to an (almost) fully functional system.

  • The first snag I hit was trying to boot the Ubuntu 14.10 startup USB disk. I was greeted with a somewhat unnerving "gfxboot.c32: not a COM32R image" message and a "boot:" prompt. A quick search brought me to Ask Ubuntu: simply type "live" at the prompt and hit enter. You'll boot into the Live CD where you can start the installation.
    I haven't seen other people running Ubuntu 14.10 on their X1 Carbon complain about this, so I'm not sure why I ran into this problem.
  • The next issue I faced was the brightness function keys not working. Some more web searching revealed an Arch Linux thread compiling a number of issues people had encountered trying to run Linux on the 3rd generation X1 Carbon. Fixing the function key problem was again easy: just force the thinkpad_acpi module to load:
    echo thinkpad_acpi > /etc/modules-load.d/thinkpad_acpi.conf
    echo "options thinkpad_acpi force_load=1" > /etc/modprobe.d/thinkpad_acpi.conf 
    
  • My laptop sports a fancy 2560 x 1440 WQHD display ("1440p"). That's great and all but with the default Ubuntu fonts text gets really tiny. Working around that involved installing the unity-tweak-tool and setting the Text scaling factor to "1,20" (explained here). I also set the default "Page zoom" to 125% in Google Chrome.
And that's about it as far as I'm concerned. There are a few more things not working properly, like the track-point buttons or fingerprint reader, but these are things I never use so I didn't bother fixing those.

So far the system has been really sweet! The hardware seems up-to-par with my previous ThinkPad which I owned many years ago (a real IBM ThinkPad X40): really rugged feel and a superb keyboard. Combine this with good Linux support and you've got a winning combination!

Wednesday, October 1, 2014

SWF Humor

Funny little blast from the (Spring Web Flow) past. Back in 2006 while working on Spring Web Flow 1.0 we needed an exception class signaling a failure to parse a flow execution key. Keith Donald and myself jokingly considered calling it the FuckedUpFlowExecutionKeyException but ultimately settled for BadlyFormattedFlowExecutionKeyException. Indeed, it would be quite painful if a user was presented with a FuckedUpFlowExecutionKeyException stack trace after having accidentally corrupted the key in the URL of his browser. :-)

The joke continued for a little bit with the following piece of JavaDoc that you can find in the Spring Web Flow 1.0 source code:

package org.springframework.webflow.execution.repository;

/**
 * Thrown when an encoded flow execution key is badly formatted and could not be
 * parsed. We debated calling this the FuckedUpFlowExecutionKeyException.
 * 
 * @author Keith Donald
 * @author Erwin Vervaet
 */
public class BadlyFormattedFlowExecutionKeyException extends FlowExecutionRepositoryException {
This was not enough however, a particularly sensitive person actually complained about Spring Web Flow using offensive language! In the end this bit of nostalgia was kicked out in the 1.0.1 release. Still makes for a fun anecdote however! ;-)