Java Reference
In-Depth Information
Chapter 16. Conclusions and where next for Java
This chapter covers
New Java 8 features and their evolutionary effect on programming style
A few unfinished-business ideas started by Java 8
What Java 9 and Java 10 might bring
We covered a lot of material in this topic, and we hope you now feel that you're ready to start
using the new Java 8 features in your own code, perhaps building on our examples and quizzes.
In this chapter we review the journey of learning about Java 8 and the gentle push toward
functional-style programming. In addition, we speculate on what future enhancements and
great new features may be in Java's pipeline beyond Java 8.
16.1. Review of Java 8 features
A good way to help you understand Java 8 as a practical, useful language is to revisit the
features in turn. Instead of simply listing them, we'd like to present them as being interlinked to
help you understand them not merely as a set of features but as a high-level overview of the
coherent language design that is Java 8. Our other aim in this review chapter is to emphasize
how most of the new features in Java 8 are facilitating functional-style programming in Java.
Remember, this isn't a capricious design choice but a conscious design strategy, centered on two
trends, which we regard as climate change in the model from
chapter 1
:
The increasing need to exploit the power of multicore processors now that, for silicon technology
reasons, the additional transistors annually provided by Moore's law no longer translate into higher
clock speeds of individual CPU cores. Put simply, making your code run faster requires parallel code.
The increasing tendency to concisely manipulate collections of data with a declarative style for
processing data, such as taking some data source, extracting all data that matches a given criterion,
and applying some operation to the result—either summarizing it or making a collection of the result
for further processing later. This style is associated with the use of immutable objects and collections,
which are then processed to produce further immutable values.
Neither motivation is effectively supported by the traditional, object-oriented, imperative
approach, centered on mutating fields and applying iterators. Mutating data on one core and
reading it from another is surprisingly expensive, not to mention the need for error-prone
locking; similarly when your mind-set is focused on iterating over and mutating existing objects,
Search WWH ::
Custom Search