Default Methods: Java 8's Unsung Heros

A few weeks ago I wrote a blog saying that developers learn new languages because they're cool. I still stand by this assertion because the thing about Java 8 is it's really cool. Whilst the undoubted star of the show is the addition of Lambdas and the promotion of functions to first class variables, my current favourite is default methods. This is because they're such a neat way of adding new functionality to existing interfaces without breaking old code.

The implementation is simple: take an interface, add a concrete method and attach the keyword default as a modifier. The result is that suddenly all existing implementations of your interface can use this code. In this first, simple example, I’ve added default method that returns the version number of an interface¹.

public interface Version {

  /**
   * Normal method - any old interface method:
   *
   * @return Return the implementing class's version
   */
  public String version();

  /**
   * Default method example.
   *
   * @return Return the version of this interface
   */
  default String interfaceVersion() {
    return "1.0";
  }

}

You can then call this method on any implementing class.

The Simple Story Paradox

I’ve recently been following the #isTDDDead debate between Kent Beck (@kentbeck), David Heinemeier Hansson (@dhh), and Martin Fowler (@martinfowler) with some interest. I think that it’s particularly beneficial that ideas, which are often taken for granted, can be challenged in a constructive manner. That way you can figure out if they stand up to scrutiny or fall down flat on their faces.

The discussion began with @dhh making the following points on TDD and test technique, which I hope I’ve got right. Firstly, the strict definition of TDD includes the following:

1. TTD is used to drive unit tests
2. You can’t have collaborators
3. You can’t touch the database
4. You can’t touch the File system
5. Fast Unit Tests, complete in the blink of an eye.

He went on to say that you therefore drive your system’s architecture from the use of mocks and in that way the architecture suffers damage from the drive to isolate and mock everything, whilst the mandatory enforcement of the 'red, green, refactor’ cycle is too prescriptive. He also stated that a lot of people mistake that you can’t have confidence in your code and you can’t deliver incremental functionality with tests unless you go through this mandated, well paved road of TDD.

Is it Imperative that you learn Functional Programming with Java 8?

I've recently been taking look at Java 8 and have got hold of "Java 8 In Action" published by Manning. The first thing that struck me is how one of Java 8's unique sales propositions is functional programming; functions are now first class variables, you can pass them around your code as you would an int or a String. This is a big change.

It seems that functional languages have become more popular in recent years and there are no end of them to choose from. Modern function programming language examples include Clojure, JavaScript, Scala, and even Erlang, invented in the late 1980s, has made a come back.

So, why is there this change in direction? You could probably come up with several reasons, but we’ll begin with the premise that industry best practise changes over time and even the most popular languages will one day fall out of favour. I imagine that if you're young enough there will be a day when you'll look back and say "remember when we used to use Java”? Before looking at why there is this change, let’s reflect on how we got here by stepping back to the 1980s...

Tracking Exceptions - Part 6 - Building an Executable Jar

If you’ve read the previous five blogs in this series, you’ll know that I’ve been building a Spring application that runs periodically to check a whole bunch of error logs for exceptions and then email you the results.

Having written the code and the tests, and being fairly certain it’ll work the next and final step is to package the whole thing up and deploy it to a production machine. The actual deployment and packaging methods will depend upon your own organisation's processes and procedures. In this example, however, I’m going to choose the simplest way possible to create and deploy an executable JAR file. The first step was completed several weeks ago, and that’s defining our output as a JAR file in the Maven POM file, which, as you’ll probably already know, is done using the packaging element:

Tracking Exceptions - Part 5 - Scheduling With Spring

It seems that I'm finally getting close to the end of this series of blogs on Error Tracking using Spring and for those who haven’t read any blogs in the series I’m writing a simple, but almost industrial strength, Spring application that scans for exceptions in log files and then generates a report. From the first blog in the series, these were my initial requirements:

1. Search a given directory and its sub-directories (possibly) looking for files of a particular type.
2. If a file is found then check its date: does it need to be searched for errors?
3. If the file is young enough to be checked then validate it, looking for exceptions.
4. If it contains exceptions, are they the ones we’re looking for or have they been excluded?
5. If it contains the kind of exceptions we’re after, then add the details to a report.
6. When all the files have been checked, format the report ready for publishing.
7. Publish the report using email or some other technique.
8. The whole thing will run at a given time every day

This blog takes a look at meeting requirement number 8: "The whole thing will run at a given time every day" and this means implementing some kind of scheduling.

Tracking Exceptions - Part 4 - Spring's Mail Sender

If you've read any of the previous blogs in this series, you may remember that I'm developing a small but almost industrial strength application that searches log files for exceptions. You may also remember that I now have a class that can contain a whole bunch of results that will need sending to any one whose interested. This will be done by implementing my simple Publisher interface shown below.

public interface Publisher {

  public <T> boolean publish(T report);
}

If you remember, the requirement was:

7 . Publish the report using email or some other technique.

In this blog I’m dealing with the concrete part of the requirement: sending a report by email.

Error Tracking Reports - Part 3 - Strategy and Package Private

This is the third blog in a series that's loosely looking at tracking application errors. In this series I’m writing a lightweight, but industrial strength, application that periodically scans application log files, looking for errors and, if any are found, generates and publishes a report.

If you’ve read the first blog in the series you may remember that I initially said that I needed a Report class and that “if you look at the code, you won’t find a class named Report, it was renamed Results and refactored to create a Formatter interface, the TextFormatter and HtmlFormatter classes together with the Publisher interface and EmailPublisher class”. This blog covers the design process, highlighting the reasoning behind the refactoring and how I arrived at the final implementation.

If you read on, you may think that the design logic given below is somewhat contrived. That’s because it is. The actual process of getting from the Report class to the Results class, the Formatter and Publisher interfaces together with their implementations probably only took a few seconds to dream up; however, writing it all down took some time. The design story goes like this...

Tracking Exceptions With Spring - Part 2 - Delegate Pattern

In my last blog, I started to talk about the need to figure out whether or not your application is misbehaving in it's production environment. I said that one method of monitoring your application is by checking its log files for exceptions and taking appropriate action if one is found. Obviously, log files can take up hundreds of megabytes of disk space and it's impractical and really boring to monitor them by hand.

I also said that there were several ways of automatically monitoring log files and proposed a Spring based utility that combs log files daily and sends you an email if / when it finds any exceptions.

I only got as far as describing the first class: the FileLocator, which will search a directory and it's sub-directories for log files. When it finds one, it passes it to the FileValidator.

Tracking Application Exceptions With Spring

A few weeks ago a colleague asked me to spend a week doing a support role as he needed cover whilst he took a well earned holiday and he couldn't find anyone else. As I'd just completed a particularly complex coding project and was feeling a little burnt out, I said 'yes'; after all the change would do me good.

Part of the job consisted of monitoring a collection of fairly critical backed processes, to see how well they were performing and whether or not they were going wrong.

We developers spend a lot of time and energy adding logging to our application in order to prove that it's working okay and to figure out what went wrong when an exception occurs. These log files are often used to tell us how well, or badly, our application is performing on a daily basis.

I'm ignoring other techniques such as adding probes to your application by whatever method you choose, such as HTTP or JMX. These provide immediate information on your application rather than the second level monitoring under discussion here.

There are at least three ways of monitoring log files:

Optimising Your ApplicationContext

There’s a problem with Spring, it’s been there for some time and I’ve come across it in a number of projects. It’s nothing to do with Spring, or the Guys at Spring, it’s down to Spring’s users like you and me. Let me explain… In the old days of Spring 2 you had to configure your Application Context by hand, manually creating an XML configuration file that contained all your bean definitions. The down side of this technique was that it was time-consuming to create these XML files and then, you had the headache of maintaining this increasingly complex file. I seem to remember that at the time, it was known as “Spring Config Hell”. On the upside, at least you had a central record of everything that was loaded into the context. Bowing to demand and the popular notion that annotations were the way to go, Spring 3 introduced a whole raft of stereotyping classes such as @Service, @Component, @Controller and @Repository together with an addition to the XML configuration file of the <context:component-scan/> element. This made, from a programming point of view, things a lot simpler and is a hugely popular way of constructing Spring contexts.

There is, however, a downside to using Spring annotations with wild abandon

Publish and Subscribe with Hazelcast

A few weeks ago I wrote a blog on getting started with Hazelcast describing how ludicrously simple it is to create distributed maps, lists and queues. At the time I mentioned that Hazelcast does quite a few other things besides. This blog takes a quick look at another of Hazelcast’s features: its broadcast messaging system based on the Publish/Subscribe pattern. This takes the usual format where by the message sender app publishes messages on a certain topic. The messages aren't directed at any particular client, but can be read by any client that registers an interest in the topic.

Investigating Memory Leaks Part 2 - Analysing the Problem

The first blog in this mini-series looked at creating a very leaky sample application, so that we can investigate techniques for solving heap based problems on server applications. It demonstrates the big problem with the Producer-Consumer pattern, namely that the consumer code has to be able to remove items from the queue at least as fast, if not faster than, the producer. The blog ended with me starting the sample code and sitting back whilst it leaked enough memory away to investigate. It’s now time to do that investigation.

If you read part 1 of this blog, you’ll know that the leaky code is part of an application¹ that records stock/share orders in a dummy database using the Producer Consumer pattern. The sample code has been written to contain a very obvious flaw, namely that the OrderRecord can’t keep up with the OrderFeed. This means that the Order queue gets bigger and bigger until finally, the application runs out of heap space and falls over. The thing is, looking at my simple code, the problem should be obvious, but what if you've never seen the code before and it's huge, complex industrial strength code, plus there's no simple monitoring thread to keep an eye on the queue size or other internals? What do you do then?

Investigating Memory Leaks Part 1 - Writing Leaky Code

I found this little problem the other day: there’s this server that runs for a while and then falls over. It’s then restarted by its startup script and the whole process repeats itself. This doesn't sound that bad as it isn't business critical although there is a significant loss of data, so I decided to take a closer look and to find out exactly what's going wrong. The first thing to note is that the server passes all it's unit tests and a whole bunch of integration tests. It runs well in all test environments using test data, so what's going wrong in production? It's easy to guess that in production it's probably under a heavier load than test, or than had been allowed for in its design, and therefore it's running out of resources, but what resources and where? That's the tricky question.

Getting Started with Hazelcast

In July I wrote a blog introducing erlang to Java developers, highlighting some of the similarities and differences between the two languages. The erlang virtual machine has a number of impressive, built-in features, one of which is that they are location independent and can talk to each other. This means that that data can be synchronised between VMs by writing very few lines of code. This is really good news if you have a networked cluster of servers all doing the same thing.

You could argue that there's something lacking in the JVM if it can't even perform the most basic interprocess communication; however, Java takes the opposite view, it has a basic VM and then layers different services on top as and when required. Whether this is right is a matter of opinion and I'll leave it as a subject for a future blog, because it seems that the Hazelcast Guys have solved the problem of JVMs talking to each other; which is the point of this blog.

So, what is Hazelcast?

Tomcat's Graceful Shutdown with Daemons and Shutdown Hooks

My last couple of blogs have talked about long polling and Spring's DeferredResult technique and to demonstrate these concepts I've shoehorned the code from my Producer Consumer project into a web application. Although the code demonstrates the points made by the blogs it does contain a large number of holes in its logic. Apart from the fact that in a real application you wouldn't use a simple LinkedBlockingQueue, but would choose JMS or some other industrial strength messaging service, and the fact that only one user can get hold of the match updates, there's also the problem it spawns badly behaved threads that don't close down when the JVM terminates.

You may wonder why this should be a problem…

Long Polling with Spring 3.2’s DeferredResult

In our last episode, the CEO of Agile Cowboys Inc had just hired a Java/Spring consultant by giving him the Porsche that he originally bought for his girlfriend. Being upset by the loss of her prize Porsche, the CEO’s girlfriend has told his wife of their affair. His wife, after cutting up the CEO’s suites has filed for divorce. Meanwhile the CEO has implemented a new ‘casual’ dress code at the office and the Java/Spring consultant has just arrived back from a spin in his new Porsche and is sitting down at his desk about to fix the TV company’s software... If this doesn’t mean anything to you then take a look at Long Polling Tomcat With Spring.

The Java/Spring Consultant has to fix the TV Company’s server resource problem before the next big game, and he knows he can do this by implementing Spring’s Deferred Result technique using the Servlet 3 specification as implemented on Tomcat 7¹

The first thing that the Java/Spring consultant does is to check

Long Polling Tomcat with Spring

"Ooh err Missus" as comedian Frankie Howerd would have said, but enough of British innuendo and double entendre because Long Polling Tomcat isn't some kind of sexual deviance with next door's moggy, it's a technique (or more of a hack) that's been developed as a result of Steve Jobs's refusal to support Adobe Flash Player on the iPhone and iPad. The thing is, using Flash Player as part of a web application was a really good way of supporting the Publish and Subscribe paradigm as it was able to cater for those scenarios that require live updates, such as live stock prices, news updates and changes to betting odds, whereas straight forward HTTP, with its request/reply paradigm, is a good way of supporting static pages. A good number of companies put a lot of effort in to developing applications that used Flash in order to provide their users with realtime data. When Apple announced that iOS would not support Adobe Flash they were left high and dry without an iPhone solution and to get back into the mobile market I imagine that a good number of them went for long polling.

So, what is a long poll? Well, it isn't a tall guy from Warsaw, the idea is to mimic the Publish and Subscribe pattern. The scenario goes like this:

Erlang for Java Developers

You probably haven't noticed, but it's a couple of weeks since I last posted a blog. There is reason for this is that I've ruptured my Soleus and my leg is in a plaster cast. Being immobile I thought that it would be a good idea to investigate something totally different - it was either that or watch day time TV and, even though reruns of Kojak and Magnum PI were tempting, investigating Erlang came out tops.

The thing to remember here is that this is not an Erlang tutorial, the idea here is to examine a few of the similarities between Erlang and Java in order to try an provide a starting point for learning Erlang. If I've made any howling mistakes, then hopefully someone with more Erlang experience will let me know.

When getting started, the first thing they tell you about Erlang is that it's a functional language; however, before you have apoplexy at the thought, it's such a well structured functional language that you'd think you were dealing with objects.

Getting Started With Spring’s MVC Test Framework - Part 2

The first blog in this mini-series introduced the Spring MVC Test Framework and demonstrated its use in unit testing Spring MVC Controller classes as controllers rather then as POJOs. It’s now time to talk about using the framework for integration testing.

By ‘integration testing’ I mean loading the Spring context into the test environment so that the controller can work with its collaborators in ‘end to end’ tests.

Getting Started With Spring’s MVC Test Framework - Part 1

Newly promoted to the main Spring framework is the Spring MVC Test Framework, which the Guys at Spring claim is a “first class JUnit support for testing client and server side Spring MVC code through a fluent API”¹. In this and my next blog, I’m going to take a look at Spring’s MVC Test Framework and apply it to some of my existing sample code to figure out whether or not it does what it says on the tin.

The API has been designed with two ways of setting up server side tests. These are firstly, with a Spring context file and secondly, programmatically without a context file. The Guys at Spring refer to the programatic method as ‘standalone’ mode.

Setting tests up programmatically