经验告诉我们，并不是所有的Java SE功能/API都值得程序员去使用，本文就这一问题作出了讨论，希望大家在软件开发过程中慎重使用。
1.Reflection

Reflection即反射，在许多流行的库里面都有反射机制，比如Spring和Hibernate。通过对业务代码进行反思，建议大家避免使用反射。下面列出反对使用的原因：

首先涉及到代码可读性/工具支持。打开IDE并且在Java代码里找到相互依赖关系。使用relection替换方法调用，并且试着重复该步骤。事情变的愈发不可收拾，正常情况下都应该封装好了再修改状态。下面来看看具体代码示例：

通过查看以上代码可以得知，方法getDeclaredField()参数只有在运行时才可以被发现。而你也清楚，运行时产生的bug总比不执行脚本要更加棘手。

其次，反射调用优化是由JIT执行的，一些优化可能需要花费很长时间才能得到应用，而有些优化甚至都得不到应用，所以关于反射的性能优化有时会被数量化。但在一个典型的业务应用程序中——你可能不会真正意识到这些性能开销。

总之，开发者应该通过AOP合理地在业务层使用反射，除此以外，你最好离它远远的。

2.Bytecode manipulation.

字节码操作，如果在Java EE应用程序里直接使用CGLIB或ASM，这是不可取的。

最糟糕的事情莫过于在编译期间没有任何可执行的代码。实际上，当产品在运行时，你根本不知道哪块代码在运行。所以，当你遇到麻烦时，会自然地把错误抛给运行时故障排除和调试，不过这样反而会更麻烦。

3.ThreadLocals

这里有两个不相关的原因。首先，在ThreadLocals的帮助里，你可能会看到许多变量的使用都没有通过方法调用链来明确地向下传递。这在某些场合下是有用的，但当你一旦粗心，你会在代码里构建许多意料不到的依赖关系。

第二个不相关原因，在ThreadLocals里存储数据容易引发内存泄露。在结合了类加载器和线程池后，“java.lang.OutOfMemoryError:Permgen space”异常可能就马上出现了。

4.Classloaders

首先，类加载器是一个复杂的野兽。你必须先了解它的层次结构、委托机制、类缓存等等。即使你认为自己已经掌握了，它可能还是不能正常工作。最终将导致一个类加载器泄露问题。因此我只能建议你将这个任务留给应用服务器处理

5.Weak/Soft references

现在，你应该更好的理解Java的内部方法。使用软引用来重写所有的缓存并不明智。如当你手上拿着锤子的时候，就会到处寻找钉子。可对于锤子来说，缓存并不是个好钉子。为什么？基于软引用构建缓存可能是如何委托一些复杂因素到GC而不是通过自身实现的一个好例子。

下面举个缓存的例子，你使用软引用来创建数据，当内存被耗尽时，GC进入并且进行清理。但是，缓存中被删除的对象并未得到你的控制，而且很有可能在下一次的cache-miss中重新创建。如果内存仍然不足，你可以触发GC进行再次清理。你可能已经看出了整个运行过程的恶性循环，整个应用程序就变成了CPU与GC不断运行的状态了

6.Sockets

普通老式的java.net.Socket实在是太复杂，以至于很难弄正确。作者觉得阻塞性是其根本性的缺陷。当你编写一个典型的带有Web前端的Java EE应用程序时，应用程序需要高并发度来支持大量的用户，而你现在最不想发生的是不具有可扩展的线程池坐等阻塞套接字。