I am very much confused about Streams.
1) Does OS(i.e Windows) provide a Common Standard Input Stream and all the languages use it(i.e. Java refers to it as System.in and same Standard Input Stream is referred with stdin in c)?
Is it like keyboard has some port or physical address and OS has stored that
in some variable and when a program needs that it will give that same address to stdin or System.in depending on the language?
OR,
2) Is it like each language has its own API written for standard streams and when we run the program, a stream will get connected to the input device?
And what information that stream would have apart from data? i.e. Physical Port or address of device or what?
Also, Please tell about what is the meaning of System.in get "connected" to program when we run it. what does "connected" mean here?
Please share some link.
Definitions
A “stream” is a catch-all word, like “window”. All a stream means is that there is some thing (a “device”) that produces sequential data or accepts sequential data.
For example, I can make a string into an input stream (produces data), by simply keeping track of what the next character to produce is. When we run out of characters, we've reached the end of the stream. C++:
struct my_hello_stream
{
static const char* s = "Hello world!";
int n;
my_stream(): n(0) {}
int get()
{
if (s[n]) return s[n++];
return EOF;
}
};
Abstractions
Every system has its own way of abstracting a stream. The OS does it through files, pipes and character devices, which you can open for reading or writing. How exactly this is done depends entirely on the design of the OS. Consult your OS API documentation.
On top of that sits a programming language, like C or C++ or Java or FORTRAN — you name it. The programming language itself also defines a stream in a way convenient for the users of that language. In C you have a FILE*. In C++ you have std::iostreams. In Java you have I/O streams. Whatever the case, this works above the OS stream to read and write data from and to files, etc.
Moreover, these language features often allow you to do more powerful things with these stream interfaces, such as convert the character sequence 1234567 into a native integer value, and to perform these operations over strings.
Beyond that, there are also external libraries that allow us to treat things like internet connections and port connections with the printer like a stream. Some of this stuff the OS handles for us. Some of it it doesn't.
tl;dr
It all depends. What matters is the abstraction you have access to — which is typically your programming language. Hence, read about how your programming language expects you to open a file and read and write data, then act as if that is right. Whatever else actually happens underneath is magic.
What is a stream?
Stream is an abstraction which is either an input source or an output destination. In UNIX for example everything is a file so your keyboard will be represented by a read only file (why?). Whenever you want to read something from keyboard you just use the read system call using the keyboard file as parameter.
Does OS(i.e Windows) provide a Common Standard Input Stream and all
the languages use it(i.e. Java refers to it as System.in and same
Standard Input Stream is referred with stdin in c)?
OS only provides the very basic functionality such as read and write system calls (OS dependent) which can be used to read and write raw bytes. All the programming languages use this basic functionality to create abstractions (such as translating raw bytes to certain character set or buffering the data before writing).
When the program starts executing operating systems opens three standard text stream (channel) automatically and provides constant file pointer for them.
The stream you can think as like a channel, rather than a standard stream we have to open a stream by some library functions like fopen in c, which creates a stream bw your program and the file specified.
Related
I tried to understand the logic behind inputstreams and reading from files, but I fail to understand how you can read from a file using an inputstream.
My understanding is that when using input devices like a keyboard, you send input data through the input stream to the system. If you are reading from an input stream, aren't you reading the input data that's being send to the system at that time?
If we are creating an inputstream with the following code:
FileInputStream test = new FileInputStream("loremipsum.txt");
And if we try to read from the newly created inputstream with test.read(); how is there any data flowing through the inputstream? As no inputdata has been input from an input device at the time, but has already been input way beforehand. Is there something I'm missing out on? It almost seems to me as input streams are used in two different ways: Java using inputstreams to read data from a source and input devices using to input data to a source.
Java streams are a general concept / interface - a stream of data that you need to open, then read the data from (or write data to for output streams), then close. The basic stream only supports sequential reading / writing, no random access. Also, the data may or may not be readily available when you attempt to read from the stream, so the read may or may not block.
This abstraction allows us to use the same approach regardless of where we read the data from - it might be keyboard, a file, a network connection, output form another program or even some kind of generator that generates an endless sequence of data. Simply put, reading the input from file behaves the same as if someone in the background opened the file and typed its content on the keyboard really fast.
There are ways in Java to read the file in another ways (e.g. random access instead of sequential), but if you need to read the file from start to end, streams are a useful abstraction.
I have a thirdparty native subroutine in C that wants to output it's results to a file descriptor. I can choose the file descriptor (including standard output, stdout, if I want) by passing it to the C subroutine, but I cannot have it output to anything other than a file descriptor. I have created my own C code to act as an interface between Java and this C subroutine.
How can I get the output of the C subroutine back to Java directly... that is, without writing it to a file then reading it back in?
The output is usually in the neighborhood of 20-30k and is plain human readable text, so it isn't terribly large and is meaningful to my users. I'd like to display the output to the user in a Java console like window as it is being output. Is this possible? And how?
I see Java has a FileDescriptor object... is this part of the solution? I do not want to plug my C fd into the FileDescriptor object (using a private field of FileDescriptor) as described here: http://www.kfu.com/~nsayer/Java/jni-filedesc.html
I'd like to do this using Java best practices and idioms.
If you're on a Unix-like system, consider creating a named pipe and then opening it in both native and Java code as though it were a normal file.
This is similar to using a temporary file, except that the data goes directly from the writer to the reader without being stored on disk.
The downside is that you will still have to manage a temporary named pipe.
How does java input streams actually work? For example when you call inputstream.read(), how does Java break the file down into packets? Does java care about whether the file is .mp3, .doc, .txt, .mov ? How does the java io actually break all these different file types down into packets which can be streamed?
I greatly appreciate any answers on this topic.
when you call inputstream.read(), how does Java break the file down into packets?
It doesn't. Files don't have packets.
Does java care about whether the file is .mp3, .doc, .txt, .mov ?
No.
How does the java io actually break all these different file types down into packets which can be streamed?
It doesn't. The files are byte-streams, and that is a property of the underlying resource and the operating system, not Java.
When reading single bytes from streams, the read() method blocks until data is available.
Some streams may fetch data in blocks rather than byte-wise, but the block size completely depends upon the implementation (reading from compressed streams, reading from encrypted streams based on block ciphers, ...).
You can ask the stream how many bytes can be read without blocking (InputStream.available()), if somehow you need to know if and how much is buffered.
Java also provides a BufferedInputStream class which wraps any stream and can do buffered reads. The buffer size can be specified (default is 8 kB).
When using file streams, the file type has no effect on the buffering behaviour. It's recommended to always use BufferedInputStream/BufferedOutputStream when reading from and writing to files.
While reading Java Tutorials, the topic Basic I/o says, use InputStreamReader and OutputStreamWriter when there are no prepackaged character stream classes.
1)What are Pepackaged character stream classes?
Does it mean, a file already has some text!
The term is quite vague and doesn't really seem to be defined anywhere, so good question.
As best I understand it it means things like FileInputStream, FileOutputStream, ByteArrayOutputStream, etc. Classes that have wrapped up a particular kind of stream for you and provide the functionality required to work with it.
Note that most of these streams are working with characters not bytes, and that is generally what you want in Java for dealing with String data in files. On the other hand though if you are reading a pure binary source then the data will come in as bytes and you can then use InputStreamReader to convert those bytes to characters.
So a prepackaged stream reader is one that already provides you the data pre-packaged in the form that you want it.
I believe it to mean classes which inherit Reader or Writer. Such classes "wrap" byte streams so as to convert them automatically to character streams. Example: FileReader, FileWriter; they can read text from files directly.
If no such classes exist for your particular stream needs but you know what you get out of it/put into it is text, then you must use these two wrapper classes.
Classical example: HTML. It is text, but what you get from sockets is byte streams; if you want to read it as HTML, use a Reader (with the correct encoding!) over the socket stream (but of course, many APIs today don't require you to do that).
what is the difference when I use buffer istead of console() for retriving the output from my code?
The Console class, as used by System.console() seems targeted to interactive character-based I/O, as provided by an actual console such as a cmd.exe window in Windows or a terminal in Unix-like systems. As such, the system console may not always be available, depending on the underlying OS and how the JVM was started.
On the other hand, Scanner works with any input stream, including files and the standard input. It is more flexible, but it does not provide some console-specific functionality that Console does, such as the ability to read text - usually passwords - without echoing it back to the console.
The Console class makes it easy to accept input from the command line, both echoed and unechoed. Unechoed means you will see some special character in your console while writing a text (ex. *, ? etc) like when you enter your password in facebook. :) Its format() method also makes it easy to write formatted output to the command line(like making a pyramid of *s or a formatted date and currency formats etc). It also helps to write test engines for unit testing. or you can use it to provide you a simple CLI (Command Line Interface) instead of a GUI (Graphical User Interface) in case you want to create a real simple and small application. And yes, it is also system dependent that means that you cannot always rely on your system to provide you a console instance.
Now about buffering, its actually a technique used in I/O (i.e. both input and output) when you are interacting with a stream (be it a character stream or byte stream, be it from a console or a socket or a file). Its basically used to speed up the I/O and save system resources by avoiding multiple call to read() and write() methods. It is suggested that you use it in almost every kind of I/O interaction.