Commit e665f22
committed
docs(generics): add WildcardsInGenerics demo + printArrayList example and notes
What
- Add Main class demonstrating use of unbounded wildcard in a reusable printArrayList method:
public void printArrayList(ArrayList<?> list) { ... }
- Keep previously considered generic variants commented for reference:
- Generic method signature for printArrayList: public <T> void printArrayList(ArrayList<T> list) { ... }
- Examples of signature shapes for getFirst and type-safe copy operations are retained as comments.
- Include minimal imports (ArrayList, Objects) and an empty main for manual testing.
Why
- Provide a compact, focused example that shows the recommended pattern for accepting lists of any element type
when only reading is required.
- Preserve alternative method signatures as comments to teach trade-offs:
- Using <T> allows stronger typing when the element type must be known.
- Using <? extends T> or ? super T are for read/write/producer-consumer scenarios, but each has constraints.
- This file will serve as an educational snippet for developers learning covariance and wildcards in Java generics.
Changes
- New file WildcardsInGenerics/Main.java with:
- printArrayList(ArrayList<?>) implementation that iterates and prints elements as Object.
- Commented examples demonstrating other generic method shapes and a sketch of a type-safe copy method.
- Empty main() left for quick manual experiments.
Examples (how to use)
- Read-only utility: pass any ArrayList<T> to printArrayList and it will print elements safely.
ArrayList<Integer> ints = new ArrayList<>(List.of(1,2,3));
new Main().printArrayList(ints);
- To implement type-safe copying between lists, switch to a bounded generic signature such as:
public static <T> void copy(ArrayList<? extends T> src, ArrayList<? super T> dst) { ... }
Real-life applications (detailed)
- Logging and debugging utilities
Use printArrayList to log contents of lists regardless of element type without exposing mutation capabilities.
- Framework APIs
Library methods that accept client-provided collections but only inspect items should accept Collection<?> or List<?>
to maximize compatibility (for example, validation code, metrics collectors, or simple serializers).
- UI rendering pipelines
Components that render lists of heterogeneous objects (for example, display adapters) can accept List<?> and
render items without knowledge of concrete types.
- Generic utilities in tooling and testing
Test helpers, assertion libraries, and debugging tools often need to read collections of unknown type; wildcards
make these helpers flexible and safe.
Notes and best practices
- Do not try to add elements to collections declared with List<?>. Adding anything but null is a compile-time error.
- When you need to write into a collection, prefer lower bounded wildcards: List<? super T>.
- When you need to both read typed values and write typed values, use a concrete generic parameter <T> and make
the method generic.
- Keep commented alternative signatures for teaching, but avoid shipping commented API in production libraries.
- Consider adding small unit tests or sample invocations in main before committing further examples.
Signed-off-by: https://github.com/Someshdiwan <[email protected]>1 parent df81c09 commit e665f22
1 file changed
+38
-0
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
| 1 | + | |
| 2 | + | |
| 3 | + | |
| 4 | + | |
| 5 | + | |
| 6 | + | |
| 7 | + | |
| 8 | + | |
| 9 | + | |
| 10 | + | |
| 11 | + | |
| 12 | + | |
| 13 | + | |
| 14 | + | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
| 19 | + | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
| 34 | + | |
| 35 | + | |
| 36 | + | |
| 37 | + | |
| 38 | + | |
0 commit comments