BufferedReader etc implements decorator pattern. Any Reader, e.g. FileReader or StringReader, can be decorated with the buffering feature, which is really source-oblivious.

---

Other patterns

• java.util.Comparator<T> is a strategy pattern

---

Anti-patterns

To add to what others have said, these are several anti-patterns in the Java libraries:

Antipattern: inheritance instead of composition

From Effective Java 2nd Edition, Item 16: Favor composition over inheritance:

There are a number of obvious violations of this principle in the Java platform libraries. For example, a stack is not a vector, so Stack should not extend Vector. Similarly, a property list is not a hash table, so Properties should not extend Hashtable. In both cases, composition would have been preferable.

Related questions

• Prefer composition over inheritance?
• java inheritance versus composition (implementing a stack)
• Difference between Inheritance and Composition
• Inheritance or composition: Rely on “is-a” and “has-a”?
• Object Oriented Best Practices – Inheritance v Composition v Interfaces
• Should I use inheritance or composition?
• Inheritance vs. Aggregation
• Aggregation verses Composition
• Decorator Pattern Using Composition Instead of Inheritance

---

Antipattern: constant interfaces

From Effective Java 2nd Edition, Item 19: Use interfaces only to define types:

There are several constant interfaces in the Java platform libraries, such as java.io.ObjectStreamConstants. These interfaces should be regarded as anomalies and should not be emulated.

Related questions

• Should a class implement a constants-only interface?
• What is the best way to implement constants in Java ?

---

Antipattern: telescoping constructor and JavaBeans patterns

From Effective Java 2nd Edition, Item 2: Consider a builder when faced with many constructor parameters (excerpt online):

Traditionally, programmers have used the telescoping constructor pattern, in which you provide a constructor with only the required parameters, another with a single optional parameters, a third with two optional parameters, and so on […] The telescoping constructor pattern works, but it is hard to write client code when there are many parameters, and harder still to write it.

A second alternative when you are faced with many constructor parameters is the JavaBeans pattern, in which you call a parameterless constructor to create the object, and then call setter methods to set each required parameter, and each optional parameter of interest. […] Unfortunately the JavaBeans pattern has serious disadvantages of its own […] a JavaBean may be in an inconsistent state partway through its construction [and it] precludes the possibility of making a class immutable.

Bloch recommends using a builder pattern instead.

Related questions

• Is this a well known design pattern? What is its name?
• What is the difference between Builder Design pattern and Factory Design pattern?
• When would you use the Builder Pattern?