Tuesday, February 24, 2009
Burk In Books: 97 Things Every Software Architect Should Know
Windows XP running slower than usual
This morning I was running a build that normally takes about seven minutes, but when I checked on it - expecting to see everything had compiled properly - I found it had hardly begun. What the...? So I pulled up the Windows Task Manager, I saw that instead of using 20 to 50% of the CPU, the java.exe (we use ant so it shows up as java.exe and not javac.exe) process was putting along at single digits with an occasional sprint up to 16%.
Looking at the list of running Processes, I noticed a few I didn't recognize. Since this is a company box, I wasn't too surprised but I figured I'd do a little research on what was out there. As it turns out, I hit a homer with the first thing I looked up - a little beastie named cidaemon.exe.
Turns out it's used by an Indexing service from our friends at Microsoft and it had somehow gotten turned on. When I Googled the name I found this page on Microsoft's Help and Support site which told me how to turn it off. I followed the instructions and suddenly java.exe was back to it's normal (relatively) speedy self.
If you're seeing a similar problem on your XP box, bring up the Task Manager, click on the Processes tab and look for something called "cidaemon.exe" under the Image Name column. Note: If the items aren't in alphabetical order you can click on the Image Names label and they will be.
If cidaemon.exe is out there don't just click the End Process button to kill it, or the next time you reboot it will be back. Instead follow these instructions from Microsoft and you'll be set.
That's all for now, I've got some code to write.
Friday, February 13, 2009
I'm speaking at ITARC 2009!
Thursday, February 12, 2009
Mini Java Puzzler
I was working on a project and needed to get a Long value from a String. I know the Long class (like the other wrapper classes for primitives) has static methods that do just the thing , so I started typing in my IDE and trusted that I’d find one that worked. As it turns out there are several methods that do similar conversions. Here’s a list of the candidates:
Long.decode(String nm)
Long.getLong(String nm)
Long.parseLong(String nm)
Long.valueOf(String nm)
So, given that each of these takes a String and returns a Long, what does the following code return? (Notice that the getLongValue() method returns a primitive long:
public long getLongValue() {
Long value = Long.getLong("23");
return value.longValue();
}
Here’s the list of possible answers:
A) 23L
B) 0L (zero)
C) It depends.
Before you continue reading, what do you think the right answer is… OK, that’s enough thinking. Let’s take a look at the possible answers and see what seems likely.
Now it seems reasonable that Long’s getLong() method should return the value of the String as a Long, so answer ‘A’ looks pretty good. Then again, if it were that easy why would I bother posting this. Answer ‘B’ doesn’t seem very reasonable - unless getLong() isn’t really converting the value of the String. So that leaves answer ‘C’ as the primary suspect. If you’re familiar with Josh Bloch’s Java Puzzler talks from JavaOne, you’ll probably go with ‘C’ because it is kind of vague and that makes it a safe bet.
And you’d be right. The correct answer is ‘C’.
It turns out that Long.getLong() doesn’t try to convert the value of the passed in String directly. It looks for a System property with that name, retrieves the value associated with it, and converts that. So what the getLongValue() method returns depends on the value of the System property “23″. So, what if there is no System property “23″? In that case, the method throws a null pointer exception because Long.getLong() will return a null. Ouch!
I found this the hard way. I needed to convert a String and picked a likely method from the list provided by my IDE. I was greatly surprised when my unit test failed, so I looked up the JavaDoc on it and realized my mistake.
There are a few morals to this story:
Unit tests are your friends.
Use the JavaDoc, and make sure you write some
for people using your code.
Hurrying can cause unexpected delays; but those
can become fodder for a blog post.
Until next time, I leave you with the traditional Java Puzzler farewell,
“Don’t code like my brother.”