Slashdot Mirror


Slashdot Asks: What Are Your Favorite Java 8 Features? (infoworld.com)

New submitter liveedu shares with us a report from InfoWorld: When Java 8 was released two years ago, the community graciously accepted it, seeing it as a huge step toward making Java better. Its unique selling point is the attention paid to every aspect of the programming language, including JVM (Java Virtual Machine), the compiler, and other help-system improvements. Java is one of the most searched programming languages according to TIOBE index for July 2016, where Java ranks number one. Its popularity is also seen on LiveCoding, a social live coding platform for engineers around the world, where hundreds and thousands of Java projects are broadcasted live. InfoWorld highlights five Java 8 features for developers in their report: lambda expressions, JavaScript Nashorn, date/time APIs, Stream API and concurrent accumulators. But those features only scratch the surface. What makes Java 8 amazing in your opinion? What are your favorite Java 8 features that help you write high quality code? You can view the entire list of changes made to the programming language here.

5 of 427 comments (clear)

  1. Major features are complementary by benjfowler · · Score: 5, Informative

    The biggest news in Java 8, obviously, are lambdas, but they also fit together with functional interfaces and java.util.stream.Stream to really change the way you build stuff in Java.

    I'm absolutely loving, after making use of Java 8 streams, just how clean, succinct and compact a lot of my new code has become.

    Oh -- and yes -- Java now has monads:


    public String getLastFour(Optional employee) {
    return employee.flatMap(employee -> employee.getPrimaryAddress())
    .flatMap(address -> address.getZipCode())
    .flatMap(zip -> zip.getLastFour())
    .orElseThrow(() -> new FMLException("Missing data"));

    }

    See here

    (Now if only they borrowed a bit more heavily from Scala or even C#: stuff like a Try monad, tuples and tuple destructuring and proper pattern matching (like C# is getting) would be awesome. Although given the glacial pace of standardization in Java-land, I'm not holding my breath.)

  2. Re:Java? by bobbied · · Score: 5, Informative

    Agreed. Not the best choice for anything.

    Bullocks.. There are places for using Java.. Lots of them actually...

    Now, I'm not going to blow the fan boy smoke and say Java is great for everything, it's not. I've seen applications in Java that where wholly inappropriate for the language, but because that's what the development team knew, that's what we got, with horrible results, performance and foot print problems that would make your head spin. (It made mine spin, trying to keep up with the ever expanding hardware requirements to keep that garbage running.)

    So what's Java good for? User interfaces (GUI, WEB you name it) it's great. Need it OS independent? Use Java. It's OK for data processing, but you will need lots of compute resources compared to the same thing in C++. Don't like the "hard work" involved in memory management, Use Java and restart often. However, if you have strict response time budgets, or cannot afford to cycle processes to keep running, and lots of extra hardware use something else... PLEASE use something else because I know I won't field those kinds of applications in Java for you, I've had enough pain in my life already and I'm going to quit your project if you try to make me do it again...

    --
    "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
  3. Re:Decimal Numbers? by gerald.edward.butler · · Score: 5, Informative

    BigDecimal is not a work-around. It is the exact solution to the problem.

  4. Re: Decimal Numbers? by AmazingRuss · · Score: 5, Funny

    Tents for porpoises?

  5. Re:So what would you use? by BBCWatcher · · Score: 5, Interesting

    There is a need for a light weight, garbage collected language with static typing an efficient compilation, but it does not exist. So Java it is.

    Exactly. However, Java is pretty damn lightweight and efficient nowadays -- a heck of a lot less heavy than many alternatives. Partly that's because hardware improved, but mostly it's because several Java implementations have improved tremendously over the circa two decades and counting of Java's history. So, for example, Java is a mandatory part of the Blu-ray standards on ~$50 video players. And Google's Android Runtime (ART), another implementation of Java technology, is the world's most popular smartphone platform. On the server side there are extremely fast starting, lightweight, lower memory runtimes such as IBM's WebSphere Liberty Profile. The traditional efficiency rap against Java doesn't apply any more. "Back in the day" people complained about COBOL because it was "too slow" compared to that (allegedly) hand tuned Assembler code they weren't actually writing. Well, for several years, they had a point. By about the 1970s they didn't. Hardware improved, and the compilers got a lot better -- and that process continues, also for COBOL. Java used to be slow, sure...but what's that in your hand and on your wrist now? (And color TV used to suck, and car tires used to blow out at the first pothole....)

    Another huge point in Java's (and for that matter COBOL's) favor is that it's a durable programming language. The invested value in Java code, and the ability to draw from that code portfolio to solve problems, is utterly massive. It's so massive that the Java programming language has crossed over into IT immortality along with only a very few other programming languages (FORTRAN, C, C++, and probably PL/I). Also, Java is the most demonstrably portable programming language (and compilation/runtime path) we have. (Any other nominees?) It's not at all hard to write functionally portable Java code that'll run, unmodified, on platforms ranging from Android smartwatches to z/OS mainframes. That's the default, and it really does work. High quality, performance-optimized and/or battery-optimized code is always a separate question. Any programmer can write lousy code in efficiency terms, and most do at least for Version 1.