donderdag 12 januari 2017

Default method implementations with Java 8 interfaces

Java 8 allows you to add so called "default" method implementations to interfaces. The intended use was being able to  extend an existing interface without breaking existing code. A new function is added with an default implementation. Existing code does not have to change because of the default implementation.

 A possible reason to add this to the language may be a side effect of adding support for functional programming with lambda support and "streams". By calling stream() to a collection you get an Iterable like structure with methods like filter(), map() and flatMap().  These methods accept a lambda expression as argument. The stream() method is implemented as a so called default method on the Collection interface. A possible reason to not add filter(), map() and  flatmap()  directly to Collection  may be the fact that all methods on an interface are public. You have no way of hiding an implementation detail in a private methods. This will change in Java 9.

Note for .NET programmers, Java 8 Stream functionality has nothing to do with IO streams but are the Java way of LINQ. Sadly there is no syntactic sugar in the language to support this.

Other uses of default methods

What else could you do with default method implementations on interfaces?
One thing you could do is defining interfaces where all methods have default methods.
These "interfaces" can then be used to mixin functionality in implementation classes instead of using delegation. This has the disadvantage of exposing implementation details to the external interface of the class. This should not be a problem since you already hide the class by using an interface and a factory for the functionality you want to expose. Or did you not?

Edit: Scala people may know this as the Cake Pattern.

Introducing Noaber

To test this idea I wrote a sample library Noaber for which the source code is available on Github.
Noaber  provides you with mixin functionality for functional programming. Noaber adds extra functionality for streams. It adds methods for currying and partial application for functions of more than two arguments.
package eu.hanskruse.trackhacks.noaber;

public  interface $ extends // 
 // Only anchor point. Default implementations are in the super interfaces
Noaber has a single interface you can ' implement' in your classes or extend in your interfaces.
Since I consider it's name not important I opted for a single character name '$'. Why '$'?
  • It is a short name that should not get in the way
  • Saves typing
  • Because '_' is illegal to use in Java 9.
  •  '$' is also available on a QWERTY keyboard and many other keyboards.
  • I was inspired  by JQuery
In case you have a class that has a real public interface I got you covered too. There is a companion class Noaber with  final static field $ that holds  an implementation of $. In this case you have to do a static import of Noaber.$ and prefix all calls to Noaber's functionality with '$.'.

package eu.hanskruse.trackhacks.noaber;

public final class Noaber implements $ {
 public static final $ $ = new Noaber();

 private Noaber() {
  // do nothing

Sample use of Noaber

In the code below I mixin Noaber's functionality by  "implementing"  $. 
This means I can call the methods of $  as if they where instance methods.
This saves a lot of typing.

package eu.hanskruse.trackhacks;

import java.util.function.BiFunction;
import java.util.function.Function;

import eu.hanskruse.trackhacks.noaber.$;
import junit.framework.TestCase;

public class CurryTest extends TestCase implements $ {

  * Create the test case
  * @param testName
  *            name of the test case
 public CurryTest(String testName) {
 public void testLeftCurryOnBiFunction(){
  final String expected ="42";
  BiFunction<Integer,Boolean, String> f = (x,b) -> Integer.toString((b?x:42)); 
  Function<Integer, Function<Boolean, String>> cf=leftCurry(f);
  final String actual =cf.apply(3).apply(false);
  assertEquals(expected, actual);
 public void testRightCurryOnBiFunction(){
   final String expected ="42";
   BiFunction<Integer,Boolean, String> f = (x,b) -> Integer.toString((b?x:42)); 
   Function<Boolean, Function<Integer, String>> cf=rightCurry(f);
   String actual = cf.apply(false).apply(3);
   assertEquals(expected, actual);

Why call it Noaber?

"Noaber" is the word for neighbor in the Saxon dialects spoken in the eastern parts of the Netherlands(Twents, Drents, Sallands,Gronings, Acherhoeks) and the north western part of Germany (Platdeutsch) and some parts of Poland and Danmark. The German word for Neigbours is Nachbarn. Do you see the pattern? A good neighbour helps you but does not get in your way. The same should be true for the Noaber library. That is why I call it Noaber ;)

Future work

Noaber is my structured kitchen sink of useful Java experiments. Please feel free to use it but do not expect anything.
I can add just an other interface to the '$' 's list of implements clauses when I like to do so during my train travels. I get my inspiration mainly from Javascript libraries such as JQuery, Underscore, Ramda and to some extend from .NET. 

I probably will also remove stuff or make changes.

zondag 11 september 2016

The six benefits of final

Ever since I returned to back to "the Duke side of the Force" I  am pleased when I can type a specific word of 5 letters: final.  Final means you cannot change it after it was set or defined.  In functional programming languages final is the default and usually implicit. At the cost of five characters more verbosity per declaration you get the  same six benefits functional languages give you for free. With final code is easier to:

  1. understand.
  2. maintain.
  3. document.
  4. debug.
  5. make parallel.
  6. optimize for a compiler.

In the rest of this post I will explore possible uses of the word final in Java.

Final for constants

Java has no keyword for constants but uses final. A constant in Java is defined within a class like:

public static final int ULTIMATE_ANSWER = 42; 

Constants are written in SNAKE_CASE in Java. Really something to get used to if you come from some other environment.  And yes const  like in C#, or JavaScript is more succinct. If you want to constrain the use more you can use package visibility, protected of private if you like.

In more recent versions of Java enums can be used for the same purpose if you use int values.

Final for fields

You can use final for fields. This enforces setting them in a constructor. Something like

public class DutchAddress{
  private final String street;
  private final int number;
  private final String postalCode;
  private final String city;
  public DutchAddress(String streetValue, //
    int numberValue, //
    String postalCodeValue, //
    String cityValue){
    //include some argument checking.
    this.street = streetValue;
    this.number = numberValue;
    this.postalCode = postalCodeValue; = cityValue; 
 //.. only add getters!

If I do not add a constructor or only a default constructor I get a compile error.
Using the constructor as above I am sure DutchAddress never contains uninitialized values for its fields. 

Taking care of argument sanity is something for another blog post.
 However making this constructor private and provide a factory is a possible solution if you do not want to throw exceptions in a constructor.

For the remainder of this post we assume we do not use final for the fields.

Final in method signatures

It is sometimes common practice to do argument checking on the arguments of a function and change the arguments value in the process. Something like the following.

public class DutchAddress{
  private String street = "";

  public void setStreet(String value){
    if(value == null){
      value = "";
    value = value.trim();
    this.street = value;

Now imagine you are debugging the code above somewhere in the middle, or actually a bit more complicated code that does something similar. You cannot lookup the original value of value easily.

At the cost of using final and introducing an extra variable you can be sure the original value can be seen when debugging.  I change the code as follows:

public class DutchAddress{
  private String street = "";

  public void setStreet(final String value){
    String checkedValue = value;
    if(checkedValue == null){
      checkedValue  = "";
    checkedValue =checkedValue .trim();
    this.street = checkedValue ;

Yes, I know:

  • This argument only holds for non mutable types. But a lot of my coding involves ints and Strings as arguments.
  •  I use value here as name of the argument instead of street. I think it is more DRY.
Using final is a promise to the compiler, yourself, your later self and the guy after you, that you do not play tricks with the arguments.

For a setter this is a bit verbose. I can improve on that and also lose the explicit temporary variable.

public class DutchAddress{
  private String street = "";

  public void setStreet(final String value){
    this.street = (value == null?"":value).trim();

Final in the body of a method

Final in the body of a method works a bit like a const but it can change on every invocation influenced by the arguments or the state of the object.

public class DutchAddresses{
  private final List<DutchAddress> addresses= //
    new ArrayList<DutchAddress>;

  public void addVerifiedAddress(final String street, //
     final  intnumber, //
     final String postalCode, //
     final String city){
  //we assume the arguments are fine for now ;)
  final DutchAddress address=new Address(street,number,postalCode,city);
  // do some amazing verifications here

  //we are certain the same address object we created earlier is added.
  //Since DutchAddress is mutable it's fields may have changed.


Here I am sure that the reference to address never changes within the current call of the method once it is set.

Final in for loops

Java has a special kind of for loop that is known as an foreach loop in other languages.

It has the following form:
for (DutchAddress address :addresses){
 //do something with the address

Unfortunately the reference to address is modifiable like with the method arguments without final keyword. You can do this.

for (DutchAddress address :addresses){
 //do something with the address
 address = new Address("Noordeinde",68,"2514GL","Den Haag");
 //do some more with the overwritten address

The guy living at the newly instantiated address is lucky for multiple reasons! One reason is that he never ends up in our address list.  To prevent such error superhero final rescues us.

for (final DutchAddress address :addresses){
 //do something with the address
 address = new Address("Noordeinde",68,"2514GL","Den Haag"); // compile error
 //do some more with the overwritten address

Every iteration an address is retrieved from the list of adresses which cannot be changed in the body of the loop. However since an instance of DutchAddress is mutable its fields can be changed.

Final at the class level

public final class DutchAddress{

This means you never intended the class to be extended. It is a clear message to your later self and the guy after you in the role of maintainer. It also allows a compiler to do some optimizing.

Making a class extensible, aka non final places great responsibility on the base class designer. The guy extending your code may not have access to the source. So you must make it bullet proof and document the extension points very well. If someone is using extended code and it breaks in the base class who is to blame?

Final at the method level

Final at the method level is similar to final at the class level. It forbids overriding a method.
Since I usually make classes final I haven't used it in Java or the similar 'sealed' construct in C#. A crazy thing you can do to test your IDE with final is making an abstract method final. At least Eclipse gives the wrong advice about making the method public or protected. 

public class DutchAddress{
 final boolean isValid(){

Final in try with resources clause

Since Java 7 try /catch is extended with the option to declare resources that get released when they get out of scope. This is similar to a .NET using clause  but with the added benefit of being able to catch Exceptions. However in Java the references to the resources are mutable where they are 'final' in .NET. However you can make them immutable by declaring the resources final. Resources must implement the interface java.lang.AutoCloseable


try( final MyAutoCloseableResource reader=new MyAutoCloseableResource()){
 //... do something
}catch(Exeption ex){
//... log something and do some exception handling
//.. here is an implicit finally clause closes the autocloseable if it is not null.

The added final makes sure we dot leak resources in the body of the try.

Disadvantages of final

There are some disadvantages on final. First of all, it is not DRY because final is not the default in Java. You have to use it again and again to enforce it. Code checking tools like findbugs or Sonarqube may help to discover violations and or enforce it.

Second method signatures may become very long with multiple arguments. 
It becomes worse if you also add argument validating decorators which will be the topic of another post.  e.g. a method signature like

public void addAddress(@NonNull final String streetValue, //
  @IntRange(from=1,to=9999) final int number, //
  @NonNull String postalCodeValue, //
  @NonNull String city){

Third, a trick to test classes is to subclass them and override methods. Sorry you better use a proxy for that.

 Finally, making fields final in existing code is usually undoable without major API redesign.


I recommend making:
  • classes final that you never intend to extend.
  • loop variables in a 'foreach' style for loop final.
  • arguments of methods final.
  • declared variables in methods final as much as possible.
I think making fields final is hard. It goes against the Java Beans Idea and requires additional methods to make it usable by other programmers. In existing code it is not doable but perhaps your team can agree upon doing it on new code.


'Finally' is another nice keyword out of the scope for this blog post.
Yes I know about using specific types for street and postal code but that is out of scope too.
If you are interested in that, read Scott Wlaschin's excellent series on Desiging with types.
Also available as video conference talk via his website. Enforcing that style in an existing codebase may be an "interesting" exercise. In a next post I try doing that a bit using decorators.
  • What's your favorite keyword or language feature and why?
  • What is a valid use for final at the method level?
  • What is the maximum number of arguments you allow in a method?
  • What is the maximum number of characters you allow in a line of code?
  • Tabs or spaces?

What's Next

  • Decorators to constrain types.
  • Streams.
  • Automatic Getter/Setter and more testing for Beans.

What's wrong with Java Beans?

TLDR: This is my rant against the concept of Java Beans.
Im my previous post I mentioned that beans are a great way to compose a solution out of smaller parts. I also mentioned writing generators for the boilerplate of a bean. Such generators are now standard in modern IDEs.  Sadly one important thing Java does not have is real properties. Syntactic sugar for properties is present in  languages like: C#,  F#, Scala, Kotlin and Ceylon.

Programming is a way of communicating your ideas:
  1. To yourself
  2. To your later self
  3. To your coworkers
  4. To the unknown people that have to maintain your crap(often politely called legacy).
  5. To outside programmers, aka customers, if you are writing a library.
In daily life we use  words, sentences paragraphs etc to express our ideas. For a frequently used idea we use  single word as  succint way of communication, a shared understanding.

Java Beans are a little bit more verbose. They use sentences to express  simple ideas:
  • For just a simple object holding a Person's details you have to add fields, getters with comments and setters with comments. 
  • Supporting one field requires at least 15 lines of code.
  • These lines need tests too! 
  • This code needs to be maintained by you, your future self, coworkers, and the guy after you.  Customers have to read about the getters and the setters from the Javadocs.
  • These lines clutter your codebase.
When Microsoft copied  improved upon Java by inventing C# they did at least one thing right. They introduced syntactic sugar for properties. Nowadays a simple property in C# is just one line, almost like a public field.  Example:

public string Name{get; set;}="John Doe";

That is:
  • 14 lines less to be read. No clutter!
  • One line to be maintained by you.
  • One line to be maintained by your future self.
  • One line to be maintained by coworkers.
  • One line to be maintained by the guy after you.
  • Much less documentation to be written.
  • Less tests to write.
  • More time to break other stuff.
Languages such as F#, Scala, Kotlin and Ceylon even improved this further. A simple class definition in these languages is a one liner:

class Person(string name, string address);

Often forgotten methods

Write default constructor, the getters, setters, the related tests and the Javadoc and your beautiful bean  is ready for use? Wrong!. When your bean is used in  collections the collection framework uses equals(...) and hashCode() for sorting bean instances. If you do nothing the equals() and hashCode()  of the super class  Object  will be used. This is usually not what you want.

For debugging purposes having a custom toString() function is a nice to have,
If you add these you already  have some code to maintain and write tests for.

Unlike C#, Java does not allow operator overloading so there are no operators to overload.

 F#,  probably other languages too, even goes a bit further by also including sensible implementations for comperator functions. These functions are more important if you use Streams. To the .NET programmer: Streams are Java's way to LINQ without syntactic sugar in the language.

Ease the pain with code generation

IDEs like Eclipse come with  code generation functionality. You can:
  • generate getters and setters form fields.
  • generate a  hashCode() and equals(...) function.
  • generate a toString() function.
 In a language like F# these functions are generated by the compiler automatically. developers do not see these functions so nothing to maintain or break.

Sadly there is no support for maintenance. Maintenance when adding, changing or deleting fields to a bean, are left to the craftsmanship of the developer. This will not change in coming Java version 9.  We have to live with it for near future.

2018-02 Update: Succinctly testing and writing Java Beans

Originally I moaned about testing whether a Bean is a Bean and that it is top Java verbosity.
The last 1.5 years I have bean using Bean Matchers and Lombok to fix those issues.

Bean Matchers 

If you want to test whether the bean you created and update is a proper bean there is the handy Bean Matcher library, that can be used in unit tests. It allow you to check for  proper getters, setters, default constructor, hashCode() and equals().  Bean Matchers build on top of Hamcrest Matchers and can be used within Junit tests. You still may need to write a custom matcher that utilizes some reflection to check all classes in "that domain model package".


If you grew tired of writing "Get me, set me I am a bean"  you can use the Lombok toolkit and library
that allows you to define a class with just fields and some special annotations to get standard bean behavior.

Disadvantage, you have to do some Maven trickery to get proper documentation generated.

Lombok comes with  a plugin for Eclipse and other IDEs to ensure that it does not scream about missing getters/setters and also make "Intellisense" for generated code work.

Other goodies it as are:

  •  A @UtilityClass generates a private constructor that throws a NotSupportedException  for classes with only static methods. Only problem is, how to teach checkstyle not to scream about classes missing a default constructor that are decorated with @Utilityclass.
  •  Local variable type inference using a  var "keyword".  This may come to Java 10 according to JEP 286.  Basically this means you do not have to write a type twice when doing an assignment, eg MyType x = new MyType(); becomes var x = new MyType();  This may be especially useful when using java.util.streams in combination with  deeply nested generics, e.g. the case where you do not care about Stream<Foo<Buzz<Bar>>>. Local Type inference is already present in in C# 3.0 since 2007. It might come to Java in 2018... In .NET it is used often when using LINQ, a language extension equivalent to Java's java.util.streams but less verbose.