benf.org :  other :  cfr :  faq

CFR - FAQ

This FAQ is missing information! Why?

I guess the question hasn't been asked! Mail me...

What does CFR mean?

Class File Reader. Nothing more interesting than that. I'm just rubbish with names.

There are so many options! You don't expect me to actually use them, do you?

Not really. CFR has multiple fallback passes where it enables different sets of fallback options, but for full disclosure, I've exposed all of these options on the command line. This means that you should never have to set an option - CFR will do it for you if necessary!

..... with the exception of flags which rename members. If these are neccessary, CFR will emit a comment suggesting you use them. I don't do it automatically, as it breaks reflective use of decompiled code.

Does it use any reflection etc?

No. I've written everything from scratch - partly because I'm doing this for fun, partly because I'm half tempted to port it to C++ at some point, so I don't want dependencies.

Where's the source?

Where's the test set?

On Bitbucket, here

Is there a mailing list?

No. If you want to get on one, mail me ;)

Is there a bugtraq?

*shame* I've been disorganised here, not got around to it yet..... any minute now...

Why isn't it on MavenCentralRepos?

Because every time I look at the work involved in pushing an artifact, I lose the will to live. I know maven's a super cool thing, but this article sums up my feelings here. TBray - Discouraged Developer.

What's the license?

Read me

Why?

For fun. That's the entire reason. I moved from a C++ job to a Java job, and writing a decompiler seemed like a good way to learn the java ecosystem... - there's a lot of published material out there on coin, etc, but not a vast amount on what's going on with the bytecode...

Your decompiler sucks at XYZ...

Yup, probably. There are always going to be edge cases. Feel free to send me examples, IF THE INTELLECTUAL PROPERTY BELONGS TO YOU.

You could get a lot better information if you trusted the LocalVariableTypeTable.

Absolutely. But I'm imagining a world where people lie, when they can. JVMs don't verify signature attributes - they can lie. Local type tables can lie. And I want to see what sort of a decompiler I can get if I don't trust information I can't verify..... (though I do use LocalVariableNameTable for hints. Hey, I'm weak.)

I still see some synthetic methods in the output - why don't you just hide them?!

Paranoia. It's possible (and legal) to mark every method in your codebase synthetic, if you're feeling mean. CFR will only remove synthetic methods when it's validated what they're doing, (i.e. friend accessors)

I see messages like Failed to find class java/util/stream/Stream.class

The JRE used when decompiling doesn't have to support the needs of the class file. If you're decompiling Java 8 files using a Java 6 JRE, then the support classes will be unavailable to CFR. They're not strictly necessary, however they will improve the quality of the decompilation.

Why not just topologically sort basic blocks all the time?

I find if the code hasn't been obfuscated (or more accurately, been madly rebuilt with dex2jar) then the bytecode straight out of javac is in a more sensible ordering than I get after a topsort. As such, I only apply the topsort if CFR can't produce sensible code off the basic ordering. (and ends up creating code that seems to contain Duff's device... :P )

Other decompilers?

awwww ;)

There are tonnes, but not many which support modern Java features.

The entire CFR website looks like it was put together in vi - why not move into the 90s, at least?

It was. Consider it my backlash against the form over function that seems to exist everywhere! (And hey, at least you don't need javascript enabled.)

.... mail me (lee@benf.org) if I've missed something ;)
Last updated 01/2015