Identifying resource-using streams

[Marko Topolnik]

Although I don't support Tino's tone and borderline sarcasm, I must say that I 
have to second much of the essence of his arguments.

It seems that Java now has an API called Streams which is not particularly 
suited to the processing of... streams. It is actually a stream-oriented 
paradigm glazed on top of Fork/Join, a framework optimized for the parallel 
processing of massive in-memory, random-access structures. At the same time, the 
stream paradigm is not well-suited to the classical target use cases of 
Fork/Join (which I imagine as physics/engineering/simulation applications where 
matrix transformation, an essentially 2D-operation, is the predominant 
paradigm), so it probably won't help even in that area. That leaves us with 
nothing but textbooks and tutorials as the use cases where in-memory collections 
are typically used to demonstrate API usage.

The introduction of the FP paradigm opens the door to significant advances in 
terms of both design and performance within Java's most important area of 
application: business software. Typically, the performance-critical use cases 
there revolve around the transformation of large outside sources such as files, 
result sets, and incoming network data into server responses, files, and INSERT 
statements. Without FP it has been notoriously difficult to capture both 
composability and lazy processing in a single design (implying O(1) space 
complexity instead of O(n)). This tension most often resulted in a decision to 
dispose with the scalability inherent to lazy processing in favor of composable 
design, a fact evidenced by a significant incidence of failures due to out-of-
memory exceptions.

The above fact may be one source of Brian's statement that most observed usages 
in the field revolve around collection processing. However, this means that the 
Streams API, which had the potential to effect an important *advance* in the 
predominant pattern of processing, will just support a slightly more concise and 
expressive way to describe the same pattern.

Time will show, but I would say that the Streams API is facing a significant 
risk of meeting the destiny of Java's date APIs, leaving the playing field wide 
open to third-party contributions which will meet the demands of Java projects 
significantly better.


Regards,
Marko Topolnik