Wow, where to begin?
Oooh, a topic for me. To add to your list:
1. Converting from byte[] to String without specifying the encoding. Good trap for young players this - 7-bit bytes work fine until... until... you run on an OS/390 box running EBCDIC.
2. java.nio. An absolute dogs breakfast this. Garbage collection is different on Windows or UNIX (to be fair this is due to differences in the underlying file system model, but Java should be abstracting this). If you're copying files to an SMB mounted drive on windows using nio, the maximum block size is 62MB. The maximum number of open files on Sun/Windows 1.4 is much smaller than it should be. The list goes on.
3. Swing. Yes, this should be obvious, but it's not just a case of different layouts, it's different functionality too. I give you JComboBox.setPrototypeDisplayValue, which does not work as advertised on Windows. And don't even start me on the GTK+ widgets. Any moderately complex, well designed UI really has to include different code for different LayoutManagers.
4. Memory requirements. Back in the bad old days on JDK 1.4 we found simply switching JVM from Sun to IBM on Linux raised memory requirements by 50%. Again, less of an issue now but still crops up now and again.
5. JVM bugs. Goes without saying I suppose. The IBM 1.3 JVM was big trouble, but even though it's much better now we still hit a few. We have IBM, Sun, JRockit and Apple JVMs here and find ourselves needing to test on all of them more than I'd like.
6. Security. Different JCE Providers supply different algorithms, different root certificates and have differing support for X.509 Certificate extensions. This is a definite issue for us, although things are much better than they were with Java 1.4.
7. Locales. A variation on point 2, but the number of questions we've had when a client has moved from staging to production and found all their ISO-8859-1 characters are now mapping to some Windows codepage are now legion.
That's off the top of my head, that's just J2SE, and that's ignoring the obvious no-no's like calling the com.sun packages directly.
Obviously things are a lot better than coding in C, but I can guarantee that if you're developing for multiple customer environments, any form of I/O to disk, screen or network is a potential problem.