This article is about the event "Tech Connect! Autumn" hosted by Link Information Systems. This is a relay article. "Tech Connect! Autumn" is relayed by a group member of engineer.hanzomon. (For the link information system Facebook, click here](https://ja-jp.facebook.com/lis.co.jp/))
On the first day, Daisuke, who is the leader of this event, will send you a poem.
It is a poem that inflates the ** subjective impression ** of java.io.InputStream that I usually use.
・ ・ ・ ・ ・ ・ ・ The impression I get from Stream is "flow". Insert an Input Stream that seems to have a sharp point when reading a file etc. into a barrel. When you stab it, the data will come out like water, so you will have to store it little by little with a Buffered Reader and drink it.
When writing a program, it is a problem even if it flows out, so I drink it while closing it with my hand by specifying the amount to read. read () and close () ** have a feeling of flowing / blocking, and are watery and nice **. But the method skip () skips n bytes of data, so what about the water in between? The question arises and it is not watery. In the first place, InputStream can handle bytes, so it is better to have a square shape that represents a number. Let's say you have a line of cards with numbers on them. Let's forget about the barrel and water.
If you read () first, you will get the first card. Since the numbers from 0 to 255 are written there, you can interpret it as ASCII or as a part of the image data, or you can freely interpret it.
If you read () again, you will get the next card. So InputStream will remember the position of the card you just passed.
Read () is defined to read one byte at a time, and a method to specify the size and read quickly is defined, and size specification read () internally calls 1 byte read ().
Mark () will remember the position of the card, and reset () will return it to that position. Genuine java.io.InputStream gets angry and throws an IOException when you call reset (), but since you don't use mark () or reset () much in the first place, you don't know or need to know that it's easy to get angry. InputStream has completely lost its wateriness, and even the cards have a casino feel due to the hustle and bustle.
There is available (), which promises to tell you how many cards are left, but the genuine java.io.InputStream always returns zero. Maybe because you don't want to assume that the read target is huge or you are dealing with continuous data? , The uncle spec decision maker who manages the casino may have decided to return zero.
If you finish reading the last card and call read () again, -1 will be returned. -1 when there are no more cards.
As I wrote so far, java.io.InputStream is abstract. I think that quite a few people get the feeling of interface ** from the text, but it's abstract. If it is an interface, it will mediate various exchanges without working, which gives the impression of a person on the compiler side, but since InputStream is abstract, it gives a slight sense of muscle and hard work. The only person who is dealing cards at the casino is the dealer.
I wrote that it is a casino dealer, but the actual feeling of use is more neat and serious, so java.io.InputStream is close to a neat resort casino dealer (in charge of cards) who wears white clothes and does a good job. Is it? I wear black-rimmed glasses.
The children who inherited InputStream continue to work at various resort casinos today, incorporating genes and responsibilities into themselves. Behind the glasses is full of achievements and confidence from JDK 1.0. Tomorrow is @ taisuke3.