@sivacoder @mkruber
I'd say the first two are fairly closely related and are easy to address. It involves extending the code of getXPAPI here.

Currently, it takes a look at arg and immediately casts it to a symbol, which it then matches against a symbol/enum name. We need to add two additional tests:

a) If arg is a string literal (e.g. if com.sun.source.tree.LiteralTree is the type, I believe) then match it's value directly against xpFlagName
b) If argSym (the symbol) is a field, then we need to check first if it's a constant (static final), and if so compare its value against xpFlagName (not sure if there is an easy way to get the declaration given a symbol or if you'd need to build a map during matchVariable, matchClass or some other matcher)

Fixing (3) will require adding info to the config format, namely changing from "list of methods" to "list of method, arg# pair" (see #6). Right now I am not sure how involved that will be.

Finally, (4) is a bit more involved, it might be a limited instance of deep clean, which is not currently part of PiranhaJava.

I'd say (1)/(a) above is good first PR.

For b), I think there should be some way to get the Tree based on the Symbol. NullAway does it like this:

https://github.com/uber/NullAway/blob/master/nullaway/src/main/java/com/uber/nullaway/NullAway.java#L628

Then from the right-hand side of the declaration, you could use code like this to get the constant value:

https://github.com/google/error-prone/blob/master/check_api/src/main/java/com/google/errorprone/util/ASTHelpers.java#L1011

At least I think that should work.

@manishamishra2715 - This ticket is to discuss new extensions support. Is it fair for you to create a separate ticket and discuss this issue rather than polluting this one? It's easier to report, trace, fix, and for other who will face the same issue to search and find.

Hopefully, it makes sense.

@lazaroclapp @mkruber @msridhar - For #1 and #2, we have raised this PR - #30

Please review

@mkruber @lazaroclapp @msridhar - Can you help with the next steps for #3 and #4 extensions?

I assume you are referring to 3 and 4 above. The links pointed in the comment refer to different issues.

For issue 3, I propose deleting the checks for argument count here. This still assumes that the first argument is the flag name. If you want to extend this further where flag name can be at any index, you will have to update the piranha.properties file and update the checks for flag name comparison to also include the index mentioned in the properties file.

For issue 4, there are many ways of handling it. It will require two passes. In the first pass, remember all assignments where the RHS contains the flag API expression and the result of the RHS. In the second pass, delete these assignment expressions and where ever the fully qualified name of the LHS occurs (for local variables, maybe you can use the Class name + methodname + variable name) to determine the FQN) and evaluate expressions. This change will be involved -- so propose that this be handled in a separate PR. You can take a look at the deepclean pass of PiranhaSwift for the general strategy.