Streams in java - theoretical points

This is kind of a strange question.  I don't really need a solution, as I've already found one, but I'd like to know some theory behind WHY the solution I've come with works.

A bit of background.  I had an assignment for a programming class that involved graphs.  My professor wrote a program to produce random graphs, that were represented as an n by n matrix, where n is the number of vertices in the graph.  We were to use his program to produce a large number of graphs, and then comment of the degree of connectivity of the vertices, and draw some fairly general conclusions.

Not wanting to do more work than I had to, I tried to write a program automate running his program, to produce the random graphs.  The way his program works is that there's a menu, the user chooses an option, then the program asks the user questions accordingly.  So I used Runtime.exec(), and treated the input and output streams.  All worked well for the choice from the menu, and for the initial questions, but at one point, his program threw a NullPointerException, because it was interpreting its input from my program as being null.  I looked at his code, and realized that it was because, at the point where the NullPointerException was thrown, he was calling a new method to get input.  In the new method, he created a NEW BufferedReader with, instead of passing the method the current BufferedReader from the main method.

Is everyone following so far?  So I modified his code, so that the main passed its BufferedReader to the second method, and all worked well.

My question is, why did that work? is still, no?  So why, if he made a new BufferedReader with, would it cease to read from the input that I'd already sent it?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

HMmm. I'm not sure, of course. But here is a possible explanation.

Assuming the "first" input was also using BufferedReader, it would be "reading ahead" to get as much input as it could (that's what BufferedReaders are for).

In the case where the program is run manually, that would not make any difference. There was no more input, the first BufferedReader couldn't get anymore. The new one gets created, and *then* the user adds input, and so it goes to the new BufferedReader.

However, in the case where you are running it from another program, it may be that the input provided from the controlling program in fact *is* available while the first BufferedReader is still sucking at the system input stream, and so the first one would get it.
By the time the second BufferedReader is created, there is nothing left for it, and a problem ensues.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
blackwednesdayAuthor Commented:
Ah, so the input that has already been caught isn't in anymore, but in the first BufferedReader?

That makes perfect sense.  I'm amazed that I thought of the solution as quickly as I did, considering I didn't really understand it.

So, another question: is it poor programming to use 2 BufferedReaders like that, or is there a real reason to do it?  I would say that maybe my professor did it on purpose, so that we couldn't write a script to run his program more quickly (I wouldn't put it past him to be sadistic like that), but I think he's too lazy to think of it.  Plus, he gave us the source, which is  why I was able to modify it.  He could have just given us the compiled class.

To other experts:  please answer this question if you will, but understand that I like imladris' answer, so unless someone points out to me that it's completely wrong, he's getting the points.
Yes, it is poor programming to use 2 bufferedreaders to read from the same inputstream here. but it might be excuaseable because of other factors.
     Could there be situations where we wanted the inputstreams to be different (read from until GUI is set up, then read from GUI).
Not knowing what he had in mind as 'possible future expansions' it is not possible to give a clear yes/no.

But it is probably just because he reused some old code modules without really considering its functionality.
Amazon Web Services

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

better yet... ask the professor :)
I do not think that using 2 BufferedReaders on the same stream  is excusable. Think about it for a while .... now why would you  want to create a new object to carry on with the same thing it has been doing for the past who nows how long. Ok I know we have alot of memory and all but hey Java isn't exactly cheap on the stuff. So the saying goes "Share and share alike" rather have two methods/threads/objects whatever have access to a single resource or stream by means of the same object (That would depend on the type of resource though) rather than create a new object and continue reading where the other has left off.

imladris' solution with the BufferedReader is in fact correct. If you would have liked that code of your professor to work other than passing it the already used BufferdReader you would have to close the old reader before the system enteres the method in which the second BufferedReader is used. That will cause the firsts BufferedReader to roll back it's reading to such a state that the buffered data that has not yet been read by the program will still be available to the second BufferedReader.
The key point is "the same thing". If it really is the same thing then yes. but if the second reader could be taking its data from some other input device it should be distinct.
blackwednesdayAuthor Commented:
Well, yes, having 2 BufferedReaders to read from 2 input devices is necessary.  In this case, though, I think my prof was just lazy  and didn't bother reading over his code to make sure what he was doing made sense (you should see his assignments and exam questions... we just had the final, and there was a question with a class called Person, with a constructor that looked like:
public Poodle(){}
Obviously, he just can't be bothrered.)

Yeah, that is typcal sloppy reuse of code. ( I know, cause I do it myself :-))
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.