Saradus,
As angryboy has already stated, you're making a ubiqitious noob "mistake" by lumping everything together into one big "do everything" main method.
While this approach can be made to "work" for relatively simple problems, it has a number of deficiencies. First and foremost it's "hard". Huh? What? Well it's just a lot more complicated than it needs to be.
Pretend you asked: Why do you say that? To which I answer:
Glad you asked. Lumping everything into one method means you're dealing with all "concerns" together... meaning that if any of the underlying requirements changes you've got to basically "change the whole program".
A "concern" in this context means "anything which impacts the program"... basically the concerns are the sum of the requirements and the known limitations. Basically: The more "concerns" you have when implementing any particular piece of functionality, the deeper the pool, the higher the risk of drowning (i.e. not producing an adequate product).
The "best practice" approach is to try to break-down the problem into it's component parts, and implement each part as-independantly-as-possible. It's called
reducing coupling.
For instance what if I asked you to change your program to give me the option to print the result of the addition to stdout (i.e. System.out) instead of to file? You'd have to make significant changes to your main method, which carries an inherest risk of breaking existing working functionality (i.e. introducing a "regression bug")... But if the "print" functionality was in it's own method, which presents a "well-defined minimal interface" to the rest of the application, then you'd just have to change the "print" method... with basically zero risk of breaking the existing working "add" functionality.
Oh, and I want you to also give me the option to input my number on the command line, so I can use your program more easily from a script. You're rewriting than "whole program" again... Get the point?
The key concept here is "managing complexity". You try to carve up the problem into small "do-able" pieces, and implement them independantly from one-another. This isn't a big issue when you're dealing with relatively simple programs which address relatively simple problems, but as the complexity of the problem ramps up, the more important it is that you design a solution... in fact, clarity and simplicity of the design becomes n^2 important. Human beings will never be smart enough to implement MS-Word in one big main method... so we simply don't try.
So... I second Angry's suggestion to seperate the input phase of the program, from the processing, from the output... this is a really really common (and useful) way to divy-up just about every problem into more-bight-sized chunks.
HTH... and yes I do tend to prattle on... but this is important stuff ;-)
Cheers. Keith.