How can we protect Java from reverse engineering attacks?

You can see in this article: http://www.bkjia.com/Article/201208/146262.html

To address the cause of Java being vulnerable to reverse engineering attacks, I will introduce the centralized measures on the market to prevent Java from reverse engineering attacks, it also points out the shortcomings of these measures in preventing reverse engineering attacks. The first is the onboard measure, which is not enough to prevent reverse engineering. Most virtual machines contain features that complicate reverse engineering. Java allows you to set a digital certificate for each class provided in the JAR archive to ensure that the original file is not changed. Although this is harmless, it is quite easy to clear and only protects static patching methods. Static patching is only a small part of attack scenarios. In addition, this method does not provide protection for the patches that are applied to the memory at runtime. Java also runs the bytecode validators through virtual machines. The validators automatically analyze the bytecode that passes execution. This prevents execution of "weird" code and makes bytecode injection more difficult. However, although these measures pose difficulties for attackers, they are far from adequate protection of intellectual property rights. The second is Java encapsulation technology. One method that developers usually use to Prevent Static Analysis of. class files and bytecode disassembly is encapsulation. This method prevents Analysis of class files by encrypting/decrypting the complete file. Through encapsulation, developers replace the original loaders of protected files with custom loaders that process encryption/decryption. Encryption uses algorithms that change. class files from standard Java. class format to only "key" Owner readable format to prevent analysis of these files. However, the bytecode of the. class file remains readable in a memory location and can be accessed from this location at any time before the system loader attempts to load the class. If hackers can find the memory location, they can access the class in the original state. Finally, the second technique is required to prevent hackers from attacking the memory location, which is called obfuscation. Obfuscation can generate a code version that is more complex, difficult to understand, and has the same behavior as the original code. There are several different types of obfuscation methods available for instruction sets: programmers can confuse code by replacing all the strings in the binary code, making it even harder to find a good starting point to start reverse engineering attacks. They can confuse attackers by inserting a jump pointing to the spam code and returning the code, or obfuscation of source code or bytecode. Developers can also use the technology named Const2Code conversion to confuse constants. For example, keys are sometimes stored as a group of bytes in an application. If hackers determine the location of these bytes, they can access these bytes. To confuse a constant (such as a key), The Const2Code algorithm converts a constant to multiple different commands that generate the same constant. For example, to hide the constant cst = 0x12345678 in the source code segment, you can simply divide the constant into several arithmetic operations, such as addition and subtraction. A = 0x9ABCDF00; B = 0x2; C = 0x135799E00. Now let's use these three variables to recalculate the constant 0x12345678. Our original constant is: cst = C/B + A-0x88888888-A + 1000 = 0x12345678. If an application only uses this routine to calculate a constant, attackers must understand the meaning, rather than simply obtaining the constant.