6 Java features a developer should avoid using

The writer is a programmer with years of experience in Java development, and from experience, not all of the Java SE feature/api are worth the programmer to use, such as the 6 listed in this article, we have to be cautious before using. The following is the selected passage of the original text.

Years of Java development experience tells me that in the long run, the following Java SE features/API, developers are best to stop using.

• Reflection
• Bytecode manipulation
• Threadlocals
• Classloaders
• Weak/soft references
• Sockets

1.Reflection

Reflection is reflective, and in many popular libraries there are reflection mechanisms, such as spring and hibernate. By reflecting on the business code, I recommend that you avoid using reflection. Here is a list of reasons why I am against it:

The first involves code readability/tool support. Open the IDE and find interdependencies in Java code. Replace the method call with Relection, and try repeating the step. Things become more and more out of hand, under normal circumstances should be encapsulated and then modify the state. Here's a look at the specific code examples:

 Public classSecret {PrivateString secrecy;  PublicSecret (String secrecy) { This. Secrecy =secrecy; }     PublicString Getsecrecy () {return NULL; }} Public classTestsecrecy { Public Static voidMain (string[] args)throwsException {Secret s=NewSecret ("TOP Secret"); Field F= Secret.class. Getdeclaredfield ("secrecy"); F.setaccessible (true);    System.out.println (F.get (s)); }}

By looking at the above code, it is known that the Method Getdeclaredfield () parameter can be found only at run time. And you know that the bugs that are generated at runtime are always more tricky than not executing scripts.

Second, the reflection call optimization is performed by the JIT, some optimizations can take a long time to get applied, and some optimizations are not even applied, so performance optimizations about reflection can sometimes be quantitative. But in a typical business application-you might not really be aware of these performance costs.

In short, developers should use AOP to properly reflect on the business layer, and in addition, you'd better leave it far away.

2.Bytecode manipulation.

Bytecode manipulation, if I see you using Cglib or ASM directly in a Java EE application, I might run away immediately.

The worst thing to do is to have no executable code during compilation. In fact, when the product is running, you don't know which piece of code is running at all. So, when you're in trouble, it's natural to throw the error at runtime troubleshooting and debugging, but it's more cumbersome.

3.ThreadLocals

There are two unrelated reasons why I tremble when I see threadlocals in the Business layer code. First, in Threadlocals's help, you may see that many variables are not being used explicitly down through the method call chain. This is useful in some situations, but when you are careless, you will build many unexpected dependencies in your code.

The second unrelated reason is related to my daily work, and storing data in threadlocals will cause a memory leak. At least one-tenth of the PermGen leaks I encountered were caused by the use of threadlocals, and after the combination of the ClassLoader and the thread pool, the "Java.lang.OutOfMemoryError:Permgen space" exception might appear immediately.

4.Classloaders

First, the ClassLoader is a complex beast. You must first understand its hierarchy, the delegation mechanism, the class cache, and so on. Even if you think you have mastered it, it may still not work properly. will eventually cause a class loader to leak the problem. So I can only recommend that you leave this task to the application server for processing

5.weak/soft references

Now, you should better understand the internal methods of Java. It is unwise to rewrite all the caches with soft references. I know that when you hold a hammer in your hand, you look for nails everywhere. But the cache is not a good nail for a hammer. Why? Building a cache based on soft references can be a good example of how to delegate some complex factors to a GC instead of implementing it by itself.

Here's a cache example where you use a soft reference to create the data, and when the memory is exhausted, the GC enters and cleans. However, the objects that are deleted in the cache are not under your control and are likely to be recreated in the next Cache-miss. If the memory is still insufficient, you can trigger the GC to clean up again. You may have seen the vicious cycle of the entire operation, and the entire application becomes the CPU and GC running state.

6.Sockets

The usual old-fashioned java.net.Socket is so complicated that it's hard to get it right. I think blocking is a fundamental flaw. When you write a typical Java EE application with a web front end, the application needs a high degree of concurrency to support a large number of users, and the last thing you want to do now is not to have an extensible thread pool waiting to block sockets.

There are many third-party libraries available that can be used to better accomplish tasks, such as Netty, and developers may wish to try them out.

http://www.iteye.com/news/28388

Http://www.infoq.com/cn/news/2013/11/six-java-features-to-avoid

6 Java features that developers should avoid (go)