22 Apr 2007
Interesting quote from a recent interview w/ bug fixer Brian Harry.
The quote itself is actually attributed to James Gosling but I like and can appreciate what Brian has added to it.
“The place where you find bugs may not be the right place to put a fix in.”
Simple example of this: Damn, I’m getting a null pointer in this method, better wrap it in a: if (object != null) doSomething;
Sure, you’ve fixed a symptom but very rarely (or perhaps not necessarily) have you addressed the problem.
Another situation: Damn, hashCode() is slow, when I’m calling it 60 million times it’s taking forever. First thought, hashCode() is inefficient, let’s re-write them (maybe they’re using HashCodeBuilder or doing something inefficiently) and save 20%. Perhaps it’d be more worthwhile to look at why your hashCode() is getting invoked 60 million times, address that, and watch the overall time (total operation, not hashCode()) spent fall from 70s to < 2s.
We all love low hanging fruit, but we shouldn’t let it become a barrier to digging deeper.
18 Apr 2007
As mentioned previously, we had a little problem at work with a certificate that prompted us to un-sign and re-sign a significant number of jars.
We didn’t have ant available in all production deployments so my co-workers ant macro was unfortunately not appropriate. If you’re in a situation where ant is available, do check it out.
About the only thing we did have was bash and the JDK/JRE. It doesn’t look like the JDK provides any tools to automate the un-signing process , so we resorted to uncompressing and removing all signatures contained within the META-INF directory.
The only kicker resulted from a jar file (jh.jar from JavaHelp) that contained the same resource in the same package multiple times but with different capitalizations (ie. Foo.gif and foo.gif). When uncompressing on a Windows machine, you’ll loose one of the versions due to NTFS being case-insensitive. This caused a bit of grief and we ended up settling on manually signing a fresh copy of the jar that wasn’t previously signed.
Here’s a snippet of what we hacked together (poorly formatted on the web):
!/bin/bash
for i in `find . -name ‘*.jar’`; do
tmp_file=tmp_$$
# Un-sign jar
mkdir $tmpfile
cd $tmpfile
echo “Scrubbing $i”
jar -xf ../$i
if [ -e META-INF ]; then
if [ -e META-INF/*.SF ]; then rm -f META-INF/*.SF; fi
if [ -e META-INF/*.DSA ]; then rm -f META-INF/*.DSA; fi
if [ -e META-INF/*.RSA ]; then rm -f META-INF/*.RSA; fi
fi
echo “Packaging $i”
jar cfM ../$i .
cd ..
echo “Signing $i”
jarsigner -keystore [keystore] -storepass [password] $i [alias]
rm -rf $tmp_file
echo “”
done
Unlike the ant macro, this script won’t necessarly create a META-INF if it didn’t exist previously. If that causes you grief, you’ll want to add a mkdir META-INF ; touch META-INF/MANIFEST.MF prior to the Packaging stage.
15 Apr 2007
Funny thing happened at work the other day, turns out the Personal Email Certificate we were using to enable SSL communication between client and server expired.
Not a good thing to have happen when you have customers across North America and Europe that are no longer able to run your application.
Fortunately for us, we were able to make quick turnaround and have a minor patch out to customers that involved re-code signing our distribution jars with a proper Verisign certificate and providing an updated keystore containing a new certificate.
The saga of the personal email certificate begain a year or two back. Basically we investigating a requirement to code sign and support SSL encryption between client/server (another related requirement involved providing HTTPS access to the web portion of our application). There’s an interesting blog about using Thawte email certificates to handle all of this. Two bonuses, they’re free and Thawte is an actual certificate authority that does exist in java, your browser, etc. (so none of the typical self-signer popups). We were developing and testing a solution so the Thawte freebie certificate were handy. The problem for us is that, in production, we only addressed usages of the free certificate that were customer visible, notably the code signing (because you still have a Java Webstart popup w/ Thawte Freemailer as the authority).
Fortunately for us, we realized the problem internally before any (or most) customers noticed a problem. Our customer support team was on the ball and let customers know they would need an emergency patch. Development had a patch ready within a couple of hours, and we were good to go. Nice team effort. Rather annoying problem, but a good hands-on approach to ensuring customer satisfaction.
Reminder to everyone, certificates don’t last forever (personal or otherwise) and when they expire, if they’re being used to support important infrastructure, all hell will break lose.