The major difference being that the problems with the JDC Tech Tips example code are higher-level, and not so easily detected by static analysis.
The quality of code in the JDC Tech Tips is usually pretty low, as if no-one realizes or cares that it will be copy and pasted into projects the world over. The
GridBagSamplecode, though, was impressively dense. Everything about it says "don't do this".
The best bit is that there's no clear way of fixing the immediate problems with the code (follow the link and look at it to see what I mean), because the whole approach is wrong.
GridBagLayout? It might be okay for a computer, but it's not suitable for human consumption.
The other tip in the same mail, "Updating Jar Files", is also pretty ugly. The code isn't that bad, if you ignore all the exception handling. But you can't ignore the exception handling: there's so much of it. The real code is completely drowned out by it.
IOExceptiona checked exception and offering
finallyclauses was not a good replacement for C++ destructors or Smalltalk blocks. No language since C does file handling with as little grace as Java. File handling is definitely Java's most monstrous carbuncle.
The question I have is this: wouldn't JDC Tech Tips be more useful if there were actually some technical tips, rather than short examples of using random bits of API – which would surely be better included in the JavaDoc itself, preferably with some new JavaDoc mechanism for actually extracting and running these examples (because nothing suffers from code rot like example code in comments) – and wouldn't it be a better idea to showcase good solutions to problems rather than just hack something together?