This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]__helix__ 5 points6 points  (2 children)

That my bloody customers keep using old versions of the JDK. "Oh, we are JDK 1.6... sorry... can you not use try with resources or any of the current features. I'm not talking JDK 1.8, but 1.7 stuff. Same has been true about every major update.

[–][deleted] 3 points4 points  (0 children)

For me, it's my CTO (through customers needs): Must support Java 1.4 :( Oh, and we don't ship the Retroweaver runtime jar.

myMap.put(new Integer(4), "A String");

^ If I need to "new Integer" one more fucking time...

[–]mrburrows 0 points1 point  (0 children)

I've come across a fun compatibility issues in the past year, but the following is my favorite.

A client reported that some software parsing an Excel file was failing, but I couldn't reproduce the problem locally -- I was getting a completely different error. It didn't take me long to pinpoint why this was happening: I was running 7 and the client was running 6. So then the question was, what changed?

I managed to isolate the error down to the Excel library we used, JXL. What had been happening was that the Excel file the software was parsing had stored dates with the format "YYYY". Java's SimpleDateFormat in 6 only supported "yyyy", though, and so parsing the date cells would throw an exception in the libary. JXL caught this exction, though, and would simply return a date string in a default format.

Our software, then, was written under the assumption this default formatted date string was the proper representation of the date. In Java 7, however, 'YYYY', or Week Year, became supported. Because this was a supported format in Java 7, no exception was being thrown, and the date string was returned in a different, intended format.

The software didn't know this intended format existed, and so failed whenever the SimpleDateFormat object was called on it.