General Programming

Making a public type mutable can force unnecessary defensive copying, harming performance.

Example: The getSize() method in java.awt.Component returns a mutable Dimension instance, forcing all implementations to allocate a new Dimension object on every invocation to prevent callers from modifying the component's internal state.

Better alternatives:

1. Make Dimension immutable (preferred)
2. Use methods returning individual primitive components (added in Java 2 for performance)

Consequence: Even though these alternatives were added later, preexisting code still uses getSize() and suffers the performance penalties.

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()));
    }
}

Comparison of Java's Random Number Generators:

Random (traditional)

• Thread-safe but with performance bottleneck under contention
• Lower quality random distribution
• Slowest performance of the three options
• Usage: Legacy code only; avoid in new development

ThreadLocalRandom

• Thread-local state eliminates contention
• Higher quality random numbers
• Significantly better performance (3-6x faster than Random)
• Not suitable for parallel streams or fork-join pools
• Cannot set seed (intentionally)
• Usage:

  // Preferred for single-threaded or thread-confined use (Java 7+)
  int randomNum = ThreadLocalRandom.current().nextInt(0, 100); // Range 0-99
  double randomDouble = ThreadLocalRandom.current().nextDouble();

SplittableRandom

• Non-thread-safe but can be split for parallel use
• Designed specifically for parallel streams and fork-join operations
• Highest quality random number generation
• Usage:

  // For use with parallel streams
  SplittableRandom splittableRandom = new SplittableRandom();
  
  // In a parallel stream
  IntStream.range(0, 1000)
           .parallel()
           .mapToObj(i -> splittableRandom.split().nextInt(100))
           .forEach(System.out::println);

Selection guide:

• For most general cases: ThreadLocalRandom
• For parallel streams: SplittableRandom
• For legacy code compatibility only: Random

The "don't reinvent the wheel" principle: The practice of using existing library code rather than writing your own implementation of common functionality.

Process to follow when you need functionality:

1. Check the Java Platform Libraries first

   • Become familiar with core packages: java.lang, java.util, java.io
   • Pay special attention to Collections Framework, Streams Library, and Concurrency Utilities

2. Look for high-quality third-party libraries

   • Example: Google's Guava library
   • Consider popular libraries with good community support and documentation

3. Implement it yourself only as a last resort

   • Only if you've thoroughly searched existing solutions
   • Document why you needed a custom implementation

Benefits of using library code:

• Generally higher quality than custom code due to wider usage and testing
• Improves over time through updates and optimizations
• Benefits from "economies of scale" - library code receives far more attention than most developers could devote to the same functionality
• Reduces maintenance burden on your team
• Often provides better performance due to optimization

Remember: Even if something seems relatively simple to implement, a well-tested library version is almost always preferable.

The transferTo method added to InputStream in Java 9 provides a simple way to transfer all bytes from an input stream to an output stream.

Method signature:

public long transferTo(OutputStream out) throws IOException

Benefits:

• Eliminates boilerplate code for buffer management
• Reduces the risk of resource leaks
• Improves code readability
• Returns the number of bytes transferred

Example usage (printing URL contents):

// Java 9+ approach
public static void main(String[] args) throws IOException {
    try (InputStream in = new URL(args[0]).openStream()) {
        in.transferTo(System.out);
    }
}

Pre-Java 9 equivalent:

// Pre-Java 9 approach
public static void main(String[] args) throws IOException {
    try (InputStream in = new URL(args[0]).openStream()) {
        byte[] buffer = new byte[8192];
        int bytesRead;
        while ((bytesRead = in.read(buffer)) != -1) {
            System.out.write(buffer, 0, bytesRead);
        }
    }
}

The new method handles all the buffer management, read/write loop, and proper exception handling internally, significantly reducing code complexity for common I/O operations.

• 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

Cross-version compatibility pattern:

When writing a package that must run against multiple versions of another package, you can:

1. Compile against the minimal environment (typically oldest version)
2. Use reflection to access newer classes or methods that may not exist in all environments
3. Implement fallback behavior when newer features aren't available

Implementation approach:

Method newMethod = null;
try {
    // Try to access a method that might not exist in older versions
    Class<?> cls = Class.forName("com.example.SomeClass");
    newMethod = cls.getMethod("newFeatureMethod", String.class);
} catch (ReflectiveOperationException e) {
    // Method or class doesn't exist - use fallback approach
}

// Later, when using the functionality:
if (newMethod != null) {
    try {
        // Use the new feature if available
        return newMethod.invoke(instance, arg);
    } catch (Exception e) {
        // Handle failure
    }
} else {
    // Use alternative implementation for backward compatibility
    return legacyApproach(instance, arg);
}

This approach allows a single codebase to work across multiple versions without requiring the newest API version.

• To access platform-specific facilities (though rarely necessary with modern Java)
• To access existing native code libraries when no equivalent Java libraries exist
• For truly high-performance multiprecision arithmetic (e.g., using GNU Multiple Precision library)

Note: It's rarely advisable to use native methods purely for performance improvements - modern JVMs have greatly improved Java performance.

1. "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason—including blind stupidity." —William A. Wulf

2. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." —Donald E. Knuth

3. "We follow two rules in the matter of optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet—that is, not until you have a perfectly clear and unoptimized solution." —M. A. Jackson