Updates from Effective Java Third Edition 2nd Edition Personal Notes

The * Effective Java Third Edition * I ordered has finally arrived, so I have summarized the changes from the second edition. I have skipped the personal notes and the parts that are not different from the second edition, so please forgive me for any omissions. Since the second edition refers to the Japanese version, there may be inconsistencies in relation to the translated text. I would be grateful if you could point out any mistakes.

Usage Guide

Quotation from Effective Java Third Edition or its translation

• Summary of contents

Plaintext-Personal impressions

Item 2

The builder has been added with recursive parameters. You can fluently design subclasses by setting the builder returned by the parent abstract class Pizza toBuilder <T extends Builder <T >>and the type returned by its method ʻaddTopping () to T`. ..

Item 5: Use Dependency injection rather than hard code resources

** Static utility classes and singletons are not suitable for classes whose behavior can be parameterized by resources **

• Pass Supplier <T> rather than pass Factory.

Item 6

The example of creating unnecessary objects has been changed from using Calendar toString.matches ()(the problem is that it creates Pattern each time).

Item 8: Avoid finalizers and cleaners

The cleaners added in Java 9 have been talked about.

** Cleaners aren't as dangerous as finalizers, but they're still unpredictable, slow, and generally unnecessary **

• finalizer attack --Use the finalizer to leave the bad object in the heap and call the method (the description itself was in the 2nd edition, but it is more emphasized)

• Should implement ʻAutoCloseable` instead

Item 9: Use try-with-resources rather than try-finally

• Try-finally is easy to make mistakes (block itself mistake, JDK implementation mistake)

Item 10

• ʻEquals () `is difficult to implement. Use AutoValue or let the IDE generate it

Personally, I don't like AutoValue very much, so I use Lombok or write it in Kotlin.

IDEs do not make careless mistakes, and humans do IDEs don't make inadvertent mistakes, but humans do

Item 11

The code example has been modified to use Type.hashCode () (Short.hashCode (), etc.) to generate the hash code. The documentation for hashCode generation has become more pronounced from "don't do it" to "don't do it" (documentation makes it impossible to change in the future).

Item 12

• You don't need toString () in static utility classes or enumerators

Item 13

• Immutable classes must not provide Cloneable (can be shared without copying in the first place)

Item 14

• Use Type.compare ()
• Use Comparator.comparing ... ()
• Do not use diff-based comparators (those that subtract values between objects) (overflow)

Item 15

• It is not yet known if Java 9 modules will become widely used.
• The module is ʻadvisory`. You don't have to force it.

Item 19

• Use @implSpec

Item 20

• Abstract classes are still useful, as default methods are useful but limited.

Item 21: Design the interface for the future

** It is not always possible to write a default method without changing all possible implementations ** ** It is still of utmost importance that great care must be taken when designing an interface **

• e.g. Apache Commons synchronizedCollection The default method is not synchronized (until it is overridden)!
• Don't feel free to design an interface just because you have a default method

Old item 21

Deleted, merged with Item 42

Item 24

• With the addition of lambdas, function and process objects are no longer needed

Item 25: Write only one top-level class in the source file

• If you mistakenly create a source with the same name, you may not be able to compile it.

You can write multiple public classes in a language like Kotlin, but I think it's better to separate them as much as possible for readability.

Item 26: Do not use prototype

"With new code" is gone (not forcibly refactored)

Item 27:

Description of diamond operator

Item 30

With the addition of the diamond operator, the description of the newHashMap utility method for omitting type parameters has disappeared when creating a new collection.

generic singleton pattern

private static UnaryOperator<Object> IDENTITY_FN = (t) -> t;
@SuppressWarnings("unchecked")
public static <T> UnaryOperator<T> identityFunction() {
    return (UnaryOperator<T>) IDENTITY_FN;
}

I don't think I have many opportunities to use it in actual battles.

Item 32: Carefully combine generic types and variadic arguments

• Always use @SafeVarargs and stop if it's not safe

Item 34

Convert from String to Enum

private static final Map<String, Operation> stringToEnum = Stream.of(values()).collect(toMap(Object::toString, e -> e));
public static Optional<Operation> fromString(String symbol) {
    return Optional.ofNufllable(stringToEnum.get(symbol));
}

I personally want to throw an exception (discussed in Item 55).

The Payroll Day was subtly refactored.

Item 37

Why did you change Herb to Plant and Type to Lifecycle?

Item 39

JUnit -> JUnit 3 JUnit 4 is annotation-based, so I'm just following the advice in this section.

Item 42: Use lambda instead of anonymous class

Lambda parameter types are not used unless it makes the program cleaner. Lambda lacks name and documentation. Do not use lambdas if the process is not self-explanatory or is larger than a few lines.

• If you need a reference to yourself, you need an anonymous class
• Lambda must not be serialized

Item 43: Use method references instead of lambda

• If it's more concise to use lambda, do so (e.g. Function :: identity vs x-> x)

Item 44: Use standard functional interface

The "template method" pattern, in which subclasses override "primitive methods" to customize the behavior of superclasses, is much less attractive. A modern alternative is to provide a static factory or constructor that accepts function objects that do the same thing.

• Use the standard one rather than creating your own functional interface

• When defining your own functional interface

• Widely used and benefiting from descriptive names

• If you have a strongly related contract

• If you benefit from your own default method

• Use @FunctionalInterface

Do not create different overloaded methods with different functional interfaces in the same position as arguments if they can be ambiguous to the client.

• e.g. ʻExecutorService.submit () is difficult to understand because it takes RunnableandCallable `.

Item 45: Use streams with caution

just because you can doesn't mean you should

** Overuse of streams makes the program hard to read and maintain **

My ears hurt

** Using helper methods in code that uses stream pipelines is even more important than using them in code that uses iterators. ** **

• Do not use Stream for char

The method name (primes) is a plural noun that describes the elements of the stream. This naming convention is highly recommended for all methods that return a stream because it improves the readability of the stream pipeline.

Item 46: Use a function with no side effects in the stream

• To use Stream, you need to adapt to the paradigm (of functional programming) as well as the API.

The forEach instruction should only be used to report the processing results of a stream, not to do any processing.

It's easy to say forEach (e-> list.add (e)).

Item 47: Use collection rather than stream for return value

If you are writing a public API that returns a sequence, you should write it not only for those who want to write a stream pipeline, but also for those who want to write a for-each statement.

** Do not store large sequences in memory just to return them as a collection. ** **

Consider implementing a collection for a special purpose.

Item 48: Carefully parallelize streams

** If the source is Stream.iterate or the intermediate operation limit is used, paralleling the pipeline will not improve performance. ** **

• Do not indiscriminately parallelize streams

** Parallelizing streams of ʻArrayList, HashMap, HashSet, ConcurrentHashMap instances, arrays, ʻint range, and long range is the biggest performance gain. Let's do it. ** **

• Parallelizing streams not only slows performance, but can also lead to incorrect results and unpredictable behavior.

• Difference between forEach and forEachOrdered

• Rough guide: Performance may improve if stream elements x code lines> 100,000 is exceeded Source in the book: When to use parallel streams

It is important to remember that stream parallelization is a performance optimization. As with any optimization, you should measure performance before and after the change to make sure you need to do so.

Item 49

• Use ʻObjects.requireNonNull`

Item 50

** Date is obsolete and should no longer be used in new code **

Item 55: Carefully return optional

** Container-types and options such as maps, streams and arrays must not be optionally wrapped. Declare a method to return ʻOptional ` if it may not return a result, * and *, and the client needs to do something special. ** **

• Use ʻOptionalInt, ʻOptionalLong, ʻOptionalDouble. If ʻOptional <T> , auto boxing will occur and performance will deteriorate.

• Do not use options for collection or array keys, values, or elements

• Saving options in fields is often a "smell" code, but it can also be justified (for example, if you have a lot of optional fields and you just need to return the optional from the getter).

Item 56

• Use @implSpec
• Note the period (considered the end of the sentence)

Item 59

• Use ThreadLocalRandom rather than Random
• Guava is convenient

Old Item 73: Avoid Thread Groups

Delete

Item 75

• In Java 9, a constructor with ʻint index as an argument has been added to ʻIndexOutOfBoundsException.

Item 80: Select executor, task, and stream from thread

The stream has been added as a candidate.

Item 85: Use alternatives rather than Java serialization

The danger of serialization is heavily emphasized.

• Case study: [San Francisco Municipal Railway](https://ja.wikipedia.org/wiki/%E3%82%B5%E3%83%B3%E3%83%95%E3%83%A9%E3%83 % B3% E3% 82% B7% E3% 82% B9% E3% 82% B3% E5% B8% 82% E5% 96% B6% E9% 89% 84% E9% 81% 93) over two days Stop
• Vulnerability in Apache Commons Collections

** The best way to avoid serialization vulnerabilities is to not deserialize anything ** ** There is no reason to use Java serialization on newly written systems **

• Alternative: JSON, Protobuf

The next best thing is to ** never deserialize untrusted data **

• If you really need a serializer, use java.io.ObjectInputFilter

In conclusion, serialization is dangerous and should not be used.

Impressions

• Regarding new parts, there are only common sense and nothing new.
• However, is it meaningful to relearn common sense?
• It is true that we warn against the blind use of streams
• It's great that the danger of serialization is emphasized
• Google promotion is increasing (Mr. Brock is a former Google employee)
• It has been brushed up overall, so if you don't have it yet, you should buy it as soon as a Japanese translation is available. I wonder if those who have it need to buy a new one.

Bonus-Mr. Brock's PC