General Modifier checks for resolved declarations

[JulianHahn96]

Add general modifier checks for resolved declarations and fix various impicit modifier checks for java parser nodes.

[jlerbsc]

This PR impacts too many files to validate it effectively. Furthermore, the hasModifier method is already implemented, notably all those which implement the NodeWithModifiers interface. It should be easy to invoke this method because all resolved declarations implement the AssociableToAST interface which provides access to the AST node.

[JulianHahn96]

Yea it is, if you know what you are working with is source code that was parsed. But what should i do when i have a mix of javassist and java parser implementations of resolved declarations. There is no generic way of checking if any resolved declaration (a class, field or method) has a specific modifier, without knowing the concrete type or implementation. Or am i missing something?
And some implementations of the isStatic, isAbstract ... methods is just inconsistent between the javassist / reflection and the javaparser implementations.

Also how is it possible to implement something new, when the only answer is that it affects to many files, even tho in most of the files its just one new method.

[jlerbsc]

Yea it is, if you know what you are working with is source code that was parsed. But what should i do when i have a mix of javassist and java parser implementations of resolved declarations. There is no generic way of checking if any resolved declaration (a class, field or method) has a specific modifier, without knowing the concrete type or implementation.

Indeed, the toAst method is only available when we have access to the AST, therefore when the code has been parsed.

[jlerbsc]

And some implementations of the isStatic, isAbstract ... methods is just inconsistent between the javassist / reflection and the javaparser implementations.

In this case you might be able to point out in a specific PR what seems inconsistent to you.

[jlerbsc]

Also how is it possible to implement something new, when the only answer is that it affects to many files, even tho in most of the files its just one new method.

Why is this PR complicated to reread? Because it affects multiple files and there are multiple patch versions on some source files. It is therefore difficult in these conditions to have a simplified overview of the code that has been modified.

However, there are some interesting ideas that are not related to each other. So you could propose what is currently not consistent in one PR and propose the hasModifier method for resolved declarations in another PR.

On the other hand I think that the ModifierUtils class is certainly not useful especially since it mixes a solution based on Javassist and on introspection and the first method does not seem to me to bring added value compared to the existing solution .

I remind you that the time we devote to this project is taken directly from our leisure time or the time we could devote to our family. A little understanding on your part wouldn't go amiss.