-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Amey Samant wrote:
[snip]
hi
first of all thanx for taking your precious time out to help me
i dont know what level you cosider yourself at with java but i
request you think this from a "novice" point of view
THIS IS WITH REFERENCE TO DOCUMENTATION FOR j2se
1. System.in is an InputStream
2. DataInputStream has a constructor that takes InputStream
so new DataInputStream(System.in) is absolutely right
3. now DataInputStream has a method with following signature
public final int readInt()throws IOException
4. thus if i write
int a=(new DataInputStream(System.in)).readInt();
it should store an integer in variable 'a' as the return type is
an
'int' for readInt()
5. now when you print this 'a' using System.out.println(a);
why should it not print correctly ??????
the method you suggested is "long cut" however well known it might
be i mean to read an integer why i have to read a Line & parse the
int
there must be other easier way
also im not looking for a method to read an integer ....you can read
it thousand ways ....
i was freaked by above points
i hope i make it clear
can anyone explain not just "Anthony Borla"
amey
Hi,
OK, here's another explanation.
First, there is a difference between bytes and characters. In Java, a
character is Unicode, 2 bytes long. A byte is 1 byte long
(obviously). A character is a piece of a human language, while a byte
is a piece of a computer data storage mechanism. In Java, a <char>
data type is a way of representing a human character in terms of
computer storage. *IN GENERAL*, streams transfer bytes and readers
transfer characters.
Alright, here we go. This is what happens in your code.
1. The user types in 58 and presses ENTER. This consists of three
characters: '5', '8', '\r', and '\n'. The operating system sends
these characters to the Java VM's standard input stream as bytes.
These bytes would typically be along the lines of 53, 56, 13, and 10.
These are the ASCII codes for the said characters. It is these bytes
that are sent to the JVM.
2. The JVM sends these bytes directly to your program by means of
System.in. This _STREAM_ reads the bytes, one after the other.
3. The DataInputStream takes the bytes from System.in and tries to
generate an int value. An int value requires 4 bytes, and I'm not
sure in which order they're used. Essentially, though, the 53, 56,
13, and 10 are used to generate the int value that is returned by
readInt(). The DataInputStream doesn't know, nor does it CARE,
*WHERE* these bytes came from! All it knows is that it got them from
somewhere. It doesn't know nor care that they are characters the user
typed on the console. Thus, you definitely don't get the value you
were looking for!
As has already been pointed out, DataInputStream reads numbers
correctly if they are written with DataOutputStream. If you feed 58
to DataOutputStream's writeInt() method, you'll get bytes 0, 0, 0,
and 58. By examining the ASCII table, we see this computes to NUL,
NUL, NUL, and colon (:). If you were to feed these four bytes back
into DataInputStream, you would get the proper value of 58 out.
In short, DataInputStream is meant to be used only to read in data
written with DataOutputStream. They do not, and are not intended to,
output data in a human-readable format; rather, they use the most
compact and efficient way possible for a computer to represent the
values.
The fact is, you're reading characters from a stream that happens to
be connected to a keyboard. Therefore, the origins of the data are
*characters*: the keyboard has letters and numbers on it; these are
elements of a human language, so they're characters, not bytes. The
fact is, the operating system sends the characters to your program in
the form of bytes. Since they were originally characters, they should
be translated back into characters before use for any other purpose.
The correct way to transform bytes into characters is to use an
InputStreamReader. This makes sense in the stream/reader system: the
stream passed in produces bytes, and the reader (the
InputStreamReader) generates characters. Thus, the bytes are turned
into characters. Now, since you want the user to type one number and
press ENTER, this means there is one number per line.
InputStreamReader doesn't directly support reading in a line at a
time, so you could do it manually or, the easier way, you could wrap
it in a BufferedReader, which does have this functionality. Reading a
line gives you a String, which makes sense, since the user types a
string of characters before pressing ENTER. Your program wants a
number, so it calls parseInt() to acquire one.
The important thing to remember here is that there are certain
transformations that go on in the operating system, and other
transformations that your program must perform to correctly work with
the data. These are the operations performed to read an integer from
the keyboard, in a typical operating system:
1. User presses keys. Microcontroller in keyboard produces scancodes,
which are numbers identifying the keys, which are sent to the
computer.
2. The operating system reads these scancodes and uses a keyboard map
to figure out what keys they represent. The OS then somehow
transforms the sum total of keys pressed (shift, control, etc plus a
letter) into a character (uppercase, lowercase, etc).
3. The character is translated into one or more bytes by the OS.
4. The OS sends these bytes to the program (the JVM).
5. The JVM sends the characters to your program by way of the
System.in stream.
6. Your program transforms the bytes into characters by way of the
InputStreamReader.
7. Your program reads a bunch of characters, representing a line, into
a String representing that bunch of characters.
8. Your program transforms the bunch of characters, in the String,
into a number, by way of parseInt().
So you see, characters come into the JVM in the form of bytes.
Changing this would require modifying the operating system and every
program running on it, including the JVM.
I hope this helped you understand, and I hope it didn't seem too
"dumbed-down" - but better too dumbed-down than too high-level.
- --
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/16+KwxczzJRavJYRAqsuAJ9FKA3nzoXEEKbK6bOj7GTzYRu1SA CeKkEf
HhaylkRBiheU6p/j1f0+OGo=
=pJD9
-----END PGP SIGNATURE-----