I was cleaning up some JavaDocs yesterday in a large, multi-project code base. The process was getting tedious so I enlisted the help of my old friend GSR (global search and replace). Since I wanted to update java files, text documents and package HTML files, I opted to use
* as my wildcard rather than, say,
*.java, *.html, *.txt. Boy what a mistake that was.
Everything was going well but then my IDE (Eclipse in this case) starting throwing a fit. I was getting AST creation errors all over the place and it seemed as though the world was caving in. I attempted the old tried-and-true technique of software; I restarted the IDE. No go. Same errors.
I was near the point of panic when I took a look at the IDE’s log. The first thing I see is
java.lang.InternalError and lots of them. Oh crap! I don’t even know what that is, but anything that starts with
java.lang and ends with
Error isn’t good. I scroll to the end of the exception line and see:
invalid LOC header (bad signature). Egad!
To make a painful story short, it turns out that the GSR was doing replacement in JARs as well as text files. This was corrupting the header and
java.util.zip.ZipFile was throwing exceptions to no end. After replacing the JAR files with fresh clean ones all was well.
I want to hand it to the Eclipse people for making the IDE tolerant to the stupidity of the average Joe out there doing his best to muck things up. Sure, I got errors up the wazoo but had I taken a moment to look at what they were really telling me I would have figured out the problem instantly.
Perhaps this should have been titled “When programmers are too smart for their own good!”.