I think this is more of a style question, but lets give some thoughts:
- It seems to be common practice to not use such a CONST collector object. In that sense: doing so might surprise some readers, and surprising readers is rarely a good thing to do.
- Then: few code can be just “copied” around (and probably shouldn’t to avoid code duplication); but still: pointing to a distinct collector object might make it a bit harder for you to re-factor or re-use your stream constructs.
- Beyond that: you stated it yourself; collector re-use depends on the a stateless implementation. So you make yourself dependent on any implementation being stateless. Probably not a problem; but maybe a risk to keep in mind!
- Probably more important: on the surface, your idea looks like a nice mean for optimization. But well; when you worry about the “performance effects” of using streams, then that one single object creation of the final collector will “not cut it”!
What I mean with that: if you are worried of “wasting” performance; you would rather look into each and any line of code that uses streams to determine whether that stream is working with “enough” objects to justify the usage of streams in the first place. Those streams come with quite some overhead!
Long story short: the java community has yet to find “standard best practices” for streams; thus my (personal) two cent at this time: prefer those patterns that “everybody” is using – avoid doing your own thing. Especially when it is “performance related”.