During a recent code review session, I was struck by the diverse approaches to writing code in our team. It became clear that maintaining consistent coding standards remains an ongoing challenge.
Today, let's explore some advanced Java techniques that can make your code perplexing to colleagues. Mastering these techniques will give your code an aura of mystery that will keep your team members guessing.
Unicode Deception
You might be surprised to learn that some developers hide executable code within comments. Consider this simple example with just a single line in the main method:
public static void main(String[] args) {
// \u000d System.out.println("Secret message");
}
What do you think the output of this program will be? Surprisingly, it prints:
Secret message
Are you puzzled why the code in the comment gets executed? The secret lies in Unicode encoding. The \u000d is a Unicode escape sequence representing a line break. Java's compiler processes these escape sequences and replaces them with their corresponding characters before compilation. So the code is actually interpreted as:
public static void main(String[] args) {
//
System.out.println("Secret message");
}
This explains why the statement in the comment gets executed. For an even more sophisticated approach, consider this example:
public static void main(String[] args) {
int counter = 1;
// \u000d \u0063\u006f\u0075\u006e\u0074\u0065\u0072\u002b\u002b\u003b
System.out.println(counter);
}
This will print 2 because the Unicode escape sequences translate to counter++;.
This technique can be useful for obscuring code that you want to hide from casual viewers. Many have seen this joke:
Image
If a client with some coding knowledge sees this, they'll immediately recognize the Thread.sleep() call. However, if you write it like this, most would assume it's just gibberish:
//\u000d\u0054\u0068\u0072\u0065\u0061\u0064\u002e\u0073\u006c\u0065\u0065\u0070\u0028\u0032\u0030\u0030\u0030\u0029\u003b
Without decades of experience, few would recognize this as a sleep command.
Overcomplication
A key technique for writing confusing code is to simplify simple things. For example, when determining if an integer is positive or negative, you could write:
public void checkValue(int number){
if (number > 0){
// positive logic
} else if (number < 0){
// negative logic
}
}
But why use straightforward code when you can make it more complex? Consider this alternative:
public void checkValueAdvanced(int number){
if (number>>>31 == 0){
// positive logic
} else if (number>>>31 == 1){
// negative logic
}
}
This approach immediately elevates the complexity of your code. Colleagues will need time to decipher what this code actually does.
The principle here involves the unsigned right shift operator (>>>). For example, with -3, we first convert to its two's complement representation:
11111111111111111111111111111101
After an unsigned right shift by 31 bits, it becomes:
01111111111111111111111111111110
This decimal value is 2147483646. When an int value is unsigned right-shifted by 31 bits, the 31 high bits become 0, leaving only the original sign bit in the lowest position. This allows us to determine the sign of the number.
Using this knowledge, we can define constants in unconventional ways. For instance, instead of using 0 directly:
int ZERO = Integer.MAX_VALUE>>31>>1;
As you can understand, shifting a number right by 32 bits results in all binary bits being 0. Why not use Integer.MAX_VALUE>>32 directly? The reason is that when performing shift operations on int values, Java takes the right operand modulo 32. Writing 32 would be equivalent to no shift at all, leaving the original value unchanged.
Truth Reversal
Throughout history, people have manipulated perceptions. In programming, you can create confusion by making conditional logic behave counterintuitively. Consider this code - would anyone believe it prints "false"?
public class RealityTest {
public static void main(String[] args) {
Boolean reality = true;
if(reality) {
System.out.println("true");
} else {
System.out.println("false");
}
}
}
No one familiar with Boolean types would expect this to print "false". However, with the following modification, it becomes possible:
First, insert this code in an inconspicuous location within your class:
static {
try {
Field trueField = Boolean.class.getDeclaredField("TRUE");
trueField.setAccessible(true);
Field modifiersField = Field.class.getDeclaredField("modifiers");
modifiersField.setAccessible(true);
modifiersField.setInt(trueField, trueField.getModifiers() & ~Modifier.FINAL);
trueField.set(null, false);
} catch(IllegalAccessException | NoSuchFieldException e) {
e.printStackTrace();
}
}
When you run the previous program, you'll be surprised to see it prints "false".
The principle is simple. First, use reflection to access the TRUE variable defined in the Boolean class:
public static final Boolean TRUE = new Boolean(true);
Then, use reflection to remove its final modifier and set its value to false. When subsequently using true to define Boolean variables, automatic boxing occurs, calling the following method:
public static Boolean valueOf(boolean b) {
return (b ? TRUE : FALSE);
}
At this point, b is true, but TRUE is actually false, so the first expression isn't satisfied, and the method returns false.
This explains the printing behavior. However, be cautious when using this technique - hide it well in your code, or you might face serious consequences...
Logic Division
The next technique is quite powerful: it allows you to transform sequential logic into different branches of conditional statements while ensuring proper execution.
Here's a question: is there a way to make both the if and else blocks execute in a single method call, like in this example:
public static void evaluate(String parameter){
if (/* condition */){
System.out.println("step one");
} else {
System.out.println("step two");
}
}
Under the constraint of calling the method only once, it seems impossible because it violates fundamental principles of conditional logic in Java.
However, with a slight modification to the condition, we can achieve this functionality. Consider the modified code:
public class ConditionTest {
public static void main(String[] args) {
evaluate("Hydra");
}
public static void evaluate(String param){
if (param == null ||
new ConditionTest(){{ ConditionTest.check(null); }}.equals("Hydra")){
System.out.println("step one");
} else {
System.out.println("step two");
}
}
}
After running, the console prints:
step one
step two
Surprising, isn't it? The secret lies in the if condition.
When the evaluate() method is first called, the first condition of the OR operation isn't satisfied, so the second condition is executed. This triggers the instance initializer block of the anonymous inner class, wich calls evaluate() again. This time, the if condition is satisfied, executing the first print statement.
The newly instantiated object doesn't satisfy the condition in the equals() method, so neither condition in the if statement is met, causing the else block to execute, printing the second statement.
This achieves the appearance of calling the method once while executing both the if and else blocks. Use this technique to split a single logical flow into confusing branches for your colleagues.
Memory Manipulation
In the programming world, there's often a hierarchy where lower-level language developers look down on those using higher-level languages. For example, C programmers might look down on Java programmmers because of direct memory manipulation. Let's pretend to be C programmers and manipulate memory directly in Java.
To do this, we'll use Java's Unsafe class. As its name suggests, this class can be unsafe if used improperly, which is why obtaining an instance is tricky and requires reflection:
Field unsafeField = Unsafe.class.getDeclaredField("theUnsafe");
unsafeField.setAccessible(true);
Unsafe unsafe =(Unsafe) unsafeField.get(null);
Once we have this object, we can manipulate memory at will. For example, when implementing a simple assignment like int a=1;, we can take a more complex approach:
void memoryDemo(){
long address = unsafe.allocateMemory(4);
unsafe.putInt(address,1);
int a = unsafe.getInt(address);
System.out.println(a);
unsafe.freeMemory(address);
}
After allocating 4 bytes of memory using allocateMemory, we write the value 1 using putInt, then read an int-sized variable from this address, effectively assigning 1 to a.
There are more advanced applications as well. Here are two examples:
void memoryFillDemo(){
long address = unsafe.allocateMemory(4);
unsafe.setMemory(address,4, (byte) 1);
System.out.println(unsafe.getInt(address));
unsafe.freeMemory(address);
}
In this code, setMemory writes the byte value 1 to each byte. When we call getInt, it reads all 4 bytes as a single int value, resulting in 16843009, which in binary is:
00000001 00000001 00000001 00000001
Memory copying in C style is also straightforward with Unsafe:
void memoryCopyDemo(){
long address = unsafe.allocateMemory(4);
long address2 = unsafe.reallocateMemory(address, 4 * 2);
unsafe.putInt(address, 1);
for (int i = 0; i < 2; i++) {
unsafe.copyMemory(address, address2 + 4*i, 4);
}
System.out.println(unsafe.getInt(address));
System.out.println(unsafe.getLong(address2));
unsafe.freeMemory(address);
unsafe.freeMemory(address2);
}
This code reallocates 8 bytes of memory space and copies the original 4-byte memory space twice into the new memory space. The code will print:
1
4294967297
This is because the new 8-byte memory space contains the binary representation:
100000000000000000000000000000001
In addition to direct memory manipulation, Unsafe also provides functionality for thread scheduling, object manipulation, and CAS operations.