Richard Warburton
Richard is an empirical technologist and solver of deep-dive technical problems. He has professionally worked on static analysis problems, verifying part of a compiler and developing advanced automated bug detection technology. More recently his career has been focussed on data analytics for high performance computing. He is a leader in the London Java Community, sits on their JCP Committee and organises the Adopt-a-JSR programs for Lambdas and Date and Time in Java 8. Richard is also a known conference speaker, having talked at JavaOne, DevoxxUK and JAX London. He obtained a PhD in Computer Science from The University of Warwick where his research focussed on compiler theory.
Using the command pattern with lambda expressions
Reduce boilerplate and make the intent of your code more obvious.
As Java developers we’re all familiar with the concept of Design Patterns. These are codified template solutions to problems that we may encounter when developing. We’re probably also familiar with being told by our functional programming brethren that design patterns are just “missing” language features. So the question now arises, with the introduction of lambda expressions in Java 8 and a more functional style of programming, how do design patterns change? In this article we’ll be looking at the command pattern.
A command object is an object that encapsulates all the information required to call another method later. The command pattern is a way of using this object in order to write generic code that sequences and executes methods based on runtime decisions.
There are four classes that take part in the command pattern:
- Receiver – Performs the actual work
- Command – Encapsulates all the information required to call the receiver
- Invoker – Controls the sequencing and execution of one or more commands
- Client – Creates concrete command instances
Let’s look at a concrete example of the command pattern and see how it improves with lambda expressions. Read more…
Unit Testing Java 8 Lambda Expressions and Streams
Two approaches to testing lambdafied code.
Over the past 18 months or so I’ve been talking to a lot of people about lambda expressions in Java 8. This isn’t that unusual when you’ve written a book on Java 8 and also run a training course on the topic! One of the questions I often get asked by people is how do lambda expressions alter how they test code? It’s an increasingly pertinent question in a world where more and more people have some kind of automated unit or regression test suite that runs over their project and when many people do Test Driven Development. Let’s explore some of the problems you may encounter when testing code that uses lambdas and streams and how to solve them.
Usually, when writing a unit test you call a method in your test code that gets called in your application. Given some inputs and possibly test doubles, you call these methods to test a certain behavior happening and then specify the changes you expect to result from this behavior.
Lambda expressions pose a slightly different challenge when unit testing code. Because they don’t have a name, it’s impossible to directly call them in your test code. You could choose to copy the body of the lambda expression into your test and then test that copy, but this approach has the unfortunate side effect of not actually testing the behavior of your implementation. If you change the implementation code, your test will still pass even though the implementation is performing a different task.
Java 8, now what?
What you'll need to know to start your Java 8 migration process today
There was recently a thread on the London Java Community mailing list about when people should think about adopting Java 8. Lambdas, an improved collections library, new date and time support, and a host of under-the-hood tweaks, add up to a lot of compelling reasons for people to upgrade. There’s still a lot of confusion over when and how to accomplish it, though, so here’s a helpful guide.
When will Java 8 be released?
The GA (General Availability) release of Oracle’s JRE and JDK, which is probably the JVM that you’re using, released March 18th. It may take other JVM vendors a while to release their implementations if you aren’t using an OpenJDK or the Oracle JDK.
So I should just upgrade on release date, right?
That would be a very brave move to make. A huge amount of resources go into testing Java 8 and ensuring that things will work out of the box on the day of release. However, the massive ecosystem of Java libraries means that not everything can be tested to destruction in time. It’s incredibly likely that there will be outstanding bugs upon release. You should expect update releases a month or two after GA, they’ll solve the major problems.
It’s also important to think about what libraries or frameworks your application depends on. If you’re just writing plain old Java then an existing codebase is likely to work fine. If, on the other hand, you depend on a library or framework that tries to do something clever then you may run into problems.