"input.txt" file contains "12345" no carriage return or line feed at the end. The method does print all the characters from the file, but at the end it keeps on printing unknown characters - like the following.
I know that f.read() would return -1 at the end-of-stream which should stop the loop, but why that's not happening here?
Why are you using the read() method? Unless it is to find out how bad that method is, you should avoid read() (and write()). Wrap that reader in a buffered reader and read the whole line. Or (probably easier) use a Scanner. ReadAllAboutIt (as the people who stood in the middle of the road selling newspapers said when I was little) in the Java™ Tutorials.
I am trying write a lexical analyzer, and I need to read from the input file character by character to see what token is it. That's why I want to avoid reading line. I can of course read lines and parse it character by character...
But what's wrong with read() and write()? Should I both avoid the them from both byte/character class?
or do you require the tokens be spaced apart: x + y? You would find it awkward to read x+y as three tokens with a Scanner.
I think you would do better to read a whole line and scan the line because a buffered reader/Scanner takes only slightly longer to read a whole line than read() does to read one letter.You would have identifyWord() methods and identifyNumber(), identifyOperator(), etc etc.
Quazi Irfan wrote:But what's wrong with read() and write()?
Nothing, they're just rather laborious.
And if you're file is arranged in lines, doesn't it make sense to read it in that way? Then you can determine "tokens" by whatever the rules are for them.
Furthermore, assuming tokens can't be split across lines, you can actually use a Stream to aid the process in version 8, viz:
I thought you had found that out already. They are slow. The read() method returns an int when you want a char. They declare all sorts of checked Exceptions which never actually are thrown.
Quazi Irfan wrote:. . . But what's wrong with read() and write()? . . .
But the most important objection to them is that there are better alternatives available.
Campbell Ritchie wrote:That depends on there being a token delimiter. If x+y and x + y are indistinguishable, then it would be very awkward to split on a delimiter.
True. As it is, it would also rely on the file contents being correct.
It seems to me that File-to-Stream functions are still a bit thin on the ground. Maybe we'll get some more with v9.
At least if you parse a file's contents you can check them for correctness. It is much harder to check the other files people read from.
Winston Gutkowski wrote:. . . As it is, it would also rely on the file contents being correct. . . .
I think the Stream methods didn't take parsing and lexing into consideration because those are specialised techniques. Also there are libraries like JFlex already available.