There are three kinds of actuaries: those who can count, and those who can't.
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Jj Roberts wrote:I'm not at my computer, so I can't help much. You are using the wrong class for reading text. Instead, look into the Reader classes, and maybe the Scanner class. The I/O learning trail from Oracle here is an excellent place to start.
Hope that helps for now.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:
Note for your own sanity's sake: Java has the convention that the "real", that is forward slash may be used as a filepath separator on all OS's, including Windows. So rather than this:
write this:
Because just one dropped backslash can ruin your whole day. Plus it helps if you ever need to run on a non-Windows OS, and that's no longer a rare occurrence. And may get rarer if Microsoft doesn't keep screwing up Windows 10.
Michael Mutek wrote:- anyways, do I understand it correctly that my syntax there "\\\\...\\\\.." is only working on Windows,
while the conventional one ("/../../..") is basically working on any OS?
So when I am using Windows, but someone would test my program on his Linux-OS it would work with the second conventional method, but not with my used one?
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Campbell Ritchie wrote:There is probably an FX class corresponding to JFileChooser. If you are already writing FX, try an FX class first. If you become proficient in FX, you may never need to use Swing. But that isn't either of the naughty things I thought I was doing.
Yes, you did use something almost identical to line 8. But it is not a case of the line being empty. When the buffered reader reaches the end of the file, it returns null from readLine(). That is how it signals completion of its task.
Oops, I actually meant this in my brain, but have for some unknown reason (maybe exhaustion^^) stated something which is wrong in my post above.
Yeah, clearly - the task there is to execute the while-loop as long as there is content in the file, i.e. til the end of the file.
A single iteration ends apparently when there is a 'new line' incoming - so after every line, a new iteration of the loop will begin.
You start by assigning line with whatever is read next, and you need additional () because != has a higher precedence than =. When you have assigned line, you test whether it is null. It there is an empty String, that suggests the enter key has been pressed twice, and readLine() will return a 0‑length String. You may wish to test for empty Strings in the body of the loop, or not.
Ah that is intersting.
Let's say we have one text-file with two paragraphs, where between thos two paragraphs two or more empty lines are existent, e.g.
"Hello world!
Bye"
In this case, reading from the file using the method would be a problem, since it would think that the file came to an end, after "Hello world!" ?
I think the subejct of your second thread is different enough from this one to merit a second thread.
Al right:)
No. The readLine() method will return an empty String, not null. It is easy to write if (!line.isEmpty()) ... or similar. Remember the trim() and strip() methods.Michael Mutek wrote:. . . one text-file with two paragraphs, where between thos two paragraphs two or more empty lines are existent, e.g.
"Hello world!
Bye"
. . . reading from the file using the method would be a problem, since it would think that the file came to an end, after "Hello world!" ? . . .
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |