Topics

Featured in Development

Peter Alvaro talks about the reasons one should engage in language design and why many of us would (or should) do something so perverse as to design a language that no one will ever use. He shares some of the extreme and sometimes obnoxious opinions that guided his design process.

Featured in AI, ML & Data Engineering

Today on The InfoQ Podcast, Wes talks with Katharine Jarmul about privacy and fairness in machine learning algorithms. Jarul discusses what’s meant by Ethical Machine Learning and some things to consider when working towards achieving fairness. Jarmul is the co-founder at KIProtect a machine learning security and privacy firm based in Germany and is one of the three keynote speakers at QCon.ai.

Featured in Culture & Methods

Organizations struggle to scale their agility. While every organization is different, common patterns explain the major challenges that most organizations face: organizational design, trying to copy others, “one-size-fits-all” scaling, scaling in siloes, and neglecting engineering practices. This article explains why, what to do about it, and how the three leading scaling frameworks compare.

Java 8 vs Scala: a Feature Comparison

Introduction

With the release of JDK 8 planned for 2013, Oracle has a pretty fixed idea of what will be included. Speaking at QCon London earlier this year, Simon Ritter outlined the new features that will be part of JDK 8, which include modularity (Project Jigsaw), JRockit/Hotspot convergence, annotations on types, and Project Lambda.

From a language perspective, perhaps the most important change is Project Lambda, which includes support for lambda expressions, virtual extension methods and better support for multicore platforms in the form of parallel collections.

Most of these features are already available in many other JVM languages, including Scala. Moreover, many of the approaches taken in Java 8 are surprisingly similar to those used in Scala. As a consequence, playing with Scala is a good way of getting a feeling for what programming with Java 8 will be like.

Related Vendor Content

In this article we will explore Java 8’s new features, using both Java’s proposed syntax and Scala. We will cover lambda expressions, higher-order functions, parallel collections and virtual extension methods aka traits. Besides this, we will provide insights into the new paradigms integrated in Java 8, such as functional programming.

The reader will experience how the new concepts incorporated in Java 8 - that are already available in Scala - are not mere bells and whistles, but could introduce a true paradigm shift, which will offer great possibilities and may profoundly change the way we write software.

Lambda Expressions/Functions

Java 8 will include lambda expressions, finally! Lambda expressions have been available in the form of Project Lambda since 2009. At that time, lambda expressions were still referred to as Java Closures. Before we jump into some code examples, we will explain why lambda expressions will be a very welcome tool in the Java programmers tool belt.

Motivation for Lambda Expressions

A common use of lambda expressions is in GUI development. In general, GUI programming resolves around connecting behaviour to events. For example, if a user presses a button (an event), your program needs to execute some behaviour. This might be the storage of some data in a datastore. In Swing, for example, this is done using ActionListeners:

This example shows the use of the class ButtonHandler as a callback replacement. The class ButtonHandler is only there to hold a single method: actionPerformed, defined in the ActionListener interface. We could simplify this code a bit by using anonymous inner classes:

This code is somewhat cleaner. When we look more closely at the code, we still create an instance of a class just to call a single method. These kinds of problems are exactly the ones solved by introducing lambda expressions.

Lambda Expressions as Functions

A lambda expression is a function literal. It defines a function with input parameters and function body. The syntax of the lambda expression in Java 8 is still under discussion, but will look something like this:

(type parameter) -> function_body

A concrete example is:

(String s1, String s2) -> s1.length() - s2.length();

This lambda expression calculates the difference in length between two strings. There are some extensions to this syntax, like avoiding the type definition for the arguments, as we will see later on, and supporting multi-line definitions by using { and } to group statements.

The Collections.sort() method would be an ideal usage example for this expression. It enables us to sort a collection of Strings based on their lengths:

So, instead of feeding the sort method with an implementation of Comparator, as we would have to do with current Java, passing the above lambda expression is all that is needed to achieve the same result.

Lambda Expression as Closures

Lambda expressions have some interesting properties. One is that they are closures. A closure allows a function to access variables outside its immediate lexical scope.

String outer = "Java 8"
(String s1) -> s1.length() - outer.length()

The example shows that the lambda expression has access to the String outer, which is defined outside its scope. For inline usage scenarios closure can be very handy.

Type Inference also for Lambda Expressions

Type inference, which was introduced in Java 7, also applies to lambda expressions. Type inference, in a nutshell, means that a programmer can omit the type definition everywhere where the compiler can ‘infer’ or deduce the type by itself.

If type inference was used for the sorting lambda expression, it could be written as follows:

As you can see, the types for the parameters s1 and s2 are omitted. Because the compiler knows that the list contains a collection of Strings it knows that a lambda expression used as comparator must also have two parameters of type String. Consequently, the types do not need to be declared explicitly, even though you are free to do so.

The main advantage of type inference is reduction of boilerplate. If the compiler can infer the type for us, why should we define them ourselves?

Hello Lambda Expressions, Goodbye Anonymous Inner Classes

Let’s see how lambda expressions and type inference help to simplify the callback example we discussed initially:

Instead of defining a class to hold our callback method, we now directly pass a lambda expression into the addActionListener method. Besides the reduction lot of boilerplate code and increased readability, it lets us directly express the only thing we are really interested in: handling the event.

Before we unravel more advantages of lambda expressions, we first take a look at the lambda expressions counterpart in Scala.

Lambda Expressions in Scala

Functions are the basic building blocks of a style of programming called functional programming. Scala combines object orientation, known from Java, and functional programming. In Scala, a lambda expression is a basic building block called a ‘function’ or ‘function literal’. Functions in Scala are first class citizens. They can be assigned to vals or vars (final or non final variables), they can be passed as an argument to another function, and they can be combined to form new functions.

In Scala a function literal is written as follows:

(argument) => //function body

For example, the previous Java lambda expression calculating the difference of length of two strings, is written in Scala like so:

(s1: String, s2: String) => s1.length - s2.length

In Scala, function literals are also closures. They can access variables defined outside their own lexical scope.

This example would result in 20. As you see, we assigned a function literal to a variable named myFuncLiteral.

The syntactical and semantic similarities between Java 8’s lambda expression and Scala’s function are remarkable. Semantically they are exactly the same, whereas syntactically the only differences are the symbol for the arrow (Java8: -> Scala: =>) and the shorthand notation, which is not covered here.

Higher-Order Functions as Reusable Building Blocks

The great advantage of function literals is that we can pass them around as any other literals, like a String or an arbitrary Object. This offers a wide range of possibilities and allows for highly compact and reusable code constructs.

Our First Higher-Order Function

When we pass a function literal to a method, we basically have a method that accepts a method. Such methods are called higher-order functions. The addActionListener method in the previous Swing code example is exactly one of those. We also can define our own higher-order functions, which can offer us a lot of benefit. Let’s look at a simple example:

In this example, we have a measure method, which measures the time needed to execute the function literal callback called func. The signature of func is that it does not take any parameters and returns a result of the generic type T. As you can see, functions in Scala do not necessarily need parameters even though they can - and most often also will - have parameters.

Now we can pass any function literal (or method) in the measure method:

What we have done, from a conceptual point of view, is separating the concern of measuring the length of a method call from the actual computation. We created two reusable code constructs (the measure part and the callback part) that are very loosely coupled, similar to an interceptor.

Reuse through Higher-Order Functions

Let’s look at another hypothetical example where two reusable constructs are slightly tighter coupled:

The method doWithContact reads a contact from a file, such as a vCard or similar, and offers it to a parser which converts it to a contact domain object. The contact domain object is then passed to the function literal callback handle, which does with the contact domain object whatever the function dictates. The doWithContact method as well as the function literal returns the type Unit, which is the equivalent of a void method in Java.

Now we can define various callbacks that can be passed to the doWithContact method:

Benefit of Higher-Order Functions

As you can see, functions helped us to cleanly separate the concern of creating a domain object from processing it. By doing so, new ways of handling contact domain objects can easily be plugged in without being coupled to the logic that creates the domain object.

As a result, the benefit we gain from higher-order functions is that our code stays DRY (Don’t Repeat Yourself) so that the programmer can optimally profit from code reuse on a very granular level.

Collections and Higher-Order Functions

Higher-order functions provide a very efficient way of dealing with collections. Because almost every program makes use of collections, efficient collection handling can be a great help.

Filtering Collections: Before and After

Let’s look at a common use case involving collections. Say we want to apply a calculation to every element of a collection. For example, we have a list of Photo objects and we want to filter out all Photos of a certain size.

This code contains a lot of boilerplate, such as creating the result collection and adding the new elements to the list. An alternative is the use of a Function class, to abstract over function behaviour:

Both of these implementations are elegant, and very succinct. Note that they both make use of type inference: the function parameter p of type Photo is not explicitly defined. As you can see in Scala type inference is a standard feature.

Function Chaining in Scala

So far we have saved at least six lines of code and even improved readability. The fun starts when we chain several higher-order functions. To illustrate that, let’s create a Photo class and add additional properties in Scala:

case class Photo(name:String, sizeKb:Int, rates:List[Int])

Without knowing much Scala, what we have done is declare the class Photo with three instance variables, name, sizeKb and rates. The rates will contain the user ratings for this image, from 1 to 10. Now we can create an instance of the Photo class, which is done as follows:

With this list of Photos, it is now quite easy to define various queries by chaining multiple higher-order functions after each other. Suppose we have to extract the file names of all the pictures whose file size is greater than 10MB. The first question is how do we transform a list of Photos into a list of filenames? To achieve that we use one of the most powerful higher-order functions, called map:

val names = photos.map(p => p.name)

The map method transforms each element of a collection to the type defined in the function passed to it. In this example we have a function that receives a Photo object and returns a String, which is the filename of the Image.

By using map we can solve the given task by chaining the map method after the filter method:

We do not have to be afraid of NullPointerExceptions, because each method (filter, map, etc.) always returns a collection, which can be empty but never null. So if the photos collection was empty right from the start, the result of the computation would still be an empty collection.

Function chaining is also referred to as ‘function composition’. Using function composition we can shop in the Collections API to look for the building blocks by which our problem can be solved.

Let’s consider a more advanced example:

Task: "Return the names of all photos whose average rating is higher than 6, sorted by the total amount of ratings given:"

To achieve this task we rely on the sortBy method, which expects a function that takes the element type of the collection as input (here Photo) and returns an object of type Ordered (here an Int). Because a List does not offer an average method, we defined the function literal avg that calculates the average of the given List of Ints for us in the anonymous function passed to the filter method.

Function Chaining in Java 8

It is not clear yet which higher-order functions the collection classes of Java 8 will offer. Filter and map will most probably be supported. Consequently, the first shown chained example will likely appear in Java 8 as follows:

Again, it is remarkable that there is almost no syntactic difference compared to the Scala version.

Higher-order functions in combination with collections are extremely powerful. They are not only very concise and readable, but also save us a lot of boilerplate code, with all the benefits thereof, like fewer tests and fewer bugs. However, there’s more...

Parallel Collections

So far we have not touched one of the most important advantages of higher-order functions in collections. Besides conciseness and readability, higher-order functions add a very important layer of abstraction. In all the previous examples we haven’t seen any loops. Not even once have we had to iterate over a collection to filter, map or sort elements. Iterating is hidden from the user of the collection, or in other words abstracted away.

This additional abstraction layer is key to leveraging multicore platforms, because the underlying implementation of the loop can choose by itself how to iterate over the collection. Consequently, iterating can not only be done sequentially but also in parallel. With the advance of multicore platforms, leveraging parallel processing is no longer a nice-to-have. Today’s programming languages need to be able to cope with the demands of parallel platforms.

In theory, we all could write our own parallel code. In practice that’s not a good idea. First of all, writing robust parallel code, especially with shared state and intermediate results that need to be merged, is extremely hard. Second, ending up with many different implementations wouldn’t be desirable. Even though Java7 has Fork/Join, the problem to decompose and reassemble the data is left to the client, which is not the abstraction level we are looking for. And third, why bother if we already have the answer in the form of functional programming?

Thus, let very smart people write the parallel iteration code once and abstract over their usage by means of higher-order functions.

Parallel Collections in Scala

Let’s look at a simple Scala example, which makes use of parallel processing:

We first define the method heavyComputation, which performs - well - a heavy computation. On a quad core laptop this expression takes about 4 seconds to perform. We then instantiate a range collection (0 to 10) and invoke the par method. The par method returns a parallel implementation, which offers the exact same interfaces as its sequential counterpart. Most Scala collection types have such a par method. From a usage point of view that’s all there is to it.

Let’s see what performance gains we can achieve on a quad core computer. In order to gain insights we reuse the measure method from further above:

What might be surprising at first glance is that the parallel execution is only about 2.5 times as fast, even though we are using four cores. The reason is that parallelism comes with the price of additional overhead, in the form of threads that need to be started and intermediate results that need to merged. Therefore, it is not a good idea to use parallel collections by default, but only apply them for known heavy computations.

Parallel Collections in Java 8

In Java 8 the proposed interface for parallel collection again is almost identical to Scala:

The paradigm is exactly the same as in Scala, with the sole difference that the method name to create a parallel collection is parallel() instead of par.

All at Once: A Larger Example

To recap higher-order functions / lambda expression in combination with parallel collections, let’s look at a larger example in Scala, which combines many of the concepts introduced in the sections above.

For this example we chose a random site, which offers a great variety of beautiful nature wallpapers. We will write a program, that strips all the wallpaper image urls from this page and downloads the images in parallel. Besides the Scala core libraries, we use two other ones, Dispatch for http communication and Apache’s FileUtils, to simplify certain tasks. Be prepared to see some Scala concepts that were not explained in this article, but whose intention should be more or less understandable.

Code explanation

The scrapeWallpapers method processes the control flow, which is fetching the image URLs from the html and downloading each of them.

By means of the fetchWallpaperImgURLsOfPage, all the wallpaper image URLs are screen scraped from the html.

The Http object is a class of the HTTP dispatch library, which provides a DSL around Apache’s httpclient library. The method as_tagsouped converts html in xml, which is a built-in datatype in Scala.

val xhtml = Http(url(pageUrl) as_tagsouped)

From the html, in the form of xhtml, we then retrieve the relevant hrefs of the images we want to download:

val imgHrefs = xhtml \\ "a" \\ "@href"

Because XML is native in Scala we can use the xpath-like expression \\ to select the nodes we are interested in. After we have retrieved all hrefs we need to filter out all image URLs and convert the hrefs to URL objects. In order to achieve that, we chain several higher-order functions of Scala’s Collection API like map and filter. The result is a List of image URLs.

The next step is to download each image in parallel. To achieve parallelism, we turn the list of image names into a parallel collection. Consequently, the foreach method starts several threads to loop through the collection simultaneously. Each thread will eventually call the copyToDir method.

imgURLs.par.foreach(url => copyToDir(url, toDir))

The copyToDir method makes use of Apache Common’s FileUtils. The static method copyURLToFile of the FileUtil class is statically imported and therefore can be called directly. For clarity we also print the name of the thread that performs the task. When executed in parallel, it will illustrate that multiple threads are busy processing.

This method also illustrates that Scala is fully interoperable with existing Java libraries.

Scala’s functional features, and the resulting benefits such as higher-order functions on collections and the "free" parallelism, make it possible to accomplish parsing, IO and conversion of data in parallel with only a few lines of code.

Virtual Extension Methods/Traits

Virtual extension methods in Java are similar to ‘traits’ in Scala. What are traits, exactly? A trait in Scala offers an interface, and optionally includes an implementation. This structure offers great possibilities. This becomes clear when we start composing classes with traits.

Just like Java 8, Scala doesn’t support multiple inheritance. In both Java and Scala a subclass can only extend a single superclass. With traits however, inheritance is different. A class can "mix in" multiple traits. An interesting fact is that the class gains both the type and all methods and state of the mixed in trait(s). Traits are therefore also called mixins, as they mix in new behaviour and state into a class.

The question that remains is: if traits support some form of multiple inheritance, won’t we suffer from the notorious "diamondproblem"? The answer, of course, is no. Scala defines a clear set of precedence rules that determine when and what is executed within the multiple inheritance hierarchy. This is independent of the number of traits mixed in. These rules provide us with the full benefits of multiple inheritance without any of the problems associated with it.

If Only I Had a Trait

The following example shows a familiar code-snippet for Java developers:

Logging is thought of as a cross cutting concern, from a design perspective. However, this is hardly noticeable in the daily practice of Java development. Each class, again and again, declares a logger. We also keep checking whether a log level is enabled, using for example isDebugEnabled(). This is a clear violation of DRY: Don’t Repeat Yourself.

In Java, there is no way to validate that a programmer declares the log level check or use the proper logger associated with the class. Java developers got so used to this practice, it’s considered a pattern now.

Traits offer a great alternative to this pattern. If we put the logging functionality into a trait, we can mix-in this trait in any class we’d like. This enables access for the class to the cross-cutting concern ‘logging’, without limiting the possibilities of inheriting from another class.

Logging as a Trait, a Solution to the Logging Problem

In Scala, we would implement the Loggable trait like the following code snippet:

Scala defines a trait using the keyword ‘trait’. The body of a trait can contain anything an abstract class is allowed to contain, like fields and methods. Another interesting part in the logging example is the use of self =>. The logger should log the class that mixes in the Loggable trait, not Loggable itself. The self => syntax, called self-type in Scala, enables the trait to get a reference to the class that mixes it in.

Note the use of the parameterless function msg: => T as input parameter for the debug method. The main reason why we use the isDebugEnabled() check is to make sure that the String that is logged is only computed if the debug level is enabled. So if the debug method would only accept a String as input parameter, the log message would always get computed no matter whether the debug loglevel is enabled or not, which is not desirable. By passing the parameterless function msg: => T instead of a String however, we get exactly what we want: the msg function that will return the String to be logged is only invoked when the isDebugEnabled check succeeds. If the isDebugEnabled check fails the msg function is never called and therefore no unnecessary String is computed.

If we want to use the Loggable trait in the Photo class, we need to use extends to mix in the trait:

The ‘extends’ keyword gives the impression that Photo inherits from Loggable, and therefore cannot extend any other class. This is not the case. The Scala syntax demands that the first keyword for mixing in or extending a class is ‘extends’. If we want to mix in multiple traits, we have to use the keyword ‘with’ for each trait after the first. We will see more examples using ‘with’ further below.

To show that this actually works, we call the method save() on Photo:

new Photo().save()
18:23:50.967 [main] DEBUG Photo - You saved me

Adding more Behaviours to your Classes

As we discussed in the previous paragraph, a class is allowed to mix in multiple traits. So besides logging, we can also add other behaviour to the Photo class. Let’s say we want to be able to order Photos based on their file size. Luckily for us, Scala offers a number of traits out of the box. One of these traits is the Ordered[T] trait. Ordered is similar to the Java interface Comparable. The big, and very important, difference is that the Scala version offers an implementation as well:

In the example above, two traits are mixed in. Besides the previously defined Loggable trait, we also mix in the Ordered[Photo] trait. The Ordered[T] trait requires the implementation of the compare(type:T) method. This is still very similar to Java’s Comparable.

Besides the compare method, the Ordered trait also offers a number of different methods. These methods can be used to compare objects in various ways. They all make use of the implementation of the compare method.

Symbolic names like > and <= etc. are not special reserved keywords in Scala like in Java. The fact that we can compare objects using >, <= etc. is due to the Ordered trait that implements the methods with these symbols.

Classes that implement the Ordered trait can be sorted by every Scala collection. By having a collection populated with Ordered objects, ‘sorted’ can be called on the collection, which sorts the objects according to the order defined in the compare method.

The Benefits of Traits

The above examples reveal that we are able to isolate generic functionality in a modular fashion using traits. We can plug the isolated functionality in every class if needed. To equip the Photo class with logging functionality, we mixed in the Loggable trait, for ordering the Ordered trait. These traits are reusable in other classes.

Traits are a powerful mechanism to create modular and DRY (Don’t Repeat Yourself) code using built-in language features, without having to rely on extra technology complexity like aspect oriented programming.

The Motivation for Virtual Extension Methods

For many existing interfaces it would be very beneficial to have support for lambda expressions in the form of higher-order functions. As an example, let’s consider the java.util.Collection interface. It would be desirable for the java.util.Collection interface to provide a forEach(lambdaExpr) method. If such a method was added to the interface without a default implementation, all implementing classes would have to provide one. It is self-evident that this would lead to a very challenging compatibility hell.

That’s why the JDK team came up with virtual extension methods. With this feature a forEach method, for example, could be added to java.util.Collection including a default implementation. Consequently, all implementing classes will automatically inherit this method and its implementation. By doing so, their API is able to evolve in a completely non-intrusive way, which is exactly what virtual extension methods intend to achieve. If the implementing class is not satisfied with the default implementation, it simply can override it.

Virtual Extension Methods vs Traits

The primary motivator for virtual extension methods is API evolution. A welcome side effect is that they offer a form of multiple inheritance, which is limited to behaviour. Traits in Scala not only provide multiple inheritance of behaviour, but also of state. Besides state and behaviour inheritance, traits offer a means to get a reference to the implementing class, shown with the ‘self‘ field in the Loggable example.

From a usage point of view, traits offer a richer set of features than virtual extension methods. However, their motivation is different: in Scala traits were always intended as modular building blocks that offer multiple inheritance ‘without the issues’, whereas virtual extension methods primarily have to enable API evolution and in the second place ‘multiple behaviour inheritance’.

The Loggable and Ordered Traits in Java 8

In order to see what we can achieve with virtual extension methods, let’s try to implement the Ordered and Loggable trait in Java 8.

The Ordered trait could be fully implemented with virtual extension methods, because no state is involved. As mentioned the counterpart of Scala’s Ordered trait is java.lang.Comparable in Java. The implementation would look as follows:

We added new comparison methods to the existing Comparable interface (‘greater than’, ‘greater than or equals’, ‘less than’, ‘less than or equals’ identical to those found in the Ordered trait: >, >=, <, <=). The default implementation, marked with the default keyword, forwards all calls to the existing abstract compare method. The result is that an existing interfaces is enriched with new methods, without the need for classes implementing Comparable to implement these methods as well. The Ordered trait in Scala looks quite similar to this implementation.

If the Photo class implemented Comparable, we also would be able to perform comparison operations with those newly added methods:

In this example, we add log methods, like debug, info etc., to the Loggable interface, that by default delegate their calls to the static Logger instance. What we miss is a means to get a reference to the implementing class. Because this mechanism is lacking, we use the Loggable interface as logger, which would log all statements under Loggable instead of the implementing class. Because of this limitation, virtual extension methods are less suitable for such a usage scenario.

To sum up, traits and virtual extension methods both provide multiple inheritance for behaviour. Traits also provide multiple inheritance for state and a means to acquire a handle to the implementing class.

Conclusion

Java 8 is going to provide a variety of new language features, with the potential to fundamentally change the way we write applications. Especially the functional programming constructs, such as lambda expressions, can be considered a paradigm shift. This shift provides great new possibilities for more concise, compact and easy to understand code.

In addition, lambda expressions are key to enabling parallel processing.

As explained in this article all these features are already available in Scala. Developers who want to try them out can explore early builds of Java 8 on most platforms. Alternatively, we recommend taking a look at Scala as a way of preparing for the paradigm shifts to come.

Appendix

About the Authors

Urs Peter is Senior Consultant at Xebia. With more than ten years of experience in IT he has held many roles, ranging from developer, software architect, team lead and Scrum master. During his career he has explored a broad range of languages, software development techniques and tools for the JVM platform. He is one of the first certified Scala trainers in Europe and current chairman of the Dutch Scala Enthusiast community (DUSE).

Sander van den Berg has been active in IT since 1999, working as a software developer for several defence related companies, mainly working on MDA/MDD solutions. He joined Xebia as a Senior Consultant in 2010, where he is responsible for Xebia’s Lean Architecture approach and the promotion of Scala. Besides architecture, Sander is interested in language design. He is active in several functional programming communities. Sander likes elegant solutions to hard problems, preferring Scala as a means to express them. Sander enjoys many languages, amongst them Clojure, Haskell and F#.

Re: Hmm

Your message is awaiting moderation. Thank you for participating in the discussion.

Going straight to Scala may or may not make sense for a particular organization. There certainly is a learning curve, and if your developers' software skills are modest, then a wholesale switch to Scala could be difficult. Of course, it is possible to write new code in Scala on an existing Java project; my group is doing that now.

But if you have nothing in particular holding you to Java, then as you suggest it may make sense to just go to Scala. Scala already has in its 2.9.2 release far more power and ergonomics than Java is likely to ever achieve, and it certainly won't be sitting still between now and 2013. Among other things Scala's upcoming 2.10 release introduces macros, which should enable interesting new features in Scala and associated libraries downstream.

Tool support is in general still somewhat better for Java, with one very notable exception -- Scala has a good REPL, and that is incredibly handy.

For some organizations, the pain of switching to Scala may lead them to just accept enhancements to Java as they emerge.

By the way, the Scala folks are delighted that Java 8 will have lambdas, since that will ultimately result in attention to performance of such code, and perhaps even to how it is represented in classfiles. Scala will likely benefit from the resulting improvements.

Great article

Your message is awaiting moderation. Thank you for participating in the discussion.

Thanks for the lucid explanation of new Java 8 features and the comparison with Scala. Notwithstanding the nice new features in Java 8, Scala seems (in my opinion) to remain significantly more concise and clean than Java.

Re:

Your message is awaiting moderation. Thank you for participating in the discussion.

As a java developer with no prior knowledge of scala I have hard time understanding benefits of turning java into scala. Being dependent on the compiler and moving away from strong typing would be a mistake as it could lead to multiple issues. Let the scripts be scripts and programming languages programming languages. I have seen an examples where compiler misses the case where strongly typed list of custom objects during the runtime is filled with strings, and the in the for loop does not allow to cast the content of the list to either custom object or string. There are screenshots of jdeveloper debugger if you d like to have a good laugh:).

Re:

Your message is awaiting moderation. Thank you for participating in the discussion.

Being dependent on the compiler and moving away from strong typing would be a mistake as it could lead to multiple issues.

What do you mean? Scala is strong typed, in fact its compiler works a lot on your types.

I have seen an examples where compiler misses the case where strongly typed list of custom objects during the runtime is filled with strings, and the in the for loop does not allow to cast the content of the list to either custom object or string. There are screenshots of jdeveloper debugger if you d like to have a good laugh:).

Scala's compiler can't "miss" such a case: it doesn't compile your code if the types don't add up. And, does a Scala debugger for JDeveloper exist? I didn't know that!

Trait example - logging pattern

Your message is awaiting moderation. Thank you for participating in the discussion.

Traits are great but the logging example I think is misleading.Code like this if(LOG.isDebugEnabled()) { LOG.debug("You saved me." ); }

cannot be efficiently replaced by traits. The reason for the code pattern above is to improve performance because debug expression is not evaluated in case of false 'if' condition. Makes no difference when we deal with simple string, but usually debug expressions look like this:

"saving object" + this + " by " + Current.getUser()

So, in case of inlining inside of if statement the expression above is not evaluated when debug is not enabled, but will be evaluated if we pass it to debug method implemented by trait slowing down execution even if debug is not enabled. Concatenating strings and objects calling theirs toString() methods can be quite expensive.

Re: Trait example - logging pattern

Your message is awaiting moderation. Thank you for participating in the discussion.

Sorry but I feel, your objection is not valid. As Peter (the author) put it: "the msg function (argument) that will return the String to be logged is only invoked when the isDebugEnabled check succeeds.".

Traits are great but the logging example I think is misleading.Code like this if(LOG.isDebugEnabled()) { LOG.debug("You saved me." ); }

cannot be efficiently replaced by traits. The reason for the code pattern above is to improve performance because debug expression is not evaluated in case of false 'if' condition.

Re: Hmm

Your message is awaiting moderation. Thank you for participating in the discussion.

REPL tools are extremely handy. For Java, I use the Groovy REPL, which is basically a superset of Java. There are other Java REPL implementations out there as well. I like having an official REPL like Scala does, but that's a small issue.

I love having both Java and Scala on the JVM.

Scala is absolutely more elegant and beautiful, but has a long learning curve. Java is much simpler, which is sometimes extremely important, and the tools are much more stable.

Java 8 getting lambdas and the extension methods will benefit the Scala community, because the general JVM ecosystem will take heavy advantage of those features, and the VM will be heavily performance tuned for it.

Re: Nothing that we have not seen in C# 3.5 in 2007

Your message is awaiting moderation. Thank you for participating in the discussion.

Clojure is now five years old and had the above features (high order fns, closures, fn literals,immutable collections, parallel processing, ...) from the start. Not as an afterthought.

I am not certain it will be funny to work on a migrated Java code base a couple of years after version 8 is released.

Languages created according to a restricted vision of the world(we can argue later about the object approach and how restricted it may be but it's a definite orientation)can rarely evolve into something nice when integrating alien features.

A mix of old object design code and this new stuff will most probably be a challenge to maintain.Seeing how slow Java shops evolve these days, it may take years before there is some adoption of theabove features.

Re:

Your message is awaiting moderation. Thank you for participating in the discussion.

As a Basic/Assembler/Fortran/Cobol/Lisp/Pascal/C/C+/Java/Clojure developer, I can assure you that strong data typingas a full proof rail guard has nothing to do with being a good (or bad) programmer.

The advantages of dynamic languages have been know for decades. It's time to improve our throughput.We, the wetware, are the obstacle to productivity. I used to code tens of thousands of assembler code linesand was pretty good at it. But this was a choice made because nothing else was available in these days.

More concise and expressive languages is the way to follow if we expect to create software to addressmoe complex problems.

Clarification on closures

Your message is awaiting moderation. Thank you for participating in the discussion.

From what I've read before, true closures aren't present in Java 8 Lambdas because in true closures, the values of the surrounding variables are available "frozen in time". This is how they work in Javascript. In Java 8, the values of the surrounding variables may change from when the lambda is created and when it is run.