Add AST Functionality

[MarkusPaulsen]

First implementation of the AST-checker, which can search through Java-Files for unwanted:

• Loop statements
• Conditional statements
• Function-based statements
• Local class statements
• Exception handling statememts
• Synchronisation statements

[MaisiKoleni]

I don't know if this was intended for review already, but the comments will probably help anyway.

The overall direction where this is going is good, and most of the API looks as well.

Just some use cases are still unclear to me, mostly this has to do with the different types.

I think some classes can be merged, and the code might get more compact, the types may even fit in a single class with nested static classes. This might also reduce the number of sub-packages to zero.

Please adjust the changes such that all tests and code style checks still work.

Don't be scared by the number of comments, I just noted everything that came to my mind and could be improved. I hope it helps to have all that feedback as early as possible.

[MaisiKoleni]

I realize now, that apart from assertThatFile(Path) and assertThatDirectory(Path) another solution might be, as discussed some weeks ago:

• assertThat(Path).asFile().hasNo(...) and assertThat(Path).asDirectory().hasNo(...)
• assertThat(Path).withConfiguration(AstAssertConfiguration).hasNo(...)

or some similar APIs.
The fluent API and the configuration+builder have the advantage that they are extensible without combinatorial explosion.
Here, it would be easy to add using(Version.JAVA_17) or similar.

The config+builder has the advantage that they can be specified once and then used for every assertion.
But then again, how many of such assertThat statements do we expect a project to have? I would assume that this is 0 or 1 in 99% of the cases, as chaining is always possible.

We can also consider if varargs is a useful addition to hasNo(...).

Please tell me what you think about the suggestions; it would be very interesting to hear of other use cases than students should not be allowed to use any loops. Because this is larger in scope than that, it would be good to know what users might need and expect.

Could you ask the users (exercise creators at TUM for EIST/PSE/PGdP/...) what would be helpful? Maybe @JohannesStoehr has some suggestions as well, he knows both Ares and many instructors fairly well.

[MaisiKoleni]

Sadly had no time to do a full review, but I hope it helps anyway.

Huge Thanks to @Strohgelaender for reviewing! Much appreciated 👍

[MaisiKoleni]

So I had a more in-depth look at the code now and changed a few small things myself, have a look if you agree. I also added the @API tags as far as I understand, check if they are correct.

I think the changes for the most part will get more detailed now, as the approach in general is good, I think. Only some questionable aspects remain:

1. The defaults for the assertion could become a problem, maybe we could make them explicit.
2. The assertion is created new every time we configure it, this differs from the default AssertJ behavior. Maybe we should match that, although I like immutable objects.
3. The way the files are located, I think this is still too much additional usage weight if we already have the configuration resolving in the class name scanner.
4. The requirements, what the user's aims are, are still unclear to me for many node type enum values.

[MaisiKoleni]

This looks better and better, and I am now happy with almost everything, the only part that stands out is the assertion and how the paths are handled. If we sort out how to do that cleanly, we can merge it. If you like, we can also have a quick talk about it when I have time. I think extracting the source folder search from the ClassNameScanner would yield clean code without too much effort.

[MaisiKoleni]

Looks good to me now, thank you @MarkusPaulsen for repeatedly improving the code and being patient.

This should enable us to release version 1.12.0 after a few dependency updates (the open PRs).