Table Of Contents Next >> Ch. 4.7: TBD Prev << Ch. 4.5: Typedefs and Type Aliases

FUNCTIONAL PROGRAMMING FRAMEWORK

In this chapter:

• 4.6.1 Why Functional Programming in Java?

4.6.1 Why Functional Programming in Java?

Introduction of Functional Programming into Java-based GridGain has its own unique story in GridGain that is worth repeating here.

It was anything but a straightforward decision... In early 2008 when we released GridGain 2.0 we've started looking for a new ways to simplify the usability of GridGain. We've had a pretty good story with AOP-based grid enabling and a direct API support for MapReduce type of processing - in fact we've been way ahead of everyone else in this department. But we felt there's still lots of plumbing exposed for many use cases where such exposition was clearly unnecessary.

The obvious thought for us was to look at DSL (Domain Specific Language) route. We quickly realized that Java-based DSL is simply out of question (it would be just another set of Java APIs not much different from we had already). XML-based DSL was considered a non-started even in a hay days of DSLs of 2006-2007.

So, we started looking at other JVM-based languages that would be much more appropriate for DSL development yet let us reuse GridGain Java-based APIs. During surprisingly short evaluation period (which we'll chronicle in Scala section later on) we quickly and decisively settled on Scala - relatively new than language that so powerfully combined OOP and FP into one cohesive and expressive language.

As we dived into Scala-based DSL development with a renewed energy we quickly realized that in order to provide truly powerful DSL in Scala (utilizing Scala's functional core including partial functions, closures, etc.) we essentially had to re-implement most of the main APIs in Scala, i.e. duplicate GridGain in Scala. That was a pretty rude awakening for us as it was simply a no-go to have GridGain implemented in two parallel tracks: one in Java and one in Scala.

And that's where functional story for Java begins. After some research on our part we noticed that if we could make Java side APIs functional in their design - we could largely reduce the Scala-based DSL to a collection of implicit conversions from functional Java parts to Scala parts (and back). That would also allow to have all implementation in Java (where it is originally was) and keep Scala APIs as a layer on top without any duplication of code what-so-ever.

After a few false starts we've got a first working prototype (that didn't suck) and started the refactoring process of our Java APIs into functional mold. What we started noticing along the way is that new APIs (newly added or refactored) were becoming much more powerful and elegant when used with functional constructs such as predicate-based node filters or closure-based executions. In about that time we also came up with grid and cache projections that truly revolutionized the GridGain usability. Many implementations became shorter and yet more expressive when we started using our GridFunc class as well as newly introduced typedefs. All these positive effects on our internal software development solidified our resolve to provide the same capabilities to the users of GridGain.

All in all, the introduction of Scala support and Scala DSL into GridGain led us to develop one of the most comprehensive Functional Programming frameworks in Java that at the core of most of the functionality in GridGain.

^Top

		Table Of Contents Next >> Ch. 4.7: TBD Prev << Ch. 4.5: Typedefs and Type Aliases