> However - the other two usecases are handling files and network sockets, and in the java world, you generally don't touch streams of bytes or lines even in those cases.
I think you live in a pretty rarified Java world.
> The unix approach of treating most things as streams of bytes or lines tends to be abstracted - if I'm writing socket-based communications, then an InputStream exists there; but if I'm making web requests, then it's through a library where no streams are exposed.
Except if you want to handle large amounts of data efficiently, you end up using streams to read and or write those web requests.
> Custom file formats would involve handling streams directly, but general practice in line-of-business apps nowadays is to never do that - you just [de]serialize to json/xml/something else standartized; and again that's done by a library that uses streams but doesn't expose them.
...and I guess you never have to debug anything or understand what is happening underneath?
> Students in java lessons use InputStream&PrintStream, but after starting work, promptly forget what the methods are called as they're used rarely.
Then why do you think they teach 'em? Aren't all subsequent concepts built on top of them?
> Except if you want to handle large amounts of data efficiently, you end up using streams to read and or write those web requests.
No you wouldn't, unless you're working on some tiny project where using raw servlets might be justified (though I'd be highly suspicious of anyone doing raw servlets). Most any other framework will provide higher level abstractions such as Play's Iteratees or variations of sendfile to handle the streaming for you. You're job is usually just to configure the proper marshaling setup so that your higher level object(s) delivered by your controller methods are properly serialized by the lower levels of the framework.
Occasionally you may need to actually write marshalling code but you should definitely be wary that you're doing it wrong if so.
I think you live in a pretty rarified Java world.
> The unix approach of treating most things as streams of bytes or lines tends to be abstracted - if I'm writing socket-based communications, then an InputStream exists there; but if I'm making web requests, then it's through a library where no streams are exposed.
Except if you want to handle large amounts of data efficiently, you end up using streams to read and or write those web requests.
> Custom file formats would involve handling streams directly, but general practice in line-of-business apps nowadays is to never do that - you just [de]serialize to json/xml/something else standartized; and again that's done by a library that uses streams but doesn't expose them.
...and I guess you never have to debug anything or understand what is happening underneath?
> Students in java lessons use InputStream&PrintStream, but after starting work, promptly forget what the methods are called as they're used rarely.
Then why do you think they teach 'em? Aren't all subsequent concepts built on top of them?