Devoxx Distilled

Didn’t go to Devoxx this week? Then read on for my subjective summary of the event.

Let’s go with the ‘exceutive summary‘ right away:

  • continue, or start doing, continuous integration, continuous delivery, or continuous deployment.
  • Java8 is already here and it’s different. The new API’s are powerful and have a definite learning curve, but start using lambdas/streams/new APIs right away or regret it later.
  • even dry-as-the-desert-banks are transforming to agile now (in what seems to be a successful and ‘correct’ fashion), no more excuses for anyone else to stick to age old Business vs IT barriers, waterflows and the like.
  • the market is exploding with cloud solutions for building, running, maintaining java applications. time to make use of them.
  • Java EE 7 (and above) is a new breed and much less cumbersome than previous versions. Have a look at it.

The ‘buzz’:

  • Docker
  • Rochefort 8 > Rochefort 6 …
  • Lambdas, Streams
  • Functional, Reactive
  • The Java Posse shuts down
  • Voxxed, a brand new Java community site
  • … Rochefort 10 > Rochefort 8!

As a conference, Devoxx…

  • … is very focused on Java and surrounding technology (obviously!); there are not many methodology, inspirational or alternative talks. Denise Jacobs talks on the creative mind, were, however, very good.
  • … has an excellent venue at the Metropolis Cinema with great audio and screens, great seats, and an easily accessible location (tram stops right outside),
  • … does not have the best quality or supply of food (!) although, there is plenty to drink,
  • … was jam packed with people that created queues for most things,
  • … is located in a country with great beer tradition.

All in all, I had a great time and I’d like to thank the Devoxx team for all their efforts, and Hybris for giving me the opportunity to attend. Hoping for a return next year!

 

Spring 3.2 Rundown, Miscellaneous

So, in this final part of my excursion into new Spring territory, I’ll talk about a few trends and tools noted in the “3.2 era”. This blog post will go high and low while trying to follow a red line, let’s see how it goes!

First of all, let’s take a look at some of the tools that leverage the ongoing boom in REST-ful API:s.

Spring HATEOAS is a framework helping out with writing HATEOAS compliant REST-interfaces (which is really a fundamental principle of REST!). Basically, a client should only take actions on a resource that were described in representations previously received from the server. You could say that the client should be able to be agnostic in terms of what resources are available, and how they are linked. So, not surprisingly, this Spring framework has support for adding this type of information to the representations the server sends back to the client. It can help you keep track of how to create the necessary relative links to other resources in your application. I believe this principle of REST is pretty fantastic, yet not fully leveraged by many teams, and I encourage you to take look!

Spring REST-shell is a tool used to help REST developers test and explore their interfaces. The command line-style shell have several commands and features such as discovering resources, following paths within the interface, setting the HTTP request headers and posting JSON (although that is somewhat clunky). An intended use of this shell is together with the HATEOAS framework, fully leveraging HATEOAS-style links. An example would be that a resource which has a “rel” linking to another resource, can easily be followed via commands instead of having to manipulate the resource URL.

The above tools can actually be used together with Spring Data Rest to, with very little boilerplate code, create a HATEOAS compliant REST-interface on top of your model.

Finally, a small reflection that most of the Spring projects on Github now seem to use Gradle instead of Maven. It’s not particularly new that Gradle is the new kid on the block, however you should take notice that things are happening here. Apparently, ThoughtWorks goes so far as to put Gradle in the ‘Adopt’ quadrant in their 2013 technology radar, whilst Maven falls back to ‘Hold’.

Spring 3.2 Rundown, Content Negotiation

Another one of the new Spring 3.2 features is better support for content negotiation. I’ll introduce the topic briefly here, and share some thoughts.

Content negotiation is used to indicate either what type of content a client would like to receive, or to indicate what type of content the server will return. This is useful for various reasons, some being:

  • Enabling servers to deliver content of the client’s preferred type.
  • Enabling better error handling, when there is a mis-match in client-server content types.
  • Serving content on the same location to different kinds of clients, such as browsers or mobile apps.

Anyway this is hardly news for anyone (!) and the technology is widely used, particularly in its most classic way, via HTTP headers. But with Spring 3.2, there are new features that help us with making the most out of a variety of content negotiation techniques:

  • URL path extension. E.g. ‘some/url/index.html’ versus ‘some/url/index.json’
  • URL path parameter. E.g. ‘some/url/index?format=html’
  • HTTP ‘Accept’ header

To minimize Internet waste, I’ve decided to not go more in depth here, and I will simply recommend that you take a look at this Spring blog which does a great job of explaining the topic. Or you can skip the reading and jump straight to the author’s demo!

Spring 3.2 Rundown, MVC Testing

Spring 3.2 comes with new, improved support for testing within the Spring MVC domain. The gist of the new MVC test feature, is that you can test your controllers in ways such that requests are routed via a proper MVC infrastructure, i.e. via the DispatcherServlet.
Previously, you may have used various mocks to test the code inside each controller method. With the new functionality, you can also test and verify specifics of the controller method, such as the mapping, HTTP headers, request data, content types and more.

So how would you accomplish this? Let’s start by turning our attention to the spring-test module, and the org.springframework.test.web.servlet package where we find the new MockMvc class. MockMvc acts as an entry point to the MVC structure under test. It’s a tool you can use to simulate requests against your controllers, with support for all kinds of assertions on the results. As indicated above, everything about your controller should work as it would at runtime, including servlet filters, view templates and the like. However, the requests will not be running in an actual servlet container, which means that JSPs will not work properly (although you can still assert some things like what model objects were set).

To get hold of an instance of MockMvc, there’s a convenient builder, namely org.springframerowk.test.web.servlet.setup.MockMvcBuilders. Currently, there are two builders you can instantiate, and they should be used for different purposes.

First, you can create a standalone MockMvc for one or more of your controller objects (annotated with @Controller). A “minimum” infrastructure required by the DispatcherServlet is then created, which may be customized as needed. This option is specifically intended for unit testing one controller at a time, leaving testing of the MVC infrastructure itself, the Web Application Context, to other test classes.

Second, you may create a MockMvc given a particular WebApplicationContext (a class which is also new in 3.2). This allows you to load a full Spring MVC configuration in which the controller under test will exist during tests. This option should be considered for integration tests, where the focus isn’t solely on the controller’s code, but the effective behaviour of the controller in the scope of the tested application.

Now it’s time to look at an example, which will demonstrate a standalone controller test and how to perform assertions. First, a very simple controller:

@Controller
public class BlogController {

    @RequestMapping(value = "/mvc/plaintext", method = RequestMethod.GET, headers = "Accept=text/plain")
    @ResponseBody
    public String plain() {
        return "a response body";
    }

}

And a simple test for this controller:

import org.springframework.test.web.servlet.setup.MockMvcBuilders;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

public class BlogControllerTest {
    @Test
    public void testPlain() throws Exception {
        MockMvcBuilders.standaloneSetup(new BlogController()).build()
                .perform(get("/mvc/plaintext"))
                .andDo(print())
                .andExpect(status().isOk())
                .andExpect(content().contentType("text/plain"))
                .andExpect(content().string("a response body"));
    }
}

As you can see, MockMvc allows for a fluent-API way of testing the controller, including assertions.

When you call “perform” on MockMvc, the result is a ResultActions, on which you can “expect” a wide variety of criteria via the “andExpect” method. The criteria here, are instances of ResultMatcher, for which there exist a large number of helper classes. For example, MockMvcResultMatchers can be statically imported to support matchers for asserting content, view, model, urls, response status, headers and more!

As we saw, there’s also a static “print” method, used as parameter to “andDo” on the ResultActions object, which will dump the result of the performed request to standard out:

this.mockMvc.perform(......).andDo(print());

Hopefully, this blog is enough to get you going with MVC testing. If you want to go more in depth in this topic, take a look at the Spring blog, consult the reference manual, and check out the Spring MVC Showcase, which includes a large amount of samples of what is possible with the new MVC testing features. Also check out this Spring blog which discusses other new, general testing features such as how you can set up and customize mocked application contexts.

These great new features mean there’s really no excuse not to test controllers, so now we can finally stop starting web servers to find out whether our code works!

Spring 3.2 Rundown, Async Support

One of the features in the latest minor release of the Spring framework (3.2), is support for Servlet 3.0 “async” processing.

In this blog I’ll show you how Spring let’s you do wizardry things like long polling in a straightforward way!

In a normal web application, the client (browser) sends HTTP requests to the server, which processes information and delivers an HTTP response. While waiting for the response, the browser normally pauses and indicates that it is waiting for a response. To alleviate the client becoming “unresponsive”, this is nowadays overcome mostly by sending the request as an AJAX request. This solves the client’s problems to a great degree.

However, a situation where the processing on the server side takes an extended amount of time, may cause problems for the server. Each (AJAX) request
that clients make will “hang” on the application server and lock up resources (such threads), while the server is trying to process it. Thus, this is where the
async functionality in Servlet 3, and Spring 3.2 comes to the rescue.

Spring async support basically comes in two variations. Both methods work in a similar fashion, namely that when a request is received, the executing thread is immediately released. Processing is done in a separate thread, before the HTTP response is written back to the client. Thus from a client side, it’s not possible to distinguish that async functionality is being used.

I built a sample application for the purpose of showing these variations, including the “normal” HTTP request/response call, and I’ll show you here how to set this up yourself.

First of all, you’ll need a project setup. Look no further than the Spring MVC Showcase project on github! In my own demo project I used a similar, but simpler, setup that I won’t show here. What I will do is highlight a few important configurations:

  • Make sure your application server supports the Servlet 3.0 spec.
  • Set the <async-supported> flag to ‘true’ on your Spring dispatcher servlet.
  • Specify that the web application is a “3.0” web application in web.xml:
    <web-app xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">

 

That’s about it.

My application loads a simple HTML page with three links:

home

When the first, called ‘normal’, is clicked, an MVC controller method is hit, which basically puts the thread to sleep for 9 seconds, before returning a view name.

When the second, called ‘async with callable’, is clicked, an MVC controller method is hit, which returns a java.util.Callable. The callable implementation sleeps for 9 seconds before returning a view name. In this case the response is written after the Callable returns the view.

When the third, called ‘async with deferred’, is clicked, an MVC controller method is hit, which returns a Spring DeferredResult typed to ModelAndView. The result is also stored in a local Collection. A separate method, scheduled by Spring to run every five seconds, is run concurrently. The thread simulates an external process or thread, by sleeping for 9 seconds before calling “setResult” on the DeferredResult stored in the collection. In this case, setting the result causes the response to be written!

To understand the differences between these methods, I took screenshots of the running Tomcat threads after having clicked each of the above links:

normal

In the normal case, you can see that the Tomcat exec thread is sleeping during execution of the controller method.

async
In the async case, you can see that the Tomcat exec thread releases execution of the controller method, and a separate thread (known by Spring) performs the “processing” before returning the response.

deferred
The deferred case is almost the same as the async one. The only difference is where the processing occurs, which in this case is the Spring initiated ‘pool-1-thread-1′ executor thread. Note that this thread could have been started from anywhere, it wouldn’t have to be known to Spring.

So in conclusion, I think it’s fair to say that Spring makes this  new functionality very easy to implement. Now you can start doing ‘long polling’ and stop hogging too much resources!

If you want to try these things out, I suggest that you take a look at the three Spring blogs on the topic and use the MVC Showcase project as your starting point.

For reference, below is the controller code used to demonstrate the above:

/**
 * @author Christian Fogel
 */
@Controller
public class AsyncDemoController {

    private final Queue<DeferredResult<ModelAndView>> eventQueue = new ConcurrentLinkedQueue<>();

    @RequestMapping("/normal")
    public String normalCall() throws InterruptedException {
        Thread.sleep(9000);
        return "normal";
    }

    @RequestMapping("/async")
    public Callable<String> asyncCall(final Model model) {
        return new Callable<String>() {
            @Override
            public String call() throws Exception {
                Thread.sleep(9000);
                return "async";
            }
        };
    }

    @RequestMapping("/deferred")
    public
    @ResponseBody
    DeferredResult<ModelAndView> deferredCall() {
        DeferredResult<ModelAndView> result = new DeferredResult<>();
        this.eventQueue.add(result);
        return result;
    }

    @Scheduled(fixedRate = 5000)
    public void simulateExternalThread() throws InterruptedException {
        Thread.sleep(9000);
        for (DeferredResult<ModelAndView> result : this.eventQueue) {
            result.setResult(new ModelAndView("deferred"));
            this.eventQueue.remove(result);
        }
    }

}

 

 

Spring 3.2 Rundown, Intro

The new version of Spring, dubbed 3.2, went “GA” in December, and I’ve taken a look at the new features and what you can do with them. This will be a rundown of selected features, with comments and examples.

First off, I’d recommend you to refer to the blog post, this video briefing and the 3.2 reference, in increasing order of detail of what the 3.2 release brings. Or you can stick around here for a distilled version! I’m going to comment and provide examples of the following topics in this blog series:

Lombok

Java developer? You feel class and method declaration is cumbersome? You want to follow Mr Bloch‘s advice but fret verbose boilerplate code? Look no further than Project Lombok!

Lombok helps you as a Java developer, with mundane tasks such as creating no-args constructors, getters/setters, toString/equals/hashCode-generation and more. All you need to do is to annotate your classes, as described in the manual.

For example, if you put the @Data annotation on your class, you’ll get generated toString, equals, hashCode, getter and setter methods, AND a constructor taking all required fields as parameters. Phew!

Behind the scenes, these are generated by code from the lombok jar-file, which must be on the classpath. Plugins exist for most IDE’s, so it’s easy to get going, here’s what you need for IntelliJ:

  1. Install the lombok plugin from the plugin repository.
  2. Add the maven dependency org.projectlombok:lombok version 0.11.6
  3. Annotate your data classes, and use them, example:
@Data
public class Person {
    private final String name;
    private int ageInYears;
}

public class PersonTest {
    public static void main(String[] args) {
        Person person = new Person("Christian Fogel");
        person.setAgeInYears(145);
        System.out.println(person.getName() + "," + person.getAgeInYears());
        System.out.println(person);
    }
}

The above would, surprisingly, not only compile but also print

    Christian Fogel,145
    Person(name=Christian Fogel, ageInYears=145)

Pretty neat isn’t it? As usual, don’t forget to read the fine print, test your classes thoroughly and beware the development status of the project (as indicated by the version number).

A New IDE(A), Overcoming The Comfort Zone Hurdle

I recently started a new assignment, where the predominant IDE in use is IntelliJ IDEA. Now, I am quite an Eclipse user having exploited its open source powers for the most part of my career. There are many reasons for this, the most obvious one being that is has been the de facto IDE for most projects I’ve been involved in. There have been a few occasions where I had the chance to try out, or switch to another IDE but I’ve never been forced to do it. And that’s why I’ve always gone back to Eclipse. The problem is that you get used to your IDE. It IS the main tool we developers use in our daily struggles to bring fluffy features into working software… You don’t want to start looking for a type hierarchy for five minutes, or an extract method refactor for another three, in the middle of your zen coding flow. I am one of those that try to learn and use as many of the available keyboard shortcuts as possible. First, it helps avoid hand and arm strain if I can avoid using the mouse, and second it minimizes the delay between having an idea and producing code. If I have to go looking in menus, or lift my hand for a split second, I percieve it as a mini-impediment in my thought process.

So, back to my new assignment, and IDEA. This time, the use of IDE was more of a requirement. I could still use Eclipse if I wanted to but I thought that this time I’d give it a real shot. At first, I tried using the Eclipse keyboard mapping available in IDEA, but I found it lacking some of my key (pun!) bindings. Instead I opted for the default bindings, used a keyboard chart on a separate screen and every time I got stuck fumbling at Ctrl-O or something similar, I made time for finding the exact equivalent. To my surprise, this learning process didn’t take too long, now that I had allowed myself to stop and really look things up.

I’m not going through a complete comparison of the two IDEs, but here a few initial observations. The IDEA Maven features are very neat, and is great for our profile-based build settings. Subversion seems to be a little bit lacking though, and I’d prefer Eclipse on that point. IDEA makes much more use of colors and markers (by default), which is actually a bad thing since I have impaired color vision. The Eclipse formatter seems to work more like I want it to, while the IDEA one doesn’t interfer as much with your line breaks. Eclipse templates such as “foreach” work better. Finally, you don’t really save things in IDEA as you might do in Eclipse, things are automagically saved and built.

Below is a short list of my most commonly used bindings, and the rough equivalents in both IDEs:

IDEA Eclipse Functionality
Ctrl-G Ctrl-L Go to line
Alt-Enter Ctrl-1 Quick Fix
Ctrl-Shift-Backspace Ctrl-Q Go to last edit
Ctrl-Q F2 Show javadoc
Ctrl-Alt-B (Ctrl-T->choose) Go to implementation. Not sure about the Eclipse one here, but I usually open type hierarchy and choose implementation
Ctrl-B F3 Go to interface/implementation
Ctrl-Space Ctrl-Space Note that you must use Ctrl-P (in IDEA) to see parameters of a method call you are making, e.g. method.(/*what args exist?*/)
Ctrl-N Ctrl-T Open type
Ctrl-Shift-N Ctrl-Shift-R Open resource
Ctrl-Y Ctrl-D Delete row
Ctrl-F4 Ctrl-W Close tab
Ctrl-H F4/Ctrl-T Type hierarchy (tabbed vs inlined)
Ctrl-F12 Ctrl-O Method list (prefer the Eclipse one)