Evolution in Data Integration From EII to Big Data
Approaches to integrating data are changing with emergence of cloud computing.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
State of the Lambda
Posted by Alex Blewitt on Dec 16, 2011
Brian Goetz has published an updated state of the lambda, giving a status report on the plan for adding lambdas to the Java language (also being tracked as JSR 335 and Java Enhancement Proposal number 126.
The plan to bring lambdas to the Java language covers both the syntax for anonymous functions, as well as plans to extend the existing set of Java classes (such as Collections) with methods that accept lambdas as well. The goal is to add functions like map and filter to allow collections to be processed in a more functional way.
In order to retrofit these on existing interfaces (and not just the core Java classes), a new type of method has been added to interfaces called default methods (previously called defender methods in earlier versions). These effectively allow an interface to carry method implementations, much like Scala's traits or an abstract class would. When invoking a default method, if the compiler will initially delegate to the instance, but if a method is not found in the course of normal method resolution, the default method will be invoked instead. Unlike earlier revisions, instead of being a pointer to an existing class' static method, the new specification permits methods (but not fields) as valid interface bodies – albeit identified with the default keyword. The example given is that of adding a skip() method to all iterators:
interface Iterator<E> {
boolean hasNext();
E next();
void remove();
void skip(int i) default {
for (; i > 0 && hasNext(); i--) next();
}
}
Since this is effectively adding multiple inheritance of behavior to the Java language, in the case of a collision (where the same default method is inherited by two separate paths) the method must be overridden in that class, or one of the default methods explicitly selected via a new Iterator.super.skip() construct.
Another recent change is the proposed syntax change for method references, from a JavaDoc-inspired Person#compare to a more C++ inspired Person::compare. Whatever the syntax, the method reference gives a way of effectively providing a typechecked shortcut to a Method to pas around into a lambda capturing method.
Although the actual lambda expressions haven't changed that much, some of the syntax parts and terminology has been recently revised. For example, whereas the previous decision was to use =>, used by both C# and Scala as the syntax for introducing a lambda expression, the syntax has been updated to be -> instead. So a function which now returns the negation of itself might be written int a -> a+1. (If the type is able to be inferred, then it is used instead; in the case of this expression however the compiler cannot know if we mean a to be a byte, short, int or long, so we must disambiguate explicitly.)
Another terminology change is the idea of classes like Runnable and Action. These are interfaces with a single abstract method, formerly called SAM types. To support the wider use of them in Java, these are now known as functional interfaces. The reason for this change is to encourage the use of these as being up-castable from a method reference; so where an existing Java codebase has methods which expect Comparator instances, you can now pass in a lambda expression (or method handle) which has the same signature as Comparator's compareTo method. Although technically, Comparator has two abstract methods (compareTo() and, for some reason, equals()), this is still seen as a functional interface as equals() is already available on Object.
Although function types were considered (and available in an earlier draft) they have been rejected – at least, for now – due to difficulties with function type erasure causing problems in the current version of the JVM. Although this doesn't rule it out in the future, the expectation is that the type-based functional interfaces will be more immediately useful both to Java and existing Java classes than a new functional type would be.
Lambdas continue to have an advantage in that the argument types can be inferred without having to be explicitly typed (unless there is a disambiguation needed, as above). Lambdas can also be recursive and capture state from their enclosing scope (lambdas, like inner classes, which capture enclosing scope are known as closures) – although that capture is only for final variables, again like inner classes. However, the introduction of effectively final means that the final can be inferred in most places and need not be explicitly mentioned.
The addition of lambdas to the Java language, along with method references, will significantly reduce the amount of boilerplate needed for common operations. For example, in order to sort an Array of Strings with case-insensitive comparison, you will be able to do:
Arrays.sort(names, String::compareToIgnoreCase)
Together with default methods, which enable interfaces to grow (like Scala's traits) without affecting existing code, writing Java code will be much more concise. A fully functional-object hybrid it isn't, but the foundations will see the rise of a number of functional-style libraries available for JDK8 and beyond. And whilst code compiled with lambdas and default methods won't be runnable on anything older than JDK8, it will permit the use of code compiled against older versions of the JDK to run, and be used in a functional way, in much the same way that generic types were slowly brought into the Java language.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Monitor your Production Java App - includes JMX! Low Overhead - Free download
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
arnaud m
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
arnaud m
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
arnaud m
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
arnaud m
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
arnaud m
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
arnaud m
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
Faisal Waris
Posted
Re: Why not go directly to Scala
by
Steve McJones
Posted
Re: Why not go directly to Scala
by
arnaud m
Posted
Re: Why not go directly to Scala
by
Sorin Suciu
Posted
Re: Why not go directly to Scala
by
arnaud m
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
arnaud m
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
Karl Peterbauer
Posted
Re: Why not go directly to Scala
by
Andrea Del Bene
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
Andrea Del Bene
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Re: Why not go directly to Scala
by
Diego Fernandez
Posted
Re: Why not go directly to Scala
by
Serge Bureau
Posted
Forget JDK8(1.8) and give me the true JDK2.0
by
light iron
Posted
Re: Forget JDK8(1.8) and give me the true JDK2.0
by
Faisal Waris
Posted
Looking good
by
Jesse Kuhnert
Posted
-
The numerous patch attempts to Java are incredibly slow coming and are all afterthoughts.
They should move to something having all of this the right way. Then we could really move on.
I loved Java, not anymore: it has to be replaced -
Because Scala breaks binary compatibility at each release,
Because Scala has performance issues,
Because tooling is not as good as java (yet?),
Because Java code is easier to understand by non-expert developers,
...
Closures in Java should have been implemented as syntaxic sugar around inner classes several years ago,
it would have avoided so many discussions (Joshua Bloch).
I agree that Java evolves too slowly (but it seems that things are moving again now),
and if it's the price to pay to keep the language robust, stable and simple, it's ok for me. -
Because Scala breaks binary compatibility at each release,
Because Scala has performance issues,
Because tooling is not as good as java (yet?),
Because Java code is easier to understand by non-expert developers,
...
Binary compatibility is also an overblown issue, but it needs to be addressed.Hundreds of language have this on a much larger scale. Small price for the flexibility and evolution.
Performance issues ?? In general because it is more expressive you get more performance and much better algorithm and abstraction. It is like saying that a type of collection is slow, choose another one ! They have parallels ones, where are the Java ones ? Be serious.
Tooling is old news, the latest Eclipse plugin is really good, plus testing tools are much better than Java ones and order of magnitude more expressive. Plus since the code is 3 to 5 times smaller than Java, it is much easier to maintain.
As far as understanding, once again, having 3 times less lines means easier to understand.
Some abstractions are more mathematical, but at least they are available. Where are those facilities in Java ?
And understanding comes with the use. Java generics is the most incredible mess, talk about being easy ??? -
Forget all old f**kin Java code base.
Let's change! All!
So many things we can learn from.
.Net CLI(not Mono), Erlang VM, Haskell, Go and more.
Google, you are the only one who can create this new world(VM not just Language).
IL -
Yes, it's easier to change a language when you don't maintain compatibility.
But not everyone has time to upgrade dependencies when you have to maintain and enhance an app for several years.
About perfs:
It seems there was some surprising behaviors in simple code, ex: groups.google.com/group/scala-debate/browse_thr...
Maybe they are fixed now.
"the code is 3 to 5 times smaller than Java, it is much easier to maintain"
so maintenability = code size?
"Be serious" :)
But I agree that Java is too verbose. JDK8 will improve that (JDK7 has already some improvements).
Java generics: yes, far from perfect, but "overblown issue", and very useful anyway. -
Yes it is always the next Java that will get things done.
Look at how generics works, twice Java was not binary compatible.
Yes generally size means more maintainability. Your head has only a certain number of lines it can tackle simultaneously also there is the abstraction level where Java is incredibly weak compared with Scala.
Scala is not perfect, but Java totally pales in comparison.
So where do you take your customer into consideration ? Continue to generate bloated code and wait for Java 8,9,10,11,12 ... Very logical. -
I don't understand what you mean about generic.
With JDK 1.5, you could use old jar that were not generic-aware.
You don't have to switch to a whole new package of collections for instance or recompile.
It has worked very well for me.
Sometimes compact code is more readable the next day, but not the next year.
It seems that Scala code can be written using very style/dialect, and that could be as bad as verbose code.
(I don't say that Java is more readable, just that code size is not the only aspect.)
For instance, many people would like optional typing in Javascript, and even if it makes the code more verbose, it would make it more understandable by someone who doesn't write it.
You can use one letter for all your variable names if you want, it would be more compact, but your coworkers would not be happy.
Yes all java developers don't take their "customers into consideration" and "generate bloated code".
Everybody knows that.
However I am more interested in objective arguments that show me that Scala is now more stable and mature, and that I can switch from Java to Scala without too much risk for my compagny. -
Yes sure all the companies using Scala are idiots and know a lot less than you do.
And yes companies generate a lot of bloated code and do not care.
They made change into the language, they also moved Swing package, your memory is quite selective.
As far as Generics, I was referring to the unreadable mess it is. Talk about easy to read.
Have fun waiting on Java improvement. You are definitely more patient than me. -
Very excited about jdk8 coming out eventually. Thanks jdk team, keep up the good work! =)
-
Each compagny has its own constraints.
So choosing java or scala (or switching to) is really dependent on the context.
I think none of them is the best choice for everybody (today). But that may change.
(Nobody is "idiot".)
A Java enhancement is good of course for the java community (especially for the guys like me that can't rewrite large application from scratch), but also can be good for the JVM community because it can provide better low-level mechanisms for other languages. -
Each compagny has its own constraints.
So choosing java or scala (or switching to) is really dependent on the context.
I think none of them is the best choice for everybody (today). But that may change.
(Nobody is "idiot".)
I would say not "everybody is idiot". Many are and many are dishonest.
But of course I agree with you that constraints and context are important to decide when and how to make a move.
But refusing or denying a move is not a valid option anymore.
Java 8,9 ,10 are too slow coming and non elegant patches.
A Java enhancement is good of course for the java community (especially for the guys like me that can't rewrite large application from scratch), but also can be good for the JVM community because it can provide better low-level mechanisms for other languages.
I do not see the "of course", and since when using Scala or Groovy or any other JVM based languages would involve a "rewrite from scratch" ???
The JVM is the link to preserve, and of course the thousands of Java library are an awesome resource , but the code from now on would be much better served by most Java alternatives.
Faster, smaller, nimbler, more scalable, better abstraction, more consistent , simply much more powerful. -
For larger enterprises (with their long technology cycle times) Java 8 is realistically a 4 year wait.
Note the whole iPhone phenomenon is about 4 years old - a lot can change.
Even while waiting for Java 8 to arrive, I believe one should learn languages like Scala, Haskell and F# (statically typed, functional) so as to become better Java developers in future. -
Because Scala breaks binary compatibility at each release,
Wrong.Because Scala has performance issues,
Mainly wrong. Link please.Because tooling is not as good as java (yet?),
What do ynu miss?Because Java code is easier to understand by non-expert developers,
Wrong.Closures in Java should have been implemented as syntaxic sugar around inner classes several years ago,
it would have avoided so many discussions (Joshua Bloch).
This wouldn't have solved the problem of producing dozens of classfiles per “real class”.I agree that Java evolves too slowly (but it seems that things are moving again now),
and if it's the price to pay to keep the language robust, stable and simple, it's ok for me.
I wouldn't call Java simple. Maybe familiar to you, but simple? Hell, no. -
Sample link about binary compatibility:
ceki.blogspot.com/2011/08/is-scala-trustworthy....
Perf of for-loop and other things:
gist.github.com/1406238
Yes, JDK8 closure implementation is supposed have some native JVM support and avoid too many classes like current JDK inner classes, so it will be better than just "improved inner class syntax".
Anyway Scala seems to have the same problem (see previous link) for the same reason, no surprise:
"At some point, we stopped seeing lambdas as free and started seeing them as syntactic sugar on top of anonymous classes and thus acquired the same distaste for them as we did anonymous classes". -
since when using Scala or Groovy or any other JVM based languages would involve a "rewrite from scratch" ?
You mean writing new code in Scala and still calling/maintaing the old java code?
Yes, why not.
Does someone has references about compagnies/apps doing that (not just reusing third-party compiled java jar)?
I don't know if it easy to switch between java/scala sources when you read code. I do that for Java/Javascript/C++ and it's not always easy. Maybe the IDE tooling is better between Java and Scala. -
Let's change! All!
So many things we can learn from.
.Net CLI(not Mono), Erlang VM, Haskell, Go and more.
+1 - yes Java needs a much bigger overhaul, starting from the VM up.
It's time to cut the cord on backward compatibility and start afresh. Legacy baggage is dragging Java and other JVM languages down. -
This compares the speed of different languages:
shootout.alioth.debian.org/u32/which-programmin...
So scala is a bit slower than Java, but not significantly. -
Yes, that is one of the most interesting aspect of Scala (for me):
it's a modern language with advanced features but at the same time, it keeps a good performance level unlike many others.
However after reading some recent articles, to get that speed, a developer may have to not use some modern features (as explained in gist.github.com/1406238) and go back to java-style code.
But maybe it's just a matter of compiler optimization, that can be quickly fixed. I don't know. -
Scala runs on the JVM and generates classes similar to Java.
It can interact transparently with Java classes. From Scala to Java it is doable but you need some interfaces sometimes as some features have no equivalent in Java.
Using Java in Scala is transparent, no tool needed.
Companies are of course not throwing away their Java libraries, you progress into Scala: no need to forget all that came before. All Java frameworks are available (Spring, Struts, EJB, ...)
Javasript and C++ are not running on a JVM so it is not at all the same. -
As I said previously you can always find examples where Java is faster and other where Scala is faster.
But because of the much better abstraction of Scala and smaller code you generally generate much better algorithm than Java, so you are faster in Scala.
Anybody doing assembler instead as C/C++ on system code ? No because the C algorithms are better than the assembler equivalent so it is generally smaller and faster in C
And Scala is much more an improvement than going from assembler to C !!! -
I know that Java & Scala run on the same JVM/bytecode. :)
I was rather talking about source code "navigability" in the IDE. -
At runtime, there is no major difference between C and assembler, so this example doesn't exactly match here.
But the article seems to say that sometimes, when you use something in Scala that is a bit "higher level" than Java,
it has a hidden cost at runtime, ex:
"Don't ever use a for-loop. Creating a new object for the loop closure,
passing it to the iterable, etc., ends up being a forest of invokevirtual calls"
2 possible reasons:
- the scala compiler has to be improved (more optimized bytecode generation)
- the current JVM bytecode is too "java-oriented" and needs new instruction (a la invokedynamic)
I agree than even with that, you may have faster scala code in practice, because you may implement more complex algorithms more quickly/easily. -
I know that Java & Scala run on the same JVM/bytecode. :)
I was rather talking about source code "navigability" in the IDE.
Sorry, at least the Eclipse IDE does work on this, I suppose the IntelliJ Idea one does. -
As far as the for loop, I do not know the exact reason and I agree it should be investigated.
But to be honest this is not the functional way of iterating and that I do not think experienced Scala users do it that way. -
I'm really sick of the messianic haughtiness of many Scala proponents and their obsessive Java bashing.
-
I won't change language just because the new one "has more feature". For now Java is simply right for me and I really appreciate its simple syntax and its 'thin' object model. The missing of functional programming it's not the end of the world, and with Java 8 will compensate this lack.
-
I won't change language just because the new one "has more feature". For now Java is simply right for me and I really appreciate its simple syntax and its 'thin' object model. The missing of functional programming it's not the end of the world, and with Java 8 will compensate this lack.
I am happy Java fulfills your needs.
But Java does not provide solutions to many of today's issue (at least not in an easy way):
- multi-threading with locks in a distributed system is painful an error prone
- using Java generics is an exercise in insanity
- no easy way to return multiple values (look for tuples)
- no real object matching
- primitive XML support
- weak package permission support
- very bad handling of null pointer exception
- no real DSL support
- ...
I am happy you do not need any of that -
Obviously I'm not saying Java is perfect, in this world everything can be improved. I've said that for me a simple and readable language is VERY important, more important then some features you can live without and which will be (almost all) available in Java 8.
Java has been successfully adopted for very large distributed/scalable systems, and with a reasonable amount of work.
Anyway, for some tasks I agree that Scala can be better then Java, but I wouldn't say "java is old, leave it now!", it doesn't make sense to me. -
Anyway, for some tasks I agree that Scala can be better then Java, but I wouldn't say "java is old, leave it now!", it doesn't make sense to me.
I use to think that way, but I already lost too much time.
I am not waiting for half baked solutions and patch like Java Generics.
So have fun waiting for Java 8,9,10, ...
If you haven't look at Scala, you do not know what your missing. -
Serge your fanaticism to promote Scala doesn't let you see what are the problems that a platform like Java (and hence Scala) have to evolve.
I've used Scala, Groovy and other languages like Smalltalk or Haskell, so I don't want to put the language features under discussion: Java -the language- was always very conservative since its inception, and languages with better abstraction mechanisms existed before it (from Smalltalk/Strongtalk/Self to Lisp).
From my point of view the core problem is that Java -the platform, and that includes by extension Scala- was always very monolithic: you cannot choose to have different versions of the existing core libraries coexisting in the same runtime.
That is a problem in Scala too.The difference is that in Scala, the problem is more visible because the core libraries evolves faster.
But as Java, Scala doesn't have today means to specify dependencies between your code and specific versions of the core framework.
To be fair, that is a difficult problem to resolve, but I think that is a problem that must be addressed by the programing languages/platforms of the future.
In the mean time, choose any JVM language that makes you happy :) -
I do agree with you.
But as far as I know, no language has really solved that issue.
Some can at least detect the change, but not fix it.
In fact I am not sure it is doable, but I might be wrong.
Fanaticism, or very enthusiastic ?
To me I see no reasons to wait for the next Java releases, as they promise little and deliver even less.
But the legacy of Java libraries is huge and very useful.
31 comments
Watch Thread Reply