book

Effective Java, 3rd Edition

by Joshua Bloch

December 2017

Intermediate to advanced

416 pages

13h 31m

English

Addison-Wesley Professional

Read now

Unlock full access

Item 1: Consider static factory methods instead of constructorsItem 2: Consider a builder when faced with many constructor parametersItem 3: Enforce the singleton property with a private constructor or an enum typeItem 4: Enforce noninstantiability with a private constructorItem 5: Prefer dependency injection to hardwiring resourcesItem 6: Avoid creating unnecessary objectsItem 7: Eliminate obsolete object referencesItem 8: Avoid finalizers and cleanersItem 9: Prefer try-with-resources to try-finally
Item 10: Obey the general contract when overriding equalsItem 11: Always override hashCode when you override equalsItem 12: Always override toStringItem 13: Override clone judiciouslyItem 14: Consider implementing Comparable
Item 15: Minimize the accessibility of classes and membersItem 16: In public classes, use accessor methods, not public fieldsItem 17: Minimize mutabilityItem 18: Favor composition over inheritanceItem 19: Design and document for inheritance or else prohibit itItem 20: Prefer interfaces to abstract classesItem 21: Design interfaces for posterityItem 22: Use interfaces only to define typesItem 23: Prefer class hierarchies to tagged classesItem 24: Favor static member classes over nonstaticItem 25: Limit source files to a single top-level class
Item 26: Don’t use raw typesItem 27: Eliminate unchecked warningsItem 28: Prefer lists to arraysItem 29: Favor generic typesItem 30: Favor generic methodsItem 31: Use bounded wildcards to increase API flexibilityItem 32: Combine generics and varargs judiciouslyItem 33: Consider typesafe heterogeneous containers
Item 34: Use enums instead of int constantsItem 35: Use instance fields instead of ordinalsItem 36: Use EnumSet instead of bit fieldsItem 37: Use EnumMap instead of ordinal indexingItem 38: Emulate extensible enums with interfacesItem 39: Prefer annotations to naming patternsItem 40: Consistently use the Override annotationItem 41: Use marker interfaces to define types
Item 42: Prefer lambdas to anonymous classesItem 43: Prefer method references to lambdasItem 44: Favor the use of standard functional interfacesItem 45: Use streams judiciouslyItem 46: Prefer side-effect-free functions in streamsItem 47: Prefer Collection to Stream as a return typeItem 48: Use caution when making streams parallel
Item 49: Check parameters for validityItem 50: Make defensive copies when neededItem 51: Design method signatures carefullyItem 52: Use overloading judiciouslyItem 53: Use varargs judiciouslyItem 54: Return empty collections or arrays, not nullsItem 55: Return optionals judiciouslyItem 56: Write doc comments for all exposed API elements
Item 57: Minimize the scope of local variablesItem 58: Prefer for-each loops to traditional for loopsItem 59: Know and use the librariesItem 60: Avoid float and double if exact answers are requiredItem 61: Prefer primitive types to boxed primitivesItem 62: Avoid strings where other types are more appropriateItem 63: Beware the performance of string concatenationItem 64: Refer to objects by their interfacesItem 65: Prefer interfaces to reflectionItem 66: Use native methods judiciouslyItem 67: Optimize judiciouslyItem 68: Adhere to generally accepted naming conventions
Item 69: Use exceptions only for exceptional conditionsItem 70: Use checked exceptions for recoverable conditions and runtime exceptions for programming errorsItem 71: Avoid unnecessary use of checked exceptionsItem 72: Favor the use of standard exceptionsItem 73: Throw exceptions appropriate to the abstractionItem 74: Document all exceptions thrown by each methodItem 75: Include failure-capture information in detail messagesItem 76: Strive for failure atomicityItem 77: Don’t ignore exceptions
Item 78: Synchronize access to shared mutable dataItem 79: Avoid excessive synchronizationItem 80: Prefer executors, tasks, and streams to threadsItem 81: Prefer concurrency utilities to wait and notifyItem 82: Document thread safetyItem 83: Use lazy initialization judiciouslyItem 84: Don’t depend on the thread scheduler
Item 85: Prefer alternatives to Java serializationItem 86: Implement Serializable with great cautionItem 87: Consider using a custom serialized formItem 88: Write readObject methods defensivelyItem 89: For instance control, prefer enum types to readResolveItem 90: Consider serialization proxies instead of serialized instances

Content preview from Effective Java, 3rd Edition

Preface

Preface to the Third Edition

IN 1997, when Java was new, James Gosling (the father of Java), described it as a “blue collar language” that was “pretty simple” [Gosling97]. At about the same time, Bjarne Stroustrup (the father of C++) described C++ as a “multi-paradigm language” that “deliberately differs from languages designed to support a single way of writing programs” [Stroustrup95]. Stroustrup warned:

Much of the relative simplicity of Java is—like for most new languages—partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity. It will double or triple in size and grow implementation-dependent extensions or libraries. [Stroustrup]

Now, twenty years later, ...