Was hat sich zwischen Effective Java 2nd Edition und 3rd Edition geändert?

Über diesen Artikel

Effektive Java 3rd Edition wurde veröffentlicht. Neue Sprachelemente von Java 7 bis Java 9 wurden hinzugefügt, und ich denke, dass es vorerst Lambda ist, aber ich war besorgt über andere Änderungen und Ergänzungen. Also habe ich die 2. und 3. Ausgabe nebeneinander verglichen und solche Stellen grob überprüft.

In diesem Artikel habe ich die Orte aufgelistet, von denen ich dachte, dass sie "charakteristisch sein könnten!". Nicht über neue Elemente, sondern über Änderungen innerhalb vorhandener Elemente. [^ 1] Vielleicht haben Sie nie Lust, diesen Artikel zu lesen, sondern eine Referenz für diejenigen, die die 2. Ausgabe gelesen haben, um die 3. Ausgabe neu zu lernen. Ich denke, es wird so verwendet. Ich denke, es gibt viele Missverständnisse und Auslassungen. Bitte genießen Sie es, nach Fehlern zu suchen.

[^ 1]: Ich werde einen separaten Artikel über neue Artikel schreiben.

Insgesamt haben sich die Änderungen im Geiste der einzelnen Elemente nicht wesentlich geändert, außer dass die Sicherheitsrisiken der Serialisierung stärker geworden sind. Darüber hinaus wurden Grammatik- und Standard-APIs für Java 7 und höher hinzugefügt, um das Schreiben zu verbessern, und das Dokumentformat wurde entsprechend geändert.

Unter den vorgestellten Tools hielt ich Java Microbenchmark Harness für nützlich. (Ich habe es nicht gut überprüft ...) http://openjdk.java.net/projects/code-tools/jmh/ Die Artikelliste lautet http://www.informit.com/store/effective-java-9780134685991 , Aus Beispielinhalt erhalten.

Chapter 2: Creating and Destroying Objects

Item 1: Consider static factory methods instead of constructors

• Die Teile, die nach der Veröffentlichung von Java7 nicht mehr als Vorteil angesehen werden können, wurden entfernt.
• Enthält einen Verweis auf die Standardmethode der Java 8-Schnittstelle. ――Die Zusammensetzung wurde geändert, wobei die in der 2. Ausgabe aufgeführten Vorteile aufgeführt sind.

Item 2: Consider a builder when faced with many constructor parameters

• Ein Beispiel-Builder mit Klassenhierarchie wurde unter Verwendung des rekursiven Typparameters (Item30) hinzugefügt.
• Der Verweis auf das AbstractFactory-Muster wurde entfernt.

Item 3: Enforce the singleton property with a private constructor or an enum type

• Die Erwähnung hinzugefügt, dass Methodenreferenzen mit einer Methode namens "getInstance ()" verwendet werden können.

Item 4: Enforce noninstantiability with a private constructor

――Es gibt keine besonderen charakteristischen Änderungen.

Item 5: Prefer dependency injection to hardwiring resources

Neuer Gegenstand

Item 6: Avoid creating unnecessary objects

• Der Beispielcode wurde mit RegEx in einen geändert. (Vielleicht wollte ich kein Beispiel für Calander oder Date geben.)

Item 7: Eliminate obsolete object references

――Es gibt keine besonderen charakteristischen Änderungen.

Item 8: Avoid finalizers and cleaners

• Der Finalizer ist veraltet und ein Reiniger wurde hinzugefügt, aber es wurde auch hinzugefügt, dass er vermieden werden sollte.

Item 9: Prefer try-with-resources to try-finally

Neuer Gegenstand.

Chapter 3: Methods Common to All Objects

Item 10: Obey the general contract when overriding equals

--Googles Autovalue wird in die Implementierung von equals () Hashcode () eingeführt. "Die automatische Generierung von IDEs kann mit Klassenänderungen nicht Schritt halten. Es ist nicht schön. Es ist besser, als es von Hand zu machen." https://github.com/google/auto/tree/master/value

Item 11: Always override hashCode when you override equals

• Die Beispielklasse PhoneNumber wurde in die in Punkt 10 beschriebene Konfiguration geändert.
• Es wird jetzt empfohlen, Type.hashcode (f) zu verwenden, um Hash-Werte zu generieren.
• Es zeigt auch, wie man die Hashing-Klasse von Guava verwendet. https://github.com/google/guava/wiki/HashingExplained
• Es wurde betont, keine detaillierten Spezifikationen für Hashcode bereitzustellen.

Item 12: Always override toString

• Statischen Dienstprogrammklassen und Aufzählungen wurde eine Klausel hinzugefügt, die besagt, dass toString () nicht erforderlich ist.
• Es wurde eine Klausel hinzugefügt, dass AutoValue empfohlen wird, um den Inhalt von toString () zu generieren.

Item 13: Override clone judiciously

• Die Erklärung von Object # clone () wurde komplett neu geschrieben.
• Der Inhalt wurde hinzugefügt "Die unveränderliche Klasse darf nicht klonbar sein, da sie Objekte vergeblich erstellt."
• Es ist eine gute Redewendung, clone () zum Duplizieren eines Arrays zu verwenden. Wurde hinzugefügt. (Könnte nützlich sein!)

Item 14: Consider implementing Comparable

• Bei der Implementierung von compareTo () wurde der Wrapper-Klasse jedes primitiven Typs anstelle des Vergleichsoperators eine statische compare () -Methode hinzugefügt. Daher wird jetzt empfohlen, sie zu verwenden. Double.compare () Float.compare () etc. --Einführung eines Beispiels mit Comparator.comparingInt`` Comparator.thenComparing aus Java8 hinzugefügt.

Chapter 4: Classes and Interfaces

Item 15: Minimize the accessibility of classes and members

• 4 Absätze aus P76 über das Java9-Modulsystem hinzugefügt.

Item 16: In public classes, use accessor methods, not public fields

Es gibt keine besondere charakteristische Änderung.

Item 17: Minimize mutability

• Es wurde eine Erklärung zum Unterschied zwischen dem funktionalen Ansatz (der das Objekt zurückgibt, nachdem es durch die Operation geändert wurde) und dem prozedural-imperativen Ansatz (der sich durch die Operation selbst ändert) hinzugefügt. (P82)
• Entfernter Absatz über die Stärken statischer Fabriken. (Da es sich um den ursprünglichen Inhalt von Punkt 1 handelt, scheint er hier gelöscht worden zu sein.)
• Die Verwendung von "TimerTask" im Beispiel der Erklärung, dass keine Neuinitialisierungsmethode erstellt wurde, wurde in "CountDownlatch" geändert. (Die fehlerhafte Klasse wurde zu einer Alternative geändert.)

Item 18: Favor composition over inheritance

Es gibt keine besondere charakteristische Änderung.

Item 19: Design and document for inheritance or else prohibit it

• Beschreibung des Tags "@ implSpec" hinzugefügt.

Item 20: Prefer interfaces to abstract classes

• Die Tatsache, dass die Standardmethode in der Schnittstelle enthalten ist, wird hinzugefügt.
• Änderungen am 2. und 3. Absatz von P102 hinzugefügt.
• 3 Absätze auf der letzten Seite gelöscht.

Item 21: Design interfaces for posterity

Neuer Gegenstand

――Lassen Sie uns die Schnittstelle für die Zukunft entwerfen. --Verwenden Sie die Standardmethoden der Schnittstelle mit Vorsicht.

• Die Einführung von Standardmethoden stimmt nicht immer mit vorhandenen Implementierungen überein.

Item 22: Use interfaces only to define types

• Es wurde hinzugefügt, dass Zahlenliterale durch Unterstriche getrennt geschrieben werden können.

Item 23: Prefer class hierarchies to tagged classes

Der Gesamtinhalt ändert sich nicht.

Item 24: Favor static member classes over nonstatic

• Eine Beschreibung von Lambda wurde zur Erklärung der Verwendung der anonymen Klasse hinzugefügt.

Item 25: Limit source files to a single top-level class

Neuer Gegenstand.

• Es sollte nur eine Klasse der obersten Ebene in einer Quelle enthalten sein. (Obwohl es natürlich ist, das zu sagen.)

Chapter 5: Generics

Item 26: Don’t use raw types

• Verwenden Sie in der 2. Ausgabe keine Rohtypen in neuem Code. Es war ein Inhalt, dass der Prototyp nicht im neuen Code verwendet werden sollte, aber in der 3. Ausgabe wurde die Einschränkung des neuen Codes entfernt. (Es scheint zu bedeuten, dass der Prototyp nicht sowohl in alten als auch in neuen verwendet werden sollte.)
• Das Beispiel mit java.util.Date ersetzt BigInteger. (Ist es die Absicht, es nicht als Beispiel zu geben?)

Item 27: Eliminate unchecked warnings

• Eine Beschreibung, dass der Diamantoperator verwendet werden kann, ist enthalten.

Item 28: Prefer lists to arrays

• Der Beispielcode in der zweiten Hälfte wurde in einen einfachen Code geändert.

Item 29: Favor generic types

• Ein Absatz der Erklärung in der Mitte wurde zu einem einfachen Inhalt umgeschrieben.

Item 30: Favor generic methods

• Entfernte Absätze mit Inhalten, die durch Weglassen des generischen Java 7-Typs abgedeckt werden können. Von der Mitte von P130 bis zum Beginn von P131 bis zu einem Viertel.
• Der Beispielcode wurde teilweise in ein Beispiel umgeschrieben, das Lambda-Ausdrücke kennt.

Item 31: Use bounded wildcards to increase API flexibility

• Die zur Erklärung von PECS verwendete Quelle hat sich geändert.
• Über explizite Typparameter wird erklärt, dass "explizite Typparameter vor Java8 erforderlich sind".
• Der Absatz, der besagt, dass die max () -Methode geändert werden muss, ist verschwunden. (Es ist wahr, aber es ist nicht die Behauptung dieses Gegenstands?)

Item 32: Combine generics and varargs judiciously

Neuer Gegenstand.

Item 33: Consider typesafe heterogeneous containers

• Fast keine Änderung. Es sind nur kleine Korrekturen und ergänzende Erläuterungen enthalten.

Chapter 6: Enums and Annotations

Item 34: Use enums instead of int constants

• Es wurde ein Absatz über das Verhalten beim Löschen des Enum-Werts hinzugefügt.
• Es wurde ein Absatz hinzugefügt, der besagt, dass vom Konstruktor des Enum-Werts nicht auf das statische Feld von Enum zugegriffen werden kann. --Verwenden Sie Optional für die Erklärungsbeispielquelle.
• Es wurde ein Absatz hinzugefügt, in dem das Strategie-Aufzählungsmuster erläutert wird, in dem das für den Aufzählungswert spezifische Verhalten definiert wird.
• Es wurde eine Beschreibung hinzugefügt, dass enum in Bezug auf die Leistung etwas nachteilig ist, mit Ausnahme von ressourcenintensiven Umgebungen wie Mobiltelefonen.
• Einige Ergänzungen zum Absatz über die Verwendung von Enum.

Item 35: Use instance fields instead of ordinals

• Der Gesamtzweck ändert sich nicht.

Item 36: Use EnumSet instead of bit fields

• Es wurde ein Absatz hinzugefügt, der die Nachteile beschreibt.

Item 37: Use EnumMap instead of ordinal indexing

• Einige Änderungen an der Beispielquelle
• Die Karte wurde geändert, um mit Stream zu initialisieren, und einige Absätze wurden hinzugefügt, um dies zu erklären.
• Mehrere Typnamen haben sich geändert. Harb-> Plant

Item 38: Emulate extensible enums with interfaces

• Ein Absatz wurde hinzugefügt, um ein Beispiel für dieses Muster zu erläutern, das in der Standard-API verwendet wird.

Item 39: Prefer annotations to naming patterns

• Ein Absatz wurde hinzugefügt, um ein Beispiel aus Java8 zu erläutern, bei dem dieselbe Annotation mehrmals geschrieben wird (Annotation "@ Repeatable").

Item 40: Consistently use the Override annotation

• Der letzte Absatz wurde teilweise überarbeitet. (Informationen zur Verwendung, wenn keine Annotation "@ Override" erforderlich ist)

Item 41: Use marker interfaces to define types

• Einige Inhalte haben sich aufgrund der Einführung der Standardmethode geändert.
• Einige der Erläuterungen zur Auswahl der Benutzeroberfläche und der Anmerkungen wurden neu geschrieben.

Chapter 7: Lambdas and Streams

Neues Kapitel! In diesem Artikel nicht behandelt.

• Item 42: Prefer lambdas to anonymous classes
• Item 43: Prefer method references to lambdas
• Item 44: Favor the use of standard functional interfaces
• Item 45: Use streams judiciously
• Item 46: Prefer side-effect-free functions in streams
• Item 47: Prefer Collection to Stream as a return type
• Item 48: Use caution when making streams parallel

Chapter 8: Methods

Item 49: Check parameters for validity

• Es wurde ein Absatz hinzugefügt, in dem alle gängigen Spezifikationen von Klassenmethoden in die Klassendokumentation geschrieben werden sollten.
• Einführung von java.util.Objects`` #requireNonNull (T) in Java7.
• Es wurde ein Absatz hinzugefügt, in dem die neue Bereichsüberprüfungsmethode für "java.util.Objects" in Java 9 eingeführt wird.

Item 50: Make defensive copies when needed

• Für den Beispielcode gibt es einen Absatz, der besagt, dass "Datum" in Java 8 oder höher nicht verwendet werden sollte.

Item 51: Design method signatures carefully

• Der Gesamtinhalt ändert sich nicht.

Item 52: Use overloading judiciously

• Ein Beispiel für die Auswirkungen von Java 8-Lambdas und Methodenreferenzen auf die Überladung wurde hinzugefügt. "Führen Sie keine Methodenüberladungen durch, bei denen unterschiedliche Funktionsschnittstellen als Argumente verwendet werden."

「inexact method reference」

Referenz: https://mjg123.github.io/2017/10/23/Java-Inexact-Method-References.html

Item 53: Use varargs judiciously

• Alle Absätze mit der Aufschrift "Sie sollten eine Methode mit einem Array als Parameter nicht in ein Argument mit variabler Länge ändern, nur weil es geändert werden kann" sind verschwunden. (Vielleicht wurde die Breite des Papiers angepasst, oder es gab nur wenige Leute, die dies taten.)

Item 54: Return empty collections or arrays, not nulls

――Die Entwicklung der Geschichte hat sich zu einer Struktur geändert, in der die Sammlung vor dem Array herauskommt.

• Der Inhalt, der die C-Sprachoptimierung berührt, wurde gelöscht. (Vielleicht, weil C-Sprachprogrammierer Java weniger wahrscheinlich starten)

Item 55: Return optionals judiciously

Neuer Gegenstand. Ich werde es in diesem Artikel weglassen.

Item 56: Write doc comments for all exposed API elements

Der Gesamtanspruch ändert sich nicht, es wurden jedoch verschiedene Ergänzungen vorgenommen.

• Hinzugefügt über das in Java8 und Java9 hinzugefügte Dokument-Tag.
• @implSpec
• Es ist praktisch, "@ index" zu verwenden, da es in den Vorschlägen für die Suche mit Javadoc angezeigt wird.
• Verweis auf module-info.java hinzugefügt (es gibt keinen detaillierten Inhalt)
• Es wurde ein Beschreibungsabschnitt über die Funktion hinzugefügt, um zu überprüfen, ob der Inhalt dieses Elements befolgt wird. JavaDoc-Tool, Checkstyle, W3C-Validator
• Es wurde ein Absatz hinzugefügt, in dem erklärt wird, dass Sie ihn tatsächlich lesen sollten, um festzustellen, ob es sich um ein klares Dokument handelt, das dem Inhalt dieses Artikels entspricht.
• Es wurde ein Satz hinzugefügt, mit dem Sie das Tag "@ return" weglassen können, wenn es mit der Methodenbeschreibung übereinstimmt.
• Die Funktionsbeschreibung des Tags "@ code" wurde hinzugefügt.
• Es wurde ein Satz hinzugefügt, dass der erste Satz einer Methode oder eines Konstruktors in der dritten Person geschrieben ist.

(Ich kann dankbar sein, wie man das Dokument schreibt.)

Chapter 9: General Programming

Item 57: Minimize the scope of local variables

Der Gesamtinhalt ändert sich nicht.

Item 58: Prefer for-each loops to traditional for loops

• Es wurde ein Satz hinzugefügt, für den die herkömmliche for-Schleife eine Codeänderung erfordert, wenn das Scan-Ziel in Sammlungen und Arrays geändert wird.
• Die Struktur des Absatzes über den Fall, dass for-each nicht verwendet werden kann, hat sich geändert (keine Änderung des Inhalts).
• Es wurde ein Satz hinzugefügt, der besagt, dass "Collection # removeIf" beim Filtern einer Sammlung verwendet werden kann, wenn for-each nicht verwendet werden kann. (Es sieht bequem aus!)

Item 59: Know and use the libraries

• In Java 7 oder höher wurde ein Absatz zur Einführung von "ThreadLocalRandom" für die Zufallszahlengenerierung hinzugefügt.
• Es wurde ein Absatz hinzugefügt, um "InputStream.html # transferTo ()" einzuführen, der in Java9 enthalten war.
• Wenn die Bibliothek nicht über die gewünschten Funktionen verfügt, ändern Sie den Text, um eine hochwertige Bibliothek von Drittanbietern zu verwenden. (Bisher sollte der Inhalt selbst implementiert werden.)

Item 60: Avoid float and double if exact answers are required

• In der Beschreibung der Beispielquelle wird hinzugefügt, dass ein Konstruktor verwendet wird, der einen String als Argument verwendet, damit ein genauer Wert eingegeben werden kann.

Item 61: Prefer primitive types to boxed primitives

Der Gesamtzweck ändert sich nicht.

Item 62: Avoid strings where other types are more appropriate

Der Gesamtzweck ändert sich nicht.

Item 63: Beware the performance of string concatenation

Der Gesamtzweck ändert sich nicht.

Item 64: Refer to objects by their interfaces

• Das Beispiel in Vector wurde durch LinkedHashSet ersetzt. (Liegt es daran, dass Vector alt ist?)
• Die Erklärung von ThreadLocal wurde durch die Erklärung von HashMap ersetzt. (Der Zweck bleibt der gleiche.)

Item 65: Prefer interfaces to reflection

――Der eine Absatz "In der Regel sollten normale Apps zur Laufzeit nicht durch Reflektion auf Objekte zugreifen" wurde gelöscht. (Weil die Grenze zwischen normal und ungewöhnlich verschwommen ist?)

• Für Ausnahmen in der Reflexion wurde ein Verweis auf eine allgemeine übergeordnete Klasse namens "ReflectiveOperationException" hinzugefügt. (Java7 Die Klasse wurde hinzugefügt. Es ist für Multi-Catch geeignet. )

Item 66: Use native methods judiciously

• Es wurde ein Absatz hinzugefügt, der die Entwicklung von BigInteger seit Java3 erklärt. (Es scheint, dass Java 1.3 als Java 3 geschrieben wurde. Das ist es.)

Item 67: Optimize judiciously

• Einen Absatz hinzugefügt. "Es ist fast 20 Jahre her, dass dieser Artikel zum ersten Mal geschrieben wurde, und die Betriebsumgebung des Programms hat sich geändert. Die Kombination der in diesem Artikel genannten Softwareelemente macht es schwierig, die Leistung vorherzusagen, und der Messbedarf ist relativ. Ich ging zu. " ――Die Beschreibung, dass "20% des Codes 80% der Zeit benötigen", wurde in "10% des Codes dauert 90% der Zeit" geändert. (Vielleicht liegt es daran, dass es größer wird.)
• Verweis auf Java Microbenchmark Harness hinzugefügt. http://openjdk.java.net/projects/code-tools/jmh/ (kann nützlich sein)

Item 68: Adhere to generally accepted naming conventions

• Beschreibung der Benennungsmethodenparameter hinzugefügt.
• Geschwächte Empfehlungen für das Reiten von Java Beans-Namenskonventionen. (Weil Serialisierung beteiligt ist?)

Chapter 10: Exceptions

Item 69: Use exceptions only for exceptional conditions

• Optional wird der Diskussion hinzugefügt, ob eine Methode zum Überprüfen des Status oder eines einzelnen Werts verwendet werden soll.

Item 70: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors

• Die Struktur der Absätze, die zusammengefasst und zusammengefasst werden, hat sich geändert.

Item 71: Avoid unnecessary use of checked exceptions

• Der Absatz über "CloneNotSupportedException" wurde entfernt.
• Es wurde ein Absatz hinzugefügt, in dem beschrieben wird, wie "Optional" verwendet wird, um geprüfte Ausnahmen zu beseitigen.
• Es wurde ein Abschnitt hinzugefügt, der zusammenfasst und zusammenfasst.

Item 72: Favor the use of standard exceptions

• Es wurde ein Absatz hinzugefügt, um die direkte Verwendung von "Exception", "RuntimeException", "Throwable" und "Error" zu vermeiden.
• Es wurde ein Satz hinzugefügt, in dem erwähnt wird, dass Ausnahmeklassen zum Erstellen untergeordneter Klassen von Ausnahmeklassen in der Standard-API serialisiert werden können.
• Es werden nun spezifische Kriterien für die Verwendung von "IllegalStateException" oder "IllegalArgumentException" zur Auswahl einer Ausnahmeklasse angezeigt.

Item 73: Throw exceptions appropriate to the abstraction

• Der Gesamtzweck ändert sich nicht.

Item 74: Document all exceptions thrown by each method

• Es wurde die Beschreibung hinzugefügt, dass nur die "Haupt" -Methode "Exception" oder "Throwable" auslösen darf.
• Es wurde ein Satz hinzugefügt, dass das Ausnahmedokument in der Methode mit dem Tag "@ throw" geschrieben werden soll.

Item 75: Include failure-capture information in detail messages

• Fügen Sie keine Passwörter, Verschlüsselungsschlüssel usw. in detaillierte Nachrichten ein. Ein Absatz wird hinzugefügt.
• Der Unterschied zwischen der Nachricht für Benutzer und der detaillierten Meldung der Ausnahme wurde hinzugefügt.
• Hinzugefügt über den Konstruktor, der von IndexOutOfBoundException in Java9 hinzugefügt wurde

Item 76: Strive for failure atomicity

• Die 3. und 4. Methode zur Aufrechterhaltung des Objektzustands wurden ausgetauscht.
• Der Inhalt der Wartung ist klarer geworden, wenn "Fehler" auftritt.

Item 77: Don’t ignore exceptions

• Der Inhalt von "ignoriert" wurde als Variablenname hinzugefügt, wenn die Ausnahme absichtlich ignoriert wird.
• Beispielquelle hinzugefügt.

Chapter 11: Concurrency

Item 78: Synchronize access to shared mutable data

--java.util.concurrent.atmic Paketbeschreibung wurde klein hinzugefügt.

Item 79: Avoid excessive synchronization

• Ein Absatz hinzugefügt. Der Grund wurde hinzugefügt, warum der mittlere "BiConsumer" von P318 nicht so verwendet wurde, wie er ist.
• Ein Absatz zu P319 hinzugefügt. Als Ergänzung zur Beispielquelle habe ich hinzugefügt, dass ich eine anonyme Klasse verwendet habe, da Lambda nicht auf eine eigene Instanz zugreifen kann. --P320 Ein Absatz am Anfang Es wurde hinzugefügt, dass Java 7 oder höher Multi-Catch verwendet wird, um mehrere Ausnahmen abzufangen.
• Zu einem Absatz von P322 hinzugefügt. In zwei Absätze unterteilt. Es gibt eine ausführliche Diskussion darüber, ob die Thread-Synchronisation außerhalb der Klasse oder innerhalb der Klasse erfolgen soll.
• Der Absatz über Synchronisierungsmethoden, die auf statische Felder zugreifen, wurde geringfügig erweitert.

Item 80: Prefer executors, tasks, and streams to threads

• Der Absatz, in dem das Executor Framework als Alternative zur Klasse "java.util.Timer" beschrieben wird, wurde durch den Inhalt für die Aufgabe "Fork-Join" ersetzt. (Ist es eine Frage der Papierbreite und Wichtigkeit?)

Item 81: Prefer concurrency utilities to wait and notify

• Es gibt einige kleine Ergänzungen.
• Bei der Einführung von "Synchronisierern" wird nur der Name "Phaser" eingeführt. (Eingeführt von Java 7)
• Es wurde ein Satz hinzugefügt, der die genaue Leistungsmessung berührt. (Auch hier wird JMH erwähnt)

Item 82: Document thread safety

――Es gibt einige geringfügige Ergänzungen, aber der Gesamtzweck ändert sich nicht.

• Es ist jetzt klargestellt, dass das Sperrfeld immer endgültig sein sollte.

Item 83: Use lazy initialization judiciously

• Der Gesamtzweck ändert sich nicht.
• Der Absatz, in dem erklärt wird, dass Double Check ordnungsgemäß verwendet werden kann, indem das Speichermodell nach 1.5 geändert wird, wurde entfernt. (Sprechen wir nicht mehr über Java 1.4 oder früher?)

Item 84: Don’t depend on the thread scheduler

Der Gesamtzweck ändert sich nicht.

• Löschte den Absatz über das, was in der ersten Ausgabe über die einzige Verwendung von Ertrag geschrieben wurde

Chapter 12: Serialization

Item 85: Prefer alternatives to Java serialization

Neuer Gegenstand

――Der Inhalt dieses Kapitels als Ganzes empfiehlt keine Serialisierung. Es ist ein Absatz wie die Gliederungserklärung. ―― "Serialisierung ist gefährlich und sollte vermieden werden. Verwenden Sie für neue Systeme JSON- oder Protokollpuffer."

Item 86: Implement Serializable with great caution

• Die Möglichkeit eines Finalizer-Angriffs wurde zur Beschreibung von Risiken hinzugefügt, wenn eine Klasse mit serialisierbaren Instanzfeldern implementiert wird.
• Einige Absätze, in denen die Punkte, die zu beachten sind, wenn die für die Vererbung vorgesehene Klasse Serializable nicht implementiert, ausführlich erläutert werden, sind verschwunden. (Etwas weniger als 2 Seiten. Problem mit der Papierbreite?)

Item 87: Consider using a custom serialized form

• Der Status der Leistungsmessung wurde in den Ergebnissen der 3. Ausgabe korrigiert.
• Die Beschreibung zur Behandlung von "defaultWriteObject ()" wurde geändert. (Es muss gemäß den Spezifikationen aufgerufen werden)
• Es wird klargestellt, dass die UID der seriellen Version nicht geändert werden sollte, es sei denn, Sie möchten absichtlich eine Inkompatibilität erstellen.

Item 88: Write readObject methods defensively

• Es gibt eine Ergänzung darüber, warum Sie im Beispielcode in "Byte" umwandeln (da Ganzzahlliterale int sind und Sie eine explizite Umwandlung benötigen, um Zahlen größer oder gleich 128 als "Byte" zu behandeln. 127 Nicht erforderlich, wenn: Wenn das höchstwertige Bit in der Binärdatei "0" ist, sind "int" und "byte" identisch.)
• Der Absatz über die Methode "writeUnshared", "readUnshared" wurde gelöscht (weil er zu verrückt war?)

Item 89: For instance control, prefer enum types to readResolve

• Der Vorbehalt "Es sei denn, ein Angreifer missbraucht AccessibleObject.setAccessible" wird der "Aufzählung garantiert Singleton für Java" hinzugefügt. (Als mir das gesagt wurde, hatte ich weder ein ehemaliges noch ein Kind, aber insgesamt neigte ich zu einem pessimistischen Ton.)

Item 90: Consider serialization proxies instead of serialized instances

Der Gesamtzweck ändert sich nicht.

Am Ende

Die Veröffentlichungstermine jeder Ausgabe sind wie folgt.

Die nächste effektive Java 4th Edition wird voraussichtlich 2027 sein, also ungefähr 9 Jahre später. Die Java-Version sollte zu diesem Zeitpunkt 30 sein, entsprechend dem aktuellen Release-Modell [^ 2], und ich kann mir nicht vorstellen, welche neuen Funktionen es hat. Wir sehen uns alle in 9 Jahren wieder. (Ist es nicht mehr geschrieben?)