Weird Issue in Getting Mac Address

I'm using Eclipse in Windows 7, 64-bit. I have some pretty standard code that does this:

BufferedInputStream bi;

try {
// WINDOWS VERSION
if (System.getProperty("os.name", "Windows").startsWith("Windows")) {

bi = new BufferedInputStream(Runtime.getRuntime().exec("ipc onfig -all").getInputStream());
bi.read(buff);
String ipConfig = new String(buff);

....etc. (I go into the String and get the "Physical Address" strings.)

When I step through this code line-by-line in debug mode, it works fine and gets the Mac address.

When I run it in non-debug mode (i.e., without stepping through) it only manages to get these first two lines of the complete ipconfig:

Windows IP Configuration

Host Name . . . . . . . . . . . . : Robo

So, I can't get my machine's Mac address with this code. It's very strange. Why does the code work when stepping through but not in a regular run?

Can anyone give me any help?

I must find a way to convert buffering questions into money... That's not begging, I'm not that desperate - yet :D

You're reading a *buffered* stream. Something puts data into the buffer and you take it out. The rates are different. When you step through, the thing putting data into the stream has plenty of time to finish filling it up. When you run it without pausing, you say "OK, here's the buffer, start fillin...I-read-it-all-NOW!", and you only get the little bit the source has managed to put into the buffer.

You either need to poll the buffer, wait for an agreed 'END OF TRANSMISSION' token, or use a class that does exactly what you need - like BufferedReader and its readLine() method.

Thanks, Sean4u. That's a great lesson on buffering. I'll give it a try and post back with the results...

Lol I thanked for my friend.. I was trying to explain buffered streams and he didn't get it. Now he does, Thanks!

Yes, it works, thanks again.

I don't know how to poll a buffer so I used BufferedReader.readLine(). Works like a charm!

By the way, my co-worker says that the original (flawed) code used to work on some slower machines. My machine has an i5 chip - pretty fast. Perhaps this chip's speed has caused the issue to show up?

Anyway, thanks again!

Quote:

---

the original (flawed) code used to work on some slower machines

---

Haha that's nice to hear. It could be anything - perhaps even multi-threading (a change in your JVM?) or multi-processing - allowing the starting context to resume faster / earlier than it once did. I'm glad you got it working.