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.

Improve this question
7
  • 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 4, 2015 at 7: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 is similar and not closed. This one is, too.
    – Patrick Collins
    Jan 4, 2015 at 7:33
  • I certainly find String.join(",", entry.getKey(), entry.getValue().toString()) strange, compared to entry.getKey() + "," + entry.getValue()
    – user253751
    Jan 4, 2015 at 7: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 4, 2015 at 7: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 4, 2015 at 7:43

1 Answer 1

Reset to default
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.

Improve this answer
3
  • "Java 7 code will mostly compile fine with JDK 8": What are the most important constructs that will not compile?
    – Giorgio
    Jan 4, 2015 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 5, 2015 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 9, 2016 at 19:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.