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.
Seriously? This is "journalism"? It's just a gushing promotion.
My favorite features are the brutally awful runtime performance and the incompatibility from one JVM/J2EE server to the next. Just awesome.
Runner up "feature" is the litigous vendor behind it all. I just *looooove* Oracle. They are such nice people!
This user's entire submission history consists of 2 stories about Java within an hour of each other. Smells like shill.
Have they added support for decimal numbers yet? .Net has had support for decimal numbers for quite a few years now (At least since 2003). It comes in really handy for doing applications dealing with money, which quite a lot of applications deal with. Floats and doubles don't work well with currency values as they can't hold exact decimal values for many commonly encountered numbers. There are work arounds like using integers to store the number of cents, and using classes like BigDecimal, but both of those have quite a few drawbacks.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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())
}
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.)
Java is so [Garbage Collecting] much fas [Garbage Collecting]ter then C becu [Garbage Collecting]se of its [Garbage Collecting] GC algorithms.
If y [Garbage Collecting] o [Garbage Collecting] u want raw [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] speed, you h [Garbage Collecting] ave to prog [Garbage Collecting]ram in Java, not C or [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] ASSembler.
With only 16Gb of [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] RAM, I can compile a simple h [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] ello W [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] orld program, and it only takes 15 [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] to run!
Windows should be redone in [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] [Garbage Collecting] ..out of memory, stack trace, garbage here:
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
The best thing Java ever had is good marketing, that's it.
Tools are tools. People need to quit arguing over how a tool was made and just use them.
I use Jenkins daily, it's written in Java. It's great. I have no desire to ever learn Java but it doesn't mean I can't use Jenkins. I have tools written in JavaScript, C, C++, Matlab, Simulink, Python, Perl, PHP, et al. As long as I have a way of getting it fixed if it's broken I don't care.
Additionally there's good money to be made in supporting tools that everyone still uses. COBOL, Fortran, Assembly all still have a massive amount of technical debt that may never go away.
My favorite Java 8 Feature: the uninstall feature.
Unless you like staying up all night tracking down errors in pointer arithmetic.
Lumping C and C++ together generally means you haven't looked at how dramatically the C++ language has changed recently, especially if you talk about pointer arithmetic. If you're using modern C++ and are still worrying about pointer arithmetic (i.e. you're not abstracting it away), you're probably doing it wrong.
The nice thing about C++ is that, quite often, those abstractions either cost nothing at all, or at worst, far less than interpreted languages. Also, having used modern C++ for a few years now, I think garbage collection is vastly overrated compared to reference counted pointers and simple RAII. C++ is still harder to use than Java or C# in many subtle ways, but basic memory management is no longer one of those persistent thorns.
Efficient compilation? Yeah, sadly, that's not C++, and likely never will be. There are some newer alternatives that have these features and compile quite efficiency, since they don't come with the baggage of backwards compatibility, but I'm not sure how much traction they're going to gain in practical measurements outside of some niche locations. Their biggest downside? Yeah, they're not backwards compatible with billions of lines of C or C++ code out in the wild.
Irony: Agile development has too much intertia to be abandoned now.
Exactly the opposite. Streams took easy to read and understand for loops used by every language on earth and replaced it with gibberish that you need to work through to understand, and is far more difficult top debug as there's no damn place to put a break point or print statement. They're banned everywhere I've heard of
I still have more fans than freaks. WTF is wrong with you people?
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.
Lambda expressions: A total brainfart. Lambda notation has no place in an imperative language; mixing paradigms is confusing for the vast majority of Java programmers. Most people just use lambdas as "magic syntax" to simplify things like declaring event handlers. The ugly syntax is a problem, but lambdas are the wrong solution.
Date/time APIs: Yes, finally!
JavaFX: Oddly, the best feature of Java 8 isn't even mentioned in TFA. JavaFX is immensely better than Swing, in every possible way: it looks better, it works more reliably, and it's easier to program.
And the worst feature of Java 8 is the unnecessary complexity throughout the new features. Two examples:
- The Optional class. Instead of checking directly for a null result, you have to unpack every result out of this idiotic wrapper.
- Factory methods instead of constructors. Java is supposed to be an object-oriented language. In OO, you create an instance of a class with a constructor, which has the name of the class. But not in Java 8, no, instead you use a whole stable of factory methods with all sorts of weird names. Look at the new date/time classes for an example.
Enjoy life! This is not a dress rehearsal.
Repeating something often enough doesn't make it true.
Rather the point! The fact is that the Java programming language and runtimes, today, utterly dominate Blu-ray disc players, Android smartwatches, and Android smartphones, to pick some examples. (And what examples they are!) They're powerful evidence that Java hardware and software efficiencies have improved tremendously over two decades. Java is a raging market success, including on devices that cannot afford much inefficiency. It's reasonable and rational to mark-to-market dated views of Java's hardware and software performance attributes. The successful, high efficiency use cases are staring us in the face, literally.
Of course it is still quite possible (a) to write lousy code that the toolchain and runtime, for any language, cannot performance-fix sufficiently for your intended use cases; (b) to have certain scenarios where Java and its toolchain/runtime (for a particular implementation at a particular moment in time) do not produce the very highest efficiency/performance result technically achievable. Point (a) is always true (although a richer and deeper toolchain, and associated skills, can help a lot), and point (b) simply means that you toss efficiency/performance into your calculus with the relative importance it merits for your particular needs. There are other programming languages (and associated runtimes) available, including five durable ones: COBOL, FORTRAN, C, C++, and PL/I. Plus myriad not-yet-durable (and most never will be) options. (Pascal, Ada, ALGOL.... IT history is littered with them.)
No,you're going to rewrite it to a for loop because its more maintainable, more easy to change with changing requirements, and more understandable.
I still have more fans than freaks. WTF is wrong with you people?