Angle Bracket in Java (Generics) with Practical Examples

When I review Java codebases in 2026, one tiny pair of characters still tells me a lot about a team’s engineering discipline: . In older code, I’ll see List without a type, casting sprinkled everywhere, and the occasional production bug that only shows up under load because a String was quietly treated as a CustomerId. In newer code, I see List, method signatures that carry intent, and far fewer “how did this even compile?” moments.\n\nThose angle brackets are the entry point to Java generics: a way to make types part of your API instead of trivia in documentation. If you already “know” generics, my goal here is to make you faster at reading and writing modern Java by focusing on the patterns I reach for most: generic classes, generic methods, the diamond operator, bounds, wildcards, and the failure modes that still bite experienced developers.\n\nBy the end, you should be able to look at in any Java snippet and quickly answer: what type is flowing through this code, what guarantees the compiler is enforcing, where the guarantees stop at runtime, and how to design generic APIs that are pleasant to call (not puzzles).\n\n## What Means in Java (and Why It Exists)\n\nAngle brackets in Java attach a type argument to a class, interface, constructor call, or method. The simplest mental model I use is:\n\n- T is a placeholder for “some reference type.”\n- List is a promise that every element in the list is T.\n\nSo when you write:\n\n- List you’re saying “a list that holds only String.”\n- Map you’re saying “a mapping from CustomerId to Invoice.”\n\nThat might sound like basic compile-time checking, but the real win is that you push correctness left: the compiler becomes your teammate that blocks a whole category of mistakes while you type.\n\nA few facts that keep you out of trouble:\n\n- Generics are for reference types, not primitives. Use Integer, not int.\n- Most generic type information is enforced at compile time and largely disappears at runtime (type erasure).\n- The standard library expects generics everywhere: collections, streams, Optional, functional interfaces, and many concurrency types.\n\nCommon shapes you’ll see:\n\n // a type parameter named T\n // a concrete type argument\n <List> // nesting generics\n // wildcard with an upper bound\n // wildcard with a lower bound\n\nWhen I’m coaching teams, I don’t frame this as “use generics everywhere.” I frame it as: make incorrect states hard (or impossible) to represent in the code that matters.\n\n## Generic Classes: Turning into Safer Data Structures\n\nA generic class is the most direct way to understand angle brackets. You define a class with a type parameter, and you use that parameter in fields and methods.\n\nHere’s a small, runnable example: a TypedValue that holds exactly one value of type T.\n\n public final class TypedValue {\n private final T value;\n\n public TypedValue(T value) {\n this.value = value;\n }\n\n public T get() {\n return value;\n }\n }\n\n class TypedValueDemo {\n public static void main(String[] args) {\n TypedValue retryCount = new TypedValue(3);\n System.out.println(retryCount.get() + 1);\n\n TypedValue environmentName = new TypedValue("staging");\n System.out.println(environmentName.get().toUpperCase());\n\n // Uncommenting this line fails at compile time (which is exactly what you want):\n // TypedValue broken = new TypedValue("not a number");\n }\n }\n\nNo casts. No runtime surprises. The type relationship is obvious at the call site.\n\n### A realistic generic interface: Repository\n\nIn real systems, generics shine when you can express domain rules. A small Repository abstraction is a common example: it’s not fancy, but it prevents mistakes.\n\n import java.util.;\n\n public interface Repository {\n Optional findById(Id id);\n T save(T entity);\n void deleteById(Id id);\n }\n\n record CustomerId(String value) {}\n record Customer(CustomerId id, String emailAddress) {}\n\n final class InMemoryCustomerRepository implements Repository {\n private final Map storage = new HashMap();\n\n @Override\n public Optional findById(CustomerId id) {\n return Optional.ofNullable(storage.get(id));\n }\n\n @Override\n public Customer save(Customer customer) {\n storage.put(customer.id(), customer);\n return customer;\n }\n\n @Override\n public void deleteById(CustomerId id) {\n storage.remove(id);\n }\n\n public static void main(String[] args) {\n Repository repo = new InMemoryCustomerRepository();\n\n CustomerId id = new CustomerId("cust1001");\n repo.save(new Customer(id, "[email protected]"));\n\n String email = repo.findById(id)\n .map(Customer::emailAddress)\n .orElse("missing");\n\n System.out.println(email);\n\n // This kind of mistake becomes impossible:\n // repo.findById("cust1001");\n }\n }\n\nIf Id were a raw String everywhere, it would be easy to pass an invoice id where a customer id is expected. With CustomerId, the compiler blocks that class of bug.\n\n### When I avoid creating generic classes\n\nGeneric classes are powerful, but they can also create friction. I avoid generics when:\n\n- the type parameter doesn’t add safety (it always ends up being the same type)\n- the API becomes harder to read than the concrete alternative\n- callers fight type inference and end up writing explicit type arguments everywhere\n\nA good smell test: if code reviews keep adding comments like “what is T here?”, your abstraction may be too broad.\n\n## Generic Methods: One Algorithm, Many Types\n\nGeneric methods let you write one implementation that works across types without making the entire class generic. The syntax is easy to miss at first:\n\n- static T methodName(...) means “this method has a type parameter T.”\n- the appears before the return type.\n\nHere’s a small method I use a lot: pick the first non-null value.\n\n public final class FirstNonNull {\n private FirstNonNull() {}\n\n public static T firstNonNull(T primary, T fallback) {\n return primary != null ? primary : fallback;\n }\n\n public static void main(String[] args) {\n String region = firstNonNull(System.getenv("REGION"), "us-east-1");\n System.out.println(region);\n\n Integer port = firstNonNull(null, 8080);\n System.out.println(port);\n }\n }\n\nWhat matters here is what you don’t see:\n\n- no at the call site (type inference handles it)\n- no casts\n\n### Two type parameters: mapping one type to another\n\nA lot of production code is “take a list of X and produce a list of Y.” Here’s a complete example using Function.\n\n import java.util.;\n import java.util.function.Function;\n\n public final class ListMapper {\n private ListMapper() {}\n\n public static List mapList(List input, Function mapper) {\n List output = new ArrayList(input.size());\n for (A item : input) {\n output.add(mapper.apply(item));\n }\n return output;\n }\n\n record InvoiceNumber(String value) {}\n record Invoice(InvoiceNumber number, long totalCents) {}\n\n public static void main(String[] args) {\n List invoices = List.of(\n new Invoice(new InvoiceNumber("INV-1001"), 12500),\n new Invoice(new InvoiceNumber("INV-1002"), 9900)\n );\n\n List invoiceNumbers = mapList(invoices, inv -> inv.number().value());\n System.out.println(invoiceNumbers);\n }\n }\n\nIf you’re used to streams, you might think “why not invoices.stream().map(...).toList()?” You often should. I still like showing the loop because it makes the generic flow (A to B) extremely concrete.\n\n### “But I passed a primitive” — what’s really happening\n\nYou can’t write List, but you can call firstNonNull(null, 8080) because 8080 autoboxes to an Integer. That convenience is great for normal code, but if you’re processing millions of numbers in tight loops, boxing can create allocations and GC pressure. In those hot paths, I keep the generic layer at the edges and use primitives internally.\n\n## The Diamond Operator and Modern Type Inference\n\nYou’ll often see used with nothing inside it: new ArrayList(). That’s the diamond operator, and it tells the compiler: “infer the type arguments from the context.”\n\n import java.util.;\n\n class DiamondDemo {\n public static void main(String[] args) {\n List serviceNames = new ArrayList();\n serviceNames.add("billing-api");\n serviceNames.add("identity-service");\n\n System.out.println(serviceNames);\n }\n }\n\nOlder code often repeats the type: new ArrayList(). It still works, but the diamond keeps instantiation readable.\n\n### Traditional vs modern calling styles\n\nI encourage teams to prefer the most readable style that still communicates intent.\n\n