2

I have a simple output text file, it is called logOutput.txt :

2

3

4

And I want my Java Program to give the most recent one in the file ( 4 ). Here is my code:

import java.util.*;
import java.io.*;

public class readLogFile {

    public static void main(String[] a) {
        int logNumber = 0;

        try {

            File file = new File("logOutput.txt");
            Scanner input = new Scanner(file);
            while (input.hasNext()) {
                logNumber = input.nextInt();

            }

            System.out.println("the log # is: " + logNumber);

        } catch (FileNotFoundException fne) {

        }
    }

}// end class

My concern is mainly regarding the while loop. Is there a way that is more efficient? Here I'm reading each line into the variable then over-writing that. I was thinking - maybe to check for when the nextInt is null ?

thanks

almightyGOSU
  • 3,731
  • 6
  • 31
  • 41
Caffeinated
  • 11,982
  • 40
  • 122
  • 216
  • Or... maybe efficiency is not concern for such small apps ! ? !?!? – Caffeinated Jul 22 '15 at 03:16
  • 3
    It's not the size of the app. It's the size of the file. Give your little apps enough time and they can fill up a hard drive. – candied_orange Jul 22 '15 at 03:17
  • @CandiedOrange - ah Ok , yea I can see this. If we have huge log files then we'd need something as efficient as possible – Caffeinated Jul 22 '15 at 03:18
  • 1
    What about this is not efficient enough? In a way, it depends on the file. If you encode the file with a size at the start, you could do it as 1 read. But in real time, I don't know how much faster it would be since most of the slow down bottleneck is from the drive access. You could also make your own reader class to handle read aheads, but again, you'd still be slowed down by the file access times. – ydobonebi Jul 22 '15 at 03:23
  • @CandiedOrange - thanks very much - yes, this is pretty much a dupe then! nice find !! – Caffeinated Jul 22 '15 at 03:23
  • @QuinnRoundy - fair enough - it shouldn't be ineffcient. thanks ! – Caffeinated Jul 22 '15 at 03:25
  • 1
    If you find yourself using one of the non fixed size encodings (non ascii) I wonder if there isn't a padding value you could write into it. This wouldn't display or print, just pad. If you control writing the file always pad out to your buffer size. Then you can read randomly wherever you like. – candied_orange Jul 22 '15 at 03:56

2 Answers2

2

You can check the input using Integer.parse()

In your while loop:

String s = input.nextLine();
try{
    int i = Integer.parseInt(s);
    logNumber = i; 
} catch(NumberFormatException ex) {
    System.out.println("It is not an int");
}

If the line is not an integer or null, Exception will be thrown.

K.Hui
  • 153
  • 1
  • 13
1

So, there are at least two ways to read a file that are relevant here.

  1. Read the whole file into a String (or a byte[]) and then parse the whole thing at once. This fails terribly with larger files, and isn't likely faster.
  2. Read part of the file into a buffer, parse it, then repeat until there's no more file.

The second way is more efficient for memory, as you're only taking into memory what you can handle at any one time. With they way you're doing it here, you have the single failure case of what happens with a really, really long line (what if they never hit 'enter'?), but other than that, this is safe... and chunks the work into something the machine can always fit into RAM.

Yes, you'll overwrite the value a bunch of times, but you'll only do it once per line of input, so it can't get exponentially bad, and writing things to RAM is cheap. This is likely about as efficient as it's going to get; the only reason to tune this would be if you were dealing with very, very large input sets.

Dean J
  • 39,360
  • 16
  • 67
  • 93