Java

JavaOne 2013

Having missed out on the last couple of JavaOne conferences, I am extremely happy that I will be attending this year. And not only as an attendant, but as a speaker.

More details on my talk will follow. For now, make sure you register for the conference.

Continuous Delivery at Javaforum Malmö

It was an excellent Javaforum meeting in Malmö at FooCafé Yesterday with three brilliant presentations….or at least two brilliant! I will leave the verdict for the last up to you since I am kind of biased…
Well, anyway, here are the slides from my presentation. Below, you will find some comments and thoughts from the discussions under and following the presentation.

Branching Strategy

This is always a hot topic when brought up. I still believe that excessive branching is evil, especially in the context of Continuous Delivery. The longer period of time a piece of code is kept away from the main part of the code, it is more likely to fail. Thus pulling and pushing (or the equivalent of your preferred VCS or DVCS) is the key to make sure that all developers are actually working on the same code base. Frequent pull/push combined with the right techniques, such as Branch by Abstraction, makes the use of the evil feature branches unnecessary even when performing so called major refactorings.

The use of Gerrit was also discussed in this context. Even though it involves a manual step (the approval) and use branching as underlying technique, I think that as long as you see it as a part of the Commit Stage and do not let the unapproved code branches batch up it is an excellent tool for securing the quality of the code base. The caveat is if the approvals starts lacking and you end up with a lot of small parts of code in their own gerrit generated branch awaiting approval that nobody is aware of.

Deployment Scrips

Should you run deployment scrips even on your local development environment? Well, it depends. Normally, you will get much faster feedback by running the application by using the application server support in your IDE. Most IDEs supports hot deploying on save nowadays. But if you make changes to the code that is likely to affect the deployment scrips, or if you are developing the deployment scripts, you should of course test them locally to be sure that they run as expected. Remember that the deployment scripts are also a part of your code base.

Another example is if the target environment is Linux and the developers are running Windows. If the target environment is not likely to change, I see no reason why you should clutter the deployment scripts with OS-specific code or, God forbid, have two versions of the scripts.

7 reasons to upgrade to Java 7

Java 7 is finally here! Or to be absolutely correct, will be released July 28. In this post, I will point out 7 (wonder where I got that number from…) reasons to upgrade.

  1. Coins are also money
    Project Coin contains a couple of nice language changes that will make life as a programmer much easier. See the project page for details.
  2. Dynamic languages
    invokedynamic adds support for dynamically typed languages on the Java platform.
  3. New File System API
    File operations have always been pain in Java, but with this new API most of the issues are solved. Manipulating symbolic links for example.
  4. Concurrency
    The Fork/Join Framework provides a set of utilities you would benefit from when writing concurrent programs, giving the possibility for true parallelism on the Java platform.
  5. Modularization
    A refactoring enabling the Java SE platform to be downloaded as required by the VM as needed. 
  6. Enhancements
    A lot of enhancements regarding classloading, unicode, locale etc.
  7. It’s new
    And new things are always more motivating to work with than old, at least in the context of programming languages.

To be honest this is not very much for a major version of a programming language, especially since it has gone nearly five years since the previous version. But it shows that Java is still alive after the whole Oracle story.

Architect’s Java DAO Generator

Usually, when I come home from work, I am pretty tired of programming and rarely ever do any programmin during weekends. But this weekend was different. I have been coding pretty much at work lately, so it should not be because of abstinence from coding. Anyhow, I set down and contributed to a small open source project started by a former colleague of mine. It is called Architect’s Java DAO Generator, and you can find it on Sourceforge. In short it is a maven plugin that generates most of the boilerplate code you usually have to code by hand. It also abstracts the data access layer from your domain logic in a nice way. Version 1.5 is soon going to be available and is absolutely worth a look.

Candidate for Daily WTF

To cry…or laugh…that’s the question…

@Test
public void spaceFiller() {
   int l = 5;
   String result = MessageUtil.spaceFiller(5);
   if (result.length() == l) {
   } else {
      fail();
   }
}

When I came across the test code above I wondered who on Earth would write such a thing. The answer came shortly after when I had a look at the method it is testing…

/**
 * Space filler.
 * Creates a string filled with spaces of the wanted length
 *
 * @param length the length of the wanted string
 * @return the string
 */
public static String spaceFiller(int length){
   String s = "";
   for(int i=0; i < length; i++)
      s = s.concat(" ");
   return s;
}

The good thing is that they actually wrote a nice and clear JavaDoc explaining their own stupidity…

Are Unit Tests Necessary?

At work today I came across a project that had not written a single unit test for their new code and wondered what the hell they were doing. Nothing unusual except that apart from the usual excuses about time constraint etc., they had the guts to challenge the value of unit tests. I did not believe what I heard and for a moment wondered if I had gone through some kind of time capsule when I was visiting the pyramids in Cairo last week and come back in a time before unit testing was invented. But a quick glance at the date on my watch ensured me that it was still 2010.

The only comforting thing about this is that as long as there are projects like this, there will be plenty of work for software consultants to clean up the mess. Just a pity that the first couple of weeks will be spent writing unit tests to be able to start refactoring the code. Good thing that writing unit tests are pretty fun and addicting, or to quote one of Kent Beck’s tweet earlier today “… tests are like potato chips”.

A Special Year

The first time I attended JavaOne was 1999 and I have only missed it once since then. Sadly, this year will be the second time I am not present there. I have become kind of used to the week in San Francisco every year. It is the perfect way to start the summer with a visit to that beautiful city. Since it is in September this year, it would probably been the perfect way to end the summer (…we have short summers here in Scandinavia…).

I will for sure miss the massive input and inspiration this conference gives me and enables me to keep up-to-date on everything that is happening in the Java Community. This year’s conference is also special since it is the first time Oracle is hosting the show. It feels like a good idea to co-host it with Oracle Develop and I hope it will be a success to be continued. Next year, I will definitely be attending, one way or the other…!