Gotcha using SimpleDateFormat with the Week year pattern ‘Y’

A couple of weeks ago, on New Year’s Eve, one of our nightly builds suddenly broke because of a spontaneously failing unit test. The next day everything worked again without anyone having been able to touch the code (because the office was closed ;)).

The culprit turned out to be one of the unit tests that was testing some trivial date conversions. In the assertions we’d happened to use a SimpleDateFormat.

org.junit.ComparisonFailure: expected:<201[4]1231> but was:<201[5]1231>
at org.junit.Assert.assertEquals(

There are alot of issues with SimpleDateFormat, such as its performance being suboptimal and most of all it not being threadsafe, but these we were aware of. What we didn’t now at the time, was the difference between using the pattern letters ‘y‘ and ‘Y‘.

Whether you format a date using the pattern ‘yyyyMMdd‘ or with ‘YYYYMMdd‘, one would expect the outcome to reflect the year of the date you’re formatting. But as it turns out, December 31st can occur in the first week of the new year, resulting in an incorrect year.

My takeaway, don’t ever use the Week year pattern ‘Y’.

Catching unforeseen JavaScript errors

JavaScript errors can originate from anywhere inside your code or the libraries you’re using. Because they are runtime exceptions you’re not alerted to them whilst you’re writing your code. So you might not be aware of all the possible errors that might occur. Failing to foresee a specific error occurring might not turn out to be dramatic. Most of the time, the error is simply logged to the console and the application continues to functions properly. Sometimes they may lead to your browser freezing. But in the most problematic of cases you’re program may continue to appear to function correctly but the outcome is faulty.

How to deal with an error largely depends on the specific type of error and the context in which it has manifested itself. So there’s no silver bullet to be found on how to deal with unforeseen errors. But at least making sure that any uncaught errors don’t go unnoticed seems essential. Continue reading “Catching unforeseen JavaScript errors”

Server side logging from browser side JavaScript code

Application logging is something we all do in our applications that get deployed on an application server, right? Using frameworks like Log4J or Logback seems like a no-brainer to most Java developers. But what about the code we’ve written that is running in those pesky browsers? I guess that, apart from the occasional console.log() statement used during debugging, we don’t give much thought to JavaScript logging. I find this situation very regrettable since nowadays the trend appears to be to move our application logic to the browser. And with it, interesting events happening in the browser might go unnoticed, or any bugs that will happen, no matter how well we’ve developed and tested our client side code, might prove needlessly hard to reproduce and therefore fix. In this blog post I’ll demonstrate a very basic setup to log messages from the browser on the server using some very basic JavaScript with jQuery, and a simple Spring controller with Slf4J. Continue reading “Server side logging from browser side JavaScript code”

My JavaScript book recommendations

I’ve been using JavaScript since the late 1990s – the era of the first browser wars between Netscape Navigator and Internet Explorer. At the time it was just to liven up the static html pages with some mouse over effects. Since the early 2000s it was all about simple form validations. But from 2008 onwards – thanks to the arrival of jQuery and the meanwhile ubiquitous presence of Ajax – the use of JavaScript has exploded. I’ve been using jQuery extensively since 2009, mainly to enhance to user experience of the web sites and applications that I’ve developed.

Probably due to the vast number of jQuery plugins that are available, I’ve never felt the need to really deepen my knowledge of the JavaScript language. That is, up until november 2012, the time I first came in to contact with the amazing framework that is called AngularJS. As a veteran Java developer AngularJS I was immediately very charmed by the framework because on the one hand there were all these familiar concepts like dependency injection, the MVC pattern, modularity, data binding, etc., whilst on the other hand my productivity soared using AngularJS instead of server side Java frameworks like Wicket or JSF. Continue reading “My JavaScript book recommendations”

Tips for (unit testing) JavaBeans

If you’re writing Java code chances are you’re writing at least a few classes that adhere to the JavaBean conventions, i.e., classes that have private properties with public getter and setter methods, contain a no-arguments constructor, are serializable, and comply with the Equals and HashCode contract. And on top of that you’ll probably also throw in a useful toString() implementation.

If, e.g., we take a very simple class called MyBean that contains two fields named id and name, we’ll end up with the following code: Continue reading “Tips for (unit testing) JavaBeans”

Custom JSR 303 Bean Validation constraints for the JSR 310 New Date/Time API

With JSR 310 Java 8 finally brought us a decent date and time API. For those of you that are still using Java 7 – like I am at my current project – there is an excellent backport available, see for more details. However, I’m not going to go into any details about using the new API since there are already a ton of blog posts out there about the topic. What I am going to show you in this post is how you can use the Date/Time API in conjunction with the JSR 303 Bean Validation API by writing your own custom annotations.
Continue reading “Custom JSR 303 Bean Validation constraints for the JSR 310 New Date/Time API”

Eclipse code templates

Eclipse comes bundled with a nice feature in the form of editor templates. These templates allow you to quickly generate commonly used code. To use a template, simply type in the name of the template and hit Ctrl + space.

There are already a ton of templates available in vanilla Eclipse like test, which will generate a JUnit 4 test method stub, or sysout that will expand into a System.out.println();. But it is also very easy to create your own. Here I will demonstrate how by creating a code template for a SLF4J logger field.
Continue reading “Eclipse code templates”

Automatically take a screenshot on failure of a Cucumber scenario

If you are using Cucumber to automate testing your web application, it can be useful to include a screenshot in Cucumber’s report whenever a scenario fails.

Cucumber itself doesn’t provide functionality for taking screenshots, but it does make it possible to embed them in the report. If you are using Cucumber together with a Selenium WebDriver, which can capture screens, it’s easy as pie. All you have to do is paste the following lines of Java code into your Cucumber steps definition:

Deploying your war file from Jenkins to Tomcat

At my company we’re currently moving away from developing large desktop applications to developing smaller web applications. Changing our build-test-deploy processes is also part of that transition. After using Jenkins for a long time merely for continuous integration, I wanted to see what it takes to set up a continuous deployment pipeline. In this short post I’ll describe the steps to extend a Jenkins job to automatically deploy a built war file to a Tomcat instance. In future posts I intend to also elaborate on adding automated tests using Cucumber and or Selenium to the Jenkins build.

Continue reading “Deploying your war file from Jenkins to Tomcat”