Joshua Bloch

Well done, Tim! By the way, the lambda-shaped tool is a bevel:

Let me leave you all with a little puzzle: there are two changes to the cover picture that relate directly to the new material. Can you find them?

Hi Liutauras. I used OpenJDK because it's open-source software☺ I use Azul's distro because it's rock-solid, easy to install, and runs on many architectures (Linux, OSX, WIndows). I'm happy to use proprietary source software too, if there's a good reason to do so, but in this case there isn't. Moreover, Oracle is extremely litigious (ask me how I know), so it makes sense for me to avoid entering into any legal agreement with Oracle beyond the GPL.

Congratulations to the winners, and thanks to everyone for participating. I know that I still owe you a few answers, which I'll attend to shortly.

Hi Campbell. Technically, var is not a reserved word in Java 10, though it feels like one. This was done for backward compatibility, so that existing programs that used var as a variable name are not broken. But it's not stretching the truth too far to call var a keyword in Java 10.

By the way, here's an obscure fact that you might be able to use in a bar bet some day: goto (!) and const are reserved words in Java, even though they are not used.

Campbell is absolutely right. Don't wait for me to write a new edition. I tend to wait until the platform has evolved enough to really justify a new edition. I don't think it would fun, or fair to the people who bought my book, to update it constantly. I may make new items available on the web in between releases, given how infrequently I update the book. As a reminder, the first edition came out in 2001, the second edition came out in 2008, and the third edition came out in 2017 (just barely).

Hello Ritchie. I agree with you about lambdas, though I would claim that it's a dangerous precedent: In this case it was a fine addition to the language, but as a rule "everyone else is doing it" is a bad reason to add a feature to a language (or, for that matter, to do pretty much anything else). Languages have a "feel" and a community. If a new feature harms the feel, or fails to address the needs of the community, it can make a language worse. At one time in the distant past, Sun was going to add XML literals to Java, because XML was all the rage. Thankfully, it took a while to do it, and by the time it seemed feasible, XML literals had fallen out of fashion. I think pretty much everyone is glad that they did not become part of the language. As for streams, Brian Goetz told me that the were not added  primarily to make it easier to use multicore machines, which is a good thing: As discussed in Item 48 ("Use caution when making streams parallel"), the great majority of stream pipelines will see no benefit from parallelization, and some will degrade catastrophically, or even fail to compute the correct results. This doesn't mean that there are no good uses for parallel streams: when the the conditions are right, they can result in linear speedup in the number of cores, with little effort on the part of the programmer. What it does mean is that you should not parallellize streams indiscriminately. You should only do so when you can prove that parallelism will preserve correctness, and you have a strong indication that it is likely to make your stream pipeline run faster. The requisite conditions are discussed in some detail in Item 48. Also,  you have to remember that parllelization is merely an optimization, and you must test the performance of your code before and after parallelizing to find out if the optimization was justified.

I'm going to give you my honest answer, but it won't make you happy: Unless you're stuck on Java 6, it is a better use of your time to read the new edition. A lot has changed in the past three major releases; the second edition is a decade old at this point. I am sorry that you spent your money on the previous edition just before the new one came out☹ Maybe you'll get lucky and win one of the four copies that JavaRanch and Pearson are giving away.  If you don't win a copy, take a look at this twitter thread.  It contains a promo code that will get you 35% off and free shipping from InformIT☺️

Again, thank you everyone for all of the lovely comments!  You really do make me feel welcome here.

Hi Paull, I'm sorry, I though I answered this one earlier, but somehow I didn't post my answer. Perhaps I hit preview instead of submit.

Anyway, number one with a bullet is lambdas and method refs. They let you do things that would be just to cumbersome using anonymous classes. I hope you'll permit me the liberty of reaching back to Java 7 for another feature, which is the try-with-resources statement. This (relatively) small feature made it really easy to ensure that resources are properly terminated, even when you're using more than one at the same time. It was such a pain to do this correctly before this feature was added that virtually no one did it. Another feature that had a really big impact is streams. When used for appropriate tasks, they can really improve the expressiveness of the language. Unfortunately they're also prone to overuse and abuse.

Sure.  A great book to learn the language if you're already comfortable in another language is Peter Stesoft's Java Precisely (third edition). There are many good books about various aspects of programming. I discussed a few of them in this thread.

Hi R.J. The way I do it is to make strong effort to understand what the critical uses are. That's really a large part of the battle. Once I've done that, then can I can rough out an API design convince myself that it addresses these uses by writing client code against the rough API, and get buy-in from the "critical users." Once I have that, I feel like I've constrained the late spec changes and I can start implementing the API without too much fear.  Of course the API is still going to change, and the requirements are still going to change, and I'm going to discover problems as I start implementing, and users are going to discover more problems as they start playing with my initial implementation, but all of this will happen within a framework that I understand. To put it simply, good requirements analysis is key, and the requirements should take the form of use-cases.

Thanks for the encouragement regarding Puzzlers. I do have a soft spot in my heart for it, and not just because it got me very interested in optical illusions;) Hopefully Neal and I will revise it some day.

Hi Camilo! I do think that Java should continue mining functional programming for good ideas, but I don't think Java should adopt all the FP constructs present in Scala. If people want to program in Scala, they can! Java is simpler than Scala, and more of a "blue collar language." That's the soul of Java. Of course it's been moving further from that ideal at least since generics (especially wildcards) were added in Java 5. It's a tough balancing act. You want to provide useful facilities, but at the same time a language only has space for a certain amount of complexity until it becomes unwieldy. Java is already becoming unwieldy. So my answer is, yes Java should consider more functional programming features, but it should only include them if they're really compelling, and easily understandable to Java's target audience.

It isn't always clear what's too complex. As an illustrative example (from Item 45), it's unclear which of these two methods of computing the Cartesian product is superior:

[b]// Iterative Cartesian product computation[/b] private static List<Card> newDeck() {    List<Card> result = new ArrayList<>();    for (Suit suit : Suit.values())        for (Rank rank : Rank.values())            result.add(new Card(suit, rank));    return result; } [b]// Stream-based Cartesian product computation[/b] private static List<Card> newDeck() {    return Stream.of(Suit.values())        .flatMap(suit ->            Stream.of(Rank.values())                .map(rank -> new Card(suit, rank)))        .collect(toList()); }

Here's what I say in Item 45:

Which of the two versions of newDeck is better? It boils down to personal preference and the environment in which you’re programming. The first version is simpler and perhaps feels more natural. A larger fraction of Java programmers will be able to understand and maintain it, but some programmers will feel more comfortable with the second (stream-based) version. It’s a bit more concise and not too difficult to understand if you’re reasonably well-versed in streams and functional programming. If you’re not sure which version you prefer, the iterative version is probably the safer choice. If you prefer the stream version and you believe that other programmers who will work with the code will share your preference, then you should use it.

I have mixed feelings about "pattern matching" (not the regex kind), which I know is being discussed for a subsequent release. Done well, it is powerful and concise, but it undeniable that it adds to the conceptual weight of the language.

I've touched on this topic in many of replies this week, and I won't put in links to all of them, but you can find them if you want

I'll start with which features I'd likely have omitted, as that's an easier question. I'd almost certainly have omitted modules, as the cost-benefit ratio seems way out of whack. The costs, in terms of conceptual surface area, and engineering effort at ever level of the platform from VM to language to libraries to  tools, are high, and the benefits are small. I've had several tool developers complain to me about how much trouble modules had caused them, and I've had senior developers at several companies tell me that they'd studied modules extensively and come to the conclusion that they would be of little or know benefit to their companies. I honestly don't know why the Java platform architects chose to pursue this feature. If I had to guess, I'd say it's because they studied it for a long time (since before I left Sun), and this produced a mindset where they were willing to throw good money after the bad. This is, of course, just speculation on my part.

While default methods in interfaces have real benefits, I believe they are likely too dangerous in their present form (see Item 21: "Design interfaces for posterity" for details). I would have insisted on a safer design, and I would have omitted the feature in the unlikely event that we couldn't have come up with one. Also I would have refactored the "downstream collector" concept, so that it leveraged the Stream API rather that duplicating major portions of it.

As for features that I would have added, they would have been small, evolutionary steps with high power-to-weight ratios. I would have added collection literals several releases back, extended the for-each loop to work on strings (and other CharSequences), and on the libraries front added immutable variants of EnumSet and EnumMap. I believe that Java 7's "Project Coin" was one of the most successful additions to the platform in "recent" years, and I'd pursue further changes along those lines. I'd provide literals for the primitive types that don't have them. Also on the libraries front, I'd make Stream extend Iterable at the first opportunity, to allow for better interoperability between streaming and iteration and, in particular, to allow for-each construct to be used on streams. See "Item 47: Prefer Collection to Stream as a return type" for more on this topic.

The lists in this post are by no means complete. They're just what comes to mind right now. I hope I've said enough that you understand my general approach.