A constraint is a limitation that narrows the choices available when designing or implementing a solution. In software work, constraints include language limits, performance goals, deadlines, resource caps, and maintainability. They are not automatically obstacles: a well-chosen limit focuses attention on what is available, while unrestricted freedom can invite overengineered, hard-to-maintain designs. The useful question is not whether to accept a constraint, but whether it is tight enough to guide invention without becoming damaging pressure. section 10.2
Treat constraints as design forces with different priorities. A performance constraint matters when dataset size, object size, or transformation cost makes repeated traversals or sorting visibly slow; optimizing away a few milliseconds otherwise has little value. A memory constraint can favor retaining only needed values and pre-sizing a result list. A paradigm constraint can require a functional solution in one pipeline, but fulfilling that rule may produce a more elaborate implementation than the problem otherwise needs. section 10.2.1 section 10.2.2
One people-analysis task, several constraints
Given Person objects with names and ages, find one youngest person, one oldest person, and an alphabetized name list. An imperative version finds both age extremes in one pass and sorts names afterward. A direct stream-based version expresses each result separately and has lower cognitive complexity, but makes independent traversals. For a genuinely large collection, parallel streams can distribute work across CPU cores; for a small one, splitting, coordination, and merging can cost more than they save. Java parallel streams also share ForkJoinPool.commonPool(), so competing parallel or blocking work can degrade performance. section 10.2.2 section 10.2.2
Listing 10.5 Single-stream constraint using a custom collector
record Stats(Person youngest, Person oldest, List<String> names) {}
record OldestAndNames(Optional<Person> oldest, List<String> names) {}
Stats stats = persons.stream().collect(
Collectors.teeing(
Collectors.minBy( #1
Comparator.comparingInt(Person::age)), #1
Collectors.teeing( #2
Collectors.maxBy( #3
Comparator.comparingInt(Person::age)), #3
Collectors.mapping( #4
Person::name, #4
Collectors.collectingAndThen( #4
Collectors.toList(), #4
list -> { Collections.sort(list); #4
return list; } #4
) #4
), OldestAndNames::new #5
),
(minOpt, resultOldestAndNames) -> new Stats( #6
minOpt.orElse(null), #6
resultOldestAndNames.oldest().orElse(null), #6
resultOldestAndNames.names() #6
) #6
) #6
);
log.info("Youngest: {}, oldest: {}, sorted names: {}",
stats.youngest(),
stats.oldest(),
stats.names());
A single-stream requirement leads to a custom collector that combines minimum, maximum, and sorted-name results. It demonstrates that satisfying a formal constraint can increase structural complexity, so clarity remains a competing constraint. section 10.2.2
Use constraints deliberately: begin with the straightforward solution, restate the problem under one limiting condition, and compare the resulting designs. Then combine only the benefits that matter in context—performance for large workloads, memory savings where capacity is scarce, or readability where future maintenance dominates. Prefer the clearest solution that meets the real limits rather than optimizing for limits that do not yet apply. section 10.2.1 section 10.2.2 section 10.4
