Wednesday, June 25, 2014

Type safe dependency injection using Java 8.0

So I sometimes really miss old school Dependency Injection. Back when Spring was still "lightweight" we happily configured all our beans in an application.xml file with the "learn-in-a-day" Spring bean xml configuration. The downsides to this were of course a loss of type safety. I can think of quite a few test cases whose sole purpose was to bootstrap the Spring configuration file and just see if the ApplicationContext starts up without going belly-up due to mis-wiring and correct resolution of included bean xml configuration files.

I may be a minority but I never liked the Spring Schema configuration. To me it feels a bit like configuration for configuration.

Annotations came along and improved things, with the caveat in that you have to import libraries for all those annotations. I like annotations but  there is a good case for having all your DI information in a central place so you can actually see how your app hangs together. Finally you sometimes need to create managed objects you can't annotate.

Java Spring configuration makes things better with compile time safety, but I had to rethink the way I did a lot of my wiring, as I had to be careful how I did my wiring as I  lost some of the lazy eval that you get in a Spring context as your Java code evaluates immediately when the ApplicationContext starts up.

So, Java based DI is nice but how can we use Java 8.0 to improve it?

Apply that Lambda Hammer

Right so this is the part of the post that starts applying the new hammer in Java 8.0: Lambdas.

Firstly Lambdas give a type safe way of deferring execution till it's needed.

So, lets first create a wrapper object called "ObjectDefinition" who's job it is to define how an object should be created and wired with various values. It works by instantiating the class we want to create and object from (In this case we have a class called "MyObject"). We also give it a list of java.util.function.BiConsumer interfaces which are mapped to a specific value. This list will be used to perform the actual task of setting values on the object.

ObjectDefintion then instantiates the object using normal reflection and then runs though this list of BiConsumer interfaces, passing the the instance of the concrete object and the mapped value.

Assuming we give our ObjectDefinition a fluent DSL we can do the following to define the object by adding the set() method which takes a BiConsumer and the value to set and populates the BiConsumer list as follows:

  MyObject result = new ObjectDefinition()
    .set((myObject, value)-> myObject.setA(value), "hello world")
    .set((myObject, value)-> myObject.setB(value), "hallo welt")

The create() method simply instantiates a MyObject instance and then runs through the list of BiConsumers and invokes them passing the mapped value.

Method pointers??!! in Java??!! (Well Kinda)

Now, Another interesting feature in Java 8.0 is Method references, which is a feature where the compiler wraps a method in a functional interface provided that that method can map to the signature of that functional interface.

Method references allow you to map to an arbitrary instance of an object provided that the first parameter of that method is that instance value, and the subsequent parameters match it's parameter list.

This allows us to map a BiConsumer to a setter where the first parameter is the target instance and the second parameter is the value passed to the setter:

   MyObject result = new ObjectDefinition()
     .set(MyObject::setA, "hello world")

     .set(MyObject::setB, "hallo welt")

Method references provide an interesting feature in that it provides a way of passing a reference to a method in a completely type safe manner. All the examples require the correct types and values to be set and the setter method needs to correspond to that type.

It's Container Time

So now we have  a nice little DSL for building objects, but what about sticking it into a container and allowing our ObjectDefinition to inject references to other values.

Well, assuming we have this container, which conveniently provides a build() method which provides a hook to add new ObjectDefinitions.

We now have a container we can use to inject different objects in that container:

     Container container = create((builder) -> {
              .set(MyObject::setA, "hello world");
     String myString = container.get(MyObject.class);        

Our Container object has the define() method which creates an instance of an ObjectDefinition, which is then used to define how the object is created.

But what about dependencies?

Dependency Injection is no fun without being able to inject dependencies, but since we have a container we can now reference other objects in the container.

To this end we add the inject() method to our ObjectDefinition type, this can then be used to reference another object in the container by it's type:

   Container container = create((builder) -> {
             .args("hello world");

   MyObject myString = container.get(MyObject.class);

In this example we map an additional object of type String (the args() method here is method which can map values to the the constructor of an object). We then inject this String calling the inject() method.

Cycle of Life.

We can use the same approach of Lambdas and Method References to manage the life cycle of an object in the container.

Assuming we want to run an initialisation method after all the values have been set, we simply add a new Functional interface which is invoked after all the values are set.

Here we use the a java.util.function.Consumer interface where the parameter is the instance we want to call the initialisation code on.

    Container container = create((builder) -> {
             .set(MyObject::setA,"hello world")
    MyObject myString = container.get(MyObject.class);

In this example we added a start() method to our MyObject class. This is then passed to the ObjectDefinition as a Consumer via the initWith() method.

Yet Another Dependency Injection Container

So all these techniques (and more) are included in the YADI Container, which stands for Yet Another Dependancy Injection Container.

The code is available on Github at And is licensed under an Apache License.

Tuesday, May 27, 2014

When writing too much code can kill you

So now that I lured you in with that provocative title I suppose I need to clarify. Well it's true; too much coding can kill you, the real question is "what is the reason?" and the answer to that is; Chronic Stress.

So why write about this; well it's personal. You see: it happened to me, and I'm hoping to tell other people that it could happen to them to.

"Holy Smokes Batman, do you mean it takes years"
So what is Chronic stress. To quote Wikipedia: Chronic stress  is the response to emotional pressure suffered for a prolonged period over which an individual perceives he or she has no control.

A few key observations:
  • Chronic stress is prolonged stress experienced over a long time, period often years.
  • There is a distinct physical effect on the body resulting in the continuous release of hormones meant to only be released for a temporary period of time.
  • When you are in state of prolonged stress, you may not recognise it or if you do, feel that you cannot do anything about it.

The Human body is designed to deal with stress, provided it's temporary. When you are under stress your body releases hormones most notably Adrenalin and Cortisol. Adrenalin boosts your heart rate and energy supplies. Cortisol increases glucose in the bloodstream and increases the bodies ability to produce glucose and ability to repair tissue.

If you were to compare is to a car, Cortisol is like Nitrous, Adrenalin is your Turbo.

Now Nitrous is meant for a short boost, running it permanently is not great for your engine. Adrenalin and Cortisol is pretty much the same. If you run it permanently it's not great for your body.

Here are a few highlights of what you might expect when you suffer from Chronic Stress.
  • Anxiety
  • Irritability
  • Recurring Insomnia
  • Headaches
  • Digestive disorders
  • Depression
  • Reliance on boosters such as caffeine
  • Spikes and drops in energy at odd times
  • Unexplained sudden weight gain
  • Increase in illness and difficulty in recovering from illness
And (The ones that can kill you):
  • Hypertension
  • Cardiovascular disease.
It's also worth noting that many of the symptoms have knock on symptoms. 

For me particularly I started suffering from Insomnia almost a year and a half before I was diagnosed with Chronic stress. The effect this had quite a negative effect on my mood and concentration. 

Developers are like Soylent green.
So Developers - contrary to popular belief - is people. In other words they are fallible limited creatures who have limitations in what they can do.

The problem is that we often subject ourselves to increased stress, because of crazy timelines, unrealistic expectations (both by our employers and also by ourselves) and no small amount of ambition.

This is complicated if you are a bit of an A-Type personality who has a tendency to take more and more things on.

The sad part is the more you take and the higher your stress levels become, the less productive you become.

The writing is on the wall
First chronic stress is not like a common cold, the symptoms develop after a long period of time and furthermore it's not something that really well understood.

The result is that it's that this type of thing that creeps up on you, and before you know it you are chronically stressed out and now you need treatment.

So here are some early warning signs that you can learn to identify it:
  • Recurrent episodes of insomnia.
  • Multiple people repeatedly tell you: "You look tired" or something similar.
  • Your buttons suddenly start being pushed often and you find yourself getting more easily aggravated at things.
  • You start becoming very negative and people tell you as much.
  • You suddenly realise you haven't engaged in a personal hobby or done something you like in quite some time.
  • You often have a headache and/or heartburn.
  • You struggle to turn off work and/or you're always anxious about a work.
  • You often work overtime because it's the only time you can get "flow" due to the multitude of distractions in your environment.
Deal with it!
There is quite a lot help out there with regards to reducing stress, but from a personal view there are a few things worth mentioning:
  • Ultimately no one actually forces you to be stressed out, If you don't find a way to deal with it no one else will.
  • Other people won't get it or recognise it unless they have first hand experience, you have to accept and deal with it yourself.
  • Acknowledge your limits.
  • Take stress seriously, it can damage your relationships, your career and your health.
  • Don't be afraid to get professional help.
  • Take that vacation.
  • Be careful when you blur work and pleasure, Especially if one of your hobbies is writing code.
So I hope this was informative and here's hoping to no more stress and - off course - staying alive.

Saturday, January 11, 2014

Builder pattern using Java 8

I work in an environment where a great deal of our day to day scripting tasks occur through calling remote services as opposed to working with the database.

For a lot of scripting tasks I've often used Groovy and one of the most useful features of Groovy specifically for that task has been it's built in fluent Builders.

Now Groovy builders exploit a few Groovy language features that are never going to make it into Java.

Most notably Groovy builders make use of Groovy's Meta programming features which isn't coming to Java any time soon.

However a key feature that Groovy builders have is their hierarchical approach to building constructs.

This allows the builders to neatly and safely create nested tree like constructs which can be used to model everything from UX form layouts to XML.

This approach we can at least model quite succinctly using Java 8 lambda expressions.

For my sample I decided to take a reasonably simple Maven pom file and see if I could create a builder to handle that.

All the code for the builder is available on Github here.

The pom.xml file is as follows:

 <?xml version="1.0" encoding="UTF-8"?>  
 <project xmlns=""  

Here is the sample code for the builder to build this model:

     MarkupBuilder pom = new XmlMarkupBuilder(true, "pom")  
         .at("xmlns", "")  
         .at("xmlns:xsi", "")  
         .at("xsi:schemaLocation", "");  
     pom.el("modelVersion", "4.0.0");  
     pom.el("groupId", "com.github");  
     pom.el("artifactId", "lambda-builder");  
     pom.el("version", "1.0-SNAPSHOT");  
     pom.el("dependencies", () -> {  
       pom.el("dependency", () -> {  
         pom.el("groupId", "junit");  
         pom.el("artifactId", "junit");  
         pom.elx("version", version::get);  
       pom.el("dependency", () -> {  
         pom.el("groupId", "commons-beanutils");  
         pom.el("artifactId", "commons-beanutils");  
         pom.elx("version", version::get);  
     pom.el("build", () -> {  
       pom.el("plugins", () -> {  
         pom.el("plugin", () -> {  
           pom.el("groupId", "org.apache.maven.plugins");  
           pom.el("artifactId", "maven-compiler-plugin");  
           pom.el("configuration", () -> {  
             pom.el("source", 1.8);  
             pom.el("target", 1.8);  
             pom.el("fork", true);  
             pom.el("compilerArgument", "-proc:none");  

A few notes on this in general:

  • I created a special form of some the methods which takes a java.util.function.Supplier as a parameter, and allows you to delay evaluation of a value until you traverse the builder.
  • I eschewed method chaining (although I catered for it in the builder). Trying both methods I personally felt this was a lot cleaner.
  • Java doesn't have all syntax sugar that Groovy has, so I used a java.lang.Runnable for the functional interface which reduced the syntax creating a closure, with the downside that you have to have a handle on the initial builder object.
Nowhere as nice as Groovy builders but nevertheless a great step forward. Can't wait for Java 8.

Thursday, November 14, 2013

Adding Java 8 Lambda goodness to JDBC

Data access, specifically SQL access from within Java has never been nice. This is in large part due to the fact that the JDBC api has a lot of ceremony.

Java 7 vastly improved things with ARM blocks by taking away a lot of the ceremony around managing database objects such as Statements and ResultSets but fundamentally the code flow is still the same.

Java 8 Lambdas gives us a very nice tool for improving the flow of JDBC.

Out first attempt at improving things here is very simply to make it easy to work with a java.sql.ResultSet.

Here we simply wrap the ResultSet iteration and then delegate it to Lambda function.

This is very similar in concept to Spring's JDBCTemplate.

NOTE: I've released All the code snippets you see here under an Apache 2.0 license on Github.

First we create a functional interface called ResultSetProcessor as follows:

public interface ResultSetProcessor {

    public void process(ResultSet resultSet, 
                        long currentRow) 
                        throws SQLException;


Very straightforward. This interface takes the ResultSet and the current row of the ResultSet  as a parameter.

Next we write a simple utility to which executes a query and then calls our ResultSetProcessor each time we iterate over the ResultSet:

public static void select(Connection connection, 
                          String sql, 
                          ResultSetProcessor processor, 
                          Object... params) {
        try (PreparedStatement ps = connection.prepareStatement(sql)) {
            int cnt = 0;
            for (Object param : params) {
                ps.setObject(++cnt, param));
            try (ResultSet rs = ps.executeQuery()) {
                long rowCnt = 0;
                while ( {
                    processor.process(rs, rowCnt++);
            } catch (SQLException e) {
                throw new DataAccessException(e);
        } catch (SQLException e) {
            throw new DataAccessException(e);

Note I've wrapped the SQLException in my own unchecked DataAccessException.

Now when we write a query it's as simple as calling the select method with a connection and a query:

select(connection, "select * from MY_TABLE",(rs, cnt)-> {        System.out.println(rs.getInt(1)+" "+cnt)

So that's great but I think we can do more...

One of the nifty Lambda additions in Java is the new Streams API. This would allow us to add very powerful functionality with which to process a ResultSet.

Using the Streams API over a ResultSet however creates a bit more of a challenge than the simple select with Lambda in the previous example.

The way I decided to go about this is create my own Tuple type which represents a single row from a ResultSet.

My Tuple here is the relational version where a Tuple is a collection of elements where each element is identified by an attribute, basically a collection of key value pairs. In our case the Tuple is ordered in terms of the order of the columns in the ResultSet.

The code for the Tuple ended up being quite a bit so if you want to take a look, see the GitHub project in the resources at the end of the post.

Currently the Java 8 API provides the object which provides a set of static methods for creating instances of We can use this object to create an instance of a Stream.

But in order to create a Stream it needs an instance of This is a specialised type for iterating and partitioning a sequence of elements, the Stream needs for handling operations in parallel.

Fortunately the Java 8 api also provides the class which can wrap existing Collection and enumeration types. One of those types being a java.util.Iterator.

Now we wrap a query and ResultSet in an Iterator:

public class ResultSetIterator implements Iterator {

    private ResultSet rs;
    private PreparedStatement ps;
    private Connection connection;
    private String sql;

    public ResultSetIterator(Connection connection, String sql) {
        assert connection != null;
        assert sql != null;
        this.connection = connection;
        this.sql = sql;

    public void init() {
        try {
            ps = connection.prepareStatement(sql);
            rs = ps.executeQuery();

        } catch (SQLException e) {
            throw new DataAccessException(e);

    public boolean hasNext() {
        if (ps == null) {
        try {
            boolean hasMore =;
            if (!hasMore) {
            return hasMore;
        } catch (SQLException e) {
            throw new DataAccessException(e);


    private void close() {
        try {
            try {
            } catch (SQLException e) {
                //nothing we can do here
        } catch (SQLException e) {
            //nothing we can do here

    public Tuple next() {
        try {
            return SQL.rowAsTuple(sql, rs);
        } catch (DataAccessException e) {
            throw e;

This class basically delegates the iterator methods to the underlying result set and then on the next() call transforms the current row in the ResultSet into my Tuple type.

And that's the basics done. All that's left is to wire it all together to make a Stream object. Note that due to the nature of a ResultSet it's not a good idea to try process them in parallel, so our stream cannot process in parallel.

public static Stream stream(final Connection connection, 
                                       final String sql, 
                                       final Object... parms) {
  return StreamSupport
                          new ResultSetIterator(connection, sql), 0), false);

Now it's straightforward to stream a query. In the usage example below I've got a table TEST_TABLE with an integer column TEST_ID which basically filters out all the non even numbers and then runs a count:

     long result = stream(connection, "select TEST_ID from TEST_TABLE")
                .filter((t) -> t.asInt("TEST_ID") % 2 == 0)
And that's it!, we now have a very powerful way of working with a ResultSet.

So all this code is available under an Apache 2.0 license on GitHub here. I've rather lamely dubbed the project "lambda tuples, and the purpose really is to experiment and see where you can take Java 8 and Relational DB access, so please download or feel free to contribute.

Sunday, December 30, 2012

New Years Resolutions for the Java Developer

So in closing on a rather eventful year for me personally it's always good to reflect and think and thus we apply the cliché of the new years resolutions - with a twist - in that they will be Geeky.

So without further ado here we go.

Use Spring Less.
I plan to use vastly less Spring this year.

Now Spring has pretty much become the de facto component framework in the Java ecosystem. This is not a bad thing; that is until every software nail must be nailed flat with the Spring hammer.

I been on the Spring Bandwagon now since about 2005 when Spring was still the breath of fresh air promising to save us from the evil Darth Ee-jay-bee. From about that time every developer with a glint in their eye and a will to type has tried to shoehorn everything to "integrate" into Spring.

Again this is not necessarily bad, however I work for a company where the perception is that anything prefixed with the word "Spring" is automatically better, sometimes coming at the cost of something that is actually better.

But lets not stop there...

  • I'm tired of the "For Real?" look I get from my developers when they are debugging Spring configuration and they ask my why Spring is better.
  • I'm tired of the massive War files I get and often the dependency clashes I have to fix because of the other stuff I need to pull in.
So this new year I plan to use Spring in it's pure simple form. 

Stop treating JPA/Hibernate as the one stop shop for Java based persistence.
I want to use something besides JPA/Hibernate to do persistence this year, I want to do this because of the following:
  • I want to have POJOs that are still POJOs at runtime.
  • I want to stop having weird hibernate exceptions that happen after we've been in production for a bit, and then have my customer stop screaming at me.
  • I want to stop having the rich domain model being so tantalisingly close to my grasp only to have it all come crashing down when the realities of ORM kick in.
  • In reference to the previous point: I hate DAOs; JPA/Hibernate don't make them go away (at least not completely).
  • I'm tired of the "For Real?" look I get from my developers when they are debugging JPA/Hibernate issues and I'm explaining to them how JPA/Hibernate simplifies things.
Now to fair a lot of the points listed is because JPA/Hibernate does a lot of complex heavy lifting on my behalf, but in many cases the power is just not needed.

Stop using Anonymous Inner classes and just bite the bullet and wait for 8.
I've been excited about the inclusion of closures in Java for a long, long time. I am a self confessed "closurist " and I fully plan to find as I many nails as I can when I get my closure powered hammer.

But I also have to accept that Java 8 especially in full production use is still going to be some ways away.

And before that I resolve to resist the temptation to butcher code with anonymous inner classes in order to recreate that style of coding.

Stop worrying about the procedural code.
Hah! bet you never saw that one coming. 

I've been looking at the code that we produce, typically I do a lot of SOAP web services in my job, and what I see a lot of is that while we normally try to stick to SOLID principles, I don't see a lot of value coming out of the abstractions we create.

We have an anaemic domain model and most of the work is done in the Service tier implementation delegating to DAOs for data operations (although I've started introducing newer patterns here).

I can't help feel that had I done this code in pure C it probably wouldn't feel massively different. To this end I sometimes wonder if all we do is procedural code with a bit of OO sauce on top.

I also wonder is this is necessarily a bad thing; the code works, it's simple to follow and read and is not burdensome to maintain, so this coming year I plan to to stop worrying about it :)


Saturday, January 14, 2012

Documentation that is useful

I was reading this article by Neil Mcallister on his Fatal Exception blog entitled "How to get developers to document their code".

Now it begs the question: What documentation is actually useful?

Well, like all things in general I don't think it's a simple answer, best I could say is; what works well in your context.

In my personal context as a developer of information systems for commercial entities I personally find  the following useful when it comes to documentation:
  • A decent setup and getting started guide: where to get the code, what tools and frameworks I need, how to build and configure it, and how to get it up and running.
  • Environmental information regarding the various environments: How the development, testing, QA and production environments are accessed, configured and managed.
  • A High level guide to how the components of the software fit together, with a one liner about what each component does.
  • An High level ERD or any other high level domain model is also quite useful.
Most of this documentation is really there to give context about the code, the rest I can figure out from the code itself.

I also have a list of documentation that I think is a waste of time and effort:
  • The above compiled into a document and then sent to die in something like Sharepoint: Useful documentation is easily searchable, easily accessible and easy to update referencing the actual models being used by architects and developers.
  • Low level code documentation: It always out of date and rarely ever reflects the truth of the implementation to begin with (It's also annoying to read, Sequence diagrams come to mind). The only time documentation like this is useful is when the documentation effectively becomes the code (using MDA for example).
  • Documentation done for the sake of process: No one will ever read this documentation except for the person who has to check that process is being followed. This seems to happen a lot in Waterfall environments where the process becomes so slow that organizations end up short circuiting pieces of the process in order to speed up development times.
What do you consider useful in your context?

Sunday, July 17, 2011

Java 8.0 Wishlist (Take 2)

Ok so it's it been a while since my last article on this topic...

The comments of course have been first rate, with opinions on the wish-list have ranged from outright agreement to threats of violence for even having such boneheaded ideas.

It's all good of course, the thing that I love about the Java community is that we take the ideas and actually question them. Something I felt the .Net world could do more with.

But anyway It's worth going through the list and giving a little rationale and meat on the wish-list, specifically on those that seemed to generate a lot of comments, so here goes...

Now I'm going to debate the OO nature of properties. Fact is that - for better or for worse - JavaBean style properties have become baked into Java and it's frameworks. So why not at the bare minimum tell the compiler you want to generate getter and setter methods with syntax sugar. And yes IDE's generate this for you, but I'd still prefer for the sake of brevity get rid of code that does stuff all.

Operator Overloading.
Easily the most contentious point. However let me give you my background: I recently did a lot of work doing monetary calculations. which  defined in an Excel spreadsheet by an Actuary. The only way I could get Java code to match the excel spreadsheet was to use ye olde BigDecimal. The code that came out is painful to say the least, mostly due to the lack of operators. Now BigDecimal is on the operator overloading todo list for Oracle, however it's painful having to wait, and the fact is that it's hard to build very expressive arithmetic types in Java.

Alternative deployment formats besides the JVM and  a classpath.
Ok this one seemed poorly presented. Basically I want to be able to compile a set of Java classes down into a native executable and deploy that. Even if all the executable does is wrap the classes together with a JVM. You ask why; that's easy I want to run Java apps on iOS.

Parameter names in method calls.
Ok so lets assume I have a method as follows:
public void crappyGFXtask(int startx, int starty, int secondx, int secondy, int lastx, int lasty)
I dare you write the code to call it, leave it for a few days and then go back to it, and see if you can make sense of the parameters. Named parameters simply give you ability to map the parameter names to values ala Objective-C so your call to the method would look something along the lines of:
crappyGFXtask(startx:10, starty:11, secondx:25, secondy:40, lastx:myVariable, lasty:myVariable)

Proxies on Abstract classes.
Yes Spring does this already, but guess what: I don't use Spring in every Java project I do (yes pigs are flying). It's a generally useful feature and JDK support would be sweet.

Ok hope that clarifies things.