This year I’ve had the honor of presenting a session at Devoxx Belgium together with my colleague Jeroen Burggraaf.
On Thursday, 10th November we gave a short presentation about JSR 354 – the Money and Currency API.
The presentation was well received by the public. A registration of the talk can be found on Slideshare and YouTube.
There are times when you’re unit testing code that is making HTTP calls to a remote server. You could be using a library such as Apache’sHttpClient or Spring’s RestTemplate to do so.
Of course, you don’t want to rely on a remote service for your unit tests. Besides the overhead involved (remember that unit test are supposed to be fast) you simply cannot rely on remote services being available during execution of your tests. You probably are also not able to completely control the response for all of your test scenarios.
Continue reading “Unit testing HTTP calls with LocalTestServer”
The ANSI SQL 1999 standard introduced a BOOLEAN data type (although unfortunately only as an optional feature). But to date it still isn’t implemented by most major database systems. As a consequence boolean columns are implemented in various ways. E.g., CHAR columns containing ‘Y’ or ‘N’, or using BIT columns. Subsequently, there is no way for JPA to provide a standardized way of mapping an entity’s boolean fields onto database columns.
Hibernate offers a custom YesNoType for boolean implementations using CHAR(1) columns containing ‘Y’ or ’N’ characters. But for other practices you basically have to provide your own solution. Fortunately, Hibernate offers the possibility of creating your own custom UserType’s. In this blog entry I will give an example of one such custom Boolean UserType. Continue reading “Custom Boolean User Type with Hibernate JPA”
Whenever you’re using JAX-WS within Spring you’ll probably want to log the incoming and outgoing SOAP messages – if only for debugging during development. So the first thing to do is increase the log levels, right? Unfortunately this will have no effect. What you will have to do is to make use of the javax.xml.ws.handler.HandlerResolver interface. So how do we do this?
Continue reading “Logging JAX-WS SOAP messages in Spring”
Lately, I’ve been writing alot of RESTful services using the Spring framework and its @RestController. The only thing I really missed was an easy way to document the RESTful API. I’ve looked into various options, and like most people, I found that Swagger seemed to be the only viable option. However, after having tried it, I found some serious issues. Besides being a very bulky dependency to have to include, having a visually attractive but very cluttered front-end in the form of SwaggerUI, what I disliked the most was the pollution of my code with alot of additional annotations.
Continue reading “Documenting Spring RESTful APIs”
For the last year or so, I’ve been struggling with what Martin Fowler calls the Anemic Domain Model. The development teams at one of my clients, employ Java in a fashion where OO concepts are sometimes hard to find. Java objects are used as mere dataholders and business logic is scattered all around the place but mostly concentrated inside stored procedures. It also doesn’t help that alot of frameworks and libraries used nowadays, such as JPA/hibernate, Jackson, etc., rely heavily on the JavaBeans specifications thereby inadvertently encouraging the Anemic Domain Model anti-pattern.
Continue reading “Implementing Domain-Driven Design book review”
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.
|
1 2 3 4 5 6 7 8 9 10 11 |
@Test public void localDateToSqlDate() throws Exception { assertNull(Dates.fromLocalDate(null)); final Date sqlDate = Dates.fromLocalDate(nowLDT.toLocalDate()); assertNotNull(sqlDate); final SimpleDateFormat sdf = new SimpleDateFormat("YYYYMMdd"); final String sqlDateFormatted = sdf.format(sqlDate); assertEquals(nowLDT.toString(DateTimeFormatter.BASIC_ISO_DATE), sqlDateFormatted); } |
org.junit.ComparisonFailure: expected:<201[4]1231> but was:<201[5]1231>
at org.junit.Assert.assertEquals(Assert.java:115)
...
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’.
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”
In my previous post I showed some tips on unit testing JavaBeans. In this blog entry I will give two more tips on unit testing some fairly common Java code, namely utility classes and Log4J logging statements.
Continue reading “Some more unit test tips”
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”