Java Basics

1.1   The structure of a Java class and source code file

1.1.1       Structure of a Java class

A class can define multiple components for example:

  • Package statement
  • Import statement
  • Comments
  • Class declarations and definitions
  • Variables
  • Methods
  • Constructors

1.1.1.1       Package Statement

All Java classes are part of a package; if a class is not defined in a named package it becomes part of a default package, which doesn´t have a name. If a class includes a package statement, it must be the first statement in the class definition (it cannot appear within a class declaration or after the class declaration) and if present, it must appear exactly once in a class:

package certification;
//should be the first statement in a class

class Course{
}

1.1.1.2 Import Statement

Classes and interfaces from the same package can use each other without prefixing the package name. But to use a class or interface from another package, the import statement can be used:

package University;
import certification.ExamQuestion;
// import must be placed after the package

class AnnualExam{
     examQuestion eq;
}

The import statement follows the package but precedes the class declaration.

1.1.1.3 Comments

The comments in Java code can be placed at multiple places in a class. To place multiline comments, start with /* and end with */ . End-of-line comments start with // and are placed at the end of a line of code. Comments can be placed before the package statement.

/**
* @author JRamirez // first name initial + last name End-of-line within a multiline
* @version 0.0.2
*
* Class to store the details of a monument
*/
package uni; // package uni End-of-line comment

class Monument {
     int startYear;
}

1.1.1.4 Class Declaration

Components of a class declaration:

  • Access modifiers
  • Nonaccess modifiers
  • Class name
  • Name of the base class, if the class is extending another class
  • All implemented interfaces, if the class is implementing any interfaces
  • Class body (class fields, methods, constructors), included within a pair of curly

braces, {}

Example:

public final class Runner extends Person implements Athlete {}

1.1.1.5 Compulsory and optional elements of a class:

Compulsory

  • Keyword class
  • Name of the class
  • Class body, marked by the opening and closing curly braces, {}

Optional

  • Keyword class Access modifier, such as public
  • Nonaccess modifier, such as final
  • Keyword extends together with the name of the base class
  • Keyword implements together with the name of the interfaces being implemented

1.1.1.6 Class Definition

The use of a class is to specify the behavior and properties of an object using methods and variables. It is a design from which an object can be created.

1.1.2       Structure and components of a Java source code file

A  Java  source code  file  is  used  to  define  classes  and  interfaces.  All your Java code should be defined in Java source code files (text files whose names end with .java)

1.1.2.1   Definition of interfaces in a Java source code file

An interface is a grouping of related methods and constants, but the methods in an

interface cannot define any implementation.

interface Controls {
     void changeChannel(int channelNumber);
     void increaseVolume();
     void decreaseVolume();
}

1.1.2.2 Definition of single and multiple classes in a single java source code file

A single class or interface can be defined in a single Java source code or multiple classes and interfaces can be within the same source code. The classes and interfaces can be defined in any order of occurrence in a Java source code file. If a public class or interface is defined, its name should match the name of the Java source code file.

1.1.2.3  Application of package and import statements in Java source code files

When an import or package statement is used within a java source code file, it applies to all classes and interfaces defined in that code.

1.2 Executable Java applications

1.2.1    Executable Java classes versus nonexecutable Java clases

An executable Java class is a class which, when handed over to the Java Virtual Machine, starts its execution at a particular point in the class in the main method. A nonexecutable class doesn’t have it. The programmer designates an executable class from all of the files of an application.

1.2.2  Main method

The first requirement in creating an executable Java application is to create a class with  a  method  whose  signature  (name  and  method  arguments)  match  the main method.

public class HelloExam {
         public static void main(String args[]) {
         System.out.println("Hello exam");
    }
}

This main method should comply with the following rules:

  • The method must be marked as a public method.
  • The method must be marked as a static method.
  • The name of the method must be main.
  • The return type of this method must be void.
  • The method must accept a method argument of a String array or a variable argument of type String

The keywords public and static can be interchanged:

public static void main(String[] args)

static public void main(String[] args)

1.3       Java Packages

1.3.1       The need for packages

Packages are used to group classes and interfaces, they also provide protection and namespace management. Subpackages can also be created within the packages.

1.3.2       Defining classes in a package using the package statement

//The first statement in a class or interface must be the package statement:

package certification;

class ExamQuestion {

     //..code

}

Rules about packages:

  • Per Java naming conventions, package names should all be in lowercase.
  • The package and subpackage names are separated using a dot (.).
  • Package names follow the rules defined for valid identifiers in Java.
  • For packaged classes and interfaces, the package statement is the first statement in a Java source file (a .java file). The exception is that comments can appear before or after a package statement.
  • There can be a maximum of one package statement per Java source code file (.java file).
  • All the classes and interfaces defined in a Java source code file will be defined in the same package. There is no way to package classes and interfaces defined within the same Java source code file in different packages.

1.3.2.1       Directory Structure and Package Hierarchy

The hierarchy of the packaged classes and interfaces should match the hierarchy of the directories in which those classes are defined.

1.3.3       Using simple names with import statements

For using classes and interfaces in other classes of your code, there are two options, using the fully qualified name or using the import statement with a simple name of the class or package.

import1


package office;

 class Cubicle {

     home.LivingRoom livingRoom;

}

package office;

import home.LivingRoom;

class Cubicle {

     LivingRoom livingRoom;

}

1.3.4       Using packaged classes without using the import statement

By using its fully qualified name, a class or interface can be used without an import statement.


class AnnualExam {

     certification.ExamQuestion eq;

}

This is often used when there are multiple classes and interfaces with the same name, because the import statement cannot be used in that case.


class AnnualExam {

     java.util.Date date1;

     java.sql.Date date2;

}

1.3.5       Importing a single or all members of a package

By using an asterisk, all the public classes, members and interfaces of a package can be imported at once.


import certification.*;

 class AnnualExam {

     ExamQuestion eq;

     MultipleChoice mc;

}

Importing a class in Java doesn’t add to the size of the file.

1.3.6       Importing Recursively

By using an asterisk, classes from a subpackage are not imported, only classes from the main package.

1.3.7       Default Package Import

If no explicit package is defined for classes or interfaces, they are imported in the default package automatically in all the classes and interfaces in the same directory.


class Person {

     // code

}

class Office {

     Person p;

}

A class from a default package can’t be used in any named packaged class.

1.3.8 Static Imports

To import an individual static member of a class or all its static members, the import static statement must be used.

package certification;

public class ExamQuestion {

     static public int marks;

     public static void print() {

          System.out.println(100);

     }

}
package university;

import static certification.ExamQuestion.marks;

class AnnualExam {

     AnnualExam() {

           marks = 20;

      }

}

//Importing all of the static members:

package university;

import static certification.ExamQuestion.*;

class AnnualExam {

     AnnualExam() {

          marks = 20;

          print();

     }

}

1.4       Java Access Modifiers

1.4.1       Access Modifiers

Access modifiers control the accessibility of a class or interface and its members, by other classes and interfaces.

They can be applied to classes, interfaces, and their members (instance and class variables and methods). Local variables and method parameters can’t be defined using access modifiers.

Java defines four access modifiers:

  • public(least restrictive)
  • protected
  • default
  • private(most restrictive)

1.4.3       Public Access Modifier

Classes and interfaces defined using the public access  modifier  are  accessible  across  all  packages,  from  derived  to  unrelated classes.

1.4.4       Protected Access Modifier

Classes and interfaces defined using the protected access modifier are accessible to classes and interfaces in the same package and all derived classes even in separate packages. They cannot be accessed by unrelated classes in other packages.

1.4.5       Default Access (package access)

Classes and interfaces defined without any explicit access modifier are defined with package accessibility (default accessibility). They can only be accessed by classes and interfaces defined in the same package.

1.4.6       Private Access Modifier

The members of a class defined using the private access modifier are accessible only to themselves. Private members are not accessible outside the class they are defined.

1.5       Nonaccess Modifiers

1.5.1       Abstract Modifier

When added to the definition of a class, interface, or method, the abstract modifier changes  its  default  behavior.

1.5.1.1       Abstract Class

When  the abstract keyword  is  prefixed  to  the  definition  of  a  concrete  class,  it changes it to an abstract class. An abstract class can’t be instantiated. An abstract class can be defined without any abstract methods but a concrete class cannot define an abstract method.

1.5.1.2       Abstract Interface

An interface is an abstract entity by default. The Java compiler automatically adds the keyword abstract to the definition of an interface.

1.5.1.3       Abstract Method

An abstract method doesn’t have  a  body.  Usually, an abstract method is implemented by a derived class.

1.5.1.4       Abstract Variables

No type of variable can be defined as abstract.

1.5.2       Final Modifier

The keyword final changes the default behavior of a class, variable, or method.

1.5.2.1       Final Class

A class defined final cannot be extended by other classes.

1.5.2.2       Final Interface

No interface can be marked as final.

1.5.2.3       Final Variable

A final variable can only be assigned a value once.

1.5.2.4       Final Method

A final method defined in a base class cannot be overridden in a derived class.

1.5.3       Static Modifier

Can be applied to the definitions of variables, methods,  classes,  and  interfaces.

1.5.3.1       Static Variables

They are common to all instances of a class and are not unique. They are shared by all the objects of the class. Static variables may be accessed even when no instances of a class have been created.

1.5.3.2       Static Methods

Static methods aren’t associated with objects and can’t use any of the instance variables of a class. They can be used to use or manipulate static variables of a class.

Nonprivate static variables and methods can be inherited by derived classes and can be redefined within the derived class.

1.5.3.3       What can a static method access?

Non-static variables and methods can access static variables and methods. Static methods and variables cannot access the instance methods of a class.

 

 

 

This entry is the first part of of a series on Java Basics, for further reading:
Java Basics II
Java Basics III

Java 8 Streams and JPA

Since the definition of the JPA Standard predates the release of Java 8 it is not surprising that the JPA API is only based on collections. There is no way to obtain a Java 8 Stream out of a query object.

For those out there using Hibernate as their JPA provider there is an interesting way to create a stream for your JPQL queries.

Hibernate Scrollable Results

Hibernate supports many more features than those offered by the JPA Standard only. Hibernate’s Query class allows us to obtain an iterator-like object for a JQPL query. This iterator-like class is named ScrollableResults.

You can see a great example of this feature in this blog post about Reading Large Result Sets with Hibernate and MySQL. I have taken the liberty of copying one of their examples:

Query query = session.createQuery(query);
query.setReadOnly(true);
query.setFetchSize(100);
ScrollableResults results = query.scroll(ScrollMode.FORWARD_ONLY);
while (results.next()) {
   Object row = results.get();
   // process the entity here
}
results.close();

Creating an Iterator Wrapper around Scrollable Results

Let’s take this a bit further now by implementing a Java Iterator wrapper around the Hibernate’s scrollable results object as shown below:

class ScrollableResultIterator<T> implements Iterator<T> {
   private final ScrollableResults results;
   private final Class<T> type;

   ScrollableResultIterator(ScrollableResults results, Class<T> type) {
      this.results = results;
      this.type = type;
   }

   @Override
   public boolean hasNext() {
      return results.next();
   }

   @Override
   public T next() {
      return type.cast(results.get(0));
   }
}

Gaining Access to Hibernate Session through JPA Entity Manager

As you can see the examples above use a Hibernate session object to obtain an instance of a Hibernate query object. Supposing we are using JPA, we typically have access to an EntityManager, but not to any particular implementation objects of the underlaying provider.

To gain access to the Hibernate’s Session object we can use a special method in the entity manger.

Session session = entityManager.unwrap(Session.class);

Be warned that at this point we are escaping from the safety of vendor agnostic code. In other words, if we ever wanted to use another provider like OpenJPA or EclipseLink, we would be forced to find a different alternative to implement our code here since those other providers won’t offer anything like Hibernate’s Session and ScrollableResults.

From Iterators to Spliterators to Streams

Our next step consists in obtaining a Java 8 stream out of this iterator. Lukas Eder recently wrote an interesting article about the difficulties to obtain a stream out of an iterable object which will be pretty handy here.

To achieve our goal we now need to use two utility classes in Java 8 named StreamSupport and Spliterators.

For instance, we could take an iterator, like the one we defined above and transform it into a Spliterator by doing:

private Spliterator<T> toSplitIterator(ScrollableResults scroll, Class<T> type){
   return Spliterators.spliteratorUnknownSize(
      new ScrollableResultIterator<>(scroll, type),
         Spliterator.DISTINCT | Spliterator.NONNULL | 
         Spliterator.CONCURRENT | Spliterator.IMMUTABLE
      );
}

This Splititerator is an intermediate product that we can now use to create a Java 8 stream out of it:

StreamSupport.stream(spliterator, false);

At this point we have built enough to create our first stream out of a JPQL query. We can do it as follows:

public Stream<T> getResultStream(
      String sql, 
      Integer fetchSize, 
      Map<String,Object> parameters) 
{
   Query query = session.createQuery(sql);
   if (fetchSize != null) {
      query.setFetchSize(fetchSize);
   }
   for (Map.Entry<String, Object> parameter : parameters.entrySet()) {
      query.setParameter(parameter.getKey(), parameter.getValue());
   }
   query.setReadOnly(true);
   ScrollableResults scroll = query.scroll(ScrollMode.FORWARD_ONLY);
   return StreamSupport.stream(toSplitIterator(scroll, type), false)
            .onClose(scroll::close);
}

A JPA Stream API

We can do a little bit better by defining the basics of the type of query object we are currently missing in JPA Standard API:

public interface StreamQuery<T> {
   Stream<T> getResultStream();
   StreamQuery<T> setParameter(String name, Object value);
   StreamQuery<T> setFetchSize(int fetchSize);
}

And putting together all we have learned so far we could create this implementation of our new StreamQuery interface:

public class HibernateQueryStream<T> implements StreamQuery<T> {

   private final Session session;
   private final String sql;
   private final Class<T> type;
   private final Map<String, Object> parameters = new HashMap<>();
   private Integer fetchSize;

   public HibernateQueryStream(
      EntityManager entityManager, 
      String sql, 
      Class<T> type) 
   {
     this.session = entityManager.unwrap(Session.class);
      this.sql = sql;
      this.type = type;
   }

   @Override
   public StreamQuery<T> setParameter(String name, Object value) {
      parameters.put(name, value);
      return this;
   }
   
   @Override
   public StreamQuery<T> setFetchSize(int fetchSize) {
      this.fetchSize = fetchSize;
      return this;
   }

   @Override
   public Stream<T> getResultStream() {
      Query query = session.createQuery(sql);
      if (fetchSize != null) {
         query.setFetchSize(fetchSize);
      }
      query.setReadOnly(true);
      for (Map.Entry<String, Object> parameter : parameters.entrySet()) {
         query.setParameter(parameter.getKey(), parameter.getValue());
      }
      ScrollableResults scroll = query.scroll(ScrollMode.FORWARD_ONLY);
      return StreamSupport.stream(toSplitIterator(scroll, type), false)
               .onClose(scroll::close);
   }
   
   private Spliterator<T> toSplitIterator(ScrollableResults scroll, Class<T> type){
      return Spliterators.spliteratorUnknownSize(
         new ScrollableResultIterator<>(scroll, type),
            Spliterator.DISTINCT | Spliterator.NONNULL | 
            Spliterator.CONCURRENT | Spliterator.IMMUTABLE
      );
   }

   private static class ScrollableResultIterator<T> implements Iterator<T> {

      private final ScrollableResults results;
      private final Class<T> type;
      
      ScrollableResultIterator(ScrollableResults results, Class<T> type) {
         this.results = results;
         this.type = type;
      }
      
      @Override
      public boolean hasNext() {
         return results.next();
      }
      
      @Override
      public T next() {
         return type.cast(results.get(0));
      }
   }
}

The Repository Layer

On top of this component we can now build our repository layer.

@Repository
public class StreamRepository {

   @PersistenceContext(unitName="demo")
   private EntityManager entityManager;

   public Stream<Order> getOrderHistory(String email) {
      String jpql = "SELECT o FROM Order o WHERE o.customer.email=:email";
      StreamQuery<Order> query = new HibernateQueryStream<>(
          entityManager, 
          jpql, 
          Order.class
      );
      return query.getResultStream();
   }
}

And from here the rest is a piece of cake:

orderRepository.findOrderHistory(email)
   .filter(order -> order.total() > 100)
   .map(Order::getOrderLines)
   .flatMap(List::stream)
   .map(OrderLine::getTotal)
   .reduce(0, (x,y) -> x + y);

It is important to highlight that the Hibernate session must be alive by the time we actually consume the stream, because it is at that point that the entities will be mapped. So, make sure that wherever you consume the stream the Hibernate session or you entity manager context is still alive.

Further Reading

Functional Programming with Java 8 Functions

Edwin Dalorzo I have finally had the opportunity to work in a couple of projects being entirely developed with Java 8 and during the past months I’ve experienced, first hand, many of the new functional programming features in the language. So I decided to write a series of articles about some of these things I’ve being learning and how some of the well known functional programming constructs can be translated into Java 8.

Preliminaries

Ok, let’s start with something simple. The following is a lambda expression (i.e. an anonymous function) that takes an argument x and increments it by one. In other words a function that receives, apparently an integer, and returns a new incremented integer:

x -> x + 1

And what is the type of this function in Java?

Well, the answer is that it depends. In Java the same lambda expression could be bound to variables of different types. For instance, the following two are valid declarations in Java:

Function<Integer,Integer> add1 = x -> x + 1;
Function<String,String> concat1 = x -> x + 1;

The first one increments an integer x by one, whereas the second one concatenates the integer 1 to any string x.

And how can we invoke these functions?

Well, now that they are bound to a reference we can treat them pretty much like we treat any object:

Integer two = add1.apply(1); //yields 2
String answer = concat1.apply("0 + 1 = "); //yields "0 + 1 = 1"

So, as you can see every function has a method apply that we use to invoke it and pass it an argument.

And what if I already have a method that does that, can I use it as a function?

Yes, since an alternative way to create functions is by using methods we had already defined and that are compatible with our function definition.

Suppose that we have the following class definition with methods as defined below:

public class Utils {
   public static Integer add1(Integer x) { return x + 1; }
   public static String concat1(String x) { return x + 1; }
}

As you can see the methods in this class are compatible with our original function definitions, so we could use them as “method references” to create the same functions we did before with lambda expressions.

Function<Integer,Integer> add1 = Utils::add1;
Function<String,String> concat1 = Utils::concat1;

These two are just the same thing as the ones we did before.

High Order Programming

The cool thing about functions is that they encapsulate behavior, and now we can take a piece of code, put it into a function and pass it around to other functions or methods for them to use it. This type of functions that operate on (or produce new) functions are typically called high order functions and the programming style based on exploiting this powerful feature is called, unsurprisingly, high order programming.

About Functions that Create Functions

Let’s see a couple of examples of how we can do this using function objects. Let’s consider the following example:

Function<Integer, Function<Integer,Integer>> makeAdder = x -> y -> x + y;

Above we have a function called makeAdder that takes an integer x and creates a new function that takes an integer y and when invoked adds x to y. We can tell this is a high order function because it produces a new function.

Now, we use this to create our original add1 function:

Function<Integer,Integer> add1 = makeAdder.apply(1);
Function<Integer,Integer> add2 = makeAdder.apply(2);
Function<Integer,Integer> add3 = makeAdder.apply(3);

With our new high order function, however, we could also create add2, add3, ..., addn, right?

Can’t we define this in a simpler way as we did before with the Utils class methods?

Yes, we can. Consider the following addition to the Utils class:

public class Utils {
    public static Function<Intger, Integer> adder(Integer x) {
       return y -> x + y;
    }
}

This signature is a bit simpler to read than that in our lambda expression, but as you can see it is pretty much the same thing. The function continues to receive the same number and type of arguments and continues to return the same type of result.

We can now use this simpler function factory to create our makeAdder and add1 functions again:

Function<Integer, Function<Integer,Integer>> makeAdder = Utils::adder;
Function<Integer,Integer> add1 = makeAdder.apply(1);

And there you have it, this is exactly the same thing as before.

About Functions that Receive Functions as Arguments

Let’s suppose we had the following two functions defined:

Function<Integer,Integer> add1 = x -> x + 1;
Function<Integer,Integer> mul3 = x -> x * 3;

Now, naively, we could invoke this two functions together to increment and multiply a number by 3, right?. Like this:

Integer x = 10;
Integer res = mul3.apply(add1.apply(x)); //yields 33

But what if we created a function that did both things instead?

Consider the following pseudocode:

(f,g) -> x -> g( f(x) )

This would be a function that takes two other unary functions and creates yet another function that applies the original two in certain order. This is a classical example of what is called function composition.

In some languages there is even an operator to compose two functions in this way:

h = f o g

Where o would be a binary operator that would compose functions f and g pretty much as we did in pseudocode above and produce a new function h.

How can we do function composition in Java?

I can think of two ways to do this in Java, one more difficult than the other. Let’s start with the more difficult first, because that will let us appreciate the value of the simpler solution later on.

Function Composition Strategy 1

First, we must start by realizing that the function in pseudocode above is a binary function (i.e. a function that receives two arguments). But all our examples so far have dealt only with unary functions.

It would seem this is not important, but in Java it is, since functions of different arities have different target functional interfaces. In Java, a function that receives two arguments is called BinaryOperator.

For instance, using a BinaryOperator we could implement a sum operator:

BinaryOperator<Integer> sum = (a,b) -> a + b;
Integer res = sum.apply(1,2); // yields 3

Well, just as easily we could implement the compose operator, right? Only that in this case, instead of two simple integers, we receive two unary functions:

BinaryOperator<Function<Integer,Integer>> compose;
compose = (f,g) -> x -> g.apply(f.apply(x));

Now we can easily use this to fabricate a compound function that adds 1 and multiplies by 3, one after the other.

Function<Integer,Integer> h = compose.apply(add1,mul3);
Integer res = h.apply(10); //yields 33	

And now we can beautifully, and in really simple way, combine two unary integer functions.

Function Composition Strategy 2

Now, function composition is something so common that it would have been a mistake if the Java Expert Group would have not considered it in their API design, and so, to make our lives simpler, all Function objects have a method called compose that allows us to very easily compose two functions together.

The following code produces the exact same result as above:

Function<Integer,Integer> h = mul3.compose(add1);
Integer res = h.apply(10);	

Partial Function Application or Currying

In most functional programming languages it is possible to create partially applied functions. That is, if a function is receiving multiple arguments, we can partially invoke the function providing just a few arguments and receive a partially applied function out of it. This is typically called currying.

Although you have not noticed it, we have already covered that in this article, but now we are going to make it much more evident 🙂

So, consider the following pseudo code

sum = x -> y -> x + y

Then we say that sum is a function that accepts one parameter x and fabricates another anonymous function that in turn accepts one parameter y that, when invoked, sums x and y.

In many functional programming languages a construct like this can be invoked as if this was just one simple function by doing:

sum 10 5 //yields 15

But the truth is that this is just syntactic sugar to do:

sum(10)(5) //yields 15

Since sum is a function that returns a function.

The beauty of this idiom is that now we could partially apply sum:

plus10 = sum 10

And now plus10 is a partially applied function of sum. Can you see now where we had already talked about this?

plus10(5) //yields 15

Can we do this with Java?

The truth is that we have already done it above, we just probably did not notice. Unfortunately, in Java we do not have the syntactic sugar that some other language have, and therefore this is a bit more verbose:

Function<Integer,Function<Integer,Integer>> sum = x -> y -> x + y;

Well, you can see sum is declared in a “currified” way. And now we can partially apply it:

Function<Integer, Integer> plus10 = sum.apply(10);
Integer res = plus10.apply(5); //yields 15

Unary, Binary, Ternary and n-ary Functions

So, as mentioned above, Java uses different functional interfaces for different function arities. And so Function<T,R> is a functional interface for any unary function where the domain and the codomain of the function may be of different types.

For instance, we could define a function that receives a string value and parses it as an integer:

Function<String,Integer> atoi = s -> Integer.valueOf(s);

But most of our examples above are for integer functions whose argument and return value are of this same type. For those cases we could alternatively use the UnaryOperator<T> instead. This is just a Function<T,T>.

Thus, some our declarations above could be slightly simplified with this functional interface:

UnaryOperator<Integer> add1 = n -> n + 1;
UnaryOperator<String> concat1 = s -> s + 1;
Function<Integer, UnaryOperator<Integer>> sum = x -> y -> x + y;
UnaryOperator<Integer> sum10 = sum.apply(10);

I have already written another article that explains Why Java 8 has Interface Pollution like this in case you are interested in an explanation.

Value Types and Primitive Type Functions?

Evidently using a type like Integer incurs into the costs of boxing and unboxing when our functions have to deal with a primitive type like int.

As you know, Java does not support value types as type arguments in generic declarations, so to deal with this problem we can use alternative functional interfaces like ToIntFunction, IntFunction or IntUnaryOperator.

Or we can define our own primitive function.

interface IntFx {
	public int apply(int value);
}

Then we can do:

IntFx add1 = n -> n + 1;
		
IntFunction<IntFx> sum = x -> y -> x + y;
IntFx sum10 = sum.apply(10);
sum10.apply(4); //yields 14

Similar functional interfaces can be found in the Java API for types double and long as well. This topic is also covered in the alternative article mentioned above about interface pollution.

And that’s it for the time being. I hope that in a future article I can take this a bit further and show some practical applications derived from my experience in actual projects.

Further Reading

JSApps 101: Introduction To JavaScript Applications

Introduction

So, JavaScript… Again! After some months away from this blog, I am back with a new series of articles related to the incredible, magical and mysterious world of JavaScript. More specifically, JavaScript applications. Have you ever heard of AngularJS, Backbone, Knockout JS, LESS and such things? Read on, this might interest you.

We have used, at some point of our Internet life, some awesome websites, such as Facebook, Github, Spotify, and others; where everything is asynchronous, the user interface is super-responsive and couldn’t be closer to a desktop application in matters of functionality, all of this right in our browser. Less that some people imagine is that these sites owe their slickness mainly to our good old friend in battle: JavaScript; oh so many developers underestimate JavaScript. This article series will dive you into the basis of how these kind of powerful JavaScript applications are built and over what technologies and frameworks, so let’s move forward into some basic concepts.

Server-side v.s. Client-side

So, what in the world is a JavaScript application anyways? Well, as you might know, the traditional way a web application works is that you have a set of specialized frameworks and tools (name it ASP.NET, PHP, Spring Framework) running server-side; when someone requests a page from the server, it responds with an HTML document, usually resulting of the parsing of a server-side template (a PHP, ASPX or the alike) and then bound to data coming from the database. Those templates being processed by the server usually contain special syntax and directives that instructs the server’s templating engine how to bind data to it and produce a valid HTML document; some might recall these as the dreaded “server tags.”

Standard Server Request/Response

 

Some server-side technologies like ASP.NET use “controls” or helpers that assist in the rendering of complex user interface components into HTML like grids, forms and charts bound to dynamic data coming from the database. Each time these components need to be refreshed, they do it through asynchronous AJAX requests or a full-page refresh (known as a server post-back, which all users love, or not). While these are handy for speed-building of web solutions, is not as efficient as pure-JavaScript graphical components.

ASP.NET WebControls

Often, JavaScript is used to manipulate the structure of the resulting HTML document, get the value of a field, and other simple tasks dynamically on the browser (better known as “the client side”) without the need of refreshing the page. But as popularity of JavaScript arise (let’s thank jQuery for that), it is being delegated with more and more complex stuff like rendering templates into HTML, so it is done client-side and not server-side; binding of server data, validation of user input and controlling page flow. This being said, a JavaScript application is basically a “client” that runs on the browser, thanks to the leverage of technologies such as JavaScript, HTML5 and CSS3. All of the UI logic is controlled client-side, right there in the browser.

Structure of a JavaScript App

Before moving on, it is true that this requires a paradigm shift if you have been working on traditional web applications for a while, specially if you have never used a Model-View-Controller approach. If you have never heard of, or used Model-View-Controller, I’m afraid there is some reading to be done before continuing. But hey! You can start here, or else you can continue reading this incredibly sexy article.

As mentioned before, a JavaScript application, or JS App (patent pending), usually follows an MVC approach. It is composed of several “views”, which are usually HTML documents or templates; “controllers” that handles validation, logic flow and communications with the server; and “models” that contains the data to be displayed and bind on the views. As you might notice, is a pretty similar model to server-side technologies like ASP.NET MVC and Spring MVC, just that the entire presentation layer is being moved to the browser, specifically into JavaScript components. We’ll analyze advantages of this later on.

With all the presentation logic being handled by the browser, where does the data we see on the UI coming from? It comes from the server; that is the real use we have for it. The controller at the browser is the one responsible for this channel of communication; it retrieves data from the server each time the user pages through a data grid and sends data to it whenever the user needs to create or edit information. JS Apps work in a similar way to smartphone apps, in which a client runs on the phone locally and it uses data coming from a remote server. In fact, there are specialized build tools, like PhoneGap, that creates applications to be installed on a smartphone from HTML/JS/CSS3 sources.

JS App Structure

Pros & Cons

While JS Apps goes far off any conventional use of a browser, it offers several advantages:

  • Rendering of pages and templates is done by the browser in the client computer, taking advantage of the client computer’s processing power and leaving less workload on the server.
  • Better user interface responsiveness, since all calls to the server are asynchronously and JavaScript UI components are usually lightweight.
  • Completely decoupled from the server logic.
  • Less calls to the server, since it is only accessed to get data and not pages in every possible display state it might have.
  • High separation of concerns, since the server ONLY handles business logic and not UI-related validation and such.
  • Easy unit testing of the user interface and UI logic.

Also, it might represent some disadvantages:

  • Lots, lots and LOTS of JavaScript to be written; we all know it can be a pain to maintain if not properly done.
  • The learning curve is quite step, since most people is used to jQuery and DOM manipulation but not to JavaScript controllers, models and pseudo-classes; let alone advanced concepts like JavaScript dependency injection.
  • Data incoming to the server needs to be double-checked in order to prevent bad information sent by tampered JavaScript components.

Sounds Kind of Interesting, Now What?

OK, now that you might get the picture of what a JS App might look like and its advantages, so the next step would be to analyze the technologies and frameworks you could use, getting your hands dirty along the way so you can start developing this kind of applications.

In the following articles we will move into learning JavaScript libraries like AngularJS, for client-side Model-View-Controller; RequireJS, a library that allows asynchronous loading of JavaScript files on-demand; usage of Twitter Bootstrap, to build nice HTML5-compliant user interfaces; and ultimately how to structure your server application as a solid data provider for your JavaScript application.

So, stay tuned for more articles! 😀

 

Memoized Fibonacci Numbers with Java 8

Edwin DalorzoSince today is Fibonacci Day, I decided that it would be interesting to publish something related to it.

I believe one of the first algorithms we all see when learning non-linear recursion is that of calculating a Fibonacci number. I found a great explanation on the subject in the book Structure and Interpretation of Computer Programs [SIC] and I dedicated some time to playing with the Fibonacci algorithm just for fun. While doing so I found an interesting way to improve the classical recursive algorithm by using one of the new methods (added in Java 8) in the Map interface and which I used here to implement a form of memoization.

Classical Recursive Fibonacci

In the classical definition of Fibonacci we learn that:

fib(n) = \left\{ \begin{array}{ll} 0 & \mbox{if n=0}\\1 & \mbox{if n=1}\\fibn(n-1)+fib(n-2) & \mbox{otherwise} \end{array} \right.

We program this very easily in Java:

public static long fibonacci(int x) {
   if(x==0 || x==1)
      return x;
   return fibonacci(x-1) + fibonacci(x-2);
}

Now the problem with this algorithm is that, with the exception of the base case, we recursively invoke our function twice and interestingly one of the branches recalculates part of other branch every time we invoke the function. Consider the following image (taken from SIC) that represents an invocation to fibonacci(5).

Clearly the branch to the right is redoing all the work already done during the recursive process carried out by the left branch. Can you see how many times fibonacci(2) was calculated? The problem gets worse as the function argument gets bigger. In fact this problem is so serious that the calculation of a small argument like fibonacci(50) might take quite a long time.

Memoized Recursive Fibonacci

However, there is a way to improve the performance of the original recursive algorithm (I mean without having to resort to a constant-time algorithm using, for instance, Binet’s formula).

The serious problem we have in the original algorithm is that we do too much rework. So, we could alleviate the problem by using memoization, in other words by providing a mechanism to avoid repeated calculations by caching results in a lookup table that can later be used to retrieve the values of already processed arguments.

In Java we could try to store the Fibonacci numbers in a hast table or map. In the case of the left branch we’ll have to run the entire recursive process to obtain the corresponding Fibonacci sequence values, but as we find them, we update the hash table with the results obtained. This way, the right branches will only perform a table lookup and the corresponding value will be retrieved  from the hash table and not through a recursive calculation again.

Some of the new methods in the class Map , in Java 8, simplify a lot the writing of such algorithm, particularly the method computeIfAbsent(key, function). Where the key would be the number for which we would like to look up the corresponding Fibonacci number and the function would be a lambda expression capable of triggering the recursive calculation if the corresponding value is not already present in the map.

So, we can start by defining a map and putting the values in it for the base cases, namely, fibonnaci(0) and fibonacci(1):

private static Map<Integer,Long> memo = new HashMap<>();
static {
   memo.put(0,0L); //fibonacci(0)
   memo.put(1,1L); //fibonacci(1)
}

And for the inductive step all we have to do is redefine our Fibonacci function as follows:

public static long fibonacci(int x) {
   return memo.computeIfAbsent(x, n -> fibonacci(n-1) + fibonacci(n-2));
}

As you can see, the method computeIfAbsent will use the provided lambda expression to calculate the Fibonacci number when the number is not present in the map, this recursive process will be triggered entirely for the left branch, but the right branch will use the momoized values. This represents a significant improvement.

Based on my subjective observation, this improved recursive version was outstandingly faster for a discrete number like fibonacci(70). With this algorithm we can safely calculate up to fibonacci(92) without running into long overflow. Even better, to be sure that our algorithm would never cause overflows without letting the user know we could also use one of the new methods in Java 8 added to the Math class and which throws an ArithmeticException when overflow occurs. So we could change our code as follows:

public static long fibonacci(int x) {
   return memo.computeIfAbsent(x, n -> Math.addExact(fibonacci(n-1),
                                                     fibonacci(n-2)));
}

This method would start failing for fibonacci(93). If we need to go over 92 we would have to use BigInteger in our algorithm, instead of just long.

Notice that the memozied example uses mutations, therefore, in order to use this code in a multithreaded environment we would first need to add some form of synchronization to the proposed code, or use a different map implementation, perhaps a ConcurrentHashMap, which evidently, may impact performance as well. Arguably, this would still be better than the original recursive algorithm.

Java 8 Optional Objects

Edwin DalorzoIn this post I present several examples of the new Optional objects in Java 8 and I make comparisons with similar approaches in other programming languages, particularly the functional programming language SML and  the JVM-based programming language Ceylon, this latter currently under development by Red Hat.

I think it is important to highlight that the introduction of optional objects has been a matter of debate. In this article I try to present my perspective of the problem and I do an effort to show arguments in favor and against the use of optional objects. It is my contention that in certain scenarios the use of optional objects is valuable, but ultimately everyone is entitled to an opinion and I just hope this article helps the readers to make an informed one just as writing it helped me understand this problem much better.

About the Type of Null

In Java we use a reference type to gain access to an object, and when we don’t have a specific object to make our reference point to, then we set such reference to null to imply the absence of a value.

In Java null is actually a type, a special one: it has no name, we cannot declare variables of its type, or cast any variables to it, in fact there is a single value that can be associated with it (i.e. the literal null), and unlike any other types in Java, a null reference can be safely assigned to any other reference types (See JLS  3.10.7 and 4.1).

The use of null is so common that we rarely meditate on it: field members of objects are automatically initialized to null and programmers typically initialize reference types to null when they don’t have an initial value to give them and, in general, null is used everywhere to imply that, at certain point, we don’t know or we don’t have a value to give to a reference.

About the Null Pointer Reference Problem

Now, the major problem with the null reference is that if we try to dereference it then we get the ominous and well known NullPointerException.

When we work with a reference obtained from a different context than our code (i.e. as the result of a method invocation or when we receive a reference as an argument in a method we are working on),  we all would like to avoid this error that has the potential to make our application crash, but often the problem is not noticed early enough and it finds its way into production code where it waits for the right moment to fail (which is typically a Friday at the end of the month, around 5 p.m. and just when you are about to leave the office to go to the movies with your family or drink some beers with your friends). To make things worse, the place where your code fails is rarely the place where the problem originated, since your reference could have been set to null far away from the place in your code where you intended to dereference it. So, you better cancel those plans for the Friday night…

It’s worth mentioning that this concept of null references was first introduced by Tony Hoare, the creator of ALGOL, back in 1965. The consequences were not so evident in those days, but he later regretted his design and he called it “a billion dollars mistake“, precisely referring to the uncountable amount of hours that many of us have spent, since then, fixing this kind null dereferencing problems.

Wouldn’t it be great if the type system could tell the difference between a reference that, in a specific context, could be potentially null from one that couldn’t? This would help a lot in terms of type safety because the compiler could then enforce that the programmer do some verification for references that could be null at the same time that it allows a direct use of the others. We see here an opportunity for improvement in the type system. This could be particularly useful when writing the public interface of APIs because it would increase the expressive power of the language, giving us a tool, besides documentation, to tell our users that a given method may or may not return a value.

Now, before we delve any further, I must clarify that this is an ideal that modern languages will probably pursue (we’ll talk about Ceylon and Kotlin later), but it is not an easy task to try to fix this hole in a programming language like Java when we intend to do it as an afterthought. So, in the coming paragraphs I present some scenarios in which I believe the use of optional objects could arguably alleviate some of this burden. Even so, the evil is done, and nothing will get rid of null references any time soon, so we better learn to deal with them. Understanding the problem is one step and it is my opinion that these new optional objects are just another way to deal with it, particularly in certain specific scenarios in which we would like to express the absence of a value.

Finding Elements

There is a set of idioms in which the use of null references is potentially problematic. One of those common cases is when we look for something that we cannot ultimately find. Consider now the following simple piece of code used to find the first fruit in a list of fruits that has a certain name:

public static Fruit find(String name, List<Fruit> fruits) {
   for(Fruit fruit : fruits) {
      if(fruit.getName().equals(name)) {
         return fruit;
      }
   }
   return null;
}

As we can see, the creator of this code is using a null reference to indicate the absence of a value that satisfies the search criteria (7). It is unfortunate, though, that it is not evident in the method signature that this method may not return a value, but a null reference..

Now consider the following code snippet, written by a programmer expecting to use the result of the method shown above:

List<Fruit> fruits = asList(new Fruit("apple"),
                            new Fruit("grape"),
                            new Fruit("orange"));

Fruit found = find("lemon", fruits);
//some code in between and much later on (or possibly somewhere else)...
String name = found.getName(); //uh oh!

Such simple piece of code has an error that cannot be detected by the compiler, not even by simple observation by the programmer (who may not have access to the source code of the find method). The programmer,  in this case, has naively failed to recognize the scenario in which the find method above could return a null reference to indicate the absence of a value that satisfies his predicate. This code is waiting to be executed to simply fail and no amount of documentation is going to prevent this mistake from happening and the compiler will not even notice that there is a potential problem here.

Also notice that the line where the reference is set to null (5) is different from the problematic line (7). In this case they were close enough, in other cases this may not be so evident.

In order to avoid the problem what we typically do is that we check if a given reference is null before we try to dereference it. In fact, this verification is quite common and in certain cases this check could be repeated so many times on a given reference that Martin Fowler (renown for hist book on refactoring principles) suggested that for these particular scenarios such verification could  be avoided with the use of what he called a Null Object. In our example above, instead of returning null, we could have returned a NullFruit object reference which is an object of type Fruit that is hollowed inside and which, unlike a null reference, is capable of properly responding to the same public interface of a Fruit.

Minimum and Maximum

Another place where this could be potentially problematic is when reducing a collection to a value, for instance to a maximum or minimum value. Consider the following piece of code that can be used to determine which is the longest string in a collection.

public static String longest(Collection<String> items) {
   if(items.isEmpty()){
      return null;
   }
   Iterator<String> iter = items.iterator();
   String result = iter.next();
   while(iter.hasNext()) {
       String item = iter.next();
       if(item.length() > result.length()){
          result = item;
       }
   }
   return result;
}

In this case the question is what should be returned when the list provided is empty? In this particular case a null value is returned, once again, opening the door for a potential null dereferencing problem.

The Functional World Strategy

It’s interesting that in the functional programming paradigm, the statically-typed programming languages evolved in a different direction. In languages like SML or Haskell there is no such thing as a null value that causes exceptions when dereferenced. These languages provide a special data type capable of holding an optional value and so it can be conveniently used to also express the possible absence of a value.  The following piece of code shows the definition of the SML option type:

datatype 'a option = NONE | SOME of 'a

As you can see, option is a data type with two constructors, one of them stores nothing (i.e. NONE) whereas the other is capable of storing a polymorphic value of some value type 'a (where 'a is just a placeholder for the actual type).

Under this model, the piece of code we wrote before in Java, to find a fruit by its name, could be rewritten in SML as follows:

fun find(name, fruits) =
   case fruits of
        [] => NONE
      | (Fruit s)::fs => if s = name
                         then SOME (Fruit s)
                         else find(name,fs)

There are several ways to achieve this in SML, this example just shows one way to do it. The important point here is that there is no such thing as null, instead a value NONE is returned when nothing is found (3), and a value SOME fruit is returned otherwise (5).

When a programmer uses this find method, he knows that it returns an option type value and therefore the programmer is forced to check the nature of the value obtained to see if it is either NONE (6) or SOME fruit (7), somewhat like this:

let
   val fruits = [Fruit "apple", Fruit "grape", Fruit "orange"]
   val found = find("grape", fruits)
in
   case found of
       NONE => print("Nothing found")
     | SOME(Fruit f) => print("Found fruit: " ^ f)
end

Having to check for the true nature of the returned option makes it impossible to misinterpret the result.

Java Optional Types

It’s a joy that finally in Java 8 we’ll have a new class called Optional that allows us to implement a similar idiom as that from the functional world. As in the case of of SML, the Optional type is polymorphic and may contain a value or be empty. So, we could rewrite our previous code snippet as follows:

public static Optional<Fruit> find(String name, List<Fruit> fruits) {
   for(Fruit fruit : fruits) {
      if(fruit.getName().equals(name)) {
         return Optional.of(fruit);
      }
   }
   return Optional.empty();
}

As you can see, the method now returns an Optional reference (1), if something is found, the Optional object is constructed with a value (4), otherwise is constructed empty (7).

And the programmer using this code would do something as follows:

List<Fruit> fruits = asList(new Fruit("apple"),
                            new Fruit("grape"),
                            new Fruit("orange"));

Optional<Fruit> found = find("lemon", fruits);
if(found.isPresent()) {
   Fruit fruit = found.get();
   String name = fruit.getName();
}

Now it is made evident in the type of the find method that it returns an optional value (5), and the user of this method has to program his code accordingly (6-7).

So we see that  the adoption of this functional idiom is likely to make our code safer, less prompt to null dereferencing problems and as a result more robust and less error prone. Of course, it is not a perfect solution because, after all, Optional references can also be erroneously set to null references, but  I would expect that programmers stick to the convention of not passing null references where an optional object is expected, pretty much as we today consider a good practice not to pass a null reference where a collection or an array is expected, in these cases the correct is to pass an empty array or collection. The point here is that now we have a mechanism in the API that we can use to make explicit that for a given reference we may not have a value to assign it and the user is forced, by the API, to verify that.

Quoting an article I reference later about the use of optional objects in the Guava Collections framework: “Besides the increase in readability that comes from giving null a name, the biggest advantage of Optional is its idiot-proof-ness. It forces you to actively think about the absent case if you want your program to compile at all, since you have to actively unwrap the Optional and address that case”.

Other Convenient Methods

As of the today, besides the static methods of and empty explained above, the Optional class contains the following convenient instance methods:

ifPresent() Which returns true if a value is present in the optional.
get() Which returns a reference to the item contained in the optional object, if present, otherwise throws a NoSuchElementException.
ifPresent(Consumer<T> consumer) Which passess the optional value, if present, to the provided Consumer (which could be implemented through a lambda expression or method reference).
orElse(T other) Which returns the value, if present, otherwise returns the value in other.
orElseGet(Supplier<T> other) Which returns the value if present, otherwise returns the value provided by the Supplier (which could be implemented with a lambda expression or method reference).
orElseThrow(Supplier<T> exceptionSupplier) Which returns the value if present, otherwise throws the exception provided by the Supplier (which could be implemented with a lambda expression or method reference).

Avoiding Boilerplate Presence Checks

We can use some of the convenient methods mentioned above to avoid the need of having to check if a value is present in the optional object. For instance, we may want to use a default fruit value if nothing is found, let’s say that we would like to use a “Kiwi”. So we could rewrite our previous code like this:

Optional<Fruit> found = find("lemon", fruits);
String name = found.orElse(new Fruit("Kiwi")).getName();

In this other example, the code prints the fruit name to the main output, if the fruit is present. In this case, we implement the Consumer with a lambda expression.

Optional<Fruit> found = find("lemon", fruits);
found.ifPresent(f -> { System.out.println(f.getName()); });

This other piece of code uses a lambda expression to provide a Supplier which can ultimately provide a default answer if the optional object is empty:

Optional<Fruit> found = find("lemon", fruits);
Fruit fruit = found.orElseGet(() -> new Fruit("Lemon"));

Clearly, we can see that these convenient methods simplify a lot having to work with the optional objects.

So What’s Wrong with Optional?

The question we face is: will Optional get rid of null references? And the answer is an emphatic no! So, detractors immediately question its value asking: then what is it good for that we couldn’t do by other means already?

Unlike functional languages like SML o Haskell which never had the concept of null references, in Java we cannot simply get rid of the null references that have historically existed. This will continue to exist, and they arguably have their proper uses (just to mention an example: three-valued logic).

I doubt that the intention with the Optional class is to replace every single nullable reference, but to help in the creation of more robust APIs in which just by reading the signature of a method we could tell if we can expect an optional value or not  and force the programmer to use this value accordingly. But ultimately, Optional will be just another reference and subject to same weaknesses of every other reference in the language. It is quite evident that Optional is not going to save the day.

How these optional objects are supposed to be used or whether they are valuable or not in Java has been the matter of a heated debate in the project lambda mailing list. From the detractors we hear interesting arguments like:

  • The fact that other alternatives exist ( i.e. the Eclipse IDE supports a set of proprietary annotations for static analysis of nullability, the JSR-305 with annotations like @Nullable and @NonNull).
  • Some would like it to be usable as in the functional world, which is not entirely possible in Java since the language lacks many features existing in functional programming languages like SML or Haskell (i.e. pattern matching).
  • Others argue about how it is impossible to retrofit preexisting code to use this idiom (i.e. List.get(Object)which will continue to return null).
  • And some complain about the fact that the lack of language support for optional values creates a potential scenario in which Optional could be used inconsistently in the APIs, by this creating incompatibilities, pretty much like the ones we will have with the rest of the Java API which cannot be retrofitted to use the new Optional class.
  • A compelling argument is that if the programmer invokes the get method in an optional object, if it is empty, it will raise a NoSuchElementException, which is pretty much the same problem that we have with nulls, just with a different exception.

So, it would appear that the benefits of Optional are really questionable and are probably constrained to improving readability and enforcing public interface contracts.

Optional Objects in the Stream API

Irrespective of the debate, the optional objects are here to stay and they are already being used in the new Stream API in methods like findFirstfindAnymax and min. It could be worth mentioning that  a very similar class has been in used in the successful Guava Collections Framework.

For instance, consider the following example where we extract from a stream the last fruit name in alphabetical order:

Stream<Fruit> fruits = asList(new Fruit("apple"),
                              new Fruit("grape")).stream();
Optional<Fruit> max = fruits.max(comparing(Fruit::getName));
if(max.isPresent()) {
   String fruitName = max.get().getName(); //grape
}

Or this another one in which we obtain the first fruit in a stream

Stream<Fruit> fruits = asList(new Fruit("apple"),
                              new Fruit("grape")).stream();
Optional<Fruit> first = fruits.findFirst();
if(first.isPresent()) {
   String fruitName = first.get().getName(); //apple
}

Ceylon Programming Language and Optional Types

Recently I started to play a bit with the Ceylon programming language since I was doing a research for another post that I am planning to publish soon in this blog. I must say I am not a big fan of Ceylon, but still I found particularly interesting that in Ceylon this concept of optional values is taken a bit further, and the language itself offers some syntactic sugar for this idiom. In this language we can mark any type with a ? (question mark) in order to indicate that its type is an optional type.

For instance, this find function would be very similar to our original Java version, but this time returning an optional Fruit? reference (1). Also notice that a null value is compatible with the optional Fruit? reference (7).

Fruit? find(String name, List<Fruit> fruits){
   for(Fruit fruit in fruits) {
      if(fruit.name == name) {
         return fruit;
      }
   }
   return null;
}

And we could use it with this Ceylon code, similar to our last Java snippet in which we used an optional value:

List<Fruit> fruits = [Fruit("apple"),Fruit("grape"),Fruit("orange")];
Fruit? fruit = find("lemon", fruits);
print((fruit else Fruit("Kiwi")).name);

Notice the use of the else keyword here is pretty similar to the method orElse in the Java 8 Optional class. Also notice that the syntax is similar to the declaration of C# nullable types, but it means something totally different in Ceylon. It may be worth mentioning that Kotlin, the programming language under development by Jetbrains, has a similar feature related to null safety (so maybe we are before a trend in programming languages).

An alternative way of doing this would have been like this:

List<Fruit> fruits = [Fruit("apple"),Fruit("grape"),Fruit("orange")];
Fruit? fruit = find("apple", fruits);
if(exists fruit){
   String fruitName = fruit.name;
   print("The found fruit is: " + fruitName);
} //else...

Notice the use of the exists keyword here (3) serves the same purpose as the isPresent method invocation in the Java Optional class.

The great advantage of Ceylon over Java is that they can use this optional type in the APIs since the beginning, within the realm of their language they won’t have to deal with incompatibilities, and it can be fully supported everywhere (perhaps their problem will be in their integration with the rest of the Java APIs, but I have not studied this yet).

Hopefully, in future releases of Java, this same syntactic sugar from Ceylon and Kotlin will also be made available in the Java programming language, perhaps using, under the hood, this new Optional class introduced in Java 8.

Further Reading

Java Streams Preview vs .Net High-Order Programming with LINQ

Edwin DalorzoIn today’s post I want to share with you a comparison that I did this weekend between the high-order programming features from LINQ and those being incorporated into the new Java 8 streams API.  It is important to highlight that the Java Stream API is still work in progress. I have been downloading and building the source code of Project Lambda for almost a year now and I have seen how the API evolves over time, but the improvements are more frequent as we approach the general availability date (planed for September 2013).

Before I delve into the comparisons, I must say that as of today, the current implementation of the Java Stream API is far away from all the high-order programming functionality offered by LINQ. It has already been announced in the mailing list that there was not going to be enough time for all improvements originally planned and the JEP 108: Collection Enhancements for Third-party Libraries has been deferred to future releases of Java. I am not sure how much of the Stream API is going to be affected by this decision but I hope that in the remaining months, prior to the release, they do much more improvements in the current API, at least, bring it closer to LINQ.

At any rate, as of today, it appears that some basic functionality is already covered (filter, map, reduce, sort, etc.), but much more work is still needed for this API to be decently compared to LINQ in terms of functionality and my comparison here only focuses particularly in the high-order programming features. So, I really hope that it is only too early to write this article, and in the coming months things are going to improve dramatically.

Also, there are some inherent problems that have been evidently difficult to overcome. One of those affecting the design of the API is the lack of value types in Java. It appears that the expert group have been struggling with this, and their solution has been to make copies of some interfaces, defining some to deal with primitive types (i.e. IntStream, LongStream, DoubleStream) and others with reference types (i.e. Stream). This has also caused a diaspora of copies of other functional interfaces (aka interface polution), particularly in the case of the interface Function the problem is much more evident (i.e. ToIntFunction, ToLongFunction, ToDoubleFunction and Function).

Even when all this repetition is done to alleviate the performance problems inherent to boxing and unboxing of primitive types, this workaround has undesirable side effects: first, the need to overload methods for everyone of these interfaces. This overloading is undesirable because it makes it impossible to use a clean lambda expression for these cases, since the compiler is incapable to determine which of all the argument functional interfaces is the one being implemented by the lambda. So, to avoid compiler errors we are  forced to use awful type castings in the code, which make it more verbose and look pretty bad. And a secondary side effect is the incompatibility between primitive type and reference type collections (i.e. an Stream<Integer> is not the same as an IntStream).

About the Comparison

For this exercise I took the code examples from the book .Net 4.0 Generics a Beginners Guide by Sudipta Mukherjee, particularly his examples from Chapter 4: LINQ to Objects. I did not do all the examples simply because there are many features still lacking in the Java Stream API which make it impossible to replicate the same functionality.

The author of the book makes all these examples to demonstrate LINQ high-order programming functionality. It is not  my intention to write an article on LINQ and all it can do, but a comparison of what I could do with the high-order programming features in the Stream API today if I wanted to implement similar idioms as those I can so easily implement using LINQ functionality. Perhaps I may have misinterpreted the author in his use of all these examples to illustrate LINQ, or perhaps, the author only intended to illustrate just one aspect of this broad technology. Therefore, this article is  based on my understanding of his view of this part of LINQ in order to make a comparison, but I can understand that LINQ is more than just a bunch of high-order functions.

Now some may argue that there is no intention in making the stream API something comparable to LINQ, which may well be true, but still LINQ offers a good example of an API that makes extensive use of high-order programming to query collections, and even if the stream API is not yet intended to query things like XML or SQL (at least initially/yet), I feel that it is still a good benchmark to compare the power of expressiveness in this new Java API. For me, this gives me an idea of how evolved this API is today when compared to the power of expressiveness of this another state-of-art technology. As it is customary in the internet world, others may freely disagree with me and present their personal perspectives as I did here.

For the cases that I could implement, the examples are based on the use of Stream and IntStream classes, and the static methods available on the Streams and Collectors helper classes. In order to keep it simple and readable I am not showing in the code examples below all the imports and static imports that  I used. For that matter you may want to take a look at the following Gist where I have published most of these examples and where you will be able to see full imports needed to make the code run properly.

Restriction Operators

Challenge 1: Filtering

Say we have a List of names and we would like to find all those names where "am" occurs:


LINQ

string[] names = { "Sam", "Pamela", "Dave", "Pascal", "Erik" };
List<string> filteredNames = names.Where(c => c.Contains("am"))
                                  .ToList();

Java Streams

String[] names = {"Sam","Pamela", "Dave", "Pascal", "Erik"};
List<String> filteredNames = stream(names)
			     .filter(c -> c.contains("am"))
			     .collect(toList());

Challenge 2: Indexed Filtering

Find all the names in the array "names" where the length of the name is less than or equal to the index of the element + 1.


LINQ

string[] names = { "Sam", "Pamela", "Dave", "Pascal", "Erik" };
var nameList = names.Where((c, index) => c.Length <= index + 1).ToList();

Java Streams

Now this one was particularly tricky in Java because, as of today, the API for streams does not contain any methods that indicate the index of an element within the stream. So, I was forced to generate an indexed stream out of the original array:

String[] names = {"Sam","Pamela", "Dave", "Pascal", "Erik"};

List<String> nameList;
Stream<Integer> indices = intRange(1, names.length).boxed();
nameList = zip(indices, stream(names), SimpleEntry::new)
			.filter(e -> e.getValue().length() <= e.getKey())
			.map(Entry::getValue)
			.collect(toList());

Now, the lack of indices in the stream made the algorithm more verbose, but it was also interesting to notice the incompatibilities between primitive-type streams, like IntStream and reference type streams like Stream<Integer>. In this case, I was forced to transform the IntStream returned by intRange into a Stream<Integer> in order to make the argument compatible with the types expected by zip as you can see in the line #4.


Projection Operators

Challenge 3: Selecting/Mapping

Say we have a list of names and we would like to print “Hello” in front of all the names:


 LINQ

List<string> nameList1 = new List(){ "Anders", "David", "James",
                                     "Jeff", "Joe", "Erik" };
nameList1.Select(c => "Hello! " + c).ToList()
         .ForEach(c => Console.WriteLine(c));

Java Streams

List<String> nameList1 = asList("Anders", "David", "James",
                                "Jeff", "Joe", "Erik");
nameList1.stream()
	 .map(c -> "Hello! " + c)
	 .forEach(System.out::println);

Challenge 4: Selecting Many/Flattening

Suppose, we have a dictionary such that each key has a list of values attached to them. Now, we want to project all the elements in a single collection:


LINQ

Dictionary<string, List<string>> map = new Dictionary<string,List<string>>();
map.Add("UK", new List<string>() {"Bermingham", "Bradford", "Liverpool"});
map.Add("USA", new List<string>() {"NYC", "New Jersey", "Boston", "Buffalo"});
var cities = map.SelectMany(c => c.Value).ToList();

Java Streams

Once more, the Java syntax, as of today, is a bit more verbose. First, we must transform the map to an entry set, and from there, we can generate a stream that we can later flatten to a list of cities, as follows:

Map<String, List<String>> map = new LinkedHashMap<>();
map.put("UK", asList("Bermingham","Bradford","Liverpool"));
map.put("USA", asList("NYC","New Jersey","Boston","Buffalo"));

FlatMapper<Entry<String, List<String>>,String> flattener;
flattener = (entry,consumer) -> { entry.getValue().forEach(consumer); };

List<String> cities = map.entrySet()
			 .stream()
			 .flatMap( flattener )
			 .collect(toList());

Ideally the lines 5, 6 should be defined as inline arguments of flatMap, but the compiler cannot properly infer the types of the expression precisely for the overloading problems that I described above. Given the amount of type information that must be provided, I felt that it was best to define it in another line as I did in #5 and #6. It looks awful,  I know. Clearly, we are in desperate need of an API that offers operations to deal with maps or tuples.


Partitioning Operators

Challenge 5: Taking an Arbitrary Number of Items

In this case we are interested in evaluating only the first n elements of a collection. For instance, using a finite list of numbers, obtain the first 4 of them.


LINQ

int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 };
var first4 = numbers.Take(4).ToList();

Java Streams

Once more, in Java, the absence of value types forced me to make a conversion from an IntStream into a Stream<Integer> to make this work (see line #5), basically because there is not value type collector. An alternative would have been to consume the stream itself (i.e. forEach) or to collect items into an array using Stream.toArray() method.

int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,13 };

List<Integer> firstFour;
firstFour = stream(numbers).limit(4)
                           .boxed()
                           .collect(toList());

Challenge 6: Taking Items Based on Predicate

In this case we are interested in taking items out of a collection as long as they satisfy a predicate. Once we find an item that does not satisfy the predicate we stop there.


LINQ

string[] moreNames = { "Sam", "Samuel", "Dave", "Pascal", "Erik",  "Sid" };
var sNames = moreNames.TakeWhile(c => c.StartsWith("S"));

Java Streams

As of today, there is no way to implement this idiom in Java using the streams API. There is an alternative way to do this, but it is not the same thing. The beauty of takeWhile is that is should be short-circuited, that is, it should stop the evaluation in the moment that one item does not satisfies the predicate. The following version in Java does not have this property:

String[] names  = { "Sam","Samuel","Dave","Pascal","Erik","Sid" };

List<String> found;
found = stream(names).collect(partitioningBy( c -> c.startsWith("S")))
                     .get(true);

The collector created by partitioningBy (line #4) forces the evaluation of the whole stream, placing items into a boolean map, where all items that satisfy the predicate are bound to true and all others to false. So clearly, it is not the same thing. I hope that as the Oracle expert group works on the API they fix this omission.


Challenge 7: Skipping an Arbitrary Number of Items

In this case we are interested in skipping items in a collection up to certain arbitrary number, then we keep the rest of the items.


LINQ

string[] vipNames = { "Sam", "Samuel", "Samu", "Remo", "Arnold","Terry" };
var skippedList = vipNames.Skip(3).ToList();//Leaving the first 3.

Java Streams

In Java, the solution consists in creating a new stream where the first n elements have been discarded. As follows:

String[] vipNames = { "Sam", "Samuel", "Samu", "Remo", "Arnold","Terry" };

List<String> skippedList;
skippedList = stream(vipNames).substream(3).collect(toList());

Challenge 8: Skipping Items Based on Predicate

In this case we are interested in skipping items out of a collection as long as they satisfy a predicate. Once we find an item that does not satisfy the predicate we take the rest of the items from there.


LINQ

int[] numbers = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 20 };
var skippedList = numbers.SkipWhile(c => c < 10);

Java Streams

With current streams API I found no way to implement this idiom.

Ordering Operators

Challenge 9: Ordering/Sorting Elements

Order the elements of a collection alphabetically:


LINQ

string[] friends = { "Sam", "Pamela", "Dave", "Anders", "Erik" };
friends = friends.OrderBy(c => c).ToArray();

Java Streams

In the case of Java, we use the sorted method to produce the same result. The sorted method can also accept a Comparator to determine the sorting criteria.

String[] friends = { "Sam", "Pamela", "Dave", "Anders", "Erik" };
friends = stream(friends).sorted().toArray(String[]::new);

Challenge 10: Ordering/Sorting Elements by Specific Criterium

Order the elements of a collection strings according to the length of the string:


LINQ

string[] friends = { "Sam", "Pamela", "Dave", "Anders", "Erik" };
friends = friends.OrderBy(c => c.Length).ToArray();

Java Streams

In this case we pass a Comparator to the sort method. And once again, we hit against the problem of overloaded methods defined in the API to deal with the lack of value types in Java. Here we are forced to provide an explicit casting (line #3) to help the compiler:

String[] friends = { "Sam", "Pamela", "Dave", "Anders", "Erik" };
friends = stream(friends)
           .sorted(comparing((ToIntFunction<String>)String::length))
           .toArray(String[]::new);

An alternative way could be to provide an implementation of the Comparator (line #3), in this case, by means of a binary lambda expression. This is a little cleaner, but more verbose.

String[] friends = { "Sam", "Pamela", "Dave", "Anders", "Erik" };
friends = stream(friends)
            .sorted( (s1,s2) -> Integer.compare(s1.length(), s2.length()))
            .toArray(String[]::new);

Challenge 11: Ordering/Sorting Elements by Multiple Criteria

Order the elements of a collection of strings according to several sorting criteria:


LINQ

string[] fruits = {"grape", "passionfruit", "banana",
                   "apple", "orange", "raspberry",
                   "mango", "blueberry" };

//Sort the strings first by their length and then alphabetically.
//preserving the first order.
var sortedFruits = fruits.OrderBy(fruit =>fruit.Length)
                         .ThenBy(fruit => fruit);

Java Streams

Originally I had thought it was not possible to implement this idiom with the latest release of the API, but one of our readers had a good suggestion. Even so I was not able to get rid of the castings in lines #5 and #7. Once again the interface pollution causes the need for castings to clarify which of the overloaded methods are the ones being implemented in Comparators and Comparator here.

String[] fruits = {"grape", "passionfruit", "banana","apple",
                   "orange", "raspberry","mango", "blueberry" };

Comparator<String> comparator;
comparator = comparing((Function<String,Integer>)String::length,
                       Integer::compare)
            .thenComparing((Comparator<String>)String::compareTo);

fruits = stream(fruits) .sorted(comparator)
                        .toArray(String[]::new);

Grouping Operators

Challenge 12: Grouping by a Criterium

Group the elements of a collection of strings by their length.


LINQ

string[] names = {"Sam", "Samuel", "Samu", "Ravi", "Ratna",  "Barsha"};
var groups = names.GroupBy(c => c.Length);

Java Streams

String[] names = {"Sam", "Samuel", "Samu", "Ravi", "Ratna",  "Barsha"};

Map<Integer,List<String>> groups;
groups = stream(names).collect(groupingBy(String::length));

Set Operators

The current implementation of streams is way behind LINQ in this area. From all possible set operations, the only ones currently implemented are “distinct” and “concat”, although “concat” is not a set operation because it would accept duplicates, the correct would be to have a “union” operation, but this does not exist in the stream API yet.

Challenge 13: Filter Distinct Elements

Obtain all the distinct elements from a collection.


LINQ

string[] songIds = {"Song#1", "Song#2", "Song#2", "Song#2", "Song#3", "Song#1"};
//This will work as strings implement IComparable
var uniqueSongIds = songIds.Distinct();

Java Streams

String[] songIds = {"Song#1", "Song#2", "Song#2", "Song#2", "Song#3", "Song#1"};
//according to Object.equals
stream(songIds).distinct();

Challenge 14: Union of Two Sets

Join together two sets of items.


LINQ

List<string> friends1 = new List<string>() {"Anders", "David","James",
                                            "Jeff", "Joe", "Erik"};
List<string> friends2 = new List<string>() { "Erik", "David", "Derik" };
var allMyFriends = friends1.Union(friends2);

Java Streams

In Java we have to concatenate the two streams and then obtain the distinct elements.

List<String> friends1 = asList("Anders","David","James","Jeff","Joe","Erik");
List<String> friends2 = asList("Erik","David","Derik");
Stream<String> allMyFriends = concat(friends1.stream(),
                                     friends2.stream()).distinct();

Element Operatos

Challenge 15: First Element

Obtain the first element of a collection.


LINQ

string[] otherFriends = {"Sam", "Danny", "Jeff", "Erik", "Anders","Derik"};
string firstName = otherFriends.First();
string firstNameConditional = otherFriends.First(c => c.Length == 5);

Java Streams

In Java we use the findFirst method which returns an Option object. The object may contain something or nothing, to validate that one must invoke the isPresent method on the returned object.

String[] otherFriends = {"Sam", "Danny", "Jeff", "Erik", "Anders","Derik"};
Optional<String> found = stream(otherFriends).findFirst();

Optional<String> maybe = stream(otherFriends).filter(c -> c.length() == 5)
                                             .findFirst();
if(maybe.isPresent()) {
   //do something with found data
}

Range Operators

Challenge 16: Generate a Range of Numbers

Generate a range of numbers that are multiples of 11.


LINQ

var multiplesOfEleven = Enumerable.Range(1, 100).Where(c => c % 11 == 0);

Java Streams

IntStream multiplesOfEleven = intRange(1,100).filter(n -> n % 11 == 0);

Quantifier Operators

Challenge 17: All

Do all elements in a collection satisfy a predicate?


LINQ

string[] persons = {"Sam", "Danny", "Jeff", "Erik", "Anders","Derik"};
bool x = persons.All(c => c.Length == 5);

Java Streams

String[] persons = {"Sam", "Danny", "Jeff", "Erik", "Anders","Derik"};
boolean x = stream(persons).allMatch(c -> c.length() == 5);

Challenge 18: Any

Do any elements in a collection satisfy a predicate?


LINQ

string[] persons = {"Sam", "Danny", "Jeff", "Erik", "Anders","Derik"};
bool x = persons.Any(c => c.Length == 5);

Java Streams

String[] persons = {"Sam", "Danny", "Jeff", "Erik", "Anders","Derik"};
boolean x = stream(persons).anyMatch(c -> c.length() == 5);

Merging Operators

Challenge 19: Zip

Combine two collections into a single collection.


LINQ

string[] salutations = {"Mr.", "Mrs.", "Ms", "Master"};
string[] firstNames = {"Samuel", "Jenny", "Joyace", "Sam"};
string lastName = "McEnzie";

salutations.Zip(firstNames, (sal, first) => sal + " " + first)
           .ToList()
           .ForEach(c => Console.WriteLine(c + " " + lastName));

Java Streams

String[] salutations = {"Mr.", "Mrs.", "Ms", "Master"};
String[] firstNames = {"Samuel", "Jenny", "Joyace", "Sam"};
String lastName = "McEnzie";

zip(
    stream(salutations),
    stream(firstNames),
    (sal,first) -> sal + " " +first)
.forEach(c -> { System.out.println(c + " " + lastName); });

In general, things are still not looking good, but I really hope that will change in the coming months. There are challenges that will be difficult to overcome, like the issues with value types, but in my opinion we could  live with those problems as long as we are provided with an API sufficiently expressive.

I am currently working on another set of examples in which I work on a small data model and see what I can do with it to run all kinds of queries using the Stream API, but I will leave that for my next post.

Related Posts

Further Reading