Add classes().that().areAnyClass(...) to syntax

[moboa]

Lost push access to toasttab fork in #167 so created this PR.

[codecholeric]

Sorry for the long break, I had a crazy month at work. I thought about this, and I think the only way it makes sense to me, is to treat anonymous and named inner classes the same. Because conceptually they are almost the same, so I don't see why the rule should be satisfied as long as my inner class has no name and suddenly fail just because I give it a name. This seems to be more driven by a specific use case, that excluding anonymous classes makes the feature really less useful.
I'll try to make a couple of changes in this direction 😃

[moboa]

Would creating 3 separate functions areAnyClass, areInnerClassesOf and areAnyOrInnerClassOf be a better solution?

[cakeface]

I like the multiple function approach.

I get that the behavior is weird between named and un-named inner classes.

In Java 8 and forward lambdas are everywhere. People use them for filtering streams. They use them unknowingly sometimes, or at least the implementation detail of an anonymous class is unknown. I don't like that this implementation detail is leaking up into the archunit tests. But at the same time, those lambdas are another class so I get why it needs to be treated separately if you actually did care about creating rules where inner classes are different.

[ghost]

DeepCode analyzed this pull request.
There is 1 new info report.

Click to see more details.

[codecholeric]

I've added some changes. I would not distinguish here, because we already have the exact case by classes()...should().be(Foo.class), if you want to match just one class.
I think it's okay to count a class and all inner classes as one, because logically this is a group, so I see the use case that you might say "it should be contained within some class, be it directly, in some lambda, anonymous inner class, named inner class or whatever".
I can see myself refactoring, creating new anonymous or inner classes and from the point of my rule this shouldn't matter. Because if I create several nested classes, that is just an implementation detail (okay, if those are public you could argue about it, but it still somehow belongs to the outer class or it wouldn't be an inner class 😉)

[codecholeric]

Could you check this out if it would match your use case? I don't think it provides any extensive value to exclude named classes as I said.

[moboa]

This seems to pretty closely match our use case. Matching against a class and all its inner classes is the best way to go, in my opinion. Could you confirm @cakeface ?

[codecholeric]

If you don't have any objections, I'll merge this 😉

[moboa]

Please go ahead!