I found the following construction in legacy java bytecode while trying to troubleshoot server application startup. My IDE decompiled some third party libraries and I'm curious how this can be valid - never saw before keywords can be used as field names in bytecode.
Bytecode version is 48.0 (Java 1.4).
public final class f implements UserContext{
private final String try;
private final UserInfo do;
// a lot of code here
public UserInfo getUserInfo(){
return this.do;
}
public String getViewName(){
return this.try;
}
}
Seems like the library was compiled using some obfuscation features, but how can it be on JVM level? Is it permissible without special flags on JVM startup?
UPDATE : the correct getter name for UserInfo field is getUserInfo -- sorry for confusing everyone with ambiguous naming for methods with different return values, it's a copy-paste issue as code is located on a remote machine w/o direct access to the site.
The Java Virtual Machine Specification (which is responsible for defining what the bytecode looks like) puts no constraints related to keywords on the names of things.
Those constraints only exist on the Java Language level. The bytecode you used does not decompile into valid Java, because it uses names that are not valid in the Java language, but that are valid to the JVM.
A similar logic applies to the two getViewName methods that differ only in return type: This is allowed (and works perfectly fine) in bytecode by the JVM spec, but the Java Language specification forbids it.
The most common reason for bytecode like this is Java code that was compiled to bytecode and then obfuscated.
Another possible reason is that the code was not originally produced by compiling Java code, but another language that targets the JVM. This is rather unlikely in this case, since no one would name a variable do when it's supposed to hold the view name.