On Tue, Feb 28, 2017 at 11:20 AM, Erich Duda <[email protected]> wrote: > Thanks for response. > > It makes sense. I thought it is done because of performance but I wasn't > sure. I supposed that Java do these optimizations already in > FileInputStream.
16 or 17 years ago.. (:O wow.. that long.. I'm getting old)... I had done a T3 Training at Sun (Train the trainer, and Yes I really mean Sun, not Oracle).. and using BufferedInputStream with a fileInputStream was even part of the official course material.. so that's a thing why I thought it was standard. :) > > Based on your response I've done research on Internet and it seems you are > right. BufferedInputStream really saves IO calls. > > Erich > > > Dňa 28.02.2017 o 16:56 Clebert Suconic napísal(a): > >> If you worked directly with the FileINputStream, it would work, but it >> would generate too many IO calls... it's user's code, the user can do >> anything they want with this Stream, but I thought any Java dev would >> do this kind of thing by default. >> >> >> I wrote this about 5 or 6 years ago though.. it's hard to remember why >> I did that... but that's what I remember anyways. >> >> On Tue, Feb 28, 2017 at 7:09 AM, Erich Duda <[email protected]> wrote: >>> >>> Hi all, >>> >>> I would like to ask one question about streaming of large messages over >>> JMS. >>> I've found a nice documentation [1] with a lot of examples. However I >>> wonder why in examples FileInputStream and FileOutputStream are wrapped >>> by >>> BufferedInputStream and BufferedOutputStream. There is no explanation in >>> the >>> text. Is it really required? Or is it done because of performance? >>> >>> Thanks in advance. >>> >>> Erich >>> >>> [1] >>> >>> https://activemq.apache.org/artemis/docs/1.5.0/large-messages.html#streaming-over-jms >>> >> >> > -- Clebert Suconic
