• Use them when constructors do not adequately describe what they're doing:
  • BigInteger(int, int, Random) vs BigInteger.probablePrime(int, int, Random)
  • They will not necessarily create a new object. Best for static classes.
  • They can return subtypes/subclasses that are private.

• Employed when many parameters and not all of them are necessary.
• Inner static class that keeps returning an instance of itself and allows you to call setter methods on it.

Eg:

public abstract class Pizza {
    public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE }
    final Set<Topping> toppings;
    abstract static class Builder<T extends Builder<T>> {
        EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);
        public T addTopping(Topping topping) {
            toppings.add(Objects.requireNonNull(topping));
            return self();
        }
        abstract Pizza build();
        // Subclasses must override this method to return "this"
        protected abstract T self();
    }
    Pizza(Builder<?> builder) {
        toppings = builder.toppings.clone(); // See Item 50
    }
}

public class NyPizza extends Pizza {
    public enum Size { SMALL, MEDIUM, LARGE }
    private final Size size;
    public static class Builder extends Pizza.Builder<Builder> {
        private final Size size;
        public Builder(Size size) {
            this.size = Objects.requireNonNull(size);
        }
        @Override public NyPizza build() {
            return new NyPizza(this);
        }
        @Override protected Builder self() { return this; }
    }
    private NyPizza(Builder builder) {
        super(builder);
        size = builder.size;
    }
}

• provide a public static final INSTANCE = new Cons() class.
• provide a public static factory method.
• Can also use an enum with a single instance (probably the best approach).

• Basically used when classes act as a collection of static methods and fields.
• Compiler provides a default public parameterless constructor.
• Also holds for things that are only instantiated once in mutable classes (basically computed once).
• Lazy initialization (checking for first invocation with null checks) might not be as performance friendly as you think.

• Reduces garbage collection overhead and memory footprint.
• The garbage collector may think that there is still a valid reference to the object.
• This usually happens when a class manages its own memory, such as an array containing objects.

• These are usually run when the object is going to be collected.
• Do not use them as they are unpredictable in nature.
• Implement AutoCloseable with a close method to make sure that objects are cleaned up.
• Do it in a try-finally block to make sure that it gets executed even when there is an exception.
• Cleaners act as a safety net when the user forgets to call close. They also help with native peers, although that's legacy now.

• Best way to autoclean for objects that implement autocloseable.
• If they provide a custom termination method then use try-finally.

static String firstLineOfFile(String path) throws IOException {
    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }
}

• Do it only when needed.
• Notion of logical equality.
• Does not violate the contract:
  • reflexive (x.equals(x))
  • symmetric (y.equals(x) same as x.equals(y))
  • transitive
  • consistent across invocations
  • non-null reference never equals null.

High quality equals check:

• Use == operator when doing reference checks (worth doing if the overall comparison is large).
• instanceof operator to check for class/interface similarity.
• typecast after using instanceof.
• Check equality for each of the elements. Use == if the elements are scalar (barring double and float), for double and float do a bit cast (using doubleToLongBits and floatToIntBits), and for others apply equals method again.
• Don't accidentally overload equals declaration.

• When overriding equals, also override hashCode.
• HashCode must return the same integer as long as the information used in object's equal implementation hasn't changed.
• Two equal objects also return the same hashcode.
• To write a good hashcode, translate most fields to an int, and then do result = 37*result + c where seed value of result is 17 and c is the integer.
• Override toString as it will return garbage otherwise.

• Cloneable interface decides whether Object class' clone is usable or not.
• If the class implements Cloneable then it does a bit by bit copy, else it throws an exception.
• Treat clone method like it's another constructor.
• TL;DR, preferably don't implement it at all if possible.
• First call super.clone() and then fix whatever's necessary.
• Just provide a copy constructor.

• compareTo is a feature of Comparable interface.
• Implementations must ensure that sgn(x.compareTo(y)) == -sgn(y.compareTo(x))
• Also transitivity.
• Usually, (x.compareTo(y)==0)==x.equals(y). However it is not necessary.
• If the above statement is not true it must be documented. This is true for floats.
• Usually it's not expected or needed for it to work across classes.
• While using integer substraction, be careful for overflows.

• Favour immutability.
  • Don't provide mutators.
  • No methods may be overriden (not necessarily making them final).
  • All fields are final.
  • All fields are private.
  • Exclusive access to mutable components.
• Static factory method classes are probably the best way to make immutable classes.
• Serializable implementations must have an explicit readObject or readResolve method. More on this later.

• Inheritance means you need to update the codebase of subclass if superclass is changed.
• Wrappers would solve this problem.
• Wrappers have a problem where the enclosed object may return a reference to itself for callback purposes or something along those lines.
• Another thing is to write all the forwarding methods.

If you are letting a class be inherited by another:

• Design and document the inheritance.
• Provide hooks to inernal behaviour to improve the ease and performance of the subclass reimplementation.
• Constructors must not utilize overridable methods, directly or indirectly.
• Try not to implement Cloneable or Serializable.
• If you do, make sure to treat clone and readObject like constructors (no overridable function calls)

• Multiple interfaces can be implemented.
• New interfaces can be easily implemented for existing classes without disturbing class heirarchies.
• Allow for construction of non-heirarchical frameworks.
• One pitfall is that Interfaces don't allow for extensions as adding a new method breaks all the existing classes that use the method.
• Only design an abstract class if you think that evolution is more important.
• Only use Interfaces to define types, and nothing else.

• Each nonstatic member class instance is associated with the enclosing class.
• When you construct the inner class, it will automatically associate with the outer class taking time and space in its construction.
• There are local classes and anonymous classes as well, these depend on the usage of them. If it's a oneshot class, create anonymous, else create a local.

• May make compilation and runtime results dependent on the order in which you passed source files.

• Simple reason, compile time checks.

// Using a recursive type bound to express mutual comparability
public static <E extends Comparable<E>> E max(Collection<E> c);

This indicates that E implements Comparable<E>, i.e., it can be compared to itself.

// Wildcard type for a parameter that serves as an E producer
public void pushAll(Iterable<? extends E> src) {
    for (E e : src)
        push(e);
}

• Anything that can safely be typecast to an E is expressed this way.

// Wildcard type for parameter that serves as an E consumer
public void popAll(Collection<? super E> dst) {
    while (!isEmpty())
        dst.add(pop());
}

• That is because dst can be anything that can hold an E, which includes its parent types as well.

The user of the API shouldn't be bothered with the presence of a wildcard. To him, it should be transparent.

• They don't mix well.

// Mixing generics and varargs can violate type safety!
static void dangerous(List<String>... stringLists) {
    List<Integer> intList = List.of(42);
    Object[] objects = stringLists;
    objects[0] = intList;
    // Heap pollution
    String s = stringLists[0].get(0); // ClassCastException
}

• Don't expose the varargs array in any way, shape or form.
• Only pass the parameter array to something that has @SafeVarargs annotation/does some gen compute on the array.

• Have an abstract class from which the various subclasses derive.
• Implement any function of the enum as a member function of the abstract class.

• Each implementation can contain different forms of the abstract method in the class.
• EnumSet and EnumMap are optimized.

• Overriding fromString

  // Implementing a fromString method on an enum type
  private static final Map<String, Operation> stringToEnum =
      Stream.of(values()).collect(toMap(Object::toString, e -> e));
  // Returns Operation for string, if any
  public static Optional<Operation> fromString(String symbol) {
      return Optional.ofNullable(stringToEnum.get(symbol));
  }
  

• In a method, don't switch on this, instead overload every variant with a new type.

• Simply better, representation is about the same.

• Only to be done if extensions are needed in enums.

class Foo {
    private final String name;
    private Foo() {}

    private Foo(String s) {
        name = s;
    }

    public String toString() {
        return name;
    }

    public static final Suit CLUBS = new Suit("clubs");
    public static final Suit DIAMONDS = new Suit("diamonds");
    public static final Suit HEARTS = new Suit("hearts");
    public static final Suit SPADES = new Suit("spades");
}

• You can also have a certain behaviour attached to the enum variants.

public abstract class Operation {
    private final String name;
    Operation(String name) { this.name = name; }
    public String toString() { return this.name; }
    // Perform arithmetic operation represented by this constant
    abstract double eval(double x, double y);
    public static final Operation PLUS = new Operation("+") {
            double eval(double x, double y) { return x + y; }
        };
    public static final Operation MINUS = new Operation("-") {
            double eval(double x, double y) { return x - y; }
        };
    public static final Operation TIMES = new Operation("*") {
            double eval(double x, double y) { return x * y; }
        };
    public static final Operation DIV = new Operation("/") {
            double eval(double x, double y) { return x / y; }
        };
}

• Omit types unless they make it more readable.
• If you can, use method references, unless they are annoying.

• Easier on the API.
• If what you need is a bit too funky, write your own.

• This is not functional programming; these OOPS normies can't handle long pipelines of code.
• Ok their arguments are kinda fair ngl.
• Use side-effect free functions in streams.

• The only problem is the size limit on them.
• Storage might also be a concern.

• These work on heuristics to parallelize stuff.
• Best to be done only when it's a stream over array based stuff (HashSet, ArrayList etc).

• @throws is helpful to tell when an exception is thrown wrt what condition.
• Throw early and throw fast.
• Might be elided if the implicit computation is going throw the exception anyways.

• If you're writing an immutable class that provides accessors, make sure that you make copies of every mutable input and every return.
• Do not use clone for making copies of the input because of a malicious subclass being possible.

• Always return zero length arrays wherever possible.

• Properties are similar to Rust.
• Don't return Optional for primitive types, use the variants meant for those.

• No more than 3 preferably.

• No more than 5 preferably.

• Especially true for loop variables, as we tend to reuse the same names for them.

• So much for string interning eh?
• If repetitive addition is gonna happen, use StringBuffer

• allows you far greater freedom in swapping out implementations if needed.
• If relevant interfaces don't exist, then use the base abstract class to describe it.

• I don't understand who in the world needed reflection so badly and why people thought it was a good idea.

• Checked exceptions are those caught using try-catch or declared in the method signature.
• Throw checked exceptions if the caller can actually recover from it.
• Unchecked exceptions are those that are, well, not checked.
• These are thrown when there are no checks to guard them.
• Inside unchecked exceptions, errors are thrown when there's a resource deficiency by JVM.
• Runtime exceptions are thrown in every other scenario.

In case of failure, leave the object in the state it was before the failure.

• Even if the data is atomic, it may be read partially.
• If you want to lazy initialize, create a nested class with a static final and use that. That's the best method.

• Lower cost
• Lower chances of error

• Basically, methods you know nothing about (because they can be overridden).
• This can easily lead to deadlocks and leaving the object in an inconsistent state.

• Same reason why you call semaphore checks in a loop in C.

• standard idiom:

  synchronized (obj) {
      while (!cond) obj.wait();
  }
  

• Before wait, it is to make sure that notify hasn't been called, else the thread may never wake up.
• After wait, it does safety check of the condition not holding.
• Conservatively, use notifyAll wherever possible as the while guard will protect threads not meant to wake up.

• Significantly better abstractions than rawdogging threads.

• Everything gets serialized, including the private and package private fields, and you'd have to support them forever.
• Classes meant for inheritance shouldn't implement it and interfaces should rarely extend it.
• Inner classes should not implement serializable unless they are static since they contain compiler generated fields to refer to the outer class.

• Yeah, third edition basically gave up on the whole idea.