Category Archives: Java

Posts containing Java code

Can we replace requirement specification with better understanding?

On larger projects, I’ve always ended up resorting to writing down a lot of detailed specifications, many of which are wrong, irrelevant or we might not be ready to answer them yet. On small projects, the dialogue between the customer and the developers can flow easy, and good things happen.

The quick analysis

Developer: … so we’re going to complete the current task tomorrow or the day after. Could we discuss what to do next before you’re off to your next meeting?

Customer: Sure. The next task on the backlog is to send the payment request to the accounting system

Developer: Yeah. Um… well, we’re not really ready for the integration tasks yet. I was thinking that we might perhaps pick another user interface task. Would that be okay?

Customer: No problem. Let’s see…. how about “road project submits funding request”?

Developer: Great. What’s that?

Customer: Well, today, the owner of the road project sends in a paper form. Let’s see, the form is available as a PDF on our web site. Let’s take a look.

Developer: Let’s see…. We know how to deal with social security number, names, addresses. This field “municipality,” that’s the usual stuff, right? (customer nods) What about “request id”? What’s that?

Customer: It’s just a sequence number per municipality. It would be really nice if you could suggest a request number and then let the user override.

Developer: That should be doable.

They work out a few more details and get on their way. Total time, 30 minutes

The low ambition implementation

Developer: So, we worked on the funding request UI for the last two days. I think we’ve got something that looks pretty good.

Customer: Great, let’s see it! Let’s see… There’s a new “apply for funding request” menu item. Nice. But it should be “Fund road project” (developer notes feedback). Let me try and press it… Hmm… “select municipality”? Why do I get that?

Developer: Well, we’re still a bit shaky on AJAX. So in order to find the next sequence number, we would like to have the user select municipality first.

Customer: Oh, AJAX. That’s interactive web pages, right? Yeah, I guess that’s fine, but we need to fix up the text a little. So, what happens when I select one…? Nice, it sort of looks like the paper form. That will help us get learn it. But let’s move the fields around a little (he sketches a few change on a piece of paper).

Developer: We were a bit uncertain about this “sum” field. Does the user have to fill in the sum himself? He’s already filled in all the numbers.

Customer: That doesn’t make too much sense. How about if the web pages updates the sum field dynamically? Oh, you’ve got that ‘don’t make me do dynamic webpages’ face again.

Developer: Yeah, sorry. The last time it was a big mess. Can we hold off on that for now? Do you really need it?

Customer: (laughs) No, that’s okay. I guess we can just remove the field. That should be fine.

Developer: Yay! What about validating the bank account number? We left that out, because the documentation is…. well, insane. That alone will take at least another day.

Customer: No, we really need that. People often type it wrong, and then it’s a nightmare to fix all the errors that follow. You just have to fight though it.

Developer: (sigh) I guess it can’t be helped. We’re on it.

Customer: All in all, it looks pretty good. I’ll go over it by myself after lunch and bring you back some issues tomorrow.

The quick completion

Customer: Here’s a list of corrections. Nothing major, just a few misplaced fields and a few extra validation rules.

Developer: Great. We spent all of yesterday doing the bank account number validation. Man, that’s some bad doc! But we should be done before lunch.

Customer: I have an opening in my calendar at the end of the day, let’s take a look then and call it done. Great work, guys!

The contrast

Have you ever been on a small project where everyone has a pretty good understand of what’s going on and the communication works well? Developers can make a pretty good guess at the details and develop a pretty good first version. There may be some more work that’s needed, but these can be negotiated when the developers have a better idea of what’s going to be easy and what’s going to be hard.

When I’ve been on larger projects, this communication seems to break down. Instead the developers require a detailed specification in writing. And if something is missing from the specification, they reject it and ask for further details. And they won’t show the product to the customer before all the kinks are worked out.

When we do it well it’s not so bad, getting a detailed specification and finishing the task before we get real feedback. But it requires the customer to decide on things that may not be important, but that may impact cost substantially. It requires back and forth to get the specification written, reviewed, amended etc.

On a small project, a developer can understand the purpose, build something quickly and adjust it based on feedback. Is the reality of larger projects that this will just remain a pipe dream? If so, why? If not, how do you get the quick and informal feedback?

Posted in English, Extreme Programming, Java, Software Development | 4 Comments

What will Java 7 mean for you?

Oracle released Java 7 on July 28, 2011. This is nearly 5 years after the release of Java 6 in December 2006. The release received a lot of bad press, both because it is very meager on features, and because it shipped with a severe bug. Nevertheless, once the most serious bugs have been fixed, you might think about starting to use Java 7. What will this mean?

New language features

Java 7 has a few new language features. Sadly, the most exciting ones have been postponed until Java 8. The following 3 features may show up in your pretty quickly, though:

This is the try-with-resources or Automatic Resource Management block. If you declare a variable in the try() statement, Java automatically calls close on it, like you would in a finally block. This is a small improvement, but nice. You can use try-with-resources on your own object by implementing the new interface java.lang.AutoCloseable.

This is the multi-catch statement. It’s useful because of the load of checked exceptions on the sanity of your average Java-developer. It’s nice, but hardly revolutionary. It makes me really wish we got rid of checked exceptions, though.

This is type inference for Generic Instance Creation. Saves a few keystrokes without removing any type safety. Again, a nice, but very small improvement.

There are a few more language features, but I expect they will see very little use.

JVM changes

The Java virtual machine gets a new instruction: invokedynamic. Using invokedynamic, the JVM can invoke a method on an object without having to know on which class or interface the method is declared. If it walks like a duck and talks like a duck…

Invokedynamic will be very helpful for implementors of dynamic languages in the JVM, so it’s great. But the average developer will never encounter it in the wild.

Library changes

Looking at the release notes for Java 7, you may first suspect that there are some interesting library changes here. However, when examining the list more thoroughly, I couldn’t find a single change that I expect I will actually use. The library changes are mostly low-level, behind the scenes fixes of small problems.

Conclusions

So there it is: try-with-resources, multi-catch and a very limited type inference. Hopefully, Java 8 will be released as planned in late 2012 with all the stuff we’ve been waiting for. If so, I expect most shops will skip Java 7. But if Java 8 follows the pattern of delays from Java 7, these slim pickings may be all the crumbs the Java community gets for another five years.

Posted in Code, English, Java | 6 Comments

This dependency injection madness must end!

Or: Poor man’s dependency injection: Singleton-initialized field

As dependency injection frameworks like Spring have become central in software applications in the last few years, the conventional view is now that the Singleton pattern is evil and should never be used. Instead, relationships between objects in your system should be managed by a dependency injection container. I have started disliking the consequence of this strategy very much: All coupling in my system becomes implicit and harder to understand. I have instead reverted to using design patterns like the Singleton pattern, but with a slight twist.

The Singleton-initialized field

Here is an example of a Singleton-initialized field:

When I write a test for this class, the test code overrides the PersonDao by passing it to the non-default constructor.

Compared: The dependency injection way

The now-conventional way of doing the same thing is with dependency injection:

And the test will set up the dependencies using a container:

Somewhere in the realms of test-context.xml we will configure the fact that PersonDao should be provided by a mock:

The problem: Declarative programming

With a dependency injection container, the components in my code are loosely coupled. Indeed, this is the main selling point of dependency injection. But sometimes, loosely coupled code is the problem.

First, understanding which dependency is actually used (and why!) can require a lot of brain power: It will require you to consider all possible configurations when you look at a dependency and it will not work well with the normal code navigation functionality of your IDE. Second, the configuration will tend to deteriorate: When you no longer use a dependency, will you check whether you can remove it, or will you just leave it there to be safe?

Lastly, it can be hard to spot errors in the configuration:

I once had a service that needed had a @Resource TransactionManager and a @Resource DataSource. However, the system had a pair of each. The test code was correct, but in the production code, I had by accident configured the wrong TransactionManager. The effect was that the Service didn’t run in a transaction for the correct data source. That is: It didn’t really run in a transaction. The problem with this is that you only discover the problem if you scrutinize the contents of the database after the transaction was supposed to be rolled back.

Dependency injection in specific and declarative programming in general mean More Magic. More Magic is seldom a good thing, at least not when there are simple, time-tested strategies that work. Even if said strategies have fallen out of fashion.

This dependency injection madness must end!

Posted in English, Java | 14 Comments

Video: No-red refactoring

The more I code, the more I’ve learned to appreciate keeping the code clean even during complex refactorings. By “clean”, I mean that the code always compiles and the test always run.

I often find myself in a situation where I have a method call that’s starting to accumulate parameters. Something like this:

After three or four parameters, the need to refactor is starting to become evident. I would rather have something like this:

This is one of the more complex simple refactorings you can make, and it requires several steps. In this five minute video, I show how to perform such a refactoring without any steps that break my code:

The screencast was created using the free BB FlashBack Express on Windows. All the magic you see happening while I program is either ctrl-space (complete) or ctrl-1 (quick fix).

Can you modify your code without going thought long stages of nothing working? I think you can!

Posted in English, Extreme Programming, Java, Software Development, video | 3 Comments

Cross-cutting code, the homemade way

I though I’d do something different this time. Instead of describing something technical, I have recorded a five minute video that shows a very neat trick in Java: How to create a bit of code that wraps existing method calls to an object with any behavior you may desire.

This is nothing new, but I’ve noticed that not many developers know how to use it, so I hope this video may be useful:

If you would rather not include a library like cglib in your code and you don’t mind having to create an interface to create this sort of code, you can do the same with java.lang.reflect.Proxy.

Posted in English, Java | 9 Comments

Eclipse telepathy: Your IDE can guess what you want

Ctrl-1 is the magic “do what I think” button in Eclipse. Whenever I press it, Eclipse seems to come up with something that’s helpful in the current context. In this blog post, I illustrate 10 things that Eclipse hide under the ctrl-1 keypress. This is a follow up on my post on Eclipse stenography.

I got some comments on my last post about Eclipse stenography about the animated gifs. I know this can be annoying, but I considered the alternative: To have you mouse-over or click a picture to animate it. I’m afraid that the pictures will sort of disappear from your attention if I do this. So I’ll try again. But this time, I’ll put the images below the fold. Click on to see the ten tips.

(more…)

Posted in English, Extreme Programming, Java | 4 Comments

How pair programming and test-driven development looks in real life

Pair programming and test-driven development are some of the practices that are most often talked about and least often actually understood. So I’ve decided to undertake the task to teach myself to program a simple, yet realistic problem with a pair programming partner. The goal is to create an entertaining and realistic performance that portrays what it feels like to work like this.

I’ve been extremely lucky. I’ve found not one, but two programmers that have been willing to train enough with me to make a smooth performance of a pair programming session. The result is the Java EE Spike Kata. My colleagues in Steria, Anders Karlsen and Ivar Nilsen have been great to work with. Between us, we’ve showed the kata at three conferences, and more are coming.

Here is the performance at JavaZone 2010 by Anders Karlsen and myself.

The Java EE Spike Kata from JavaZone on Vimeo.

Make sure to watch the video in full screen mode as there will be LOTS of code.

Some things to watch for when you’re watching a (paired) code kata:

  • How are we working together? How often are we changing who’s at the keyboard? What will the person who’s not at the keyboard be doing?
  • How do we progress from one test to the next? When do we decide to modify an existing test and when do we decide to add a new one? How much of the test do we write before we start modifying the production code?
  • How are we writing the production code? How often are we refactoring existing code?
  • How are we using the IDE? What tricks do we use to take advantage of the code completion facilities? How often do we use the mouse and how often do we use the keyboard?

I also hope to be putting up the video of me and Ivar Nilsen at the TelecomCity conference in Sweden. As we’d both practiced even more for that performance, I think it’s even smoother than the JavaZone performance.

Enjoy!

(Kudos to Cisco Norway, formerly Tandberg, for excellent filming services at JavaZone. And thank you to Robert “Uncle Bob” Martin for turning me on to code katas in the first place)

Posted in English, Extreme Programming, Java, Pair programming, video | 10 Comments

Eclipse stenography: Create code faster

According to Wikipedia, stenography or shorthand is “is an abbreviated symbolic writing method that increases speed or brevity of writing as compared to a normal method of writing a language”.

Just as a stenographer learns to take down information really fast, a good programmer can learn to write code really fast by taking advantage of his or her tools. In this post I’ll show you my secret code stenography tricks.

The basic way completion works is: You write something and press ctrl-space. Eclipse will respond with a list of option. Use the arrow keys to select an option and press enter. Eclipse will replace what you typed with the option.

Name completion

The most well-known form of completion: Start writing the name of a class or method, press-ctrl space, and Eclipse will complete the typing for you.

Complete method name

Notice the blue squares around “expected” and “actual”. These are “fields”. Use tab to jump between them.

New to many is the fact that Eclipse support CamelCase syntax when completing names:

Class name completion

When I type “TPH”, Eclipse finds to classes with names that match (“TaggedProfileHelper” and “TaggedProfileHolder”) and offers them to me as a list. When I type “TPHe”, Eclipse finds only one class that matches (“TaggedProfileHelper”), and expands it automatically.

Pro tip: Remove classes you don’t use but that often make completion ambiguous by going to Window->Preferences and adding the classes to Java->Appearance->Type filter.

Expand code template

Another fairly basic one: Type the name of a template (from Window->Preferences, Java->Editor->Templates) and press ctrl-space to insert it.

Expand code template

Notice that Eclipse brings up the type list on the first ctrl-space. Press ctrl-space again to show Template completions.

Pro tip: Edit and remove editor templates to make your coding faster. You may also add template, but I seldom find this as useful.

Override method

Now, we’re getting into new territory for most of you: In the class body, type the name of a method in the super class and press ctrl-space:

Override method

Eclipse offers to override the method for you. Notice that CamelCase completion works here.

Generate getters and setters

Yet another little know super trick: In the class body of a class with a field “name”, type “getN” and press ctrl-space to generate a getter, or “setN” to generate a setter:

Generate getter and setter

Notice that CamelCasing doesn’t work perfectly here; you can’t type “gNa” to create a getter for “name”.

(It’s possible to generate getters and setters for a large number of fields with “Source->Generate getters and setters”. But when I only add one new field, I find code completion to be a faster option)

As I’ve been working on code katas, I’ve found many ways to speed up my programming in my IDE of choice. I hope Eclipse stenography or code completion can help you write code faster as well.

Posted in English, Extreme Programming, Java | 1 Comment

Dynamic subclass APIs make Java seem young again

At JavaZone 2010 I will be giving a lightning talk on APIs that use dynamic subclasses. These APIs make it possible to do things in Java that seem like pure magic. Here are some ideas of what you can get from these APIs and a look under the hood, so you really understand what’s going on.

Mockito – “the best Java library named after a summery drink”

Mocking is a hotly debated subject within testing camps. I think a lot of the arguments come against mocking (beyond overuse…) come down to the fact that the last generation of mocking libraries left a lot to be desired. A desire that has been fulfilled by Mockito.

I will leave the examples at a minimum, but here’s an example from code I actually use a lot. Mocking the servlet API:

For those of you who’ve struggled with jMock or it’s ilk, you may notice the concise syntax used to specify behavior (“when(…).thenReturn()”) and the fact that you don’t have to set up expectations before exercising the code.

LambdaJ – “making Java beautiful and incomprehensible”

LambdaJ pretty much starts with the realizations that waiting for new language features like closures may prove to be a very long wait indeed. Furthermore, anonymous inner classes may technically be used to simulate closures, but they are so ugly that not even a mother could love them.

Let’s look at an example: Finding the name of every member of the Simpsons family who’s older than 8, in order of age.

In plain Java:

More modern languages are way ahead of Java. Here’s Ruby:

The rather simple request is simple to express. Yay!

Java 7 may make this better.

All in all, not a bad contender. What about LambdaJ:

It’s not perfect, but it has one thing to recommend it: This works with standard, everyday Java, today! There’s no special compilation crap. No other language. Nothin. Just plain old Java.

(Thanks to Mario Fusco for improving the example with LamdbaJ 2.3 syntax)

What’s going on

Both LambdaJ and Mockito use a tricky sleight-of-hand: Generate a dynamic subclass which records its method invocations for later use. Creating such an API is in principle easy, although my implementation leave a lot! of details unimplemented.

So: We want invocations on the generated class to be template/mock objects to be saved:

This magic is surprisingly easy to implement with CgLib:

This creates a subclass of the template class (in this case: Person). But every method in Person is overridden by calling the invocation handler. Which simply saves what method was called.

This makes it possible to implement a prototype of LambdaJ’s collect method:

This is a gross simplification. LambdaJ handles many aspects that my prototype simple ignores: Chained method calls, multithreading, method arguments, and multiple invocations on the same line.

The future of Java

Maybe the future of Java isn’t extending the language. Maybe the future of Java isn’t replacing the language with Scala. Maybe the future of Java is smart people discovering smarter ways of using what’s already there. My hat off to Mario Fusco, Szczepan Faber and everybody who’s contributed to LambdaJ or Mockito.

Come to my talk at JavaZone to learn more!

Posted in English, Java | 5 Comments

Six ideas that improve your software design

“Design” is a verb, not a noun. If I want to create a good program, studying the process of getting there is much more important than the resulting software. This is why I use coding katas as a form of study. I find an interesting problem problem and then solve the same problem over and over again. In this blog post, I will focus on six principles of software design. I will illustrate each with a screencast from a kata.

One of my favorite problems is that of creating a Java EE application from scratch. I call this kata “The Java EE Spike Kata”. In order to understand the role of frameworks, I use no web frameworks in the process of creating this application. I’ve completed this particular exercise about forty times on my own and more than ten times with various pair-programming partners. The whole exercise takes me about 90 minutes, and I still learn new things.

The total time of the screencasts is around 40 minutes, so you may want to pick and choose. Each section provides a link to the starting point for the source code if you want to follow along.

Please notice: The videos are accompanied by loud, pounding music. Keep you headphones on or your volume down if you share offices with someone else. Or mute the videos if you dislike the music.

Idea 1: Build your software from the outside-in

(10 minutes, github starting point)

I start building the application by writing tests that access the application over HTTP and looks at the resulting HTML. As you might have gathered, when I start this test, there is no web application. Only when the tests require a web application to continue do I start creating it. In this example, I had created a basic sketch of the interaction between the three web pages in the application before I started coding. No further design was necessary.

This particular approach uses WebDriver and Jetty to run. The cute assertion library that you may have noticed at the end of the video is FEST-assert.

Idea 2: Specify behavior rather than implementation

(6 minutes, github starting point)

I don’t make much of a distinction between different types of tests. All good tests try to describe what the software should do at some level, rather than how the software does it. But the how at some level may be the what at another level. My first test specified the interaction between the web browser and the server. In this test, one step may be to fill in the form element of a web page. This second video shows how this form works in terms of actual HTML. But the details of what framework (if any) is used, is not visible in the test.

The second thing you’ll notice in the video is that I run the tests more frequently. And each test run is much quicker. As our tests move close to the code, the rate of feedback improves.

This particular test uses Mockito to mock out the Servlet API. The assertions use FEST-assert.

Idea 3: Increase the rate of feedback

(5 minutes, github starting point)

This video illustrates the frequency of feedback. The example test-drives creating an equals-method. This task is often not worth test-driving. The resulting method is usually simple and/or generated by your IDE. But it is a good example to of how quick the cycle between test and production code can be when you’re writing tests that are close to the problem at hand. When I pair program this part of the kata, we usually use a technique called ping-pong programming: One programmer writes a failing test (or failing assertion) and hands the keyboard to his partner, the other programmer makes the test pass and writes another failing test before passing the keyboard back. On a good run, we will switch who’s got the keyboard more often than once per minute.

Notice that I also focus on the behavior of the equals-method in this test.

Idea 4: Grow the API rather than designing it up front

(8 minutes, github starting point)

As the web application grows under my fingers, I discover the need for a Data Access Object (DAO). However, as this represents a major internal interface in my application, I use Mockito to mock the implementation until I’m done with the behavior of my servlet. When this is done, I test-drive the implementation of the DAO in a separate test class.

The video also illustrates another important lesson: The code is getting ripe for a refactoring. But it’s important to resist the urge to refactor until the tests are green. If you refactor on red tests, you have much higher chances of running down a dead-end road and you’ll have to throw away your progress, wondering what went wrong.

The example uses Mockito to mock out the DAO API.

If you want to see how I implement the DAO with Hibernate, you can see the video on blip.tv.

Idea 5: Grow the design rather than speculating

(3 minutes, github starting point)

The video is only a partial example of this principle. Throughout the whole application, I’ve been refactoring, gradually pulling out structure to more well-structured methods and classes. The video illustrates some of the power of IDE’s when it comes to refactoring. Using the IDE to massage your code into a better design makes evolutionary design much easier to do in practice. Make sure to learn your IDE’s most useful refactorings!

The kata may seem like a non-realistic example at this time, but I’ve actually grown a very successful architecture on my current project using much the same approach. If you want to explore where to go next, the next step needed for this application is to factor out the views into separate classes and then use either a View Template language (like Velocity) or a View Transformer (using, for example dom4j) to generate the HTML. (Let me know if you’d like to see the screencast of this as well).

Idea 6: It’s supposed to work the first time around

(5 minutes, github starting point)

In this video, I return to the first test, PersonWebTest, to finish the configuration of the application. I discover a few mistakes I made in the web test as I complete the exercise. Then I try out the code in the browser. And all the scenarios I had planned for work out of the box.

When you try out your code for the first time, it should work. When you master test-driven development, you will probably forget how you programs didn’t use to work the first time. Only when you occasionally run into an unexpected error during manual testing it becomes clear how test-driven development changes you life.

If you want to see the whole, uninterrupted 75 minute code kata, the video is available at blip.tv. You can also take a look at the finished source code at github.

Happy programming!


A big thanks to Trond, Thomas, Ram and Christian who helped improve this post. Thank you to Finn-Robert, Øistein, Mats, Anders, Siv, Peyman, Ivar, Øystein, Cecilia, Nicolay, and Karianne who have pair-programmed this exercise with me. I especially appreciate how Ivar and Karianne both helped influence the way the application is wired together and showed me that even after 30 iterations, I still had things to learn; and how Øistein showed me how two trained developers could complete the exercise faster with pair-programming than alone. And thank you to Nicolay who graciously brought food to our pair-programming exercise.

The videos were made with the excellent (and free!) BB FlashBack Express. The keyboard echo is courtesy of KeyPosé by Magnus Jungsbluth.

Posted in Extreme Programming, Java, video | 7 Comments