BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Interview and Book Review: Java in a Nutshell, 6th Edition

Interview and Book Review: Java in a Nutshell, 6th Edition

Java in a Nutshell, 6th Edition by Benjamin J. Evans and David Flanagan is an update to the tried-and-true Java in a Nutshell series. This edition covers Java 8 for the experienced Java Developer, but it is also designed as a learning path for new developers. The 5th edition of this book covered Java 5, so it was due for an update.

This version recognizes that developers have the internet at their fingertips and can easily find Java’s API docs and answers to common questions on Stack Overflow. However, that doesn’t mean it skimps on the details.

Last November, I was presented with the opportunity to review this book for InfoQ and I leapt at the opportunity. In 2012, I’d read one of Ben’s other books, The Well-Grounded Java Developer. I thoroughly enjoyed this book and wrote a review about it on my website. When I say that Java in a Nutshell, 6th Edition was focused on Java 8, I thought reading and reviewing it would be an excellent way to keep my Java skills up-to-date.

I don’t recommend reading this book cover-to-cover. If you have a photographic memory, this might serve you well. But otherwise, you’ll simply be overwhelmed with the amount of knowledge and detail in this book. I did read this book cover-to-cover, and it took me several months. The reason is simple: it’s meant as a reference book, not as a story-telling tech book that teaches you how to develop an app with a new technology. Even though it wasn’t exactly a page-turner, I found that I learned something new in almost every chapter.

The first half of the book focuses on the Java platform: syntax, object oriented programming, Java’s type system and its memory model and approach to concurrency.

As a developer with a keen interest in Java 8, I found streams (chapter 8), the date API (chapter 9) and Nashorn (chapter 12) to be the most intriguing. I’m not currently using Java 8 in any projects, but I plan to soon, so I expect I’ll be looking back at these chapters then.

Recently, InfoQ caught up with author Ben Evans about the book.

InfoQ: In the foreword, you wrote "In working on this new edition of David’s classic text, I hope to have embodied the spirit of that prehistoric tree." You mentioned the original book's tenacious form, its feel and the important parts emphasized. Are you satisfied with the results?

Evans: I hope that this edition of Nutshell is a good attempt to bring the book into the era of modern development practices. However, I do see it as a work in progress. Hopefully, if O’Reilly commission a 7th Edition, I’ll have a chance to address some of the topics and areas that I feel aren’t covered as well as I would have liked in the current edition. The book was produced on a tight schedule, and I didn’t have the opportunity to do everything I wanted to for the 6th Edition.

InfoQ: What are some of the topics you’d like to cover in more detail?

Evans: The biggest thing (and the first thing on my laundry list if a 7th Edition happens) is to change all of the inner classes that are really lambdas to be actual lambdas. I got to some of them but ran out of time. I’d also trim the inner classes coverage, and place lambdas and the changes to Java’s OO front and centre. With many developers now familiar with other languages, describing Java’s interfaces in terms of stateless traits now makes much more sense.

I’d also want to extend the coverage of Java’s type system - discuss what type inference Java does and what is possible. Type annotations should also get some love, as they’re still an underused and underappreciated great feature of the language. Finally, I want to do a proper deep-dive on G1, especially given the debate about it becoming the default collector in Java 9.

InfoQ: Obviously, chapter 12 about Nashorn is a new chapter. Are there any other chapters that required a lot of work?

Evans: Actually, Nashorn was one of the easiest and quickest chapters to write. Partly that’s because through the London Java Community (LJC), we’d already run a number of hackdays looking at Nashorn, so the writing of the chapter really flowed. The data formats chapter took a surprisingly long time, but I was lucky to have the help of an LJC member who had worked on the test cases for new Date & Time to support me, so that section was less time-consuming to write than it should have been.

Perhaps surprisingly, the chapters that took an unexpectedly long time were often chapters from David’s original text that looked like they only needed fairly light editing. Chapter 2, the syntax chapter, was more-or-less untouched, except for changes for newer language versions (e.g. try with resources, lambdas, etc). I had to read and reread the chapter, making sure that everything that was said in it in the days of Java 5 is still true today. So that took more time than I’d estimated, and despite how careful we were, one or two errors did sneak through. However, some eagle-eyed readers spotted them, and we’ve corrected them for the next print run.

InfoQ: Which chapter or section did you enjoy authoring the most? The least?

Evans: The Nashorn chapter was good fun - in fact I made myself stop writing it when it was about ⅓ done, and deliberately left the rest of it till almost last, as a kind of bribe to make myself get some of the other chapters done on time.

The first chapter was mostly written right at the start of the project. I was on a small Scottish island, where the only Internet connection was by using my phone - and it would only connect at a data rate of 9.6Kb/s. So, I couldn’t browse the web, couldn’t read my web-based mail, but the Atlas authoring tools O’Reilly asked me to try out still worked - because they were based on ssh, Asciidoc and git. So the actual writing experience was great - no distractions and I could still work effectively.

InfoQ: What do you think is the most compelling feature of Java 8? What about Java 9?

Evans: The obvious answer is lambdas, and they are such a huge change that it’s hard to argue against them. However, I think time will tell whether the changes to Java’s OO model (with default methods providing a way to have implementation in interfaces) actually lead to interfaces being viewed as essentially stateless traits. That would be a huge shift in Java developers’ thinking. The changes under the hood to support Nashorn properly are very exciting, but probably not all that visible to most people.

Java 9 is still getting going. The big change is going to be modularity, and the loss of access to the non-standard implementation packages. I think that will make some shops nervous - despite the fact that everyone knows that you shouldn’t link directly to internal packages, and that the APIs can (and do) change or disappear between releases, I still know of quite a few projects who do this. Personally, I haven’t seen the need to link directly to com.sun.* or sun.* since Java 7 came out, but people still do, even experienced open-source projects that really ought to know better.

Having said that, I think that modularity, combined with the other goodies in the JDK 9 platform (HTTP/2 support, the new JShell REPL, huge improvements in Nashorn, rewritten JVM logging, proper low-level JIT control) will prove irresistible to most companies. However, I’m sure that there will be a few holdouts that take a long time to move to 9 - so I think some of the push to get Java 7 EOL’d is because Oracle know, deep down, that Java 8 will have to be a Long Term Support release.

InfoQ: What sort of reading strategy would you recommend for experienced (10+ years) Java developers? What about newbies to the platform?

Evans: For Nutshell? I think that experienced developers should try to use it primarily as a reference text - try to use it to contrast against their “from the trenches” experience, and to think about how Java’s language features shape code in the large.

For example, having been working with Scala again recently, I was struck by the inherent complexity that Java’s division into statements and expressions brings. Of course, hindsight is 20/20, and I tend to agree with the idea that Java’s backwards compatibility and platform stability count for a great deal in critical applications at scale. Those qualities could well be worth some annoyances that more recent languages have been able to sidestep. In fact, you could argue that other JVM languages have only been able to be successful (to the extent that they have) because of having Java to examine in detail - both for its good and its bad points.

For newcomers, I would recommend not trying to learn Java just from Nutshell by itself. There are some other great books out there, including the evergreen Head First Java by Bert Bates and Kathy Sierra. For more visual learners, I also have the “Introduction to Java 8” videos available from O’Reilly.

If we do get a 7th Edition to cover Java 9, and provided JShell makes it in on time, I already have plans to open up the book to be better for Java newbies, by making heavy use of the REPL. For this edition, I would not try to read straight through. Instead, I’d concentrate on chapters 1, 3-5 and 8-10. The other chapters (especially chapter 2) can be thought of more as reference material for the beginner.

InfoQ: There don't seem to be many references to frameworks that have helped make Java popular (for example, dynamic JVM languages, Spring or any of the many web frameworks). Do you feel it's necessary to know the fundamentals of the Java language to use its frameworks effectively?

Evans: Partly it’s a question of space in the book. Of course, we do have a dynamic language, in the form of Nashorn, but Nutshell has always been about the core language. Java is such a huge ecosystem that I am quite fond of the idea that we should have specialised texts to cover the frameworks, and I do think that understanding the fundamentals help. I think every good Java developer should understand the basics of classloading and memory management, for example.

I also found when writing my previous book (The Well-Grounded Java Developer, for Manning) that too many introductions to too broad a set of topics ran the risk of diluting the focus, and that it really divided the audience - some people loved it, others were quite ranty in their reviews (“If I wanted a basic introduction to non-Java topics, I’d just go and read a bunch of blog posts” is one I particularly remember).

However, I’m well aware it’s very much the case that “you can’t please all of the people all of the time”. One of the very first reviews of Nutshell on Amazon was from someone who was infuriated that we’d cut the reference section at the end - despite the fact that Java’s standard library is now so big that if we’d tried, the book would have been too heavy to pick up and uneconomical to produce. Sure enough, he gave us 1-star.

While I know we can’t please everyone, if we’re pleasing most of our audience, and developers are happy with the book, find it useful and are glad they bought it, then I’m happy too.

 

About the Book Authors

Ben Evans is co-founder of jClarity, a startup which delivers performance tools & services to help development & ops teams. He is an organizer for the LJC (London's JUG) and a member of the JCP Executive Committee, helping define standards for the Java ecosystem. He is a Java Champion; JavaOne Rockstar; co-author of "The Well-Grounded Java Developer" & the new edition "Java in a Nutshell" and a regular speaker on the Java platform, performance, concurrency, and related topics.

David Flanagan is a computer programmer who spends most of his time writing about JavaScript and Java. His books with O'Reilly include Java in a Nutshell, Java Examples in a Nutshell, Java Foundation Classes in a Nutshell, JavaScript: The Definitive Guide, and JavaScript Pocket Reference. David has a degree in computer science and engineering from the Massachusetts Institute of Technology. He lives with his wife and children in the U.S. Pacific Northwest bewteen the cities of Seattle, Washington and Vancouver, British Columbia. David has a blog.

Rate this Article

Adoption
Style

BT