Java Equivalent to C# Extension Methods

Java equivalent to C# extension methods

Java does not support extension methods.

Instead, you can make a regular static method, or write your own class.

Java 8 add extension/default method to class

C# extension methods are just syntactic sugar for static methods that take the extended type as first argument. Java default methods are something completely different. To mimic C# extension methods, just write usual static methods. You will not have the syntatic sugar, however; Java does not have this feature.

Java default methods are real virtual methods. For example, they can be overridden. Consider a class X inheriting from an interface I that declares a default foo() method. If X or any of its super classes declares no own foo() method, then X will get the foo() implementation of I. Now, a subclass Y of X can override X.foo() like a usual method. Thus, default methods are not only syntactic sugar. They are real extensions of the method overriding and inheritance mechanism that cannot be mimicked by other language features.

Default methods even require special VM support, so they are not even a compiler only feature: During class loading, the hierarchy of a class has to be checked to determine which default methods it will inherit. Thus, this decision is made at runtime, not at compile time. The cool thing about it is that you do not have to recompile a class when an interface it inherits gets a new default method: The VM will, at class load time, assign that new method to it.

Can I create extensions in Java like I do in C#?

public class ParameterListExtension
{
  public static boolean contain(List<Parameter> parameters, String key)
  {
    for(Parameter parameter:parameters)
      if(parameter.key.equals(key)) return true;
    return false;
  }
}

…

import static ParameterListExtension.contain;
…
List<Parameter> parameters = getParameters();
if(contain(parameters, "myParameter")) { ... }

I don’t see the advantage of obfuscating where the method came from and pretending it was an instance method of the list.

What is the C# equivalent of Java's java/util/function/BiFunction?

Rather than using functional interfaces to represent functions like Java does, C# uses delegates. There is a built in delegate - Func<T1,T2,TResult>, that represents a function with 2 parameters and a non-void return value, just like BiFunction in Java.

To apply a delegate, you just can just call them like a function/method. Example:

Func<int, int, int> add = (x, y) => x + y;

// similar to: System.out.println(add.apply(1, 2));
Console.WriteLine(add(1, 2));

If you really want to write a word there, you can write Invoke:

add.Invoke(1, 2);

It doesn't have the andThen method, but you can write an extension method for that:

public static Func<T1, T2, R> AndThen<T1, T2, U, R>(this Func<T1, T2, U> bifunction, Func<U, R> andThen)
    => (x, y) => andThen(bifunction(x, y));

What is the practical use of extension methods in Java?

The reason these were added were part of the adding of closures to Java so that there was a easy upgrade path to things like collection classes. The challenge with the addition of closures is there now are a whole lot of functions you want to add to standard collections. However, if you add those to the existing interfaces you break any implementations of those interfaces. A way around this is to add an additional interface with the new methods. This is possible without the virtual extension methods, however, it has its own drawback. Namely, that the implementation of that new interface needs to be added before it can be used. Since there are probably a lot of implementations out there today it may take a long time to get all those implementations upgraded. However, at the same time the way that the methods you want to add are pretty agnostic to the implementation. They should do basically the same thing, at least in the base case. The way the team that built this decided to handle the case was enable the specification of a default behavior that could be overridden. That way with the addition of the interface the functionality is there and it is up to the library writer decide it they want to write a different implementation. The key is they don't have to, or there is a stop gap functionality until they do.

The long an short of it is they basically act like traits and you are correct they aren't the same thing as extension methods in C#. From what I've read the original implementation of this was more C#. However, the decision to use them that way because of the limitations of the style (i.e. unable to override the functionality) and lack of being able to use reflection do discover them. It seems the name stuck, even though the approach to the implementation changed.

See the write-up explaining Virtual Extension Methods for full details.

---

Related Topics