There is nothing wrong with composite threads. These objects are lightweight because they relate only to the source data, but do not copy data, such as the contents of the array. The cost of such a lightweight facility can only be relevant if the actual payload is also very small. Such scenarios can be processed with specialized, semantically equivalent overloads:
public void something(String required, String ... additional) { somethingImpl(Stream.concat(Stream.of(required), Stream.of(additional))); } public void something(String required) { somethingImpl(Stream.of(required)); } public void something(String required, String second) { somethingImpl(Stream.of(required, second)); } private void somethingImpl(Stream<String> allParams) {
therefore, in the case of only one argument, you not only save instances of Stream , but also a varargs array (similar to overloading Stream.of s). This is a common template; see, for example, the overloads of EnumSet.of .
However, in many cases, even these simple overloads are not needed and can be considered premature optimization (libraries like JRE offer them, because otherwise the application developer can add them if it is ever needed). If something is part of the application, not the library, you should not add them unless the profiler tells you that this is a bottleneck caused by this parameter processing.
Holger
source share