0

Are the new, functionally-inspired features of Java 8 well-regarded within the enterprise development community? Have they been adopted by large companies? Have coding standards been updated to account for them?

I'm in the process of completing a programming exercise for an interview. I don't write much Java, and this is my first time playing with the new features (which I think are fantastic). The company seems very "old fashioned" to me. I'm wondering if they'll find code like:

public String currentInventory() {
    String inventory = prices.entrySet().stream()
            .map(entry -> String.join(",", entry.getKey(), entry.getValue().toString()))
            .collect(Collectors.joining("\n"));

    return inventory;
}

to be strange.

Patrick Collins
  • 2,165
  • 18
  • 24
  • Adoption of Java 8 features is going to vary widely, based on a number of factors, including company culture. I think the answer to this question is going to be based largely on opinion. – sea-rob Jan 04 '15 at 07:27
  • 1
    @RobY I disagree, I think there are objective answers to this question. I'm not asking what *you* think, I'm asking what it's standing is in the industry. [This question](http://programmers.stackexchange.com/questions/63859/why-do-people-hesitate-to-use-python-3) is similar and not closed. [This one is, too](http://programmers.stackexchange.com/questions/39371/what-are-the-factors-that-have-made-java-a-success-as-a-programming-language-in?rq=1). – Patrick Collins Jan 04 '15 at 07:33
  • I certainly find `String.join(",", entry.getKey(), entry.getValue().toString())` strange, compared to `entry.getKey() + "," + entry.getValue()` – user253751 Jan 04 '15 at 07:36
  • 1
    Sorry, no offense; it's just that people are going to chime in with "we're using it" or "we hate it", but there aren't any real objective ways to capture the *state of adoption* or *attitude* of the industry. Much less reading the minds of the folks you're interviewing with! Also, a year from now, the landscape will be completely different, so people's opinion of these features will be very different then than now. Interesting question, but doesn't seem appropriate for here. – sea-rob Jan 04 '15 at 07:41
  • @immibis I wasn't aware that `+` implicitly calls `.toString()`? I wrote that mostly because I would have written `",".join(...)` in Python. – Patrick Collins Jan 04 '15 at 07:43
  • And @RobY: okay, fair enough. I'm hoping that it can attract some good answers, but if it's closed then it's closed. – Patrick Collins Jan 04 '15 at 07:44
  • Definitely not appropriate. – DeadMG Jan 04 '15 at 10:03

1 Answers1

3

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.

Community
  • 1
scriptin
  • 4,432
  • 21
  • 32
  • "Java 7 code will mostly compile fine with JDK 8": What are the most important constructs that will not compile? – Giorgio Jan 04 '15 at 21:41
  • @Giorgio just take your java 7 code and compile it with `javac -source 1.8 -target 1.8` - there are NO language level (or byte code level, for that matter) constructs in Java 7 that would NOT compile with JDK8. The only way I've seen it failed was when where was an *explicit* (and incorrect) checking of java version in the code - that's what I meant when said "mostly". It is *fully* backwards compatible, unless someone messed it up. – scriptin Jan 05 '15 at 22:10
  • @Giorgio I believe there was actually a bug in the Java 1.7 compiler that would allow certain generics code that technically was invalid, and that the bug was corrected in Java 1.8, so certain code could compile in 1.7 but not 1.7. But I might have it backward. – Reinstate Monica Aug 09 '16 at 19:54