Ce qui a changé entre la 2e édition effective de Java et la 3e édition

À propos de cet article

La 3e édition effective de Java a été publiée. De nouveaux éléments de langage de Java 7 à Java 9 ont été ajoutés, et je pense que c'est Lambda pour le moment, mais je m'inquiétais des autres changements et ajouts. J'ai donc comparé les 2e et 3e éditions côte à côte et vérifié grossièrement ces endroits.

Dans cet article, j'ai répertorié les endroits que je pensais "peut-être caractéristiques!" Pas sur les nouveaux éléments, mais sur les changements dans les éléments existants. [^ 1] Peut-être que vous n'avez jamais envie de lire cet article, mais plutôt une référence pour ceux qui ont lu la 2ème édition pour réapprendre la 3ème édition. Je pense qu'il sera utilisé comme ça. Je pense qu'il y a beaucoup de malentendus et d'omissions, alors appréciez la recherche d'erreurs.

[^ 1]: J'écrirai un article séparé sur les nouveaux éléments.

Dans l'ensemble, les changements n'ont pas beaucoup changé dans l'esprit de chaque élément, sauf que les risques de sécurité liés à la sérialisation sont devenus plus prononcés. De plus, la grammaire et les API standard Java 7 et ultérieures ont été ajoutées pour améliorer l'écriture, et le format du document a été modifié en conséquence.

Parmi les outils introduits, j'ai pensé que Java Microbenchmark Harness pourrait être utile. (Je ne l'ai pas bien vérifié ...) http://openjdk.java.net/projects/code-tools/jmh/ La liste des articles est http://www.informit.com/store/effective-java-9780134685991 , Obtenu à partir d'un échantillon de contenu.

Chapter 2: Creating and Destroying Objects

Item 1: Consider static factory methods instead of constructors

• Suppression des parties qui ne peuvent plus être considérées comme un avantage après la sortie de Java7.
• Contient une référence à la méthode par défaut de l'interface Java 8. ――La composition a été modifiée là où sont listés les avantages listés dans la 2ème édition.

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

--Ajout d'un générateur d'exemple avec une hiérarchie de classes à l'aide du paramètre de type récursif (Item30).

• La référence au modèle AbstractFactory a été supprimée.

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

• Ajout de la mention que les références de méthode peuvent être utilisées en ayant une méthode appelée getInstance ().

Item 4: Enforce noninstantiability with a private constructor

――Il n'y a pas de changement de caractéristique particulier.

Item 5: Prefer dependency injection to hardwiring resources

Nouvel article

Item 6: Avoid creating unnecessary objects

--L'exemple de code a été changé en un utilisant RegEx. (Peut-être que je ne voulais pas donner un exemple de Calander ou de Date.)

Item 7: Eliminate obsolete object references

――Il n'y a pas de changement de caractéristique particulier.

Item 8: Avoid finalizers and cleaners

• Le finaliseur est obsolète et un nettoyeur a été ajouté, mais il a également été ajouté qu'il devrait être évité.

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

Nouvel article.

Chapter 3: Methods Common to All Objects

Item 10: Obey the general contract when overriding equals

• L'Autovalue de Google est introduit dans l'implémentation de equals () hashcode (). "La génération automatique de l'EDI ne peut pas suivre les changements de classe. Ce n'est pas joli. C'est mieux que de le faire à la main." https://github.com/google/auto/tree/master/value

Item 11: Always override hashCode when you override equals

--L'exemple de classe PhoneNumber a changé pour la configuration décrite dans l'élément 10. --Il est maintenant recommandé d'utiliser Type.hashcode (f) pour générer des valeurs de hachage. --Il montre également comment utiliser la classe de hachage de Guava. https://github.com/google/guava/wiki/HashingExplained --Il a été souligné de ne pas fournir de spécifications détaillées pour le hashcode.

Item 12: Always override toString

• Ajout d'une clause aux classes d'utilitaires statiques et aux énumérations indiquant que toString () n'est pas obligatoire.
• Ajout d'une clause selon laquelle AutoValue est recommandé pour générer le contenu de toString ().

Item 13: Override clone judiciously

• L'explication de Object # clone () a été complètement réécrite.
• Ajout du contenu "La classe immuable ne doit pas être clonable, car elle crée des objets en vain."
• C'est un bon idiome d'utiliser clone () pour dupliquer un tableau. Était ajouté. (Peut être utile!)

Item 14: Consider implementing Comparable

--Dans l'implémentation de compareTo (), plutôt que d'utiliser l'opérateur de comparaison, une méthode statique compare () a été ajoutée à la classe wrapper de chaque type primitif, il est donc maintenant recommandé de l'utiliser. Double.compare () Float.compare () etc.

• Ajout d'une introduction d'un exemple utilisant Comparator.comparingInt`` Comparator.thenComparing introduit à partir de Java8.

Chapter 4: Classes and Interfaces

Item 15: Minimize the accessibility of classes and members

--Ajout de 4 paragraphes de P76 sur le système de module Java9.

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

Il n'y a pas de changement de caractéristique particulier.

Item 17: Minimize mutability

• Ajout d'une explication sur la différence entre l'approche fonctionnelle (qui retourne l'objet après qu'il a été modifié par l'opération) et l'approche procédurale impérative (qui se modifie par l'opération). (P82)
• Suppression du paragraphe sur les atouts des usines statiques. (Puisqu'il s'agit du contenu original de l'élément 1, il semble avoir été supprimé ici.) --L'utilisation de TimerTask dans l'exemple de l'explication de ne pas créer de méthode de réinitialisation a été remplacée par CountDownlatch. (La classe défectueuse est devenue une alternative.)

Item 18: Favor composition over inheritance

Il n'y a pas de changement de caractéristique particulier.

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

• Ajout de la description de la balise @ implSpec.

Item 20: Prefer interfaces to abstract classes

• Le fait que la méthode par défaut soit incluse dans l'interface est ajouté. --Ajout de modifications aux 2e et 3e paragraphes de P102.
• Suppression de 3 paragraphes sur la dernière page.

Item 21: Design interfaces for posterity

Nouvel article

―― Concevons l'interface du futur.

• Utilisez les méthodes par défaut de l'interface avec précaution.
• L'introduction des méthodes par défaut n'est pas toujours cohérente avec les implémentations existantes.

Item 22: Use interfaces only to define types

-Ajout de la possibilité d'écrire des littéraux numériques séparés par des traits de soulignement.

Item 23: Prefer class hierarchies to tagged classes

Il n'y a aucun changement dans le contenu global.

Item 24: Favor static member classes over nonstatic

• Une description de lambda a été ajoutée à l'explication de l'utilisation de la classe anonyme.

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

Nouvel article.

• Une seule classe de premier niveau doit être incluse dans une source. (Bien qu'il soit naturel de dire cela.)

Chapter 5: Generics

Item 26: Don’t use raw types

• Dans la 2ème édition, n'utilisez pas de types bruts dans le nouveau code. C'était un contenu que le prototype ne devrait pas être utilisé dans le nouveau code, mais dans la 3ème édition, la restriction du nouveau code a été supprimée. (Cela semble signifier que le prototype ne doit pas être utilisé à la fois dans l'ancien et dans le nouveau.)
• L'exemple utilisant «java.util.Date» remplace «BigInteger». (Est-ce l'intention de ne pas le donner à titre d'exemple?)

Item 27: Eliminate unchecked warnings

• Une description que l'opérateur diamant peut être utilisé est incluse.

Item 28: Prefer lists to arrays

• L'exemple de code de la seconde moitié a été remplacé par un simple.

Item 29: Favor generic types

• Un paragraphe de l'explication au milieu a été réécrit en un contenu simple.

Item 30: Favor generic methods

• Suppression des paragraphes dont le contenu peut être couvert en omettant le type générique Java 7. Du milieu de P130 au début de P131 jusqu'à un quart.
• L'exemple de code a été partiellement réécrit en un exemple conscient des expressions lambda.

Item 31: Use bounded wildcards to increase API flexibility

• La source utilisée pour expliquer le PECS a changé. --À propos du paramètre de type explicite, il est expliqué que «le paramètre de type explicite est requis avant Java8».
• Le paragraphe qui dit que la méthode max () doit être modifiée a disparu. (C'est vrai, mais ce n'est pas la revendication de cet article?)

Item 32: Combine generics and varargs judiciously

Nouvel article.

Item 33: Consider typesafe heterogeneous containers

• Presque aucun changement. Seules de petites corrections et des explications supplémentaires sont incluses.

Chapter 6: Enums and Annotations

Item 34: Use enums instead of int constants

--Ajout d'un paragraphe sur le comportement lorsque la valeur de Enum est supprimée.

• Ajout d'un paragraphe sur l'impossibilité d'accéder au champ statique d'Enum à partir du constructeur de la valeur enum. --Utilisez Facultatif pour la source d'échantillon d'explication.
• Ajout d'un paragraphe expliquant le modèle d'énumération de stratégie, qui définit le comportement spécifique à la valeur d'énumération.
• Ajout d'une description qui enum est légèrement désavantageuse en termes de performances, sauf pour les environnements gourmands en ressources tels que les téléphones mobiles.
• Quelques ajouts au paragraphe sur le moment d'utiliser enum.

Item 35: Use instance fields instead of ordinals

• Il n'y a pas de changement dans l'objectif général.

Item 36: Use EnumSet instead of bit fields

• Ajout d'un paragraphe décrivant les inconvénients.

Item 37: Use EnumMap instead of ordinal indexing

• Quelques exemples de modifications de source
• La carte a été modifiée pour s'initialiser avec Stream, et quelques paragraphes ont été ajoutés pour l'expliquer. --Plusieurs noms de types ont changé. Harb-> Plante

Item 38: Emulate extensible enums with interfaces

• Un paragraphe a été ajouté pour expliquer un exemple de ce modèle utilisé dans l'API standard.

Item 39: Prefer annotations to naming patterns

--Un paragraphe a été ajouté pour expliquer un exemple de Java8 utilisant la méthode d'écriture de la même annotation plusieurs fois (annotation @ Repeatable).

Item 40: Consistently use the Override annotation

• Le dernier paragraphe a été partiellement révisé. (À propos de l'utilisation lorsque l'annotation @ Override n'est pas requise)

Item 41: Use marker interfaces to define types

• Certains contenus ont changé en raison de l'introduction de la méthode par défaut.
• Certaines des explications sur l'interface et la sélection d'annotations ont été réécrites.

Chapter 7: Lambdas and Streams

Nouveau chapitre! Non couvert dans cet article.

• 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

• Ajout d'un paragraphe indiquant que toutes les spécifications communes des méthodes de classe doivent être écrites dans la documentation de classe. --Introduction de `java.util.Objects`` #requireNonNull (T) ʻen Java7.
• Ajout d'un paragraphe présentant la nouvelle méthode de vérification de plage de java.util.Objects dans Java 9.

Item 50: Make defensive copies when needed

• Pour l'exemple de code, il y a un paragraphe indiquant que «Date» ne doit pas être utilisé dans Java 8 ou version ultérieure.

Item 51: Design method signatures carefully

• Il n'y a pas de changement dans le contenu global.

Item 52: Use overloading judiciously

• Ajout d'un exemple de l'impact des lambdas Java 8 et des références de méthode sur la surcharge. "Ne faites pas de surcharges de méthode qui prennent différentes interfaces fonctionnelles comme arguments."

「inexact method reference」

Référence: https://mjg123.github.io/2017/10/23/Java-Inexact-Method-References.html

Item 53: Use varargs judiciously

• Tous les paragraphes qui disent "Vous ne devriez pas changer une méthode qui a un tableau comme paramètre en un argument de longueur variable simplement parce qu'il peut être modifié" ont disparu. (Peut-être que la largeur du papier a été ajustée, ou peu de gens l'ont fait.)

Item 54: Return empty collections or arrays, not nulls

――Le développement de l'histoire est devenu une structure dans laquelle la collection sort avant le tableau.

• Le contenu qui touche à l'optimisation du langage C a été supprimé. (Peut-être parce que les programmeurs en langage C sont moins susceptibles de démarrer Java)

Item 55: Return optionals judiciously

Nouvel article. Je vais l'omettre dans cet article.

Item 56: Write doc comments for all exposed API elements

Il n'y a pas de changement dans la demande globale, mais divers ajouts ont été faits.

• Ajout de la balise doc ajoutée dans Java8 et Java9.
• @implSpec --Il est pratique d'utiliser @ index car il apparaîtra dans les suggestions de recherche avec javadoc.
• Ajout d'une référence à module-info.java (il n'y a pas de contenu détaillé) --Ajout d'un paragraphe de description sur la fonction pour vérifier si le contenu de cet élément est suivi. Outil JavaDoc, checkstyle, W3C-Validator --Ajout d'un paragraphe expliquant que vous devez réellement le lire pour voir s'il s'agit d'un document clair selon le contenu de cet élément.
• Ajout d'une phrase que vous pouvez omettre la balise @ return si elle est la même que la description de la méthode. --Ajout de la description de la fonction de la balise @ code.
• Ajout d'une phrase indiquant que la première phrase d'une méthode ou d'un constructeur est écrite à la troisième personne.

(Je serai peut-être reconnaissant de savoir comment rédiger le document.)

Chapter 9: General Programming

Item 57: Minimize the scope of local variables

Il n'y a aucun changement dans le contenu global.

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

• Ajout d'une phrase indiquant que la boucle for traditionnelle nécessite une modification du code lors du changement de la cible d'analyse en collections et tableaux
• La structure du paragraphe concernant le cas où for-each ne peut pas être utilisé a changé (pas de changement de contenu)
• Ajout d'une phrase que Collection # removeIf peut être utilisée lors du filtrage d'une collection dans les cas où for-each ne peut pas être utilisé. (Cela semble pratique!)

Item 59: Know and use the libraries

• Dans Java 7 ou version ultérieure, un paragraphe introduisant ThreadLocalRandom a été ajouté pour la génération de nombres aléatoires.
• Ajout d'un paragraphe pour introduire ʻInputStream.html # transferTo () `entré dans Java9.
• Si la bibliothèque ne possède pas les fonctionnalités souhaitées, modifiez le texte pour utiliser une bibliothèque tierce de haute qualité. (Auparavant, le contenu consistait à l'implémenter vous-même.)

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

--Dans la description de la source de l'échantillon, il est ajouté qu'un constructeur qui prend une chaîne comme argument est utilisé afin qu'une valeur précise puisse être saisie.

Item 61: Prefer primitive types to boxed primitives

Il n'y a pas de changement dans l'objectif général.

Item 62: Avoid strings where other types are more appropriate

Il n'y a pas de changement dans l'objectif général.

Item 63: Beware the performance of string concatenation

Il n'y a pas de changement dans l'objectif général.

Item 64: Refer to objects by their interfaces

• L'exemple de «Vector» a été remplacé par «LinkedHashSet». (Est-ce parce que Vector est vieux?)
• L'explication par «ThreadLocal» a été remplacée par l'explication par «HashMap». (Le but reste le même.)

Item 65: Prefer interfaces to reflection

―― Le paragraphe «En règle générale, les applications normales ne doivent pas accéder aux objets par réflexion lors de l'exécution» a été supprimé. (Parce que la ligne entre normal et inhabituel est floue?)

• Ajout d'une référence à une classe parent commune appelée ReflectiveOperationException pour les exceptions en réflexion. (Java7 La classe ajoutée. Il convient aux prises multiples. )

Item 66: Use native methods judiciously

• Ajout d'un paragraphe expliquant l'évolution de BigInteger depuis Java3. (Il semble que Java 1.3 a été écrit en tant que Java 3. C'est ce que c'est.)

Item 67: Optimize judiciously

• Ajout d'un paragraphe. Selon lui, «Près de 20 ans après la première rédaction de cet article, l'environnement opérationnel du programme a changé. La combinaison des éléments logiciels dont il est question dans cet article rend difficile la prédiction des performances et le besoin de mesure est relatif. Je suis allé jusqu'à. " ――La description selon laquelle "20% du code prend 80% du temps" a été remplacée par "10% du code prend 90% du temps". (Peut-être que c'est parce qu'il s'agrandit.)
• Ajout d'une référence à Java Microbenchmark Harness. http://openjdk.java.net/projects/code-tools/jmh/ (peut être utile)

Item 68: Adhere to generally accepted naming conventions

• Ajout de la description des paramètres de méthode de dénomination.
• Recommandations affaiblies pour utiliser les conventions de nommage des Java Beans. (Parce que la sérialisation est impliquée?)

Chapter 10: Exceptions

Item 69: Use exceptions only for exceptional conditions

• Facultatif est ajouté à la discussion sur l'opportunité d'utiliser une méthode pour vérifier l'état ou une valeur individuelle.

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

• La structure des paragraphes qui sont résumés et résumés a changé.

Item 71: Avoid unnecessary use of checked exceptions

• Le paragraphe sur CloneNotSupportedException a été supprimé.
• Ajout d'un paragraphe sur la façon d'éliminer les exceptions vérifiées en utilisant ʻOptional`.
• Ajout d'une section qui résume et résume.

Item 72: Favor the use of standard exceptions

• Ajout d'un paragraphe indiquant que ʻException, RuntimeException, Throwable, ʻError ne doivent pas être utilisées directement.
• Ajout d'une phrase qui mentionne que les classes d'exceptions peuvent être sérialisées pour créer des classes enfants de classes d'exceptions dans l'API standard.
• Les critères d'utilisation de ʻIllegalStateException ou ʻIllegalArgumentException pour la sélection des classes d'exception sont maintenant présentés concrètement.

Item 73: Throw exceptions appropriate to the abstraction

• Il n'y a pas de changement dans l'objectif général.

Item 74: Document all exceptions thrown by each method

• Ajout de la description selon laquelle seule la méthode main peut être throws Exception ou Throwable.
• Ajout d'une phrase indiquant que le document d'exception dans la méthode doit être écrit avec la balise @ throws.

Item 75: Include failure-capture information in detail messages

• N'incluez pas les mots de passe, les clés de cryptage, etc. dans les messages détaillés. Un paragraphe est ajouté. --Ajout de la différence entre le message pour les utilisateurs et le message détaillé d'exception.
• Ajouté à propos du constructeur ajouté par ʻIndexOutOfBoundException` dans Java9

Item 76: Strive for failure atomicity

• Les 3e et 4e méthodes de maintien de l'état de l'objet ont été permutées.
• Le contenu est devenu plus clair sur la maintenance lorsque ʻError` se produit.

Item 77: Don’t ignore exceptions

--Ajout du contenu de ʻignored` comme nom de variable lorsque l'exception est intentionnellement ignorée.

• Ajout de la source d'échantillon.

Chapter 11: Concurrency

Item 78: Synchronize access to shared mutable data

--java.util.concurrent.atmic La description du package a été ajoutée petite.

Item 79: Avoid excessive synchronization

• Ajout d'un paragraphe. Ajout de la raison pour laquelle le «BiConsumer» du milieu sur P318 n'a pas été utilisé tel quel. --Ajout d'un paragraphe à P319. En complément de l'exemple de source, j'ai ajouté que j'avais utilisé une classe anonyme car Lambda ne pouvait pas accéder à sa propre instance. --P320 Un paragraphe au début Ajouté que Java 7 ou plus récent multi-catch est utilisé pour intercepter plusieurs exceptions. --Ajouté à un paragraphe de la P322. Divisé en deux paragraphes. Il y a une discussion détaillée sur l'opportunité de laisser la synchronisation des threads en dehors de la classe ou de la faire à l'intérieur de la classe.
• Des ajouts légers ont été apportés au paragraphe sur les méthodes de synchronisation qui accèdent aux champs statiques.

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

• Le paragraphe décrivant le Framework Executor comme une alternative à la classe java.util.Timer a été remplacé par le contenu de la tâche fork-join. (Est-ce une question de largeur et d'importance du papier?)

Item 81: Prefer concurrency utilities to wait and notify

• Il y a quelques petits ajouts. --Dans l'introduction de «Synchroniseurs», seul le nom de «Phaser» est introduit. (Introduit à partir de Java 7)
• Ajout d'une phrase qui concerne la mesure précise des performances. (Ici encore, JMH est mentionné)

Item 82: Document thread safety

――Il y a quelques ajouts mineurs, mais il n'y a pas de changement dans l'objectif général.

• Il est maintenant précisé que le champ de verrouillage doit toujours être définitif.

Item 83: Use lazy initialization judiciously

• Il n'y a pas de changement dans l'objectif général.
• Suppression du paragraphe expliquant que Double Check peut être utilisé correctement en modifiant le modèle de mémoire après 1.5 (Ne parlons-nous plus de Java 1.4 ou d'une version antérieure?)

Item 84: Don’t depend on the thread scheduler

Il n'y a pas de changement dans l'objectif général.

• Suppression du paragraphe sur ce qui était écrit dans la première édition sur la seule utilisation de yield

Chapter 12: Serialization

Item 85: Prefer alternatives to Java serialization

Nouvel article

――Le contenu de ce chapitre dans son ensemble ne recommande pas la sérialisation. C'est un paragraphe comme l'explication du plan. ―― "La sérialisation est dangereuse et doit être évitée. Pour les nouveaux systèmes, utilisez JSON ou Protocol Buffers."

Item 86: Implement Serializable with great caution

• Ajout de la possibilité d'attaque du finaliseur à la description des risques lors de l'implémentation d'une classe avec des champs d'instance sérialisables.
• Plusieurs paragraphes détaillant ce qu'il faut rechercher lorsqu'une classe destinée à l'héritage n'implémente pas Serializable ont disparu. (Un peu moins de 2 pages. Problème de largeur de papier?)

Item 87: Consider using a custom serialized form

• L'état de la mesure de la performance a été corrigé dans les résultats de la 3e édition. --Modification de la description de la gestion de defaultWriteObject (). (Il doit être appelé selon les spécifications) --Il est clairement indiqué que l'UID de la version série ne doit pas être modifié à moins que vous ne vouliez intentionnellement créer une incompatibilité.

Item 88: Write readObject methods defensively

• Il y a un supplément expliquant pourquoi vous transtypez en octet dans l'exemple de code (puisque les littéraux entiers sont int et vous avez besoin d'un cast explicite pour traiter les nombres supérieurs ou égaux à 128 comme octet. Il n'est pas nécessaire s'il est inférieur ou égal à. Si le bit le plus significatif exprimé en binaire est «0», il en est de même pour «int» et «octet».)
• Suppression du paragraphe sur la méthode writeUnshared, readUnshared (parce que c'était trop maniaque?)

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

• La clause "Sauf si un attaquant abuse de AccessibleObject.setAccessible" est ajoutée à "enum garantit singleton pour Java". (Quand on m'a dit cela, je n'avais ni ancien ni enfant, mais dans l'ensemble, je penchais vers un ton pessimiste.)

Item 90: Consider serialization proxies instead of serialized instances

Il n'y a pas de changement dans l'objectif général.

À la fin

Les dates de sortie de chaque édition sont les suivantes.

La prochaine édition effective de Java 4e devrait être prévue pour 2027, soit environ 9 ans plus tard. La version Java à ce moment-là devrait être 30 selon le modèle de version actuel [^ 2], et je ne peux pas imaginer quelles nouvelles fonctionnalités il a. Rendez-vous tous dans 9 ans. (N'est-il plus écrit?)