Question:

I have an obfuscated jar which is part of a deployed application in Tomcat on my machine. The jar consists of some weird code with same variable names. I used jshrink in order to decompile the code.

static private org.apache.commons.logging.Log a; private org.springframework.context.MessageSource a; private org.springframework.context.support.MessageSourceAccessor a; static private LicenseBean a; static private ThreadLocal a; private javax.servlet.ServletContext a; private String a; public LicenseBean() { a = null; a = null; a = this; }

Is it an issue with decompilation process? My question is how does JVM handle this if the decompilation process is correct?

Some obfuscators use control symbols for making identifiers harder to read. This concerns especially situations where code is printed to a console which interprets these symbols instead of printing their escaped icon. It could therefore be that these names are actually obfuscated as for example:

U+0061 U+200B * n

where U+0061 represents a and U+200B is the zero-length width symbol which is entailed an incremented amount of times for each of the n identifiers. In a normal editor, all identifiers would then displayed as a.

In general, Java byte code does not allow duplicate identifiers for fields of a class but it allows identifiers which are not normal legal in Java source code. If your code runs, the Unicode theory is the most likely explanation. Maybe your decompiler also misses these characters or and they are not even put into the source code. Try to read the byte code (javap output) of the above class file with an editor which displays <em>invisible Unicode</em> to verify this theory.

That code is not valid Java code, it is possible that jshrink didn't manage to decompile the code correctly, the usual decompiler behavior is based on a <em>best-effort</em> technique.

Try to decompile it using <a href="http://www.benf.org/other/cfr/" rel="nofollow">CFR</a>, it's a wonderful Java decompiler that usually produces valid code.