+1 That's clearly decompiled code
What he said.
"PolicyNodeImpl policynodeimpl, Boolean flag, Boolean flag1, Set set, Set set1, String s ..."
That's automated variable naming based on type, output from a decompiler filling in information lost during the compilation to bytecode. And they didn't even bother to clean it up.
You can also see where the decompiler has added curlies around some conditionals because it doesn't (and almost certainly can't*) know that they're one liners.
On the extremely slim chance that the Android code was generated by a human being, they should be beaten with a cluestick until the fail comes out for using variable names like flag1.
Sorry fandroids, but given that code sample, Oracle has a case. It's got big greasy decompiler fingerprints all over it. It's about as far from a clean room implementation as you're going to get.
*because when it sees bytecode if_* ops, it only knows that the code is going to branch, it doesn't know how many instructions it will find when it reads the bytecode at the branch offsets. I say "almost" certainly, because you could probably avoid this by doing a bit of read-ahead in your bytecode decompiler and counting the output instructions for each branch, but why bother ?