Java 8

This article discusses and compares the initial version of Java 8 and C# 4.5.1. I have not used Java 8 and I have not tested that any of the examples—Java or C#—even compile, but they should be pretty close to valid.

Java 8 has finally been released and—drum roll, please—it has closures/lambdas, as promised! I would be greeting this as champagne-cork–popping news if I were still a Java programmer.[1] As an ex-Java developer, I greet this news more with an ambivalent shrug than with any overarching joy. It’s a sunny morning and I’m in a good mood, so I’m able to suppress what would be a more than appropriate comment: “it’s about time”.

Since I’m a C# programmer, I’m more interested in peering over the fence at the pile of goodies that Java just received for its eighth birthday and see if it got something “what I ain’t got”. I found a concise list of new features in the article Will Java 8 Kill Scala? by Ahmed Soliman and was distraught/pleased[2] to discover that Java had in fact gotten two presents that C# doesn’t already have.

As you’ll see, these two features aren’t huge and the lack of them doesn’t significantly impact design or expressiveness, but you know how jealousy works:

Jealousy doesn’t care.

Jealousy is.

I’m sure I’ll get over it, but it will take time.[3]

Default methods and static interface methods

Java 8 introduces support for static methods on interfaces as well as default methods that, taken together, amount to functionality that is more or less what extensions methods brings to C#.

In Java 8, you can define static methods on an interface, which is nice, but it becomes especially useful when combined with the keyword default on those methods. As defined in Default Methods (Java Tutorials):

“Default methods enable you to add new functionality to the interfaces of your libraries and ensure binary compatibility with code written for older versions of those interfaces.”

In Java, you no longer have to worry that adding a method to an interface will break implementations of that interface in other jar files that have not yet been recompiled against the new version of the interface. You can avoid that by adding a default implementation for your method. This applies only to those methods where a default implementation is possible, of course.

The page includes an example but it’s relatively obvious what it looks like:

public interface ITransformer
{
  string Adjust(string value);
  string NewAdjust(string value)
  {
    return value.Replace(' ', '\t');
  }
}

How do these compare with extension methods in C#?

Extension methods are nice because they allow you to quasi-add methods to an interface without requiring an implementor to actually implement them. My rule of thumb is that any method that can be defined purely in terms of the public API of an interface should be defined as an extension method rather than added to the interface.

Java’s default methods are a twist on this concept that addresses a limitation of extension methods. What is that limitation? That the method definition in the extension method can’t be overridden by the actual implementation behind the interface. That is, the default implementation can be expressed purely in terms of the public interface, but perhaps a specific implementor of the interface would like to do that plus something more. Or would perhaps like to execute the extension method in a different way, but only for a specific implementation. There is no way to do this with extension methods.

Interface default methods in Java 8 allow you to provide a fallback implementation but also allows any class to actually implement that method and override the fallback.

Functional Interfaces

Functional interfaces are a nice addition, too, and something I’ve wanted in C# for some time. Eric Meijer of Microsoft doesn’t miss an opportunity to point out that this is a must for functional languages (he’s exaggerating, but the point is taken).

Saying that a language supports functional interface simply means that a lambda defined in that language can be assigned to any interface with a single method that has the same signature as that lambda.

An example in C# should make things clearer:

public interface ITransformer
{
  string Adjust(string value);
}

public static class Utility
{
  public static void WorkOnText(string text, ITransformer)
  {
    // Do work
  }
}

In order to call WorkOnText() in C#, I am required to define a class that implements ITransformer. There is no other way around it. However, in a language that allows functional interfaces, I could call the method with a lambda directly. The following code looks like C# but won’t actually compile.

Utility.WorkOnText(
  "Hello world",
  s => s.Replace("Hello", "Goodbye cruel")
);

For completeness, let’s also see how much extra code it is do this in C#, which has no functional interfaces.

public class PessimisticTransformer : ITransformer
{
  public string Adjust(string value)
  {
    return value.Replace("Hello", "Goodbye cruel");
  }
}

Utility.WorkOnText(
  "Hello world",
  new PessimisticTransformer()
);

That’s quite a huge difference. It’s surprising that C# hasn’t gotten this functionality yet. It’s hard to see what the downside is for this feature—it doesn’t seem to alter semantics.

While it is supported in Java, there are other restrictions. The signature has to match exactly. What happens if we add an optional parameter to the interface-method definition?

public interface ITransformer
{
  string Adjust(string value, ITransformer additional = null);
}

In the C# example, the class implementing the interface would have to be updated, of course, but the code at calling location remains unchanged. The functional interface’s definition is the calling location, so the change would be closer to the implementation instead of more abstracted from it.

public class PessimisticTransformer : ITransformer
{
  public string Adjust(string value, ITransformer additional = null)
  {
    return value.Replace("Hello", "Goodbye cruel");
  }
}

// Using a class
Utility.WorkOnText(
  "Hello world",
  new PessimisticTransformer()
);

// Using a functional interface
Utility.WorkOnText(
  "Hello world",
  (s, a) => s.Replace("Hello", "Goodbye cruel")
);

I would take the functional interface any day.

Java Closures

As a final note, Java 8 has finally acquired closures/lambdas[4] but there is a limitation on which functions can be passed as lambdas. It turns out that the inclusion of functional interfaces is a workaround for not having first-class functions in the language.

Citing the article,

“[…] you cannot pass any function as first-class to other functions, the function must be explicitly defined as lambda or using Functional Interfaces”

While in C# you can assign any method with a matching signature to a lambda variable or parameter, Java requires that the method be first assigned to a variable that is “explicitly assigned as lambda” in order to use. This isn’t a limitation on expressiveness but may lead to clutter.

In C# I can write the following:

public string Twist(string value)
{ 
  return value.Reverse();
}

public string Alter(this string value, Func<string, string> func)
{
  return func(value);
}

public string ApplyTransformations(string value)
{
  return value.Alter(Twist).Alter(s => s.Reverse());
}

This example shows how you can declare a Func to indicate that the parameter is a first-class function. I can pass the Twist function or I can pass an inline lambda, as shown in ApplyTransformations. However, in Java, I can’t declare a Func: only functional interfaces. In order to replicate the C# example above in Java, I would do the following:

public String twist(String value)
{ 
  return new StringBuilder(value).reverse().toString();
}

public String alter(String value, ITransformer transformer)
{
  return transformer.adjust(value);
}

public String applyTransformations(String value)
{
  return alter(alter(value, s -> twist(s)), s -> StringBuilder(s).reverse().toString();
}

Note that the Java example cannot pass Twist directly; instead, it wraps it in a lambda so that it can be passed as a functional interface. Also, the C# example uses an extension method, which allows me to “add” methods to class string, which is not really possible in Java.

Overall, though, while these things feel like deal-breakers to a programming-language snob[5]—especially those who have a choice as to which language to use—Java developers can rejoice that their language has finally acquired features that both increase expressiveness and reduce clutter.[6]

As a bonus, as a C# developer, I find that I don’t have to be so jealous after all.

Though I’d still really like me some functional interfaces.