97 Things every JAVA Programmer should Know (Kevlin Henney, Trisha Gee) (z-library.sk, 1lib.sk, z-lib.sk)

1. Preface a. Permissions b. O’Reilly Online Learning c. How to Contact Us d. Acknowledgments 2. 1. All You Need Is Java a. Anders Norås 3. 2. Approval Testing a. Emily Bache 4. 3. Augment Javadoc with AsciiDoc a. James Elliott 5. 4. Be Aware of Your Container Surroundings a. David Delabassee 6. 5. Behavior Is “Easy”; State Is Hard a. Edson Yanaga 7. 6. Benchmarking Is Hard—JMH Helps a. Michael Hunger 8. 7. The Benefits of Codifying and Asserting Architectural Quality a. Daniel Bryant 9. 8. Break Problems and Tasks into Small Chunks

a. Jeanne Boyarsky 10. 9. Build Diverse Teams a. Ixchel Ruiz 11. 10. Builds Don’t Have To Be Slow and Unreliable a. Jenn Strater 12. 11. “But It Works on My Machine!” a. Benjamin Muschko 13. 12. The Case Against Fat JARs a. Daniel Bryant 14. 13. The Code Restorer a. Abraham Marin-Perez 15. 14. Concurrency on the JVM a. Mario Fusco 16. 15. CountDownLatch—Friend or Foe? a. Alexey Soshin 17. 16. Declarative Expression Is the Path to Parallelism a. Russel Winder 18. 17. Deliver Better Software, Faster a. Burk Hufnagel 19. 18. Do You Know What Time It Is? a. Christin Gorman

20. 19. Don’t hIDE Your Tools a. Gail Ollis 21. 20. Don’t Vary Your Variables a. Steve Freeman i. Assign Once ii. Localize Scope 22. 21. Embrace SQL Thinking a. Dean Wampler 23. 22. Events Between Java Components a. A.Mahdy AbdelAziz 24. 23. Feedback Loops a. Liz Keogh 25. 24. Firing on All Engines a. Michael Hunger 26. 25. Follow the Boring Standards a. Adam Bien 27. 26. Frequent Releases Reduce Risk a. Chris O’Dell i. What Is Risk? ii. Large, Infrequent Releases Are Riskier 28. 27. From Puzzles to Products a. Jessica Kerr

29. 28. “Full-Stack Developer” Is a Mindset a. Maciej Walkowiak 30. 29. Garbage Collection Is Your Friend a. Holly Cummins 31. 30. Get Better at Naming Things a. Peter Hilton 32. 31. Hey Fred, Can You Pass Me the HashMap? a. Kirk Pepperdine 33. 32. How to Avoid Null a. Carlos Obregón i. Avoid Initializing Variables to Null ii. Avoid Returning Null iii. Avoid Passing and Receiving Null Parameters iv. Acceptable Nulls 34. 33. How to Crash Your JVM a. Thomas Ronzon 35. 34. Improving Repeatability and Auditability with Continuous Delivery a. Billy Korando i. Repeatable ii. Auditable

36. 35. In the Language Wars, Java Holds Its Own a. Jennifer Reif i. My History with Java ii. Java’s Design and Background iii. Java’s Downsides iv. Why I Like Java v. What Does It Mean for Developers? 37. 36. Inline Thinking a. Patricia Aas 38. 37. Interop with Kotlin a. Sebastiano Poggi 39. 38. It’s Done, But… a. Jeanne Boyarsky i. 1. Communication and Clarity ii. 2. Perception iii. 3. There’s No Partial Credit for Done 40. 39. Java Certifications: Touchstone in Technology a. Mala Gupta 41. 40. Java Is a ’90s Kid a. Ben Evans 42. 41. Java Programming from a JVM Performance Perspective

a. Monica Beckwith i. Tip #1: Don’t Obsess Over Garbage ii. Tip #2: Characterize and Validate Your Benchmarks iii. Tip #3: Allocation Size and Rate Still Matter iv. Tip #4: An Adaptive JVM Is Your Right and You Should Demand It 43. 42. Java Should Feel Fun a. Holly Cummins 44. 43. Java’s Unspeakable Types a. Ben Evans 45. 44. The JVM Is a Multiparadigm Platform: Use This to Improve Your Programming a. Russel Winder 46. 45. Keep Your Finger on the Pulse a. Trisha Gee 47. 46. Kinds of Comments a. Nicolai Parlog i. Javadoc Comments for Contracts ii. Block Comments for Context iii. Line Comments for Weird Things iv. Last Words

48. 47. Know Thy flatMap a. Daniel Hinojosa 49. 48. Know Your Collections a. Nikhil Nanivadekar 50. 49. Kotlin Is a Thing a. Mike Dunn 51. 50. Learn Java Idioms and Cache in Your Brain a. Jeanne Boyarsky 52. 51. Learn to Kata and Kata to Learn a. Donald Raab 53. 52. Learn to Love Your Legacy Code a. Uberto Barbini 54. 53. Learn to Use New Java Features a. Gail C. Anderson 55. 54. Learn Your IDE to Reduce Cognitive Load a. Trisha Gee 56. 55. Let’s Make a Contract: The Art of Designing a Java API a. Mario Fusco 57. 56. Make Code Simple and Readable a. Emily Jiang 58. 57. Make Your Java Groovier

a. Ken Kousen 59. 58. Minimal Constructors a. Steve Freeman 60. 59. Name the Date a. Kevlin Henney 61. 60. The Necessity of Industrial-Strength Technologies a. Paul W. Homer 62. 61. Only Build the Parts That Change and Reuse the Rest a. Jenn Strater 63. 62. Open Source Projects Aren’t Magic a. Jenn Strater 64. 63. Optional Is a Lawbreaking Monad but a Good Type a. Nicolai Parlog i. Monad Definition ii. Monad Laws iii. So What? 65. 64. Package-by-Feature with the Default Access Modifier a. Marco Beelen 66. 65. Production Is the Happiest Place on Earth a. Josh Long 67. 66. Program with GUTs a. Kevlin Henney

68. 67. Read OpenJDK Daily a. Heinz M. Kabutz 69. 68. Really Looking Under the Hood a. Rafael Benevides 70. 69. The Rebirth of Java a. Sander Mak 71. 70. Rediscover the JVM Through Clojure a. James Elliott 72. 71. Refactor Boolean Values to Enumerations a. Peter Hilton 73. 72. Refactoring Toward Speed-Reading a. Benjamin Muskalla 74. 73. Simple Value Objects a. Steve Freeman 75. 74. Take Care of Your Module Declarations a. Nicolai Parlog i. Keep Module Declarations Clean ii. Comment Module Declarations iii. Review Module Declarations 76. 75. Take Good Care of Your Dependencies a. Brian Vermeer i. Vulnerable Dependencies

ii. Updating Dependencies iii. A Strategy for Your Dependencies 77. 76. Take “Separation of Concerns” Seriously a. Dave Farley 78. 77. Technical Interviewing Is a Skill Worth Developing a. Trisha Gee 79. 78. Test-Driven Development a. Dave Farley i. Red ii. Green iii. Refactor 80. 79. There Are Great Tools in Your bin/ Directory a. Rod Hilton 81. 80. Think Outside the Java Sandbox a. Ian F. Darwin 82. 81. Thinking in Coroutines a. Dawn Griffiths and David Griffiths 83. 82. Threads Are Infrastructure; Treat Them as Such a. Russel Winder 84. 83. The Three Traits of Really, Really Good Developers a. Jannah Patchay 85. 84. Trade-Offs in a Microservices Architecture

a. Kenny Bastani 86. 85. Uncheck Your Exceptions a. Kevlin Henney 87. 86. Unlocking the Hidden Potential of Integration Testing Using Containers a. Kevin Wittek 88. 87. The Unreasonable Effectiveness of Fuzz Testing a. Nat Pryce 89. 88. Use Coverage to Improve Your Unit Tests a. Emily Bache i. When You’re Writing New Code ii. When You Have to Change Code You Didn’t Write iii. When You’re Working in a Team 90. 89. Use Custom Identity Annotations Liberally a. Mark Richards 91. 90. Use Testing to Develop Better Software Faster a. Marit van Dijk 92. 91. Using Object-Oriented Principles in Test Code a. Angie Jones i. Encapsulation ii. Inheritance

iii. Polymorphism iv. Abstraction 93. 92. Using the Power of Community to Enhance Your Career a. Sam Hepburn i. The Silver Lining ii. How Can Community Help? iii. Looking for Your Next Challenge? 94. 93. What Is the JCP Program and How to Participate a. Heather VanCura 95. 94. Why I Don’t Hold Any Value in Certifications a. Colin Vipurs 96. 95. Write One-Sentence Documentation Comments a. Peter Hilton 97. 96. Write “Readable Code” a. Dave Farley 98. 97. The Young, the Old, and the Garbage a. María Arias de Reyna i. The Garbage Collector ii. GC Strategies iii. References 99. Contributors

100. Index

97 Things Every Java Programmer Should Know Collective Wisdom from the Experts Kevlin Henney and Trisha Gee

97 Things Every Java Programmer Should Know by Kevlin Henney and Trisha Gee Copyright © 2020 O’Reilly Media Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Suzanne McQuade Developmental Editor: Corbin Collins Production Editor: Beth Kelly Copyeditor: Piper Editorial Proofreader: Sonia Saruba

Indexer: Ellen Troutman-Zaig Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Rebecca Demarest June 2020: First Edition Revision History for the First Edition 2020-05-15: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781491952696 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. 97 Things Every Java Programmer Should Know, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the authors, and do not represent the publisher’s views. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such

licenses and/or rights. 978-1-491-95269-6 [LSI]

Dedication To the memory of those who shaped us through their wisdom and compassion

Preface The mind is not a vessel that needs filling, but wood that needs igniting. —Plutarch What should every Java programmer know? It depends. It depends on who you ask, why you ask, and when you ask. There are at least as many suggestions as there are points of view. In a language, platform, ecosystem, and community that affects the software and lives of so many people, and has done so from one century to the next, from one core to many, from megabytes to gigabytes, it depends on more than you could ever hope to cover in a single book by a single author. Instead, in this book, we draw on some of those many perspectives to collect together for you a cross section and representation of the thinking in the Java-verse. It’s not every thing, but it is 97 of them from 73 contributors. To quote the preface of 97 Things Every Programmer Should Know (O’Reilly): With so much to know, so much to do, and so many ways of doing so, no single person or single source can lay claim to “the one true way.” The contributions do not dovetail like modular parts, and there is no intent that they should—if anything, the opposite is true. The value of each contribution comes from its distinctiveness. The value of the collection lies in how the contributions complement, confirm, and even contradict one another. There is no overarching narrative: it is for you to respond to, reflect on, and connect together what you read, weighing it against your own context, knowledge,