General Programming

When using nested traditional for loops with iterators, calling next() in both the outer and inner loops can lead to premature iterator exhaustion.

Example bug:

// BUG: Incorrect nested iteration
for (Iterator<Suit> i = suits.iterator(); i.hasNext(); ) {
    for (Iterator<Rank> j = ranks.iterator(); j.hasNext(); ) {
        deck.add(new Card(i.next(), j.next())); // i.next() called for each card!
    }
}

The outer collection iterator (i.next()) is called from the inner loop, exhausting it after just a few iterations. This often results in:

1. NoSuchElementException if outer collection is smaller
2. Silent failure producing incorrect results if collections have related sizes

Correct solution:

// Fixed approach
for (Iterator<Suit> i = suits.iterator(); i.hasNext(); ) {
    Suit suit = i.next(); // Call next() ONCE per outer iteration
    for (Iterator<Rank> j = ranks.iterator(); j.hasNext(); ) {
        deck.add(new Card(suit, j.next()));
    }
}

When a variable is initialized from an expression that can throw a checked exception, it creates a scope management challenge:

// Problem: Need variable both in and outside try block
try {
    InputStream fileIn = new FileInputStream("myFile.txt");
    // Use fileIn
    fileIn.close(); // Close in same block
} catch (IOException e) {
    // Handle exception
}
// Cannot use fileIn here

If you need to use the variable outside the try block, you face a dilemma:

1. If you declare outside but initialize inside the try:

   InputStream fileIn = null; // Must be declared before try
   try {
       fileIn = new FileInputStream("myFile.txt"); // Init in try
       // Use fileIn
   } catch (IOException e) {
       // Handle exception
   }
   // Can use fileIn here, but must check for null
   if (fileIn != null) { /* ... */ }

2. The variable can't be "sensibly initialized" outside the try block and must be checked for null

Best solution (Java 7+) using try-with-resources:

try (InputStream fileIn = new FileInputStream("myFile.txt")) {
    // Use fileIn
} catch (IOException e) {
    // Handle exception
}
// fileIn not needed outside, automatically closed

• Binary floating-point arithmetic cannot exactly represent decimal fractions like 0.1 (or any negative power of ten)
• Examples of errors:
  • 1.03 - 0.42 evaluates to 0.6100000000000001 instead of 0.61
  • 1.00 - 9 * 0.10 evaluates to $0.09999999999999998 instead of $0.10
• This occurs because these values must be represented as binary fractions which often results in infinite recurring digits
• The problem cannot be solved simply by rounding before printing

For exact monetary calculations, use:

1. BigDecimal with String constructor (not double constructor)
2. int or long (tracking cents or smallest unit)

Proper performance optimization process:

1. Focus first on good design and architecture rather than speed
2. Consider performance during design, especially for APIs, protocols, and data formats
3. Implement a clear, concise, well-structured solution
4. Measure performance to determine if it's satisfactory
5. If performance is inadequate: a. Use profiling tools to identify bottlenecks b. Examine algorithm choices first (most important) c. Optimize the specific problematic parts d. Measure again after each change
6. Repeat until performance goals are met

Remember: "Strive to write good programs rather than fast ones. If a good program is not fast enough, its architecture will allow it to be optimized."

Dangers of mixing primitives and boxed primitives:

1. Unexpected NullPointerException

   • Occurs when a null boxed primitive is auto-unboxed
   • Example:

     Integer nullInteger = null;
     int value = nullInteger; // Throws NullPointerException during auto-unboxing

2. Identity comparison issues

   • Using == on boxed primitives performs reference comparison, not value comparison
   • Example:

     Integer a = 127;
     Integer b = 127;
     System.out.println(a == b); // May print true (due to caching)
     
     Integer c = 1000;
     Integer d = 1000;
     System.out.println(c == d); // Will print false (different objects)

3. Performance degradation

   • Repeated boxing/unboxing creates unnecessary objects and overhead
   • Common in loops and calculations with mixed types

Prevention strategies:

1. Prefer primitives whenever possible

   // Good
   long sum = 0L;
   
   // Bad
   Long sum = 0L;

2. Be explicit about unboxing when working with potentially null values

   // Safer approach with null check
   if (boxedValue != null && boxedValue.intValue() > 0) {...}

3. Use proper value comparison for boxed primitives

   // For equality:
   if (Integer.valueOf(42).equals(otherInteger)) {...}
   
   // For ordering:
   if (Integer.compare(a, b) < 0) {...}

4. Be consistent with variable types in arithmetic expressions

   // All primitives
   int a = 1;
   int b = 2;
   int c = a + b;
   
   // All boxed
   Integer x = Integer.valueOf(1);
   Integer y = Integer.valueOf(2);
   Integer z = Integer.valueOf(x.intValue() + y.intValue());

• Declare variables using interfaces rather than implementation classes whenever possible
• Use the most general appropriate interface type for parameters, return values, variables, and fields

Good practice:

// Good - uses interface as type
Set<String> itemSet = new LinkedHashSet<>();

Poor practice:

// Bad - uses implementation class as type
LinkedHashSet<String> itemSet = new LinkedHashSet<>();

Benefits:

• Allows changing implementations without modifying client code
• Makes code more flexible and adaptable to future requirements
• Enables easy performance optimization by swapping implementations
• Decouples code from specific implementations

Implementation changes only require updating the constructor call, not all variable declarations throughout the codebase.

Limited Reflection Pattern:

1. Use reflection only for instantiation of objects of classes unknown at compile time
2. Access the objects through a known interface or superclass after instantiation
3. Contain all reflection code in a small, isolated portion of the application

Example approach:

// Use reflection only to create the instance
Class<? extends Set<String>> cl = 
    (Class<? extends Set<String>>) Class.forName(className);
Constructor<? extends Set<String>> cons = cl.getDeclaredConstructor();
Set<String> set = cons.newInstance();

// Then use normal interface methods (no more reflection)
set.addAll(elements);
set.remove(element);

Benefits:

• Most code remains type-safe and efficient
• Reflection code is isolated to object creation
• Runtime flexibility while minimizing performance penalties
• Compiler still checks most of your code

String Concatenation vs. StringBuilder:

String concatenation in a loop:

• Time complexity: O(n²)
• Each concatenation creates a new string object
• Each new string copies all previous content plus new content
• Memory allocation increases with each iteration
• For n strings of average length m: approximately O(n²m) character copies

StringBuilder approach:

• Time complexity: O(n)
• Maintains a single mutable character array
• Dynamically resizes as needed (typically doubles capacity)
• Copies characters only during resizing operations
• For n strings of average length m: approximately O(nm) character copies

Why the difference exists:

• Strings are immutable in Java (Item 17)
• Each concatenation must create a new String object
• The entire content must be copied with each operation
• StringBuilder maintains an internal mutable char array

Performance example: For 100 strings of 80 characters each:

• String concatenation: approximately 396,000 character copies
• StringBuilder: approximately 8,000 character copies
• Measured result: StringBuilder is 6.5× faster

Even with Java compiler optimizations for string concatenation, the difference remains substantial for loops and large operations.

• Initially (Java 1.1): BigInteger used a fast native multiprecision arithmetic library in C
• Java 3: Reimplemented in pure Java and tuned to run faster than the original native implementation
• Since then: Limited changes except faster multiplication for large numbers in Java 8
• Meanwhile: Native libraries like GNU Multiple Precision arithmetic library (GMP) continued advancing

Key lesson: While native implementations initially seemed faster, pure Java implementations eventually matched or exceeded performance while maintaining safety and portability. However, for specialized domains, native libraries may still offer advantages when they evolve more rapidly.

String Concatenation Performance Issues

• Fundamental Problem: Strings in Java are immutable, meaning:
  • Each concatenation (+ operator) creates a new string object
  • All previous content must be copied plus the new content
  • Performance degrades to O(n²) when concatenating n strings

When String Concatenation Is Acceptable

• Limited scenarios where + is fine:
  • Combining 2-3 strings in a single statement
  • Non-loop contexts with few concatenations
  • When performance is explicitly not a concern

When and How to Use StringBuilder

• Required for:

  • Loops (most critical case)
  • Unknown number of concatenations
  • Large strings
  • Performance-sensitive code

• Implementation Pattern:

// Good performance - O(n)
StringBuilder builder = new StringBuilder(estimatedCapacity); // Pre-allocation is important
for (int i = 0; i < numItems(); i++) {
    builder.append(lineForItem(i));
}
return builder.toString();

Performance Comparison

• StringBuilder vs. String concatenation in loops:
  • 5-6× faster for moderate collections
  • Gap widens dramatically as collection size increases
  • Changes algorithm from O(n²) to O(n)

Best Practices

1. Pre-allocate capacity when possible for additional performance
2. Chain append operations for cleaner code: builder.append(x).append(y)
3. Consider processing strings individually without concatenation when feasible
4. In tight loops, StringBuilder is always the correct choice