I’m sure you’ve seen this form of initialization many times

public static final String[] SOME_ARRAY = new String[] {
    "value1",
    "value2"};

but what if you want to have lists? or you want to have a list that builds upon another list?

Then odds are this is what you’ve written:

public static final List LIST1;
public static final List LIST2;
{
    LIST1 = new ArrayList();
    LIST1.add("value1");
    LIST2 = new ArrayList();
    LIST2.addAll(LIST1);
    LIST2.add("value2");
}

an alternative way to write it is this:

public static final List<String> LIST1 = new ArrayList<String>()  {{
     add("value1");}}
public static final List<String> LIST2 = new ArrayList<String> {{
     addAll(LIST1);
     add("value2");
}}

Personally, I think the above is cleaner, and easier to follow, so if you agree, consider using it the next time you want this type of construct.

To explain what’s happening here, basically, you are constructing an anonymous subclass of ArrayList, and whatever is inside the nested {} is the constructor.

You could, although I wouldn’t recommend it, do something like this:

    public static final List<String> LIST2 = new ArrayList<String> {
        private Long someField;
        public Long getSomeField() { return someField; }
       ....
       {
           addAll(LIST1);
           add("version2");
      }
    }

One place where this syntax is put to use is JMock2 and construction of it’s expectations.

In Groovy (and other languages that support meta-programming), one can extend the functionality of existing classes to provide powerful functionality. Here’s a simple example in Groovy.

Integer.metaClass.daysAfterToday = { ->
  Calendar today = Calendar.instance
  today.add(Calendar.DAY_OF_MONTH, delegate)
  today.time
}

// now can use this syntax anywhere after the metaClass modification
5.daysAfterToday()

The above code adds a new method, getDaysAfterToday to an Integer. As you can see, it will return the date that is 5 days after today (hence the name).

Something similar can be accomplished in Scala via implicit conversions. Here’s the code.

class DateHelper(days:Int) {
  def daysAfterToday():Date = {
    val today = Calendar.getInstance
    today.add(Calendar.DAY_OF_MONTH, days)
    today.getTime
  }
}
implicit def Int2DateHelper(days: Int) = new DateHelper(days)

// now we can use this syntax anywhere the implicit conversion is defined
5.daysAfterToday

So, what does the Scala code do?

• Defines a class that has a constructor that takes an Int. This will also create a property called days
• Define a method daysAfterToday that returns a Date that is ‘days’ days after today.

The line beginning with implicit is the interesting one. It defines a conversion from Int to DateHelper.

So, the compiler will then see the 5.daysAfterToday. As 5 is an Int, it will try and find a method daysAfterToday on Int. Obviously it doesn’t exist. So, it will then start examining all implicit definitions that are in scope (as implicits have a lexical scope. They would generally be associated with a package, and imported accordingly).

The compiler will eventually ‘find’ the Int2DateHelper implicit definition, and modify the 5 to be a DateHelper object. Then when that line of code is executed, it will actually be calling daysAfterToday on the DateHelper object.

So, the same syntactic sugar can be used when defining a DSL or any other type of coding. Of course, you also now have the compiler doing some testing for you, as it will complain if it can’t find an implicit conversion.

In contrast, it’s up to the developer to test their code thoroughly to ensure that all places where daysAfterToday is used actually work correctly. For example, if I wrote the following in Groovy

Long someLong = 10:
someLong.daysAfterToday

The dev wouldn’t find out until run time (or hopefully in the test the dev wrote around their code) that daysAfterToday is not defined for a Long.

If a developer does something similar in Scala, the compiler will tell them that ‘daysAfterToday is not a member of Long’, and no explicit test is required.

I’m in the process of learning Scala, and find it interesting to contrast the 3 languages of the title. Java is Java.

Groovy, at least in my mind, is a nicer Java. Cleaner syntax, with more commonly done functions built-in. Also, not too hard to learn if you already know Java. With a few exceptions, you can write Java code, and the Groovy compiler will know what to do with it. Once you learn some Groovy features, you can start taking advantage of them.

Groovy also adds dynamic and meta-programming abilities, which are very powerful features, and can make development quicker. Just make sure you write lots of unit tests.

Scala on the other hand is a new animal. It’s still a JVM language, but is trying to address the weaknesses of Java, provide dynamic typing development speed, and still remain statically typed.

Two things in Scala really help with the above. One is type inferencing, and the other is being able to define types.

One of the biggest complaints about Java is the amount of typing required for defining items, especially when Generics are involved. For example:

// Java version
List<String> myList = new ArrayList<String>();
myList.add("some value")

//Scala version
// Note: Scala uses [] rather than <> for generics.
// < and > are valid in Scala method names, so can't be used in definitions.
val myList = new ArrayList[String]
myList.add("some value")
myList add "some other value"

// of course to make it truly Scala, it would become:
val myList = List("some value", "some other value")

The end result is the same. Both myList will be ArrayLists of String, but much less typing required.

Scala also allows something akin to duck-typing. It isn’t duck typing, but it does allow one to not have to define interfaces on a number of Objects that will be used in a method.

// Java
public void testMethod(IOutputable someObject) {
  someObject.output();
}

// Groovy
def testMethod(someObject) {
 someObject.output() // may throw a MissingMethod exception at runtime, so make sure you test
}

//Scala
def testMethod(someObject:{def output()}) = {
  someObject.output()
}

The above method will take any object that has an output() method defined on it. So, you don’t have to define an interface with an output method on it to pass objects in, but the compiler will also have an error if the testMethod is called passing an object that doesn’t define an output method.

The syntax of Scala will seem weird to a Java developer. There are a number of conventions to get used to, and various other ‘oddities’ about the language that take time to get used to. Here’s an example of the same functionality in all three languages.

//Java - what we're used to seeing
public String buildEpochKey(String... keys) {
  StringBuilder s = new StringBuilder("elem")
  for(String key:keys) {
    if(key != null) {
      s.append(".")
      s.append(key)
    }
  }
  return s.toString().toLowerCase()
}

//Groovy - still fairly straight forward to see what's happening.
// NOTE: .with {} means that any method calls in the curly-braces will be called on
// the object before the .with.
// i.e. addAll, retainAll and join will be called on keys2
def buildEpochKey(String... keys) {
  def keys2 = ["elem"]
  keys2.with {
    addAll(keys)
    retainAll{it != null}
    join(".").toLowerCase()
  }
}

//Scala
// - in the method definition, keys is the variable.
// String* is like Java's String...
// the : after the parenthesis with a type defines the method return type (i.e. String in this case)
def buildEpochKey(keys: String*): String = {
  ("elem" +: keys) filter(_ != null) mkString(".") toLowerCase
}

What was that?!?

• +: means add the item before the +: to the item after it
• filter filters a collection based on the closure after it. Filter will pass each item into the closure. If the closure returns true, the item will be added to the new collection, otherwise it won’t.
• _ in a closure is a shortcut for saying the first parameter passed in
• mkString is Scala’s version of join. mkString also has a variant that takes delimiters.
• toLowerCase is just that. A call on the string that is the result of mkString

I suspect the Java code is the most efficient of the 3, as it only loops through the items once. Don’t know if Groovy or Scala are able to optimize away the multiple iterations. And, it’s possible this could be written more efficiently. After all, I’m relatively new to Scala and the whole functional development thing.

So, as you can see, Scala can allow you to be very succinct with the code you write, but it certainly takes some getting used to. Also, I’m finding the Scala IDE plugin for Eclipse is only ok. It allows for debugging, and some basic refactoring, but it seems somewhat slow right now.

It is being improved all the time, but as there isn’t a lot of boilerplate code to type with Scala, I’m not minding the plugin weaknesses that much.

As far as resources for learning Scala, I’m currently reading 2 books. One is Programming in Scala 2nd Edition, and the other is O’Reilly Programming Scala. Programming in Scala 2nd Edition was just released, so it covers all the features added in Scala 2.8.1, and the O’Reilly book appears to be updated when new language releases are made. I can’t find a link to the downloadable PDF for the O’Reilly book, but I was able to find one Googling around.

If you have an enum defined as such:

public enum myEnum {
   VALUE1,
   VALUE2
}

and you want to convert it to string values of VALUE1 and VALUE2 for use elsewhere, there are 2 methods available. name() and toString().

If you want to always be guaranteed that you get VALUE1 and VALUE2, you must use name(). toString() can be overridden, and depending on the enum, is likely to be.

For example, if we modified an enum to contain properties, we might want toString to reflect this.

public enum Planets {
   MERCURY("first"),
   VENUS("second"),
   EARTH("third")

   private String positionFromSun;

   public Planets(String positionFromSun) {
      this.positionFromSun = positionFromSun;
   }

   @Override
   public String toString() {
      return "The planet " + this.name() + " is the " + this.getPosition() + " planet from the sun";
   }

name() for the above enum would still return MERCURY, VENUS and EARTH whereas toString() obviously will not.

Ever wanted to write a Regex and be able to test the results?

Found a useful website that allows just that. Enter a regex, and a number of test values (up to 10 at once), and it will show the results.

RegEx: online regular expression testing

In a blog post titled Toyota’s journey from Waterfall to Lean Software development, Henrik Kniberg describes his visit to Toyota in April 2009.

It appears they were using waterfall, and had only begun investigatin the pros and cons of Agile.

We look to their manufacturing side for insight into Agile software development, and yet they aren’t doing that themselves. Very interesting.

It appears they’re finding the waterfall process doesn’t work for them (I doubt any of us are too surprised), and they’re investigating other options.

Perhaps this explains some of the issues we now see with software in cars…

An amusing take on the development ‘game’, and unfortunately, you’ve probably worked with someone like this…

3 Simple Rules that will make you a ‘Superstar’developer

NB:Read to the bottom before you get upset….

Ever since attending the SpringOne 2GX conference, I’ve been intrigued by Groovy. I’ve finally had a bit of time to start working with it, and decided to share some of the niceties of Groovy. This post is a very simple example of the differences in coding between Java and Groovy, so expect to see more as time, and my knowledge permits.

The first thing I really liked about Groovy was the removal of explicit setters and getters. I’ve always hated the clutter, and especially since it makes it harder to see if any getter/setter is doing something ‘special’, or if there are methods that aren’t setters/getters.

So, a simple bean defined like so in Java to support easier setting of variables

public class Bean {
    private long numberOfCompanies;
    private long numberOfUsersPerCompany;
    private long numberOfSecureMessages;

    public long getNumberOfCompanies() {
        return numberOfCompanies;
    }
    public Bean setNumberOfCompanies(long numberOfCompanies) {
        this.numberOfCompanies = numberOfCompanies;
        return this;
    }

	// code snipped here
}	

//used like this
    growthRequest
       .setNumberOfCompanies(1L)
       .setNumberOfUsersPerCompany(1L)
       .setNumberOfSecureMessages(2L);

becomes this in Groovy

public class bean {
    long numberOfCompanies
    long numberOfUsersPerCompany
    long numberOfSecureMessages
}

 // and gets used like this
growthRequest.identity {
   numberOfCompanies = 1L
   numberOfUsersPerCompany = 1L
   numberOfSecureMessages = 2L
}

// or like this, without defining a constructor...
	GrowthRequest gr = new GrowthRequest("numberOfCompanies:1L", "numberOfSecureMessages:2L", "numberOfUsersPerCompany:1L")

Groovy also supports the concept of a read-only property. It uses the final keyword, which is a little confusing to us Java devs, as the field isn’t final in the Java sense. A getter will be defined in the public interface of the Groovy object, but the object can still modify the value internally.

Another case that is very nice is long strings, or strings that are concatenated with variables. In Java, we have

String s = "some text that is long " +
	"and some more text that goes here" +
	someVar + " more text and more";

whereas Groovy would have

String s = """some text that is long
	and some more text that goes here
	${someVar} more text and more"""

If your string is just a regular string (i.e. no variable replacement), you can use apostrophes. If you use a single quotation mark, or triple quotation marks, then Groovy will parse the string to search for replacements. So, for performance reasons, unless you need a variable replacement, use apostrophes for strings.

The heredoc format allows for much easier test string generation. For example

String s = """
	<xml>
		<entities>
			<entity>1</entity>
			<entity id="idValue">2</entity>
		</entities>
	</xml>

Keep in mind that I’m intentionally typing variables. Groovy allows for no typing as well, so the previous example could merely def s.