This post was made possible with the expertise of two local developers: Kenneth Rose, Principal Software Engineer at PagerDuty (who just returned from ScalaDays in Amsterdam) and Jason Goodwin, and experienced developer who has worked on complex technical products at companies like Rogers, mDialog and BlastRadius.
Developers are solving problems at a bigger scale today than ever before. Functional programming paradigms have become increasingly attractive because they work so well with concurrency, especially with non-blocking (asynchronous) I/O. Scala has gained a following as a programming language because it has been built from the ground up to be a highly scalable, functional language. It also compiles down to bytecode just like Java does, making it possible to mix Scala and Java.
With the release of Java 8, Oracle made the biggest changes ever to Java by introducing some key functional programming concepts, moving it closer to languages like Scala. Where does this leave Scala and its relationship with Java?
Here are two things to know about the state of the Scala/Java 8 relationship today.
1. Interops between Java and Scala are in an uncertain phase.
While Java 8 is still quite bleeding edge, it looks like it’ll soon be the new normal. Oracle is phasing out support to Java 6 and 7, though paid extended support will continue to be available. The latest version of Scala that’s stable is 2.11 and it was built to be interoperable with Java 6; it only has experimental support for Java 8.
The point: Scala and Java work great together, but it depends on which version you’re using.
The onus is now on the Scala community to push version 2.12 out the door. 2.12 will only support Java 8, so 2.11 will have a longer than usual life cycle for companies that need to stay on Java 6/7 for a while (see the full Scala roadmap here).
It could also be argued that Scala and Java 8 will never be fully interoperable, if we look at interops as going beyond language version support. Interops is also about the ability of Scala and Java 8 to use each other’s concurrency mechanisms. Ultimately their functional APIs are different, making it necessary to use libraries (like the scala-java8-compat library on GitHub or this Try monad library on GitHub that Jason made) to make the actual mechanics work between the two languages. The APIs between Scala and Java 8 will never interop without converting between their respective APIs (especially functional APIs like Future or Try).
2) Even though Scala does functional programming better, Java 8 offers Java Devs a gateway to its key concepts.
You can tell Scala’s grown up in a world where concurrency has been a consideration from the get-go. Concepts like lambdas, which help describe callbacks simply, a stronger preference for immutability, simple pattern matching, are what keep developers passionate about using Scala.
While Java 8 has borrowed some key functional programming concepts, like lambdas, playing catch-up with functional programming paradigms can only go so far. With so many companies using Java 6 and 7, playing catch up to Scala doesn’t seem possible without invalidating a whole chunk of the codebase out there already.
Yet Java 8 offers a gateway to functional programming for Java developers. It’s also more realistic for most companies to retrain existing Java teams than to hire a whole new team of Scala devs, since there are less developers working with it. Java has been around for much longer so there is a far greater number of seasoned Java pros out there who can ease into functional programming concepts through Java 8.
If you can’t get Scala into your environment for some reason, Java 8’s new features (like supporting lambdas) are definitely a step towards writing more concise and maintainable code.
Have a thought, comment or experience with Java 8/Scala interops that you want to share? Leave us a comment below.