FileInputStream question.

[Norm]

We're trying to help you learn. You learn by doing. There are many, many mistakes you must make before you become a good programmer. If you do not write code you will not makes these mistakes.

[fatabass]

Norm thanks for all the efforts.
We are both wasting our times.

Your way of helping is obviously not helping me, rather confusing me.

I am a simple guy, with simple answers that are asked to me.
and I prefer simple answers myself.

Thanks for all the efforts,
I will try harder and hope to understand how this method could be used..

Maybe as I get better in JAVA, I will..
Thanks.

[DarrylBurke]

Why are you answering my questions with questions?

Anyone else see the irony in this?

db

[al_Marshy_1981]

It amazes me how far people will go before they try out a method etc. Seems quoting the Buddha is an exempt or something. Funny thing is if he coded up the most awful use of FileInputStream ever seen to man he would have gotten some real code examples or near enough... pains me

[JosAH]

My question is:

I have a byte array and some byte values in it. And I create a FileInputStream to read the bytes in it.
But I can not create a FileInputStream without pointing it to a file.
But I really do not need a file to read an array.

So why would that be ?
Any logical answers?

Of course my reply #23 was written in invisible ink again ...

kind regards,

Jos

[fatabass]

If you want an InputStream that reads from a byte array (not a file), have a look at the ByteArrayInputStream class. (it is also mentioned in the API documentation as a sub class of the InputStream class).

kind regards,

Jos

@JosAh thanks, I am aware of this.
But I do not want to read from an array. I am trying to understand what this method would be used for.

@people who are in pain:
http://cbsnewyork.files.wordpress.co...ills.jpg?w=300

[Fubarable]

Anyone else see the irony in this?

db

It amazes me his quote here where he insults all who have tried to help him:

I did not try.

I really like personal connection.
I will just wait until I make some friends who knows JAVA.

This dumbfounds me, especially in light of Norm's amazing patience with him (not to mention his in-depth knowledge of Java).

[JosAH]

@JosAh thanks, I am aware of this.
But I do not want to read from an array. I am trying to understand what this method would be used for.

If that is not what you want you should rephrase your question.

kind regards,

Jos

[fatabass]

Hi fatabass,

I will try to answer your question.

See, you are probably confused due to the returning value of this method. This method is returning an integer, but that is really not what you are after.

Also, what is confusing you is that, the array you are passing as an argument to this method has 2 functions:

1) This method gets the length of the array,
--> This method read that many bytes from a file,
2) This method passes the byte values to the same array you are passing as an argument to this method.

You are probably stuck with the returning int value, because usually read() methods RETURN relevant read information. (like a string, or an integer..) But this is not the case in this method.

So, to your very clear question:
You would use this method to read a file as bytes and store it in an array easily.

Here is a sample code.

You will need a try.txt file in c:\ , and just put some text

	public static void main(String args[]) throws IOException
	{
		FileInputStream firstStream = new FileInputStream(new File("c:/try.txt"));
		byte[] myArray = new byte[firstStream.available()];
		firstStream.read(myArray);
		for(int i=0;i<myArray.length;i++)
		{
			System.out.print((char)myArray[i]);
		}
	}

This will output the text in the file to the console.

Good luck learning JAVA.

[fatabass]

Here in

firstStream.read(myArray);

You are passing an integer value to the method. (Which the length of that array..)
The method reads that many bytes from the source.
The method writes those bytes to the array you have passed as the argument.

You do not care about the returning value.

[Norm]

You do not care about the returning value.

No!!! You do care! That tells you how many bytes were read. It can be important to know in the real world.

[fatabass]

Thank you so much Norm.

I should have said:

You should not focus on the returning value to understand what this method is really doing. The returning value is more like an extra feature of this method. It doesn't have REALLY MUCH about what the method is doing. ( Since what the method really doing is, it gets a byte array, gets its length, reads that many bytes from the source, and passes them as bytes to the same byte array you passed to the argument. )

[Norm]

reads that many bytes from the source,

Some times it reads fewer and when it does the value returned by the read method will tell you.
For reading from disk it is mostly the same. If reading over a network connection, it can be different.

[fatabass]

Some times it reads fewer and when it does the value returned by the read method will tell you.
For reading from disk it is mostly the same. If reading over a network connection, it can be different.

Thanks for the further explanation.

So we can say, it can be used for verification or controlling purposes.

[Norm]

yes. It should not be ignored.

[fatabass]

One more question:

First the information:

There’s a difference between the bytes in a stream and the bytes represented
by the byte class. A byte in Java has a value ranging from –128
to 127, while a byte in a stream has a value from 0 to 255.

IF a character in my text file has a corresponding byte value of 200, which is out of primitive type byte limit, what happens ?

Thanks.

[Norm]

A byte has 8 bits. It can have 256 different values. If the byte is signed, then the top bit is used for the sign which changes the range of numbers it can represent as you describe. If you put the int value 200 into a byte it will have the top bit set on which will make it a negative number.
Try this to see what bits are used for 200:
System.out.println(Integer.toBinaryString(200)); // 11001000

[fatabass]

Thanks for the answer,

A byte has 8 bits. It can have 256 different values. If the byte is signed, then the top bit is used for the sign which changes the range of numbers it can represent as you describe. If you put the int value 200 into a byte it will have the top bit set on which will make it a negative number.

After this point I am lost..

like the char 'k' has a byte value 107.

So when you read a character 'k' from a text file with FileInputStream, the InputStream returns the value 107 to a byte[] array, and a byte can hold the value 107 without any errors.

But what if reads some character that has a byte value greater than 127? What happens then? ( I wish I knew a such character so I could try, I found this: UTF-8 - Wikipedia, the free encyclopedia, but then the largest value is 122 (of character 'z'), which can be stored as the primitive type byte in JAVA )

[Norm]

Since Americans were the ones to develop this scheme, they put their letters first in the ASCII characters (0-127).
Most letters in the rest of the world require 2 or more bytes to store their values in.
You need read up on Unicode and how all the different languages get a range of values for their letters. Think of Chinese and Thai and the Indian languages. They all have different ranges of values for their letters.

[fatabass]

Since Americans were the ones to develop this scheme, they put their letters first in the ASCII characters (0-127).
Most letters in the rest of the world require 2 or more bytes to store their values in.
You need read up on Unicode and how all the different languages get a range of values for their letters. Think of Chinese and Thai and the Indian languages. They all have different ranges of values for their letters.

Thanks,
So it will never need to read a value of 200, because in no character set it represents a character.
If 0-127 is not enough, a weird character like :
()
will be represented by two byte values. ( like 66 66 ), and java will just know it should read two of them and return the character corresponding.