JCrete2013:Java 8 Future

From WikiEducator
Jump to: navigation, search
Java 8 Future
Convenor: Sven Reimers
Participants:
  • Kirk Pepperdine
  • Heinz Kabutz
  • Angelo D' Angano
  • David Gomez
  • Giannis Skitsas
  • Alex Kashmir
  • Elizabeth Kashmir
  • Kruno Markotic
  • Maurice Naftalin
  • Giorgos Peponakis
  • Maz Rashid
  • Thomas Weil
  • Andres Taylor
  • Gregor Koukkoullis
  • Giannis Ledakis
  • John Kostaras
  • Marek Nowicki
Summary:
Day 3, Session 2 - Java 8 and the Future of Java - JCrete2013


Free content media streamed from Wikimedia Commons
Cc-sa.svg

Download:
Download: .ogg

How to reduce boilerplate, do more with less code. Discussion started with introduction of lambdas but then redirected to a more broader discussion on syntax and self-documenting (more expressive) code.

Java 8 introduces two mindsets:

  • functional programming
  • asynchronous processing

Maurice pointed out that Oracle is very interested in getting feedback from the developers (something that was hard to get with Generics).

It is very difficult to understand how type inference works. It is difficult to work out class overloading though. Type inference (in the context of lambdas) is how the language understands the type of an expression (e.g. whether a block of code is a callable or a runnable) since in lambda expressions most of the type the developer doesn't provide the type.

Parallel streams do not necessarily run the faster.

Rickard mentions that the stream source is asynchronous. How to have a synchronous stream(), something like an isDone() method?

Maz asked what about debugging and logging?

Rickard asked: "will lambdas make java developers to move more to Scala, or remove Scala code that can be done by Java lambdas".

Scala moves much quicker than Java does. There is no disruptive motivation to move to Scala. Maurice thinks that there will not be much difference, as Java is a "blue colour" language. If Java had lambdas from the beginning, then developers might have not switched to Scala.

Kirk argued that languages not need be to be limited to be simple.

Kruno argued that Java doesn't need to cover everything. There are languages that are more expressive than Java.

Recommendations:
  • Tools cannot replace craftmanship
  • Use metrics tools to check your code (e.g. Sonar)