New language features in Java 7
I’m just back from the Devoxx conference in Antwerp. An update was given on the new language changes that will be in Java 7. The JDK currently has a release date of September 2010.
Here are 7 of the new features that have been completed:
- Language support for collections
- Automatic Resource Management
- Improved Type Inference for Generic Instance Creation (diamond)
- Underscores in numeric literals
- Strings in switch
- Binary literals
- Simplified Varargs Method Invocation
There is a lot more to Java 7 then just these language changes. I’ll be exploring the rest of the release in future posts. One of the big debates is currently around Closures, which are a separate JSR.
Language support for collections
Java will be getting first class language support for creating collections. The style change means that collections can be created like they are in Ruby, Perl etc.
Instead of:
List<String> list = new ArrayList<String>();
list.add("item");
String item = list.get(0);
Set<String> set = new HashSet<String>();
set.add("item");
Map<String, Integer> map = new HashMap<String, Integer>();
map.put("key", 1);
int value = map.get("key");
You will be able to use:
List<String> list = ["item"];
String item = list[0];
Set<String> set = {"item"};
Map<String, Integer> map = {"key" : 1};
int value = map["key"];
These collections are immutable.
Automatic Resource Management
Some resources in Java need to be closed manually like InputStream, Writers, Sockets, Sql classes. This language feature allows the try statement itself to declare one of more resources. These resources are scoped to the try block and are closed automatically.
This:
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
br.close();
}
becomes:
try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}
You can declare more than one resource to close:
try (
InputStream in = new FileInputStream(src);
OutputStream out = new FileOutputStream(dest))
{
// code
}
To support this behaviour all closable classes will be retro-fitted to implement a Closable interface.
Improved Type Inference for Generic Instance Creation (diamond)
This is a particular annoyance which is best served with an example:
Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
becomes:
Map<String, List<String>> anagrams = new HashMap<>();
This is called the diamond operator: <> which infers the type from the reference declaration.
Underscores in numeric literals
Long numbers are hard to read. You can now split them up using an underscore in ints and longs:
int one_million = 1_000_000;
Strings in switch
Currently you can only use numbers or enums in switch statements. String has been added as a candidate:
String s = ...
switch(s) {
case "quux":
processQuux(s);
// fall-through
case "foo":
case "bar":
processFooOrBar(s);
break;
case "baz":
processBaz(s);
// fall-through
default:
processDefault(s);
break;
}
Binary literals
Java code, due to its C heritage, has traditionally forced programmers to represent numbers in only decimal, octal, or hexadecimal.
As quite a few domains are bit orientated, this restriction can introduce errors. You can now create binary numbers using an 0b prefix.
int binary = 0b1001_1001;
Simplified Varargs Method Invocation
When a programmer tries to invoke a *varargs* (variable arity) method with a non-reifiable varargs type, the compiler currently generates an “unsafe operation” warning. JDK 7 moves the warning from the call site to the method declaration. This will enable API designers to use varargs due to the reduction of warnings reported.
This one is slightly more involved so you are better off looking at the proposal.
Coding Dojo: Example Katas
In my previous post I discussed the basics of what a Coding Dojo is and why you’d want to have one.
I host a Coding Dojo at my work every month, so I’ve decided to periodically update an index page of example Katas. They are usually based off existing Katas which are available on the main Coding Dojo website. I’d also recommend the prolific Sao Paulo Coding Dojo.
You should be able to reuse the same problems at your own Dojo. If you have any other recommendations then please email/twitter me, or comment on this post.
Current Problems
Minesweeper Kata
On a slightly related note, I just completed the common Minesweeper Kata.
Matt Wynne, who has an excellent blog, recently created a test harness using the Ruby BDD framework called Cucumber. It acts as a great way to introduce you to BDD and Github if you haven’t used them before.
The Coding Dojo
Joe Wright talks about Coding Dojos from TechMeetup on Vimeo.
A Coding Dojo is a programming session based around a simple coding challenge. Programmers of different skill levels are invited to engage in deliberate practice as equals. The goal is to learn, teach and improve with fellow software developers in a non-competitive setting.
I’ve been running a Coding Dojo at JPMorgan in Glasgow for over a year and I’ve found it to be a fantastic way of encouraging people to stretch their coding muscles and meet other fellow developers who they haven’t met before.
Background
Researchers at Florida State University have been trying to find out what makes certain people experts in a craft. They have studied people recognised as world class in their fields like Tiger Woods, Warren Buffet and Luciano Pavarotti to find out whether they are excelling as a consequence of possessing innate gifts or due to hard work.
Their research found that elite performers in many diverse domains have been found to practice on average the same amount every day, including weekends, over a period of at least 10 years. There is an intrinsic link between deliberate practice and high levels of skill.
The renowned pianist Vladimir Horowitz supposedly said, “If I don’t practice for a day, I know it. If I don’t practice for two days, my wife knows it. If I don’t practice for three days, the world knows it.”
Dave Thomas seized upon this idea in his book The Pragmatic Programmer. He suggested that programmers should be practising small problems outside of their job regularly, repeating the same problem in order to learn from previous mistakes. To encourage people to practice he posted a series of Code Katas on his website. The word Kata comes from martial arts and is a practice of repeating a small movement repeatedly in order to perfect it.
One of the limitations with the Code Kata is that when you complete the task on your own, you don’t receive any feedback. An important positive stimulus found in research around deliberate practice shows that having a master in the craft available to you while you learn is crucial.
Laurent Bossavit, a determined Parisian, decided that practising Katas at home was keeping this beneficial element away from him. He created the Coding Dojo concept, where he would present a rehearsed Kata from scratch in front of an audience. His weekly Paris Dojo started in 2005 and it has since inspired many other programmers to start their own.
Principles and Rules
The premise of a Coding Dojo is to promote continuous learning in a safe environment. It is both non-competitive and inclusive. People of different skill levels collaborate together, encouraging each other to talk openly about design and techniques.
The rules used at a Dojo depend on which format the Dojo uses; one rule that must be adhered is that you elect to use either Test Driven Development or Behaviour Driven Development. These practices allow for greater testing of a codebase and allow developers to express their needs from that codebase.
Everyone participating should be able to go home and recreate a solution to the same problem. If one person doesn’t understand, then the coding should stop until they are confident with what is taking place.
Formats
All Dojos take place in a room with at least one laptop over two hours. There is an overhead projector available where people can display and speak about their code. The Dojo itself can have differing formats which control the different way developers interact.
Prepared Kata (Parisian)
The Parisian style of Dojo requires the most effort up front by an individual. A single developer starts from scratch and codes a Kata in front of an audience. The developer will have tried the problem a few times before and shows their solution to the crowd over the projector.
While the presenter creates their code they are constantly speaking to the audience letting them know exactly what they are doing and why. Any member of the audience is allowed to interrupt the presenter and ask them why they are coding in a certain pattern.
Randori (Finnish)
The Randori style of Dojo was created by the Agile Finland group as a way of making a more interactive Dojo. It involves developers programming in rotating pairs to design a solution to a problem. The problem and proposed programming language are voted on before the event by the participants.
No one is required to have done any research into the problem before the Dojo begins. Pairs are given a 7 minute time frame to code in front of the audience; once their 7 minutes are up, another person from the audience replaces a member of the pair and takes over.
This format requires dedicated concentration from the participants in order to be successful. Because of this a person is normally made product owner to make sure that everyone is paying attention to the progress the current pair are making.
Individual Pairs (Glaswegian)
Due to the upfront effort required of the prepared Kata and the dedication needed for a Randori to succeed, I’ve been using a different approach at JPMorgan. The format I use is to introduce a problem, then split the group into pairs who choose their own programming language to craft a solution in. After two hours of coding the pairs perform a short presentation on their codebase, showing the progress and design they’ve made.
Start a Coding Dojo at Work
Hosting a Coding Dojo is a very cheap and effective way to train and improve with your colleagues. All you need is a room with a projector and some willing developers with laptops. It doesn’t require much money and it’s not complicated to set up. There are a lot of sample problems available online already and participants don’t have to attend every Dojo.
A Coding Dojo represents a different challenge to developers. It encourages them to speak to an audience about their code, which is a different skill to producing it. These skills are developed during a Dojo as it stimulates social and self organisational skills. It makes people become more rounded software engineers and discover potential areas of improvement.
So what’s stopping you?
Attending a Coding Dojo can help you improve enormously; it is a fun and challenging experience you share with other developers. It encourages deliberate practice by working together on a common problem during which you can learn, teach, accept criticism and defend your ideas. You will receive feedback not only on the code you produce, but the techniques you use. You will be exposed to new ways to use your favourite language and some different tricks you can perform with your code editor.
As Ron Jeffries points out “What changes people is what they do, not what they read. How many diet books have I read? Am I thinner?…”
Further Reading
Continuous Integration: An Introduction
Have you experienced Integration Hell? Do you find that sometimes broken code gets into the mainline without anyone noticing?
These practices can occur frequently. A way to combat this is to adopt the mindset of Continuous Integration (CI).
Background
CI is a development methodology involving daily developer integrations verified by automated builds. Martin Fowler wrote the original article on CI:
“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly” martinfowler.com
The Fowler article highlights that adopting CI represents a sizable shift in the process of building software. Integration usually happens infrequently, resulting in a small effort today being replaced with a lot of pain later.
CI changes the developer approach by encouraging frequent integration as part of their daily activities.
Risks of not doing CI
- Without CI the team can lack cohesion (incompatible conflicts, different libraries in use, “I thought you fixed that bug 3 months ago!”).
- Lack of Visibility: Not knowing when a build fails or your code coverage.
- Isolation: “It works on my machine!”.
- Integrating late means fixing bugs late, which is costly.
Benefits of CI
- CI allows you to develop software faster, better and cheaper.
- Faster: No integration points. Release builds become a non-event.
- Better: Tested early and often. Consolidated metrics though a CI Server.
- Cheaper: Identify defects earlier and fix when least costly.
- Easily repeatable testing.
Prerequisites to adopting CI
In order to take advantage of CI you will need to already have your source code in a repository such as Subversion or Clearcase. You will also need to have adopted an automated build tool such as make, maven or an equivalent.
The biggest benefit you can get from CI is when you have a suite of automated unit tests. If you don’t have unit tests then you will only have the validation that your code can compile, not that it functions as expected.
CI will not work if you want to use:
- Nightly Builds.
- Developer Branches.
- Scheduled Integration.
- Building via an IDE.
If you can match these prerequisites then you will be able to take advantage of a CI with a CI Server.
CI Servers
A CI Server acts as a centralised build machine for your project. It is possible to practice CI without a CI Server but it isn’t advised. CI Servers give you a web interface that allows you to see the status of your project within different environments.
To get started with a CI server you make a job which knows where your codebase lives. You then give it a simple script which can be run from the command line. The CI Server will then continuously poll your source code repository for changes, if it detects a change then it will check out your codebase and run your build tool. It will then report back the result of the build including if anything has broken.
CI Servers offer different mechanisms for reporting feedback on builds. A few common options are email, instant messaging, RSS, IDE integration and tray icons.
This feedback gives developers confidence that their changes are working with everyone else’s and allows them to continue to develop with that reassurance. This is especially important when a developer is performing a large refactoring task.
Rules for CI
In order to get the most out of CI, there are some rules that you need to follow:
- Commit early and commit often.
- Never commit broken code.
- Fix build failures immediately.
- Ensure your builds run fast, and fail fast.
- Avoid known CI Anti Patterns.
CI within organizations today
CI is a development methodology which takes getting used to, but it allows you to develop software faster, better and cheaper. Teams within organizations are building software in a CI Server as you read this.
While the choice of CI Server differs within organizations, Hudson is getting a lot of support as it is free and has a large community creating extensions.
Using Ruby to parse an Excel document
If you work in the finance domain you are often confronted with data in spreadsheets. I’ve used a number of ways to read spreadsheets before like Scriptom (Groovy) or POM (Java). Ruby comes with a windows specific OLE bridge which allows you to use COM to communicate with a number of different MS applications. The pickaxe has more details.
Here is a 4 line working example of opening an Excel document, choosing a worksheet then printing the values of a range:
require 'win32ole'
excel = WIN32OLE::new('excel.Application')
sheet = excel.Workbooks.Open('c:\excel.xls').Worksheets('worksheet')
sheet.Range('A1:A3').columns.each { |col| col.cells.each { |cell| puts cell['Value'] } }
Automatically resolving jars for the Java classpath
When you use the Java classpath (pre java 1.6) you have to manually list each jar on your classpath such as:
java -cp lib/database.jar:lib/commons.jar:/lib/log.jar com.joejag.Main
On Java 1.6 a little known feature is that you can now use wildcards, so the above command becomes:
java -cp lib/*.jar com.joejag.Main
I still have to use an earlier version of Java for some applications I handle. To save having to list all the jars manually I use the following bash script which allows you to automatically list all the jars in a directory:
java -cp `find lib -name *.jar -exec printf :{} ';'` com.joejag.Main
Using Ruby as an AWK replacement
Someone at work asked if you could use Ruby like AWK. I did a little digging and found that you can.
cat file | ruby -n -a -e 'puts "#{$F[0] $F[1]}"'
‘-n’ makes the Ruby iterate over all lines successively assigning them to $_
‘-a’ makes Ruby split $_ into its parts assigning the result to $F which is an array of strings
‘-e’ means that what follows is code to be executed.
‘-F’ specifies the column separator
I performed a speed comparison on some different size files and operations. For files under 500kb lines Ruby has comparable performance to AWK. For anything larger then Ruby (1.8.6) is at best twice as slow. Though I wouldn’t expect a general purpose language to outperform a specialist tool.
