Enums and Annotations

This approach causes a compilation error because enum constructors aren't permitted to access the enum's static fields (except constant variables).

This restriction exists because:

• Static fields have not yet been initialized when enum constructors run
• If allowed, it would cause a NullPointerException at runtime

For example, this would fail:

public enum Planet {
    EARTH(5.975e+24, 6.378e6);
    
    private static final Map<String, Planet> registry = new HashMap<>();
    
    Planet(double mass, double radius) {
        // This causes compilation error:
        registry.put(this.name(), this); // Cannot access static field
    }
}

Instead, initialize maps after all constants are created:

private static final Map<String, Operation> stringToEnum =
    Stream.of(values()).collect(toMap(Object::toString, e -> e));

Key differences:

1. Method annotations are NOT inherited by default

   • An annotation on a superclass method will not appear on the overriding method
   • Each method must be explicitly annotated even if it overrides an annotated method

2. Method inheritance follows standard OOP rules

   • Overridden methods inherit behavioral contracts
   • Method implementation can be replaced in subclasses

Implications for test frameworks:

• Test annotations must be reapplied to each overriding method
• Cannot rely on annotation inheritance to mark test methods
• May need to use @Inherited meta-annotation for class-level annotations
• Test runners need special logic to find tests in class hierarchies:

// Finding all tests including inherited ones requires special handling
for (Class<?> c = testClass; c != null; c = c.getSuperclass()) {
    for (Method m : c.getDeclaredMethods()) {
        if (m.isAnnotationPresent(Test.class)) {
            // Process test method
        }
    }
}

Problems with ordinal() indexing:

• Compiler has no knowledge of relationship between ordinals and array indices
• Making errors in transition tables leads to runtime failures (ArrayIndexOutOfBoundsException, NullPointerException)
• Can cause silent erroneous behavior
• Table size grows quadratically with number of enum constants, even with sparse relationships

Recommended alternative: Use EnumMap instead

// Instead of:
private static final Transition[][] TRANSITIONS = {
    { null, MELT, SUBLIME },
    { FREEZE, null, BOIL },
    { DEPOSIT, CONDENSE, null }
};

// Use nested EnumMap:
private static final Map<Phase, Map<Phase, Transition>> m = 
    Stream.of(values()).collect(groupingBy(t -> t.from,
        () -> new EnumMap<>(Phase.class),
        toMap(t -> t.to, t -> t,
            (x, y) -> y, () -> new EnumMap<>(Phase.class))));

A nested EnumMap for enum pairs requires:

1. Define enums with relationship data:

public enum Phase {
    SOLID, LIQUID, GAS;
    
    public enum Transition {
        MELT(SOLID, LIQUID), FREEZE(LIQUID, SOLID),
        BOIL(LIQUID, GAS), CONDENSE(GAS, LIQUID),
        SUBLIME(SOLID, GAS), DEPOSIT(GAS, SOLID);
        
        private final Phase from;
        private final Phase to;
        
        Transition(Phase from, Phase to) {
            this.from = from;
            this.to = to;
        }
    }
}

2. Initialize the nested EnumMap:

private static final Map<Phase, Map<Phase, Transition>> m = 
    Stream.of(values()).collect(groupingBy(t -> t.from,
        () -> new EnumMap<>(Phase.class),
        toMap(t -> t.to, t -> t,
            (x, y) -> y, () -> new EnumMap<>(Phase.class))));

3. Access transitions:

public static Transition from(Phase from, Phase to) {
    return m.get(from).get(to);
}

This provides type safety, better performance, and easier maintenance than arrays indexed by ordinals.

A marker annotation (one without elements/parameters) for designating test methods:

import java.lang.annotation.*;

/**
 * Indicates that the annotated method is a test method.
 * Use only on parameterless static methods.
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Test {
    // No elements - this is a marker annotation
}

Meta-annotations explained:

1. @Retention(RetentionPolicy.RUNTIME):

   • Specifies the annotation should be retained at runtime
   • Enables test runners to discover annotated methods through reflection
   • Other options (SOURCE, CLASS) would make annotation invisible to test framework

2. @Target(ElementType.METHOD):

   • Restricts annotation to only be used on methods
   • Prevents misuse on classes, fields, or other elements
   • Compiler will report error if applied elsewhere

Usage example:

public class SampleTest {
    @Test  // Marks this method to be run by test framework
    public static void testMethod() {
        // Test code here
    }
}

A test runner would use reflection to find all methods annotated with @Test:

for (Method m : testClass.getDeclaredMethods()) {
    if (m.isAnnotationPresent(Test.class)) {
        // Run test method
    }
}

To create a repeatable annotation:

1. Create the base annotation with @Repeatable(ContainerType.class):

   @Retention(RetentionPolicy.RUNTIME)
   @Target(ElementType.METHOD)
   @Repeatable(ExceptionTestContainer.class)
   public @interface ExceptionTest {
       Class<? extends Exception> value();
   }

2. Create a container annotation with the same retention and target:

   @Retention(RetentionPolicy.RUNTIME)
   @Target(ElementType.METHOD)
   public @interface ExceptionTestContainer {
       ExceptionTest[] value();
   }

Critical considerations:

• Container must have the same or wider retention policy
• Container must have the same or wider target
• Container must have a value() method returning an array of the repeatable annotation
• Failing to match retention/target causes compilation errors
• Without proper configuration, annotations may not be visible at runtime or in the intended contexts

When retrieving a Class<?> parameter via reflection:

// Getting annotation with Class<?> parameter
ExceptionTest excTest = method.getAnnotation(ExceptionTest.class);
Class<? extends Exception> excType = excTest.value();

// Using the Class<?> parameter
if (excType.isInstance(exception)) {
    // The exception is of the expected type
}

Common error: TypeNotPresentException

• Occurs when the annotation parameter's class was valid at compile time
• But the class file isn't available at runtime
• Must be handled explicitly in annotation processors:

try {
    Class<?> excType = annotation.value();
    // Use the class...
} catch (TypeNotPresentException e) {
    System.err.println("Referenced class not found: " + e.typeName());
}

This equals method does not properly override Object.equals because it has the wrong parameter type:

• The correct signature must take Object as a parameter: equals(Object o)
• This implementation takes a Bigram parameter instead: equals(Bigram b)
• As a result, this method overloads rather than overrides Object.equals
• The default Object.equals (testing for reference equality) remains in effect
• Distinct objects with the same content will be considered unequal
• Java will not generate a compile-time error without @Override annotation

Correct implementation:

@Override
public boolean equals(Object o) {
    if (!(o instanceof Bigram))
        return false;
    Bigram b = (Bigram) o;
    return b.first == first && b.second == second;
}

The @Override annotation for equals() catches several subtle issues:

1. Parameter Type Problems:

   • Catches when you write equals(MyClass o) instead of equals(Object o)
   • Without @Override, you accidentally create an overloaded method, not an override

2. Method Coexistence Bugs:

   • Without @Override, both your equals() and Object.equals() exist simultaneously
   • Collection classes (HashSet, HashMap) call Object.equals(), not your version
   • Objects that should be considered equal are treated as distinct

3. Signature Deviations:

   • Catches misspellings (equal() vs equals())
   • Catches wrong return type (void or int instead of boolean)
   • Catches additional parameters

4. Inheritance Chain Issues:

   • Ensures your equals() properly participates in the inheritance chain
   • Prevents accidental hiding of superclass methods

These issues typically cause difficult-to-debug equality problems in collections, serialization, and comparison operations.

When equals() takes a specific type parameter instead of Object:

// Incorrect implementation
public boolean equals(Bigram b) { // specific type parameter
    return b.first == first && b.second == second;
}

This causes collection failures because:

1. Method Resolution Problem:

   • Java collections (HashSet, HashMap, etc.) call Object.equals(Object o)
   • Your method equals(Bigram b) doesn't override but overloads Object.equals()
   • Both methods coexist in your class

2. Collection Behavior:

   • When HashSet checks for duplicates, it calls Object.equals()
   • Object.equals() performs reference equality (==), not content equality
   • Two identical Bigrams with same content but different references are considered different

3. Concrete Example:

   Set<Bigram> set = new HashSet<>();
   set.add(new Bigram('a', 'b'));
   set.add(new Bigram('a', 'b')); // Should be a duplicate
   System.out.println(set.size()); // Prints 2 instead of 1

4. Root Cause:

   • When HashSet calls equals(), it passes an Object reference
   • Method signature matching selects Object.equals(Object) not your equals(Bigram)
   • The wrong equals implementation gets used for collection operations