• Post Reply Bookmark Topic Watch Topic
  • New Topic

Richard Warburton: Functional Future of Java

 
Yagiz Erkan
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Richard,

Lambdas, Streams, Optional, etc... With Java 8, Java has taken a step into Functional Programming. I guess it's better late than never. This has, without a doubt, raised the Java community's curiosity and awareness of FP in general. As someone who has been working with Java 8 for more than 2 years, do you see Java going deeper into FP in its future versions? If yes, what would you like to see added/adopted next?

Thank you.
 
Richard Warburton
Author
Greenhorn
Posts: 22
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yagiz Erkan wrote:Hi Richard,

Lambdas, Streams, Optional, etc... With Java 8, Java has taken a step into Functional Programming. I guess it's better late than never. This has, without a doubt, raised the Java community's curiosity and awareness of FP in general. As someone who has been working with Java 8 for more than 2 years, do you see Java going deeper into FP in its future versions? If yes, what would you like to see added/adopted next?

Thank you.


Hi Yagiz,

I do see a more functional style of Java being adopted over the next few years. I think the biggest win is getting people familiar and comfortable with the features in Java 8, but I imagine there will be other changes in support of a functional style. Here's some ideas:

* Value Types. Functional programming means allocating and using lots of small objects in local scopes. Introducing value types would help make a functional style more efficient and potentially easier if they add some syntactic sugar (eg case classes). There's a proposal at [0]
* Simplified Generics. If you look at the streams api there are is a load of wildcard generics usage. People don't understand wildcards or generics that well - but understanding them is important in using lambda-heavy APIs effectively. One solution would be to add Scala's approach of declaration site variance rather than use-site variance. Its a bit of an involved topic so I won't expain things in detail here - [1] provides interesting details of the alternatives.
* Intrisify Primitive Generics. The streams API has a bunch of code which has ended up with primitive specialised versions (eg: IntStream, DoubleStream etc.) They did this because there are significant performance (mainly locality of reference) and memory overheads with boxed numbers, ie Integer vs int. It would be nice if I was able to have something like an ArrayList<int> and we wouldn't have to use these kind of hacks for performance.

[0] http://cr.openjdk.java.net/~jrose/values/values-0.html
[1] http://stackoverflow.com/questions/4231305/how-does-javas-use-site-variance-compare-to-cs-declaration-site-variance
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!