Introduction of functional interfaces to Java 8

Introduction of functional interfaces to Java 8
Adding lambda calculus to Java 8 is an exciting new feature. Although this feature comes too late, the current mainstream development languages, JAVA seems to be the last language that supports functional thinking. Although it is a little late, it is always better than nothing. Besides, I think its implementation is still feasible, at least better than the implementation of C ++ (the C ++ compiler cannot automatically process the closure environment well, but requires the programmer to introduce the variables in the lambda expression in the Code (capture the list) -- The C ++ type system is too rich. If there is no capture list, the compiler cannot determine whether to capture the system by "value" or by "reference". JAVA type systems are much simpler, ). In the past, whenever I returned to Java from Scala, there was an inexplicable pain-Scala's collection library was designed specifically for functional styles, and its abstraction level was higher than that of Java's collection library, so that Scala can usually deal with two or three lines of code, it takes more than a dozen lines of code in Java. I have been using Java 8 for a few months now (I have been using openjdk8 since beta), and I will go back to the company to use the old JDK 6, it is also a terrible pain-it is said that jdk6 is not enough. From jdk5 in 03 to jdk7, the java syntax has never changed, the latest jdk version used by the company is jdk6. Although the functional syntax currently supported by Jdk8 is still far from Scala in terms of simplicity, it is also a rapid development. After the official jdk8 version was released, many articles on jdk8 began on the Internet. I personally like these changes very much, but since many people have already said these benefits, I do not need to describe them any more. Secondly, most of my friends who love to learn jdk8 now use jdk8, for good places, it will naturally take time to understand and do not need to talk too much. So here I will talk about something that may not be ready for functional thinking in java, and I will not talk about it here if many people have mentioned it, if I talk a little about it, I will talk about one or two sentences. For example, this item is rarely mentioned: the non-termination operations of the newly added Stream interface are all evaluated by inertia, this design ensures the efficiency of the set operation as a whole. In the big data era, concurrency will become the core competitiveness of the language, while functional language development's concurrent program performance is generally better than imperative language, this is also one of the reasons why java's 20-year-old language has changed its mindset. For example, Scala and Java are the same language running on JVM, but Spark developed by Scala is 100 times better than Hadoop developed by Java. There is a big gap from the apache spark Project website (comparison of the execution time of Logistic Regression Algorithms) that is hard to believe. But for now, this is the truth-the same JVM, is there such a poor performance just because of language differences? I think the reason why Hadoop's performance is inferior to Spark is that it cannot write such high performance without using Java, but there are some things in Java that make it highly resistant to developing high-performance concurrent programs. I have not thoroughly studied the internal mechanisms of Hadoop and Spark, so I will only talk about the existing (possible) Vulnerabilities of Java 8 in terms of the language itself. Note: The following is a simple one or two sentences to be added later. 1. null. Null is a common keyword in normal java code, but it is meaningless for functional thinking. If an object is empty, it means that you cannot call any method of this object. In a functional program, if a function cannot match an object, it usually means that the function is over. If a function will continue to generate an empty object, it usually means that this empty reference will be assigned a new object. In jdk8, you can also see the methods of the set framework modified to avoid null. For example, the Map interface adds a method getOrDefault to try to avoid the problem that the get method will return NULL; the Optional class added by JDK 8 is also added to simulate pattern matching in Functional Languages-null is not possible for pattern matching. 2. There is a mutable state. If an object is variable, it means there is a problem with the concurrency of this object. But in java, It is very troublesome to make it impossible to change a type object (imagine adding a final to all attributes ), developing a mutable object is very easy. Although writing a function that meets the Pure Functional requirements does not necessarily have to use an immutable state, if all objects are in an immutable state, then the written functions must conform to the functional standard. A variable Object usually means that a problem occurs when the object is called concurrently. Therefore, you need to lock a part of the object to avoid the problem, and the lock is the most direct cause of the deterioration of concurrency. Iii. Optimization without tail recursion. In functional languages such as Scala and Erlang, tail recursive optimization is a common concept, but most JAVA programmers have never heard of this concept (Because Java does not have tail recursive optimization) -- For more information about tail recursion optimization, see my other article "Implementing tail recursion optimization for the interpreter of SNL Language". The immutable State objects in the functional style have a great impact on concurrency, but for programmers who are familiar with imperative language code, there will be a very unaccustomed effect-there is no loop. Imagine that there is no for or while in a language, which may be a disaster. However, if we are familiar with the functional style, we can implement equivalent functions even if there is no loop. 4. High compatibility. Java has not added any reserved words from JDK 5 to the current JDK 8. All new syntax changes are fully reflected in the code structure. Many new ideas are implemented using libraries, this greatly affects the use and promotion of new ideas. However, the relationship between this and performance is not too great (the database is well designed, and the performance is not poor), but it is also somewhat related-in many functional languages, some common data structures are at the language syntax level, rather than at the database level. 5. No more advanced thread models were added. Some time ago, I saw a conversation with Ruby's author, Song benhong. This is probably the case: Q: If time goes back, what changes will you make (to Ruby )? Answer: remove the thread and use a more advanced actor-based thread model. First, you can add, delete, or modify the above items as your understanding deepens. The preceding points are common for common java programs. However, the development of concurrent programs or functional thinking may lead to different levels of obstacles.