[Solved] Why do I get a $ sign in decompiled java classes full with errors? [closed]

Question

What you’re seeing is Java’s internal representation of the anonymous inner classes. Java implements these by creating classes with generated names, which — like all inner classes — are based on adding $ and a suffix to the name of the containing class. (There are some other changes made to support the inner class’s ability to refer back to its containing context.)

Apparently whichever decompiler you used didn’t attempt to reverse that rewrite. That isn’t very surprising; I haven’t yet seen one that did handle this situation correctly, and some don’t even handle constructors correctly (leaving them with their generated function name, <init>(). Unfortunately, compilation of any language always involves discarding some information, and decompilation will generally not be able to reconstruct the original code — and may not be able to reconstruct syntactically correct code, since the object code is generally allowed to do things that the source language can’t. You should expect to have to manually edit the decompiler’s output.

If you’re just trying to get the code running, you may be able to do so by replacing the generated class and function names with ones which are acceptable to Java syntax (as opposed to the less-restricted JRE). If you actually want to turn the generated classes back into anonymous inner classes, you’ll have to do that manually as well.

Or you can try to find a decompiler which is better at handling this case and isn’t worse at handling other cases. Good luck; if you do find one, let us know.

(The real answer here is to be extremely careful not to lose your source code. The best thing that can be said about decompilers is that they’re usually better than trying to directly read the instructions.)

Accepted Answer

What you’re seeing is Java’s internal representation of the anonymous inner classes. Java implements these by creating classes with generated names, which — like all inner classes — are based on adding $ and a suffix to the name of the containing class. (There are some other changes made to support the inner class’s ability to refer back to its containing context.)

Apparently whichever decompiler you used didn’t attempt to reverse that rewrite. That isn’t very surprising; I haven’t yet seen one that did handle this situation correctly, and some don’t even handle constructors correctly (leaving them with their generated function name, <init>(). Unfortunately, compilation of any language always involves discarding some information, and decompilation will generally not be able to reconstruct the original code — and may not be able to reconstruct syntactically correct code, since the object code is generally allowed to do things that the source language can’t. You should expect to have to manually edit the decompiler’s output.

If you’re just trying to get the code running, you may be able to do so by replacing the generated class and function names with ones which are acceptable to Java syntax (as opposed to the less-restricted JRE). If you actually want to turn the generated classes back into anonymous inner classes, you’ll have to do that manually as well.

Or you can try to find a decompiler which is better at handling this case and isn’t worse at handling other cases. Good luck; if you do find one, let us know.

(The real answer here is to be extremely careful not to lose your source code. The best thing that can be said about decompilers is that they’re usually better than trying to directly read the instructions.)