There's a survey conducted in September 2014 which shows that Java 8 has already been widely adopted: Survey of More Than 3,000 Developers Reveals Java 8 Adoption Ahead of Previous Forecasts.
The report shows that 27% of those who filled out the survey have already upgraded to Java 8, with a further 36% planning to upgrade within the next 12 months (from the time of taking the survey). Only 23% of respondents were yet to evaluate Java 8.
21% of those who already upgraded to the latest Java version are using it in production, with a further 36% in staging or planning to upgrade their production environment shortly and 40% running pilots or testing with Java 8.
-- Typesafe survey: Java 8 Adoption Strong, Users Anxious for Java 9
The main reported migration problem is legacy architecture:
Of Java 8 "holdouts," 69% are running Java 7 and 26% are running Java 6. For the majority of Java holdouts, the main challenge to migrating to the latest release is their past. 37% cited "hurdles with legacy infrastructure" while 19% cited organizational obstacles. Only 19% called out specific concerns with Java 8.
I've had the exact same experience. Language migration is almost painless, unless there is some old library somewhere in dependencies which refuses to work with Java 8 (I saw this once, library mistakenly detected Java 8 as Java 4 because of incorrect
if condition). The problem was (and still is) switching deployment environments to Java 8: bash scripts, OS packages, application servers, etc.
Two main reasons to switch are:
- It is easy because of backwards compatibility: Java 7 code will mostly compile fine with JDK 8. You lose nothing and still can write the old-fashioned code if you like.
- You get the new features, and those are not just lambdas. For example, if you use Joda-Time, there is a new Time API, which is recommended replacement for Joda-Time.
I'm wondering if they'll find code like: ... to be strange.
I'd ask them if they want to see Java 8 or Java 7 code, if it wasn't stated in requirements for solution.