Ben Evans is the co-founder of jClarity. His company develops performance tools and services that help development and operations teams. He is one of the organizers of the LJC (London Java User Group) and a member of the executive committee of the JCP (Java Community Process), helping to define some standards in the Java ecosystem. He is also a recipient of "Java Champion" honors. He has co-authored "The Well-Grounded Java Developer" and "Java Authoritative Technical Manual (6th Edition)" (Java in a Nutshell). He has given numerous lectures on the Java platform, performance, concurrency, and related topics.
Question: "Java in a Nutshell" is a classic. Its last edition (5th edition) was 1,200 pages long, and the third edition will be published in China ten years later. The 6th edition only has 400 pages. What kind of changes are there between the two editions? What does this decade mean for Java?
The first edition of "Java Definitive Technical Manual" was published soon after Java just became popular. At that time, people were full of imagination about Java. Over the next five editions, the book grew in size and content. Therefore, the focus of each volume is somewhat historical, because there is an evolutionary relationship between several versions. This is the result of several factors. Part of the reason is simply that it is easier to write. You just need to know what has been added or subtracted from this version compared to the previous version. But more importantly, in the early days, in most enterprises, Java had a long life cycle, so you could often see very old versions of Java. So it becomes important to understand the differences between the different versions. So when you work on a certain Java version in a certain company, if you know which version it is, you also know what you can and cannot do, and what changes this version has compared to other versions.
This is the first thing I want to change when I start writing a new edition. Because the life cycle of the latest version of Java 8 (at this point, it is easy to be confused, the 6th edition of "Java Authoritative Technical Manual" talks about the 8th edition of Java) is much shorter than before. Of course, this depends on the specific domain, but once you look at the common usage, you will find that older versions (such as Java 6) are only used by a very small number of people. Of course there are still some crazy people still using versions before version 6, and most users are using version 7. Now, version 8 is occupying the market at a very fast speed. In just half a year, 15% to 20% of users are already using Java 8. Therefore, the focus of the new version of "Java Authoritative Technical Manual" is more open than before. We begin to pay attention to the world outside of Java, and will also discuss the present and the future.
The second important change is the length. As you said, the 5th edition is 1200 pages long, while the 6th edition is only one-third of that. When I started to sort out the previous edition, I did The first thing is to remove two-thirds of the content. If you have read the fifth edition, you know that in addition to discussing the main content of Java, the second part of the book is about indexes. Of course, this is also due to historical reasons. When Java first came out, the use of the Internet was not very common, so it is very reasonable for the book to have its own index. But there are two other reasons. The Java platform is getting bigger and bigger. In the first chapter of "The Definitive Java Technical Manual" I discussed Java version evolution and pointed out the rapid growth of the Java platform. It took 800 pages to describe the basic knowledge of the Java 5 platform. That was back in the days of Java 5. If the same method was used to discuss Java 8, the book would be as high as the ceiling. It can be seen that this method is not feasible. No one would be willing to hold such a book. Another reason (perhaps these two things are related) is that the way people use technical information has changed. The Internet is now everywhere, people are unwilling to carry heavy books, and all indexes can be found online in PDFs, websites, etc. Found in resources. Therefore, it is unreasonable to add a heavy index at the back of the paper book at this time. This is the major change between the two versions of "Java Definitive Technical Manual".
The third thing I try is to capture the changing trends and patterns of Java. So a lot of content about how to use Java in the past has been removed, and I have added more modern usage methods. Readers need to understand garbage collection, memory allocation, and concurrent programming. I talk a lot about these aspects. There was a lot of work involved, as the original version was focused on preserving the original content. Of the one-third of the content left in the fifth edition, only about 25%-30% was left in the sixth edition. These contents have also been re-edited, while the remaining about 70% of the content is completely new. .
Because we wanted to publish this book when Java 8 was put into use, we started writing it before Java 8 came out. Later, some work that we did not expect at the beginning appeared (such as Java 8 hidden features). But this time we have more experience, so we hope to complete the next version in April 2016, when Java 9 comes out. In fact, I have made specific plans.
Question: Do you have any next plans for "The Well-Grounded Java Developer"?
This project "How to Cultivation as a Java Programmer" is very good, and the writing process was also very enjoyable. But I spent a lot of energy in the process of writing "The Definitive Technical Manual of Java", and I think I may not write a second edition of this book. I have talked with Manning, the original publisher of this book, but I am not aware of the latest developments, so it is very likely that there will not be a second edition of this book.
Question: What is the difference between a Java expert and an ordinary Java programmer?
I think the level of programmers can be viewed as a pyramid, which can be roughly divided into 3 levels. At the bottom are very hard-working programmers, but they may have little interest in programming itself. They can also do a good job, but they will not think about programming after get off work. This is a normal phenomenon. The software industry needs many programmers, and this demand is still growing. Programmers at the intermediate level want to do more, they read technology news and news on websites, they follow the progress of the next version, they care about their skills, programmers at this level are very interesting. Programmers at the top are always fascinated by craftsmanship and the nature of technology. When you get to the top of this pyramid, you start to have a feedback loop where you learn from yourself and gain a deeper understanding of the craft. But I think the hardest part is how to break through from the second level to the top. If you have the slightest interest in knowledge outside of what you do, you have to look for your own point. This point is different for everyone. Once you find the field that fascinates you, you can follow your curiosity. Driven to study in depth.
There is a saying about open source software. A good open source developer must find his or her own pain points, and they have to solve the problem that bothers them. This is the reason why most people are interested in open source software, and why many people are called Java developers. You find a point that interests you, and because you don’t know why, you keep learning. This is the secret of growth.
Question: Although Lambda has been added to Java 8, there are always complaints among developers that Java syntax is too verbose. Do you think this is the main reason why many developers and teams are reluctant to use Java?
I don’t think so. James Gosling has three sentences to explain the language design of Java and why Java is what it is now. The first sentence is what is called "blue collar" language in English. Blue collar workers are those who work on the front line, while white collar represents the work of offices and managers. Java is a blue-collar language designed to allow working programmers to solve real problems. Java is a practical language that solves real-world business problems.
James Gosling talked about Lambda and some designs that did not appear in early versions of Java at the 2014 JavaOne conference. He said: If I don't find the right way to do something, then I won't do anything. This sentence expresses a slow and conservative evolutionary design philosophy. If you want to understand what Java is, you must understand this. Many people think that Java is old and the programming language needs to change, but what they don't understand is that the real change is themselves. They develop in their abilities, they want to see further and deeper, and the language reflects this. It's not that the language needs to change, it's that the programmers themselves who came up with this idea have changed. Java has been and will be a conservatively designed language. This is also a major advantage of Java.
When James explained his original intention of designing Java, he said: When I was designing, I knew that people wanted automatic memory management, people wanted strong typing, but these features would scare away blue-collar workers. For example, Smalltalk is an excellent language, but it is too advanced and divorced from the way developers actually think when building applications. So Java inherited some of these ideas, simplified them, and put these ideas into a language and format. These things explain the basic motivation for the design of this language.
So you can certainly say that Java is a verbose language, but I think the extra content is for ease of reading. Especially when you are a junior or intermediate programmer, those seemingly redundant words can help you. People will always remember that our demands for productivity are getting higher and higher, but code is still written. So I don't think Java is verbose, although we can add some advanced features, but some things can never be changed in a language, which is a shame. Of course we will make progress, but as I always say, people always care too much about grammar rather than what can be achieved with language.
Question: Nowadays, many large enterprises (Paypal, etc.) are switching from Java to Node.js. Java’s position in enterprises is threatened. What are the areas in which Java and Node.js are good at each?
There is a misunderstanding in this question. In fact, there is no large wave of companies abandoning Java and switching to Node.js. The Node.js-enabled part of Paypal is small, and most of Paypal's running code is still Java. Node.js is participating in a pilot project, which is understandable. Node.js is an interesting environment with some interesting ideas. Node.js is very young, and at the same time, it has many serious problems, so it is too early to predict the future development of Node. So although there are many voices supporting Node on various developer websites, and there are many interesting projects on GitHub (such as using it to write Ardruino, playing with hardware), among all products in production environments, there is no doubt that Java has the most lines of code. Enterprises will not abandon working software without a good reason. Although there are many entrepreneurs using Node.js, entrepreneurs come and leave quickly.
As one of the interesting products in recent years, Twitter, if you observe their development, you will find that they initially used Ruby on Rails. Three or four years ago, a very cute cartoon character, the Fail Whale, started appearing on their website. It was an embarrassing thing, and they did a lot of investigating to figure out what was going on, and after looking at Ruby's garbage collection, they found there was nothing they could do. At the same time, their Java pilot project was successful and they realized that Java could solve their scalability problems. Then over the next 18 months, they used some JRuby as a staging ground and then rewrote the entire system to Java. The final effect is also very good, they introduced new services and new architecture around Java. Once upon a time, Ruby was seen as the future of enterprise software, but today, Ruby is just one programming language among many. The three most widely used languages now are Java, JavaScript, and C/C++, but most of the JavaScript code is on the client side. If these three languages are removed, the market shares of other languages will be very small.
Question: Until now, the virtual hosting model for Java applications requires that the entire x86 virtual machine be allocated to host a separate JVM instance. Relatively speaking, the instance also hosts a separate Java application. This method is very inefficient, but Java does not natively support multi-tenant virtualization and cloud computing configurations. Fortunately, you can find some multi-tenant Java solutions in the community to solve cloud computing problems. Which solution do you think is mature enough to be applied to production environments?
There are two things involved here. Mixing virtualization with cloud and multi-tenancy is not entirely correct. For example, at QCon Shanghai, there were many sharings about docker (docker is a platform that does not rely on virtualization), and one of the wonderful sharings came from Chris Swan. He showed the benefits of moving CPU memory from a virtual environment to a Docker-based environment. Although it is still not perfect, it already brings additional advantages to Java. You can feel it just by running Java on Docker. arrive. We should sort out the relationship between cloud and virtuality clearly. Additionally, there are a lot of other things you can do, such as you can set up multiple JVM hosts.
But what this question is really asking is multi-tenancy. Regarding this issue, there is one product that is a well-deserved champion in my mind, and that is Waratek. Waratek can separate a separate non-hotspot JVM and run the host JVM in it. What is running in the JVM is the Java virtual multi-tenant JVC, and the JVC can be very lightweight. I think Waratek is a very mature product that can be put into use. Deutsche Bank has just announced that it will move its first working JVM to Waratek. Since Deutsche Bank has approved this product, it should be worth your time to study. one time.
Question: Java is often compared with Scala. What are the differences in the design purposes of these two languages? Is it possible that the two languages will develop in exactly the same direction in the future?
Java and Scala are very different languages. We talked about Java's design philosophy before, now we can talk about Scala's design philosophy and what are the differences between them. Scala was originally a language from academia. The language originally created by Martin Odersky was called Pizza. At that time, Java was still version 4. At this time, Pizza began to gradually add some features similar to the Java paradigm, which were also added in Java 5. Some of Pizza's features serve as paradigms.
Martin is a very smart person, and Scala also has many great designs. But at the same time, this language also has its own problems. It's sometimes called a "kitchen sink" language, which goes to show that people have a love-hate relationship with the language. The meaning of this metaphor is: there is an excessive amount of various things in the sink. This is really a problem with Scala, it has too many features. There is a rule of language design, which is also an important principle in the Java design process - conservatism. Specifically, every time you add a new feature (a specific example is discussed on page 14 of "The Cultivation of Java Programmers"), you may also create new problems. If your language has 200 features and you want to add one more, I need to check how it interacts with all the other features. Scala is constantly adding new features. It's difficult to know how these features interact. Even if Scala has a very flexible community that can embrace change, changes in language features are not easy. So you will find that although Scala has a lot of excellent performance, you need to decide which features you want and which features you can't touch. This isn't a problem when you're programming in a team. The real problem is that the software stack in modern society has never relied solely on code. The problem comes from function libraries. There are some Scala features whose actions not only affect the target object, but also other things. The more features Scala has, the more easily these problems overlap.
In addition, they have always been struggling with binary compatibility issues. Java, Sun, and Oracle have always believed that this is the most important design concept for Java, so I can write a program in Java 1.0, compile it, and put it in the Java 8 virtual machine. It can still run, and the running speed will be faster than It used to be many times faster. Scala has never made a promise in this regard, and problems will occur even in the previous version. In the library space, this problem is even more serious. I know that many projects have abandoned Scala because every time they upgrade the library, the entire system crashes.
So, the design ideas of these two languages are very different. People always like new things, and the first person to try it will also be the first to enjoy many benefits, but in more cases, people prefer to be the second person to try it. You can watch the first person make a mistake and learn from it. And Java is such a language that learns from other people's mistakes. I just mentioned the programmer's pyramid. I think Scala is not suitable for the bottom layer. Its role is more to stimulate thinking for the top-level programmers. Java is a language that applies to the entire pyramid, and it is especially suitable for low-level and middle-level programmers. I believe there will be a strong and healthy Scala community for many years to come, and I hope to exchange ideas with them. But I don't think Scala will grow from a niche language to a mass language. There may be hundreds of Scala programmers on the planet now, but this number is at most one percent of Java programmers, and this ratio is likely not to continue to grow.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
