The other day I did an SVN update on my project. All of the sudden, this one piece of code wouldn't compile. I think it's probably OK to show this 1 line of code.
Anyway, the bit that was barking at me was
javax.xml.XMLConstants.W3C_XML_SCHEMA_NS_URI.I asked a colleague where this lives. In rt.jar, he says. Waa? OK. It's in the JDK. I looked around in rt.jar. Yep. It's there. Why the hell isn't it compiling then?
Hmm. Here's the answer.
Project | Properties | Java Build Path | Order and Export
There was a jar in our project (which wasn't being used any longer) called jsr173_1.0_api.jar. That jar contains a class in the javax.xml package called XMLConstants just like in RT.jar. Only this copy did not have
javax.xml.XMLConstants.W3C_XML_SCHEMA_NS_URI. But, why does that affect whether it compiles or not? The jar without the class was listed higher in the classpath order. We didn't notice the problem before the JDK was previoulsy higher in the classpath order. Someone had re-ordered it on the last commit. Ugh. But, I'm glad they did it.It was an easy fix for us. We were able to simply remove the unused jar from our project and the problem was gone. But, what if we couldn't remove it? Hmm. You can cheat, at least in the IDE. Though I'm sure that might have caused deployment issues. You can re-order the classpath by moving a class up or down in the list. Just click the jar in question and move it below the JDK entry. Voila, it compiles.
Be careful out there. It's a weird classpath world.
No comments:
Post a Comment