Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet or computer – no Kindle device required. Learn more
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera, scan the code below and download the Kindle app.
Follow the Authors
97 Things Every Java Programmer Should Know: Collective Wisdom from the Experts Paperback – Illustrated, June 23 2020
|New from||Used from|
Purchase options and add-ons
If you want to push your Java skills to the next level, this book provides expert advice from Java leaders and practitioners. You’ll be encouraged to look at problems in new ways, take broader responsibility for your work, stretch yourself by learning new techniques, and become as good at the entire craft of development as you possibly can.
Edited by Kevlin Henney and Trisha Gee, 97 Things Every Java Programmer Should Know reflects lifetimes of experience writing Java software and living with the process of software development. Great programmers share their collected wisdom to help you rethink Java practices, whether working with legacy code or incorporating changes since Java 8.
A few of the 97 things you should know:
- "Behavior Is Easy, State Is Hard"―Edson Yanaga
- “Learn Java Idioms and Cache in Your Brain”―Jeanne Boyarsky
- “Java Programming from a JVM Performance Perspective”―Monica Beckwith
- "Garbage Collection Is Your Friend"―Holly K Cummins
- “Java's Unspeakable Types”―Ben Evans
- "The Rebirth of Java"―Sander Mak
- “Do You Know What Time It Is?”―Christin Gorman
Frequently bought together
About the Author
- Publisher : O'Reilly Media; 1st edition (June 23 2020)
- Language : English
- Paperback : 267 pages
- ISBN-10 : 1491952695
- ISBN-13 : 978-1491952696
- Item weight : 432 g
- Dimensions : 15.24 x 1.45 x 22.86 cm
- Best Sellers Rank: #766,294 in Books (See Top 100 in Books)
- #406 in Java Programming (Books)
- #729 in Software Design & Engineering Textbooks
- #2,004 in Programming Languages Textbooks
- Customer Reviews:
About the authors
Top reviews from other countries
Better spend the 35 euros on other books.
Some ideas, opinions and tips I got from the book -
As apps move to serverless architectures, where the deployment units can be single functions, the benefits we get from application frameworks diminish.
“We have to reinvent the wheel every once in a while, not because we need a lot of wheels; but because we need a lot of inventors”
Ergonomics of older JVMs are fooled when running inside docker containers.
Containers’ key benefit - reduce the coupling between an app and the underlying platform.
JVM ergonomics enables JVM to tune itself by looking at two env metrics - (i) number of CPUs and (ii) available memory.
Behavior is easy, state is hard - offer only a carefully designed API surface for any state mutation. Hardest bugs are caused by inconsistent state.
One of the advantages of being a job hopper is that “I’ve seen the way many different teams work”.
Developer Productivity Engineering - practice and philosophy of improving developer experience through data.
Actor model reduces the consequences of mutable state by preventing sharing, and functional programming makes the state shareable by prohibiting mutation. Functional programs can be less efficient than imperative equivalents and may place a bigger burden on GC. Functions facilitate the use of reactive programming paradigm consisting in asynchronous processing of stream of events.
Countdownlatch is a powerful tool but blocks the current thread. Different concurrency models don’t play well together.
Imperative - code explicitly telling the computer what to do. Declarative - code expressing a goal abstracting over the way in which the goal is achieved.
You aren’t paid to write code. Change your focus from writing code to delivering software. Your job is designing change, not code. Code is a detail. Designing change means feature flags
Localizing the scope of anything that is variable into a supporting method makes the top-level code predictable. Broadly, trying to lock down anything that does not vary makes you think more carefully about design and flushes out potential bugs.
Embrace SQL thinking - the biggest failing of applied OO programming is the belief that you should faithfully reproduce your domain model in code. It leads to unnecessary classes. SQL is declarative and is a data DSL.
In the early 2000s, most Java developers were actually full-stack developers - they just did not know because the phrase had not yet been coined!
Heap access is geologically slow compared to instruction processing, so modern computers use caches.
Java profilers use either byte code instrumentation or sampling. Flame graph sorts and aggregates the traces up to each stack level.
Uncertainty is when we cannot quantify the risk.
Risk = (Likelihood of Failure X Worst-case impact of Failure)
Playing the lottery is low-risk, Free solo climbing is high risk.
Large, infrequent releases are riskier. There is no way to reduce the impact of a failure - the worst case is still the ENTIRE system down and incur severe data loss, but we lower the likelihood of failure with smaller releases.
Naming is important - Orwell said - “the worst thing one can do with words is surrender to them”.
Technical classes (e.g., Hashmap) rarely have a place in the vocabulary of the domains we’re working in. The need for utility classes should be a red flag that you’re missing an abstraction.
Try to crash your JVM to learn deep stuff - e.g., try using Unsafe to get access to low-level stuff (e.g., memory management)
Cost of going to RAM, relative to registers, kept growing.Thus, cache-friendly code is a much researched area.
Fun can have different faces - Exploration (focused investigation); Play (no goal, for its own sake); Puzzles (rules with a goal); Games (rules with a winner) and Work (satisfying goal).
Kintsugi is a Japanese art where a precious broken object - rather than thrown away - is put back together using gold powder along its cracking lines. We should similarly learn how to fix legacy code that should make us similarly proud.
Package-by-layer structure (e.g., tld.domain.project.controllers, ..model, ..service etc) for your classes requires a lot of methods to be public. In order to benefit from package-private access protection, package-by-feature package hierarchy is a better organizing principle (e.g., tld.domain.project.company, ..user etc). The latter reduces coupling.
Service hedging - multiple idempotent calls to identically configured service instances on discrete nodes are launched and all but the fastest response discarded.
Boolean literals are worse than hard coded numbers - a 42 in code might look familiar, but a “false” could be anything and anything could be false.
Classes that represent Value objects don’t need getters or setters. Why Java 14 introduced a record structure.
Marginality : what is the average diminishing marginal return of adding developers to a team?
Programmers writing automated tests suffer from positive test bias. Fuzz testing is an unreasonably effective technique for negative testing that is easy to include in automated test suites.
Comment only what the code cannot say. Code says “what”, comments should say “why”.