0、遍历结果集并构造对象
如果你是个时髦的开发者而不是专业人员，显然你从某篇博客中读过有开发者遇到Hibernate的“性能问题”，因而认为ORM都不好，觉得手动编码“明显更好”。喜欢的话你当然可以用JDBCTemplate之类，但是谢谢你的对它们的无端指责，我还会继续用我的JPA/Hibernate。
如果你是个时髦的开发者而不是专业人员，显然你从某篇博客中读过有开发者遇到Hibernate的“性能问题”，因而认为ORM都不好，觉得手动编码“明显更好”。喜欢的话你当然可以用JDBCTemplate之类，但是谢谢你的对它们的无端指责，我还会继续用我的JPA/Hibernate。
1、 在交易型系统中写PL/SQL
随着时间推移，你系统中的业务逻辑会被逐步迁移到关系数据库中，所有宝贵的设备交易都会迁移到数据库中去。有的人将它们转换为类似COBOL的处理方式，绑定到调用物化视图的触发器中。通过他们调用其它扁平化版本。简而言之，很快你会拥有一个极其难以控制的遗留系统。这对Oracle的投资者而言是好事，但对我们则不然。
2、编写，调试甚至真正使用Swing应用程序
许多年来我一直觉得自己在GUI代码方面相当差劲，甚至根本不该去碰前端的东西。Java看起来根本不应该和前端有什么关联，Swing效率很低。没错，如果你是开发NetBeans的前Sun员工，又不用担心浏览器，而且还有一堆内存空间可以尽情使用的话，确实可以写出很快的Swing代码来。否则Swing的确很慢。默认情况下Swing弄出一堆跟原生GUI动画一样的图形界面来，让人不爽。此外还有Java的沙箱模型。
3、强制类型转换
Java泛型并不完美,甚至不是我所首选的 解决方案，有时总会有些边界情况使得泛型无法有效处理。例如，我实在不想再这么做:
不幸的是，总有些库没有及时更新，而且遗留代码总是存在。我们只好自作自受，乖乖多写些测试用例、使用 泛型。
4、用Calendar或Date来做日期计算
用JDK中的Date和Calendar来做复杂的日期和时间计算简直就是浪费生命。内建的类仅仅支持最基本的操作，而且一点也不直观。我们还是用JODA Time这样的先进库来代替吧，除非您还在用x86编译器来写Web应用，因为除此之外你也享受不到用JDK的Date和Calendar之类带来的乐趣。
5、配置会话（Session）复制
2000年早就过去了，现在所有分布式缓存产品和项目都已用NoSQL的键值对存储方式重构过了。如果需要带状态的客户端，那就用AJAX/Javascript好了，把HttpSession丢一边去吧，这样的话可以大大提高应用程序的可靠性和可扩展性。我们也就不用因为隐藏在深处的一连串异常爆发而半夜起来一路颠簸了。可别误会了，半夜颠簸挺好的，至少我老婆因此买了辆小货车(虽然我更喜欢我那辆Ninja 650机车)，不过老实说，是时候换成更好、更快、更聪明的东西了。
6、自己写排序算法
这是最让人厌恶的，我个人对排序算法并不留意。写排序代码的人要么是不知道Java已经提供了你所需的排序算法(或者自己写了个排序的第三方库文件)，要么根本不知道Comparable和Comparator如何工作。赶紧去补充一下功课，以后再也不要自己写排序自寻烦恼了。
7、自己写链表,栈,队列等
必须承认，写个基本的链表挺容易。Wikipedia有个关于链表的不错的页面(网页链接)，上面有含代码的内容，完全可以直接复制粘贴，不过何苦要这么做？也许我是挺懒的，不过我更愿意用一个已经通过测试的数据结构，而我也是花过不少功夫才决定这么做的。
8、自己写池，集合或通用的并发代码
认识Doug Lea大师。崇拜大师，那就支持大师的java.util.concurrent包吧。大师可不是凡人，人家可的以高度并行，因此您想得到的并发问题对策，大师也早已想到。
9、处理日志框架
你用什么词来形容Commons logging、SLF4J之类？答案是：烂！几年前Sun不肯简单地把Log4J的接口引入JDK就导致了这个问题，Oracle倒是可以把java.util.logging做得好点。我宁可大家都用java.util.logging这个烂标准，也不要有人搞出个伟大的其他日志候选项。这就像有人进行下面的对话：
“我有可口可乐”
“喝百事怎么样？”
“管它呢，反正喝了都胖，有什么区别？